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

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: eggert@cs.ucla.edu,  phillip.lord@russet.org.uk,  20202@debbugs.gnu.org, 
>>  20484@debbugs.gnu.org
>> 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