>>> 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
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
