Re: Shell completion on w32 uses "/" instead of "\"

[Eli Zaretskii]

> Date: Tue, 19 Dec 2006 09:16:42 +0100
> From: Lennart Borgman <address@hidden>
> CC:  address@hidden
> X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS 
>       autolearn=no version=3.0.4
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 19 Dec 2006 01:23:18 +0100
> >> From: Lennart Borgman <address@hidden>
> >> Cc: address@hidden
> >>
> >> I believe the problem is in comint-dynamic-complete-as-filename. The let 
> >> variable dirsuffix has a hardcoded "/". Maybe a fix could look like this
> >>
> >>      (dirsuffix (cond ((not comint-completion-addsuffix)
> >>                "")
> >>               ((not (consp comint-completion-addsuffix))
> >>                            (if (w32-shell-dos-semantics)
> >>                                "\\"
> >>                              "/"))
> >>
> >> but I am not sure at all. Even if this is correct however I think that 
> >> shell-file-name and explicit-shell-file-name must be made buffer local 
> >> in the interactive shell buffers. (And did I not mention before that 
> >> w32-shell-dos-semantics needs to test explicit-shell-file-name too?)
> >>     
> >
> > I really don't think we should try to open this can of worms now.
> > Let's wait until after the release.
> >   
> 
> As I said this is clearly a bug. Could you please comment on my 
> tentative solution? What do you think can go wrong?
> 
> My solution also includes adding to shell-mode two lines that makes 
> shell-file-name and explicit-shell-file-name buffer local:
> 
>   (make-local-variable 'list-buffers-directory)
>   (make-local-variable 'explicit-shell-file-name)
>   (make-local-variable 'shell-file-name)
> 
> I believe steps similar to those are necessary to a solution. This must 
> be done in one form or the other. It might not be sufficient and it 
> might introduce other similar bugs, but that is in my opinion not enough 
> to avoid them, not even now.
> 
> 
> I will add the above to my patched version, as usual.
>