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