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
