|
From: | Lennart Borgman |
Subject: | Re: Shell completion on w32 uses "/" instead of "\" |
Date: | Wed, 20 Dec 2006 22:13:27 +0100 |
User-agent: | Thunderbird 1.5.0.9 (Windows/20061207) |
Eli Zaretskii wrote:
It autocompletes in the shell buffer with "\" if the shell used has w32-shell-dos-semantics. When do you not want this?Personally, I _never_ want to see backslashes, even when I work in CMD. It makes me saner, since I happen to work simultaneously on Unix and on Windows. I'm sure I'm not the only one.
I see ;-)
I doubt it is the correct place. The semantics of the shell is not sufficient as far as I can see to know enough about the program arguments. You also need to know the semantics used by the program in interpreting the arguments. If you do something like thiscmdproxy is IMO the _only_ level where this should be done, because we are talking about rewriting commands typed by the user, to make them palatable to the Windows shells -- _precisely_ the job for which cmdproxy was invented. Doing this on any other level would need introduction of too much knowledge of the shell semantics into places which don't want to know about that. By contrast, cmdproxy already knows about shell semantics, and is meant to deal with that.
C:\> myprog "some/path/perhaps"how could cmdproxy know if the slashes should be changed to backslashes? If it really is a path then they should, but perhaps it is information with another semantics. It might be a string which has nothing to do with filenames.
On the other hand Emacs has this knowledge since you user wanted file completion with TAB. It would be very complicated to try to give this information to cmdproxy IMO.
[Prev in Thread] | Current Thread | [Next in Thread] |