Re: Shell completion on w32 uses "/" instead of "\"
The main reason we support Emacs on MS Windows is that there are people who want to use it on Windows, and are willing to maintain that port. Windows support is not a priority for GNU. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Nick Roberts wrote: >...And unfortunately it is a bug on w32, that in one sense is a > platform where we want to attract people because it makes it easier to > switch to GNU/Linux later. Is that really the aim of Emacs on Windows? Presumably it could also make GNU/Linux users feel more comfortable on Windows and they could switch the other way. I do not know if that is the aim, but at least I consider it one of the goals. If we would assume that feeling comfortable on the other system was equal then it woudl be much more people switching from Windows to GNU/Linux just because there are more people using Windows. Now if Emacs does not work well on Windows people on Windows will never be comfortable with Emacs. Unless they switch to GNU/Linux without beeing comfortable with Emacs of course, but then Emacs have not helped them feeling at home on GNU/Linux. (And they may instead look for Windows tools on GNU/Linux.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
>...And unfortunately it is a bug on w32, that in one sense is a > platform where we want to attract people because it makes it easier to > switch to GNU/Linux later. Is that really the aim of Emacs on Windows? Presumably it could also make GNU/Linux users feel more comfortable on Windows and they could switch the other way. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Kevin Gallagher wrote: I just got finished reading through this thread and, I must say, I'm a bit puzzled by its continued limited focus to the question of "To backward slash or not to backward slash?" in an Emacs shell window running cmd.exe (or equivalent) on w32. Instead, this discussion would benefit greatly by taking several steps backward and looking at the overall command line behavior in cmd.exe, with the goal of devising an overall strategy for Emacs. There is a need to determine to what extent should Emacs support cmd.exe syntax and behavior in its support for running cmd.exe in a shell window. So, let's take a look at some of the cmd.exe input syntax. Some it is is rather strange, by the way, and some of it is quite unexpected. For example, sometimes delimiters are needed between a command and the first parameter, but other times they are not needed. For example, ">cd ..", with a space delimiter, and ">cd..", without a space delimiter are both accepted by the parser as valid. Press return and both are move the current directory up one level. However, enter ">cd." followed by a and the bell rings, even though ">cd.." is valid. Suppose the current directory contains 5 directory entries called "aa", "bb", "cc", "dd one", and "eleven ee". Enter "cd" at prompt and then press , the bell rings. Enter "cd", followed by a space, and then press , the first directory, in the current directory, is displayed next to "cd" like this: cd aa Press again and the line is re-written as cd bb again and we have cd cc again, cd "dd one" again, cd "eleven ee" and again, cd aa cycling back through the list. It makes no attempt to continue command completion into a subdirectory. To make this happen, the user must enter a backward slash after the directory name and then press . Yes, you are right. This behaviour is not mirrored at all in Emacs shell. Now, here's a surprise! Suppose "aa" has a subdirectory "xy" and "xy" ... I do not think cases outside of what cd is specified to do in cmd.exe are important. Nevertheless, if, instead, I wrap the parameter input to "dir" in double quotes like this E:\kg\aa>dir "xy/zz" then cmd.exe accepts this and generates a directory listing of "E:\kg\aa\xy\zz"! This is not specified to work. I found some surprises there too before. This leads me to suggest that, instead of "To backward slash or not to backward slash?", perhaps the question should be "To double quote or not to double quote?" Of course, we have to remember that this applies to "dir" but not "cd", though "cd" will accept the double quotes. I haven't tested this syntax with other commands, such as "copy", "xcopy", etc. But, hopefully, you get the point: cmd.exe has a very strange input syntax parser with unexpected and inconsistent behavior in what it is willing to accept as valid input syntax. The behavior of cmd.exe, when is pressed, is quite different from what Emacs attempts to do for the user. Technically, one could argue that, for cmd.exe, Emacs should append nothing to a directory completed by . It would make a very bad impression I think. I think I've made the case that the support Emacs should provide when running cmd.exe in a shell window is complicated and very messy; too messy to deal with now. I vote we let it be until after Emacs 22 is released. Then we will just leave that bug there for a long period. I think that a combination of long periods between releases and leaving bugs is not so very good. And unfortunately it is a bug on w32, that in one sense is a platform where we want to attract people because it makes it easier to switch to GNU/Linux later. BTW, I found the directory sync in shell is not working so good for me. Is there something that prevents that comint sends a pwd and reads the result before trying to TAB file name expansion? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
I just got finished reading through this thread and, I must say, I'm a bit puzzled by its continued limited focus to the question of "To backward slash or not to backward slash?" in an Emacs shell window running cmd.exe (or equivalent) on w32. Instead, this discussion would benefit greatly by taking several steps backward and looking at the overall command line behavior in cmd.exe, with the goal of devising an overall strategy for Emacs. There is a need to determine to what extent should Emacs support cmd.exe syntax and behavior in its support for running cmd.exe in a shell window. So, let's take a look at some of the cmd.exe input syntax. Some it is is rather strange, by the way, and some of it is quite unexpected. For example, sometimes delimiters are needed between a command and the first parameter, but other times they are not needed. For example, ">cd ..", with a space delimiter, and ">cd..", without a space delimiter are both accepted by the parser as valid. Press return and both are move the current directory up one level. However, enter ">cd." followed by a and the bell rings, even though ">cd.." is valid. Suppose the current directory contains 5 directory entries called "aa", "bb", "cc", "dd one", and "eleven ee". Enter "cd" at prompt and then press , the bell rings. Enter "cd", followed by a space, and then press , the first directory, in the current directory, is displayed next to "cd" like this: cd aa Press again and the line is re-written as cd bb again and we have cd cc again, cd "dd one" again, cd "eleven ee" and again, cd aa cycling back through the list. It makes no attempt to continue command completion into a subdirectory. To make this happen, the user must enter a backward slash after the directory name and then press . Now, here's a surprise! Suppose "aa" has a subdirectory "xy" and "xy" has a subdirectory "zz". Suppose the current directory is "kg" on drive E. The the prompt looks like this: E:\kg> Suppose I enter the cd command like this: E:\kg>cd aa/xy/zz (Note I am using forward slashes.) When Enter is pressed, you might think cmd.exe would report an error. It does not. It changes the directory AS IF backward slashes had been entered! The prompt returned is E:\kg\aa\xy\zz> This behavior is quite strange. Now let's look at the "dir" command. We already know that E:\kg\aa>dir xy/zz yields Invalid switch - "zz" but not always! In some circumstances, it will yield Parameter format not correct - "zz" Nevertheless, if, instead, I wrap the parameter input to "dir" in double quotes like this E:\kg\aa>dir "xy/zz" then cmd.exe accepts this and generates a directory listing of "E:\kg\aa\xy\zz"! This leads me to suggest that, instead of "To backward slash or not to backward slash?", perhaps the question should be "To double quote or not to double quote?" Of course, we have to remember that this applies to "dir" but not "cd", though "cd" will accept the double quotes. I haven't tested this syntax with other commands, such as "copy", "xcopy", etc. But, hopefully, you get the point: cmd.exe has a very strange input syntax parser with unexpected and inconsistent behavior in what it is willing to accept as valid input syntax. The behavior of cmd.exe, when is pressed, is quite different from what Emacs attempts to do for the user. Technically, one could argue that, for cmd.exe, Emacs should append nothing to a directory completed by . I think I've made the case that the support Emacs should provide when running cmd.exe in a shell window is complicated and very messy; too messy to deal with now. I vote we let it be until after Emacs 22 is released. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Lennart Borgman wrote: With MSYS I get some very strange problems: MSYS /c > dir Pr<*> MSYS /c > dir Pr] The above seems to be trouble because I tested different keyboards in XP. I forgot to turn the keyboard switching characters off in XP. If I try to enter * (see above) I get a ]. Quite strange. It only happens inside Emacs. MSYS /c > dir Pr In minibuffer: Partially completed MSYS /c > dir (the listing does not contain Program Files, but it should as far as I can see) MSYS /c > pwd /c I have seen this trouble for the shell command both using MSYS and Cygwin as inferior shells. Seems to be a problem with sync of Emacs view of the directory and the shells dito. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Chris Moore wrote: Personally I always found that all the spaces in directory names on a Windows box breaks shell-mode completion anyway. It's been a while since I used Windows, but doesn't it act something like this: cd /Docum cd /Documents and Settings/chr no such file or directory: /Settings/ Actually it works with cmd/cmdproxy shell (with that little change we are discussing, but it is broken with both MSYS and Cygwin as inferior shells. With Cygwin I get the behaviour above. With MSYS I get some very strange problems: MSYS /c > dir Pr<*> MSYS /c > dir Pr] If I try to enter * (see above) I get a ]. Quite strange. It only happens inside Emacs. MSYS /c > dir Pr In minibuffer: Partially completed MSYS /c > dir (the listing does not contain Program Files, but it should as far as I can see) MSYS /c > pwd /c ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii <[EMAIL PROTECTED]> writes: > You can try mocking my preferences till Kingdom Come, but they are > still _my_ preferences, and I didn't impose them on anyone else. I'm not mocking your preferences; sorry that you thought I was. I didn't realise you were saying it should be a preference - I thought you were arguing that the way it currently is in Emacs is acceptable, ie. hitting tab completes directory names with a /, even when you're on Windows. > Anyway, I guess you've never used keyboard enhancement programs that > make such rewrites seamlessly and transparently. No, I've not. > For people who routinely work on both Windows and Unix, this is a > sanity-savior. Personally I always found that all the spaces in directory names on a Windows box breaks shell-mode completion anyway. It's been a while since I used Windows, but doesn't it act something like this: cd /Docum cd /Documents and Settings/chr no such file or directory: /Settings/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Cc: Lennart Borgman <[EMAIL PROTECTED]>, > emacs-pretest-bug@gnu.org > From: Chris Moore <[EMAIL PROTECTED]> > Date: Fri, 22 Dec 2006 13:52:19 +0100 > > Eli Zaretskii <[EMAIL PROTECTED]> writes: > > > 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. > > Compare: > > "Personally, I never want to see those funny accent characters over the > letters when I type in Czech. I work simultaneously in English and > Czech, and the accents confuse me. Let cmdproxy insert the accents > for me". You can try mocking my preferences till Kingdom Come, but they are still _my_ preferences, and I didn't impose them on anyone else. Arguing about personal preferences, like about taste, is futile and counter-productive. I clearly wrote that the character used in completion should be a *user option*. So if you want, you can set that character to the Czech accent, it's fine with me. > If cmdproxy is changed to re-write dir commands, you'll be breaking > things for people who expect dir to work like dir works in a regular > cmd.exe window Read my lips: it should be a user option. No one will have anything broken if they don't want this. Anyway, I guess you've never used keyboard enhancement programs that make such rewrites seamlessly and transparently. For people who routinely work on both Windows and Unix, this is a sanity-savior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii <[EMAIL PROTECTED]> writes: > 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. Compare: "Personally, I never want to see those funny accent characters over the letters when I type in Czech. I work simultaneously in English and Czech, and the accents confuse me. Let cmdproxy insert the accents for me". When you're typing "dir" commands, backslashes are for separating directories and forward slashes are for introducing options - this will list \p page by page: dir \p/p If cmdproxy is changed to re-write dir commands, you'll be breaking things for people who expect dir to work like dir works in a regular cmd.exe window, just like I'd be breaking Czech support for native Czech speakers with my proposed language mangling. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: Why not set (buffer-locally) a different variable (such as "shell-uses-backslashes") when starting the inferior process? That seems more inline with what we usually do, rather than make a global variable buffer-local because we later (re)compute something that depends on the value the global variable had when the buffer was created. Because we must check that value with for example w32-shell-dos-semantics. Huh? Which code uses w32-shell-dos-semantics? For example the code for file name completion should IMO use this. But could there not be other situations too? That is why I argue to have w32-shell-dos-semantics check a buffer local variable. I don't understand. I expected to use w32-shell-dos-semantics to set shell-uses-backslashes and then to use shell-uses-backslashes to decide whether completion should use / or \. Yes, it is essentially the same thing as I tried to say in this case. Sorry if I was unclear. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
>>> Why not set (buffer-locally) a different variable (such as >>> "shell-uses-backslashes") when starting the inferior process? That seems >>> more inline with what we usually do, rather than make a global variable >>> buffer-local because we later (re)compute something that depends on the >>> value the global variable had when the buffer was created. >> Because we must check that value with for example w32-shell-dos-semantics. Huh? Which code uses w32-shell-dos-semantics? > Eh, that was a bad argument from me. (My brain just told me that it would > not exist in w32-shell-dos-semantics, but that is wrong. In elisp.) > Yes, we could do it the way you propose and check for the existence of this > variable in w32-shell-dos-semantics. If it does not exist then we have an > error (because there can only be a shell in a buffer and then this variable > should be set). I think that is a clear advantage. > But maybe it is better to still use the value of shell-file-name so the > semantics for the backslash choice still is in w32-shell-dos-semantics? > I think so. I don't understand. I expected to use w32-shell-dos-semantics to set shell-uses-backslashes and then to use shell-uses-backslashes to decide whether completion should use / or \. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
From: Jason Rumney <[EMAIL PROTECTED]> Date: Thursday, December 21, 2006 12:19 pm Subject: Re: Shell completion on w32 uses "/" instead of "\" > Eli Zaretskii wrote: > > cmdproxy is IMO the _only_ level where this should be done > > I think it is wrong to do this in cmdproxy, as cmdproxy has no > knowledge > about what is a filename, and what is a literal string that must > be > passed to the command untouched. > The right place to do this is when completing file names, since we > know > then that we are dealing with a file name. We should never change > what > the user has manually typed. Yepp. That is what I wrote too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: cmdproxy is IMO the _only_ level where this should be done I think it is wrong to do this in cmdproxy, as cmdproxy has no knowledge about what is a filename, and what is a literal string that must be passed to the command untouched. The right place to do this is when completing file names, since we know then that we are dealing with a file name. We should never change what the user has manually typed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: Date: Wed, 20 Dec 2006 22:13:27 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> CC: emacs-pretest-bug@gnu.org cmdproxy 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. 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 this C:\> myprog "some/path/perhaps" how could cmdproxy know if the slashes should be changed to backslashes? The case you were talking about originally was with the DIR command. That command is a CMD built-in, so cmdproxy can know everything about it. It was just an example, not the problem itself of course. The file name completion with TAB works for any program in a shell window. I am sure you not that. So the problem is there and I can not see the relevance in your argument above. Can you explain to me what you mean? Why is it relevant for the problem I described? 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. Again, this is a totally different issue, it has nothing at all to do with completion! I could type the full command "dir foo/bar", and it would still fail, even though completion is not involved. Please be more relevant! Could you please rethink your arguments? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Wed, 20 Dec 2006 22:13:27 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: emacs-pretest-bug@gnu.org > > > cmdproxy 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. > > > 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 this > > C:\> myprog "some/path/perhaps" > > how could cmdproxy know if the slashes should be changed to backslashes? The case you were talking about originally was with the DIR command. That command is a CMD built-in, so cmdproxy can know everything about it. > 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. Again, this is a totally different issue, it has nothing at all to do with completion! I could type the full command "dir foo/bar", and it would still fail, even though completion is not involved. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Lennart Borgman wrote: Why not set (buffer-locally) a different variable (such as "shell-uses-backslashes") when starting the inferior process? That seems more inline with what we usually do, rather than make a global variable buffer-local because we later (re)compute something that depends on the value the global variable had when the buffer was created. Because we must check that value with for example w32-shell-dos-semantics. Eh, that was a bad argument from me. (My brain just told me that it would not exist in w32-shell-dos-semantics, but that is wrong. In elisp.) Yes, we could do it the way you propose and check for the existence of this variable in w32-shell-dos-semantics. If it does not exist then we have an error (because there can only be a shell in a buffer and then this variable should be set). I think that is a clear advantage. But maybe it is better to still use the value of shell-file-name so the semantics for the backslash choice still is in w32-shell-dos-semantics? I think so. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: The user might be testing new configurations for example and thereby changing shell-file-name (which now has only a global value). Since w32 is not that simple when it comes to shell that is a very likely situation, at least when the user has learned a bit more about emacs. But the user isn't expected to keep doing that indefinitely, right? Actually on w32 it seems so ... ;-) Another possibility is that you want to use Cygwin or MSYS for interactive inferior shells, but use the gnuwin32 tools with cmdproxy otherwise. That's OK: we already have the distinction betwen shell-file-name and explicit-shell-file-name for that. So this shouldn't cause any change to the global variables. Nearly. Of course there is no problem unless you changes shell-file-name, but if you do there is definitively a problem today. I think a buffer local value is needed, but as I pointed out in another message another name is needed for the buffer local value (a make-variable-buffer-local var). Why not set (buffer-locally) a different variable (such as "shell-uses-backslashes") when starting the inferior process? That seems more inline with what we usually do, rather than make a global variable buffer-local because we later (re)compute something that depends on the value the global variable had when the buffer was created. Because we must check that value with for example w32-shell-dos-semantics. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> The user might be testing new configurations for example and thereby > changing shell-file-name (which now has only a global value). Since w32 is > not that simple when it comes to shell that is a very likely situation, at > least when the user has learned a bit more about emacs. But the user isn't expected to keep doing that indefinitely, right? > Another possibility is that you want to use Cygwin or MSYS for interactive > inferior shells, but use the gnuwin32 tools with cmdproxy otherwise. That's OK: we already have the distinction betwen shell-file-name and explicit-shell-file-name for that. So this shouldn't cause any change to the global variables. > Of course there is no problem unless you changes shell-file-name, but if > you do there is definitively a problem today. I think a buffer local value > is needed, but as I pointed out in another message another name is needed > for the buffer local value (a make-variable-buffer-local var). Why not set (buffer-locally) a different variable (such as "shell-uses-backslashes") when starting the inferior process? That seems more inline with what we usually do, rather than make a global variable buffer-local because we later (re)compute something that depends on the value the global variable had when the buffer was created. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: Anywhere. The point is that those variables may change during the time the interactive shell exists (or perhaps a non-interactive shell). In this case I noticed it because the file completion code needs to know the value of shell-file-name. Hmm... interesting, I didn't think of this case. If shell-file-name is set globally somewhere to something different from that in the shell buffer things may fail (as they did here). I hope I am clear enough. Other than when the user changes the configuration (which shouldn't happen all the time), when/why would shell-file-name change during the lifetime of an interactive shell-mode buffer? Or alternatively, why would the user regularly change the global setting of shell-file-name? The user might be testing new configurations for example and thereby changing shell-file-name (which now has only a global value). Since w32 is not that simple when it comes to shell that is a very likely situation, at least when the user has learned a bit more about emacs. Another possibility is that you want to use Cygwin or MSYS for interactive inferior shells, but use the gnuwin32 tools with cmdproxy otherwise. Of course there is no problem unless you changes shell-file-name, but if you there is definitively a problem today. I think a buffer local value is needed, but as I pointed out in another message another name is needed for the buffer local value (a make-variable-buffer-local var). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Anywhere. The point is that those variables may change during the time > the interactive shell exists (or perhaps a non-interactive shell). > In this case I noticed it because the file completion code needs to know > the value of shell-file-name. Hmm... interesting, I didn't think of this case. > If shell-file-name is set globally somewhere to something different from > that in the shell buffer things may fail (as they did here). I hope I am > clear enough. Other than when the user changes the configuration (which shouldn't happen all the time), when/why would shell-file-name change during the lifetime of an interactive shell-mode buffer? Or alternatively, why would the user regularly change the global setting of shell-file-name? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
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 ;-) cmdproxy 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. 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 this 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Wed, 20 Dec 2006 20:39:31 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: emacs-pretest-bug@gnu.org > > Can you please explain more exactly what problems you see with my patch? Backslashes are generally a problem in Emacs, because of their Lisp interpretation. I don't want us to introduce such a danger before the release. This problem was with us for a long time, way before Emacs 22, so I don't think anything will happen if we suffer from it for one more release. > 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. > >> C:\myecvs> dir bld/emacs > >> dir bld/emacs > >> Invalid switch - "emacs". > >> > > > > That's a different problem, because I could type the full command > > "dir foo/bar" without using auto-completion, and it would still fail. > > It could be solved in cmdproxy, for example. If you have time to work > > on this, please do. > > There is no need to do it on that level AFAICS cmdproxy 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Lennart Borgman wrote: Can you please explain more exactly what problems you see with my patch? It autocompletes in the shell buffer with "\" if the shell used has w32-shell-dos-semantics. When do you not want this? Why do you think it has to be customizable? After taking a pause I see that you are right. There are problems with my patch. I was somehow assuming that the buffer local value of shell-file-name could not be propagated further. I just thought about the command you send to the shell, but you can of course do other things. However an easy way to fix this would be to have a new variable, buffer-shell-file-name, that is always buffer local and with a global value that is always nil. Setting this whenever starting a shell process and checking for this in w32-shell-dos-semantics would be enough. The reason I prefer this way is that there might more problems with this. Because of this I believe that it would be a buffer local variable holding the value that shell-file-name had when the buffer was setup. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: That's because, to this day, there's no coherent set of Windows ports of GNU tools that is sufficiently free of bugs. Maybe instead of distributing patched Emacs binaries, you could use the energy to produce such a set of ports. Then the job of building Emacs would be so much easier. You are absolutely right about the lack of sufficiently good tools, but do not think I am the right one to do it now. Actually I would have had quite a bit more time if my more essential patches had been accepted.( The most essential patches at this time are the low level keyboard hook and the automatic startup of Emacs through emacsclient. Some workaround for ange-ftp too perhaps.) If someone is interested in trying to make the tools better for w32 I would argue that some of the tools should just handle lines and not care about what line types the files have. Strip the line endings, do what is needed and then output with the wanted line endings. That is actually the way Emacs work. It would be nice if for example patch.exe did this. Though for such work to be long standing and without much trouble the patches must find it ways into the main code of those GNU programs. But a distribution is actually another thing too. It should help people getting started easily. It was not very easy from the beginning in my opinion. Your suggestions are always seriously considered, but please don't expect them to be always accepted. Ah, thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: Date: Wed, 20 Dec 2006 16:33:00 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> CC: emacs-pretest-bug@gnu.org I heard what you said, and I obviously disagree that it's a clear bug. It is no more a bug than the fact that Emacs uses only forward slashes in file-name completion in the minibuffer, even on Windows. In other words, you are arguing for a new feature. While I'm not opposed to having such a feature, now is not the time to introduce new features. New feature? I think that things work correctly is hopefully not a new feature in Emacs ;-) It's a new feature because it will have to be customizable. I don't want my shell buffers auto-complete with backslashes, and I'm sure I'm not the only one. Can you please explain more exactly what problems you see with my patch? It autocompletes in the shell buffer with "\" if the shell used has w32-shell-dos-semantics. When do you not want this? Why do you think it has to be customizable? C:\myecvs> dir bld/emacs dir bld/emacs Invalid switch - "emacs". That's a different problem, because I could type the full command "dir foo/bar" without using auto-completion, and it would still fail. It could be solved in cmdproxy, for example. If you have time to work on this, please do. There is no need to do it on that level AFAICS, but maybe I will change my mind if you explain the problems you see with my patch a bit more in details. You have not told me any such yet that I think are relevant. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Wed, 20 Dec 2006 18:33:40 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org > > I actually started my distribution because it was so damned > difficult to get Emacs into a working condition on w32. I recently added > some gnuwin32 binaries to make it easier. That's because, to this day, there's no coherent set of Windows ports of GNU tools that is sufficiently free of bugs. Maybe instead of distributing patched Emacs binaries, you could use the energy to produce such a set of ports. Then the job of building Emacs would be so much easier. > You have a point there of course. I do not wish this. However it would > be much easier if my patches were a bit more seriously considered. Your suggestions are always seriously considered, but please don't expect them to be always accepted. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Wed, 20 Dec 2006 16:33:00 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: emacs-pretest-bug@gnu.org > > > > I heard what you said, and I obviously disagree that it's a clear bug. > > It is no more a bug than the fact that Emacs uses only forward slashes > > in file-name completion in the minibuffer, even on Windows. > > > > In other words, you are arguing for a new feature. While I'm not > > opposed to having such a feature, now is not the time to introduce new > > features. > > > New feature? I think that things work correctly is hopefully not a new > feature in Emacs ;-) It's a new feature because it will have to be customizable. I don't want my shell buffers auto-complete with backslashes, and I'm sure I'm not the only one. > C:\myecvs> dir bld/emacs > dir bld/emacs > Invalid switch - "emacs". That's a different problem, because I could type the full command "dir foo/bar" without using auto-completion, and it would still fail. It could be solved in cmdproxy, for example. If you have time to work on this, please do. > It is a bug and I offered a solution which I think is safe. It isn't safe enough for this time. > The pretest is for fixing bugs. Only those that don't run the risk of introducing more complex bugs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Juanma Barranquero wrote: I'm sure my usage pattern is very different from yours (I never print from inside Emacs, for example), but I don't have any trouble "getting Emacs into a working condition on w32". There are some rough edges. Which Is Not The Same Thing :) Yes, my fingers are probably different too. I am used to cua keys, alt-tab, alt-f etc. (And I am rather used to vi.) And printing the code is sometimes necessary for me. While I am coding everything is very abstract and actually have to look at the code afterwards ;-) There are not many Windows developers for Emacs, so resources are scarce. That does not mean they don't care. Yes, I know, I have understood this now. But it was quite a bit frustrating in the beginning. I would welcome more developers on the w32 side! I've always tried to take your patches seriously; I'm sure I'm not the only one. Thanks! I guess we differ more in how we see the needs and possibilities. Perhaps I more often restructure code to get benefits. Restructure and bind together (like for my printing solution/hack ;-) If they're not final, and we are in pretest (or we were approaching pretest) its harder to give them the attention they need. It will be easier to reconsider them after 22.1, IMHO. Depends on if they are bug solutions or not IMHO. I send the suggestions to the list to see if we together can see flaws/benefits/better ways. It is quicker than doing it all yourself just to find you have to redo it which happen to me quite a number of times since I always see more of the benefits than the problems ;-) I have not heard many people complaining that they cannot remap Win + R, for example. I looked once to your low-level code, and it seemed complicate for the small benefit it offers (IMHO again, of course). Some people give up. Unfortunately. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
On 12/20/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: Maybe. I actually started my distribution because it was so damned difficult to get Emacs into a working condition on w32. I'm sure my usage pattern is very different from yours (I never print from inside Emacs, for example), but I don't have any trouble "getting Emacs into a working condition on w32". There are some rough edges. Which Is Not The Same Thing :) My thoughts at the beginning was that no one has time to set this up any more. What a pitty, that makes it much harder for those developers/web developers wanting to go from w32 to GNU/Linux later. There are not many Windows developers for Emacs, so resources are scarce. That does not mean they don't care. You have a point there of course. I do not wish this. However it would be much easier if my patches were a bit more seriously considered. I've always tried to take your patches seriously; I'm sure I'm not the only one. As I have tried to explain many times I hardly ever consider them as final patches. I want comments on them but not dismissing. If they're not final, and we are in pretest (or we were approaching pretest) its harder to give them the attention they need. It will be easier to reconsider them after 22.1, IMHO. I always have a problem I want to solve with them (and it is hardly only for myself). I have not heard many people complaining that they cannot remap Win + R, for example. I looked once to your low-level code, and it seemed complicate for the small benefit it offers (IMHO again, of course). (I guess everyone agree, but it does not really feel that way always.) I think yes, many agree. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Juanma Barranquero wrote: On 12/20/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: I guess you mean logical relation? Causal. Arguing for bug fixes does not cause you having to do an alternate distribution. So the fact that you argue for bugs has no bearing on whether you do an alternate distribution or not. I do argue for bug fixes. I don't have my own distribution. Maybe. I actually started my distribution because it was so damned difficult to get Emacs into a working condition on w32. I recently added some gnuwin32 binaries to make it easier. (I have long been thinking about doing this but wanted to test a long time first. And have others opinion of course.) My thoughts at the beginning was that no one has time to set this up any more. What a pitty, that makes it much harder for those developers/web developers wanting to go from w32 to GNU/Linux later. At the moment I think the benefits outweighs the problem, but if some of the more nagging bugs/missing features were corrected I think I would change my mind. Your distribution gets notoriety as a "better way to use Emacs on Windows", i.e., it's better for an Emacs user on Windows to use yours than the standard one. If you someday change your mind, there's nothing stopping someone from deciding that he will continue maintaining the "improved for Windows" version. I'm not saying it is going to happen. I'm not ever saying it is likely to happen. But it is not difficult to happen. Some projects never fork; others... well, look at GNU Arch / Baz / Bazaar / ArX. You have a point there of course. I do not wish this. However it would be much easier if my patches were a bit more seriously considered. As I have tried to explain many times I hardly ever consider them as final patches. I want comments on them but not dismissing. I always have a problem I want to solve with them (and it is hardly only for myself). Of course I am not a C programmer, I had never seen lisp before I tried Emacs. I am not either a *nix user. I do not know the *nix API:s at all. Why I mention this? Because I have got the impression that it is a bit difficult to come into this from the w32 side. However for the success of a project like Emacs it is of course important that we meet with our different knowledge. (I guess everyone agree, but it does not really feel that way always.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
On 12/20/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: I guess you mean logical relation? Causal. Arguing for bug fixes does not cause you having to do an alternate distribution. So the fact that you argue for bugs has no bearing on whether you do an alternate distribution or not. I do argue for bug fixes. I don't have my own distribution. At the moment I think the benefits outweighs the problem, but if some of the more nagging bugs/missing features were corrected I think I would change my mind. Your distribution gets notoriety as a "better way to use Emacs on Windows", i.e., it's better for an Emacs user on Windows to use yours than the standard one. If you someday change your mind, there's nothing stopping someone from deciding that he will continue maintaining the "improved for Windows" version. I'm not saying it is going to happen. I'm not ever saying it is likely to happen. But it is not difficult to happen. Some projects never fork; others... well, look at GNU Arch / Baz / Bazaar / ArX. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Juanma Barranquero wrote: On 12/20/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: Yes, and I was not here then. Now instead I am arguing for correcting the bugs. No. You're arguing for correcting the bugs (don't we all?) and you're *also* distributing an alternate version of Emacs. They're separate actions with no causal relation. I guess you mean logical relation? Distributing your own build has certain dangers; tiny at this point, I concede, but dangers nonetheless. Yes, one of the more problematic points might be that people never see the bugs so this list gets the impression that they are not important. Most users downloads the patched version from my site. At the moment I think the benefits outweighs the problem, but if some of the more nagging bugs/missing features were corrected I think I would change my mind. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
On 12/20/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: Yes, and I was not here then. Now instead I am arguing for correcting the bugs. No. You're arguing for correcting the bugs (don't we all?) and you're *also* distributing an alternate version of Emacs. They're separate actions with no causal relation. Distributing your own build has certain dangers; tiny at this point, I concede, but dangers nonetheless. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: Date: Tue, 19 Dec 2006 09:16:42 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> CC: emacs-pretest-bug@gnu.org 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. I heard what you said, and I obviously disagree that it's a clear bug. It is no more a bug than the fact that Emacs uses only forward slashes in file-name completion in the minibuffer, even on Windows. In other words, you are arguing for a new feature. While I'm not opposed to having such a feature, now is not the time to introduce new features. New feature? I think that things work correctly is hopefully not a new feature in Emacs ;-) emacs -Q M-x shell C:\myecvs> dir b C:\myecvs> dir bld/ C:\myecvs> dir bld/emacs dir bld/emacs Invalid switch - "emacs". C:\myecvs> Maybe you believed that this worked since very similar things actually do work. It is a bug and I offered a solution which I think is safe. I believe I already have commented on it, see the citation from my original message above: I don't want us to mess with this so close to a release. The pretest is for fixing bugs. What do you think can go wrong? Everything. As you yourself point out, the situation with w32 shells is complicated and fragile. What else should be said to convince you that now is not the time to mess with it? Can you then please look at the patch again and tell more specific what you think can go wrong? I will add the above to my patched version, as usual. Sigh... That's how the XEmacs fork started, you know... Yes, and I was not here then. Now instead I am arguing for correcting the bugs. Please excuse me if I am not the really careful type sometimes. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Tue, 19 Dec 2006 09:16:42 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: emacs-pretest-bug@gnu.org > > > > 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. I heard what you said, and I obviously disagree that it's a clear bug. It is no more a bug than the fact that Emacs uses only forward slashes in file-name completion in the minibuffer, even on Windows. In other words, you are arguing for a new feature. While I'm not opposed to having such a feature, now is not the time to introduce new features. > Could you please comment on my tentative solution? I believe I already have commented on it, see the citation from my original message above: I don't want us to mess with this so close to a release. > What do you think can go wrong? Everything. As you yourself point out, the situation with w32 shells is complicated and fragile. What else should be said to convince you that now is not the time to mess with it? > I will add the above to my patched version, as usual. Sigh... That's how the XEmacs fork started, you know... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Tue, 19 Dec 2006 09:16:42 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > CC: emacs-pretest-bug@gnu.org > 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 <[EMAIL PROTECTED]> > >> Cc: emacs-pretest-bug@gnu.org > >> > >> 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. > ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: How that structured way should look is a bit more complicated to tell. I preferred to make those variables local in just the interactive shell buffers. Where are the `setq's affected by the `make-local-variable' calls? Anywhere. The point is that those variables may change during the time the interactive shell exists (or perhaps a non-interactive shell). In this case I noticed it because the file completion code needs to know the value of shell-file-name. If shell-file-name is set globally somewhere to something different from that in the shell buffer things may fail (as they did here). I hope I am clear enough. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> How that structured way should look is a bit more complicated to > tell. I preferred to make those variables local in just the interactive > shell buffers. Where are the `setq's affected by the `make-local-variable' calls? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> 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 guess I lack the big-picture here: to me, the above three lines can never be the right fix for anything. At best, they may be acceptable workarounds in some special cases. `make-local-variable' to me only makes sense when followed pretty much immediately by `set' or `setq' on the same variable. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: 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 guess I lack the big-picture here: to me, the above three lines can never be the right fix for anything. At best, they may be acceptable workarounds in some special cases. `make-local-variable' to me only makes sense when followed pretty much immediately by `set' or `setq' on the same variable. I do not know about the first line, it was there before. However I know about the other two. The situation on w32 regarding shells is quite complicated, but I believe that part of what I have seen could apply to other platforms as well. Since there are many shells to use (at least on w32) and you in a case like completion wants to do it for the shell you are actually using in the interactive shell buffer (*Shell*) you need to know which shell is used in that particular buffer (or rather how completion should be done of course). A structured way to handle this is needed. How that structured way should look is a bit more complicated to tell. I preferred to make those variables local in just the interactive shell buffers. That would lead to a minimal disruption since their use there is very limited I believe. The bad thing about this is that this situation was not foreseen before. There is no notion about how to handle situations like this and the exact use of these variables. I suspect however that there are other similar cases where these variables should be buffer local so does it not seem like they simply should be made local with make-variable-buffer-local? There might be other situations when you need to know which shell is used. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Eli Zaretskii wrote: Date: Tue, 19 Dec 2006 01:23:18 +0100 From: Lennart Borgman <[EMAIL PROTECTED]> Cc: emacs-pretest-bug@gnu.org 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> Date: Tue, 19 Dec 2006 01:23:18 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
Stefan Monnier wrote: It could, but it doesn't want to. In Emacs, the canonical directory separator is / (although \ is made to work as well under w32, for obvious interoperability reasons). You make it sound like / and \ both work in Windows, but they don't: They do if you use another shell ;-) (IIUC the API-level functions in w32 understand / just fine, it's only the/some shells which insist on using \ exclusively). If shell-mode could use backslash when completing on w32 it would be a lot more useful. I'll let the w32 people decide. I was just explaining the current situation. It is clearly a bug when using cmd.exe for the shell (cmdproxy.exe really). I think it need to be corrected. 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?) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
>> It could, but it doesn't want to. In Emacs, the canonical directory >> separator is / (although \ is made to work as well under w32, for obvious >> interoperability reasons). > You make it sound like / and \ both work in Windows, but they don't: They do if you use another shell ;-) (IIUC the API-level functions in w32 understand / just fine, it's only the/some shells which insist on using \ exclusively). > If shell-mode could use backslash when completing on w32 it would be a > lot more useful. I'll let the w32 people decide. I was just explaining the current situation. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses "/" instead of "\"
> When I use the Interactive Inferior Shell in emacs on w32 and press > TAB for completion, I get "/" instead of "\" after the directory > names. > Couldn't emacs add "\" on w32 instead? It could, but it doesn't want to. In Emacs, the canonical directory separator is / (although \ is made to work as well under w32, for obvious interoperability reasons). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Shell completion on w32 uses "/" instead of "\"
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: When I use the Interactive Inferior Shell in emacs on w32 and press TAB for completion, I get "/" instead of "\" after the directory names. Couldn't emacs add "\" on w32 instead? Thanks anyway for your great work. B.R. Mats If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Download/emacs061211/emacs/etc/DEBUG for instructions. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.0.2195) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc ( 3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: SVE locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Shell Minor modes in effect: shell-dirtrack-mode: t encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x s h e l l c d SPC . . c d SPC b M-x r e p o r t SPC e m SPC b SPC Recent messages: (C:\Download\emacs061211\emacs\bin\emacs.exe -q --no-site-file) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading shell...done ~/Download/emacs061211/emacs Completing file name... Completed Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
