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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

We already do as much as we can to alleviate the problems: set
INSIDE_EMACS as well, and don't set EMACS=t if it is already set.  I
don't see what we can possibly do more.

> IOW, right now people who suffer from bug#20202 are not satisfied either.

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.

> The ideal situation (which I think is the one that we should strive for
> in the long-run) is to have Emacs not touch the $EMACS var (which will
> address bug#20202).  So the question is how to get there.

Waiting is the only way I see.