GNU bug report logs - #20202
24.3; Comint mode sets a bad $EMACS

Previous Next

Full log

Message #69 received at 20202 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: phillip.lord <at> russet.org.uk (Phillip Lord)
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 20484 <at> debbugs.gnu.org,
 20202 <at> debbugs.gnu.org
Subject: Re: bug#20202: Considered Harmful 73d213: 'Comint, term,
 and compile new set Emacs'
Date: Thu, 07 Apr 2016 18:20:08 -0400

> So, bash has a command line option to achieve the same thing as EMACS=t.

or the code can be changed to use $INSIDE_EMACS
or the user could tell Emacs to set EMACS=t
or the user could upgrade to the (upcoming) next release of Bash.

4 options for Bash, one of them will actually become the default in the
future.  So Bash is not a big problem here.

> I've checked tcsh and as far as I can tell, here, there is no clear
> solution.  EMACS=t is used, and it's deep in the init code.  In my hands,
> directory tracking in tcsh does not work in ansi-term either way.

So, does anything break if we don't have EMACS=t?
It sounds like it's a non-issue.

> Zsh does not, AFAICT, use EMACS=t (it's hard to be sure searching
> through the code, since most instances of "emacs" refer to zsh's
> emulation of Emacs). In fact, though, as the FAQ entry you found shows,
> zsh actually does this...
>
>     /* unset zle if using zsh under emacs */
>     if (!strcmp(term, "emacs"))
> 	opts[USEZLE] = 0;
>
> which, according to the faq is behaviour from < Emacs-19.29.

Indeed, this code has been useless for many years already since Emacs
doesn't set $TERM to "emacs" any more.

> So, zsh users already explicitly tell their zsh what to do.

So we don't have any evidence that removing EMACS=t will have any effect
on Zsh users either.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.