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

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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


So, this turns out to be untrue. Bug #20484 is caused NOT by the lack of
EMACS=t. Ansi term sets 

EMACS="25.0.91.0 (term 0.91)"

which is notable not "t".

The code which checks this looks like this:

      running_under_emacs = (emacs != 0) || (term && STREQN (term, "emacs", 5));
      running_under_emacs += term && STREQN (term, "eterm", 5) && emacs && 
strstr (emacs, "term");


which sets running_under_emacs=2 in ansi-term.

This is checked later in eval.c.

 if (running_under_emacs == 2)
        send_pwd_to_eterm ();   /* Yuck */


(the /*Yuck*/ is their comment not mine!).

which does this:

static void
send_pwd_to_eterm ()
{
  char *pwd, *f;

  f = 0;
  pwd = get_string_value ("PWD");
  if (pwd == 0)
    f = pwd = get_working_directory ("eterm");
  fprintf (stderr, "\032/%s\n", pwd);
  free (f);
}


In otherwords, bash detects ansi-term specifically, and prints out PWD
every command. The workaround to this is (nearly) documented in the
headers of term.el. Adding this:

cd(){ command cd "$@";printf '\032/%s\n' "$PWD"; }

to .bashrc, and directory tracking works in Emacs-21.0.92 (with no EMACS
set).

The patch to bash that supposedly fixes bash to use INSIDE_EMACS looks
like this...


diff --git a/shell.c b/shell.c
index c0107ff..dc9015d 100644
--- a/shell.c
+++ b/shell.c
@@ -581,12 +581,13 @@ main (argc, argv, env)
       emacs = get_string_value ("EMACS");
 
       /* Not sure any emacs terminal emulator sets TERM=emacs any more */
-      no_line_editing |= term && (STREQ (term, "emacs"));
+      no_line_editing |= STREQ (term, "emacs");
       no_line_editing |= emacs && emacs[0] == 't' && emacs[1] == '\0' && STREQ 
(term, "dumb");
+      no_line_editing |= get_string_value ("INSIDE_EMACS") != 0;
 
       /* running_under_emacs == 2 for `eterm' */
-      running_under_emacs = (emacs != 0) || (term && STREQN (term, "emacs", 
5));
-      running_under_emacs += term && STREQN (term, "eterm", 5) && emacs && 
strstr (emacs, "term");
+      running_under_emacs = (emacs != 0) || STREQN (term, "emacs", 5);
+      running_under_emacs += STREQN (term, "eterm", 5) && emacs && strstr 
(emacs, "term");
 
       if (running_under_emacs)
        gnu_error_format = 1;


Which is not the problem in the first place. Future versions of bash
won't work either with ansi-term either.

There may be outstanding issues -- i.e. "gnu_error_format" is also set,
as is "no_line_editing". What practical implications these have for bash
under Emacs, I do not know. AFAICT, though, we had no bug reports from
users of M-x shell with bash for the year that "EMACS= ". We have a bug
report for ansi-term with bash, is all.



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

Not in my hands. To get directory tracking in tcsh would require
porting the bash fix above.


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


At the moment, I have some evidence from the bash and tcsh that they are
doing something with EMACS=t. But I do not, at the moment, know what the
practical implications of these something are; loss of dir-tracking is
not one of them.

Phil