bug#20484: bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs'

[phillip.lord@russet.org.uk (Phillip Lord)]

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 04/07/2016 09:07 AM, Phillip Lord wrote:
>> Well, I need to scope this. If the issue is tcsh and bash, then I will
>> look at both. I cannot, of course, look at any arbitrary program which
>> might be affected.
>
> I think we'd be OK if we work with the "common" shells. But that would include
> zsh, whose current FAQ says the following:
>
>   Probably the most reliable way of dealing with this is to look for
>     the environment variable `$EMACS', which is set to `t' in
>     Emacs' shell mode.  Putting
>
>       [[ $EMACS = t ]] && unsetopt zle
>
>     in your .zshrc should be sufficient.
>
> So here it's not merely a matter of fixing zsh, it's also fixing all the
> users' .zshrc files that are following this (obsolescent) advice.
>
> So far we've looked at three shells (bash, tcsh, zsh), and found compatibility
> issues with all three. This is not a good sign.

Incidentally, I have looked again at #20484. What ever it is that is
supporting the directory tracking, it is not the EMACS=t behaviour of 
bash, since in ansi-term we have:

 (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)

This usage will happily not break cask, since it was never supported in
the first place.

On the other hand, directory tracking works just fine in M-x shell in
both Emacs-25.0.91, and Emacs-25 head. So, the EMACS=t setting is not
an issue there either. And, dir tracking is not an issue at all for M-x
compile.

This suggests a simple fix: restore beaab89, except for the bit dealing
with ansi-term, which remains for the sake of future compatability. Both
bug reports are fixed. Anyone launching cask (or the make files Eli
Barzilay talked about in #20202) inside ansi-term may still have
problems.

ansi-term is already exceptional, note, because it does not obey the
"don't fiddle with EMACS if EMACS is already set" semantics.

Phil