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

From: [email-masked] (Phillip Lord)
Date: Fri, 08 Apr 2016 14:15:07 +0100

Eli Zaretskii <[email-masked]> writes:

>> From: Stefan Monnier <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked],  [email-masked]
>> Date: Thu, 07 Apr 2016 14:58:07 -0400
>> 
>> >> Maybe the best solution is to stop messing with $EMACS by default (and
>> >> hence change the behavior of sub-shells in negative ways for some
>> >> users), and then provide an easy way for those users to get back the
>> >> "fully featured" sub-shell they love.
>> > I don't think this will satisfy users of those shells.
>> 
>> I don't think "satisfy" is sufficiently well defined to be useful in
>> this conversation.
>
> I think it is.
>
>> There's clearly a tradeoff to be made between bug#20202 and bug#20484.
>
> Experience has taught us that there's no real tradeoff, at least not
> in the next few years.  As long as shells are in use which want
> EMACS=t, we must leave that in place.

Both zsh and bash also check TERM=emacs, which isn't set.

> They are mostly those who bump into this in Makefile's, where it is
> relatively easy to switch to another name.  It's inconvenient, but
> easily fixed.  By contrast, users of shells cannot always easily
> change what their shells expect in their sources.

Should we patch the Emacs makefiles to stop making use of $(EMACS) then?

Phil