From: phillip.lord@russet.org.uk (Phillip Lord)
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
20484@debbugs.gnu.org, 20202@debbugs.gnu.org
Subject: bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs'
Date: Fri, 08 Apr 2016 14:09:22 +0100 [thread overview]
Message-ID: <87vb3sjlh9.fsf@russet.org.uk> (raw)
In-Reply-To: <jwvpou1rrsf.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Thu, 07 Apr 2016 18:20:08 -0400")
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
next prev parent reply other threads:[~2016-04-08 13:09 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87oa9otixb.fsf@russet.org.uk>
[not found] ` <5703E15B.7080601@cs.ucla.edu>
[not found] ` <87k2kcovt8.fsf@russet.org.uk>
[not found] ` <5704233B.4020103@cs.ucla.edu>
[not found] ` <8737qzso88.fsf@russet.org.uk>
[not found] ` <57045765.4000309@cs.ucla.edu>
[not found] ` <87r3ei8vz9.fsf@russet.org.uk>
[not found] ` <5705B246.10201@cs.ucla.edu>
[not found] ` <74bf15b3e1a5afeb41cf6b39d5247e8b.squirrel@cloud103.planethippo.com>
2016-04-07 14:57 ` bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs' Paul Eggert
[not found] ` <c32b8d04f5c78203f06c4e48e03b37b0.squirrel@cloud103.planethippo.com>
2016-04-07 15:01 ` Paul Eggert
2016-04-07 15:18 ` Phillip Lord
2016-04-07 15:25 ` Paul Eggert
2016-04-07 16:01 ` Glenn Morris
2016-04-07 16:07 ` Phillip Lord
2016-04-07 16:26 ` bug#20484: " Paul Eggert
2016-04-07 19:55 ` Phillip Lord
2016-04-07 22:20 ` bug#20484: " Stefan Monnier
2016-04-08 7:05 ` Eli Zaretskii
2016-04-08 13:09 ` Phillip Lord [this message]
2016-04-08 20:50 ` Paul Eggert
2016-04-08 21:20 ` Phillip Lord
2016-04-08 7:03 ` bug#20484: " Eli Zaretskii
2016-04-08 7:34 ` Andreas Schwab
2016-04-08 13:12 ` bug#20484: " Phillip Lord
2016-04-07 21:42 ` Phillip Lord
2016-04-08 7:01 ` Eli Zaretskii
2016-04-08 16:49 ` bug#20202: " Stefan Monnier
2016-04-08 18:12 ` Phillip Lord
2016-04-07 16:51 ` Stefan Monnier
2016-04-07 16:59 ` bug#20202: " Eli Zaretskii
2016-04-07 18:58 ` Stefan Monnier
2016-04-07 19:25 ` Eli Zaretskii
2016-04-07 22:01 ` Stefan Monnier
2016-04-08 7:00 ` bug#20202: " Eli Zaretskii
2016-04-08 15:32 ` Glenn Morris
2016-04-08 15:59 ` Eli Zaretskii
2015-05-01 23:36 ` bug#20484: 25.0.50; Directory tracking in ansi-term broken Jacob Oursland
2015-05-02 2:17 ` Glenn Morris
2015-05-02 2:43 ` Glenn Morris
2015-05-02 19:33 ` Jacob Oursland
2015-05-03 5:45 ` Stefan Monnier
2015-05-03 6:15 ` Jacob Oursland
2015-05-03 16:29 ` Richard Stallman
2015-05-03 17:36 ` Jacob Oursland
2015-05-04 2:06 ` Stefan Monnier
2015-05-04 16:15 ` Richard Stallman
2015-05-03 17:57 ` Glenn Morris
2015-05-03 19:09 ` Jacob Oursland
2015-05-04 2:07 ` Stefan Monnier
2016-03-23 22:15 ` Paul Eggert
2016-04-08 18:47 ` bug#20484: Bash 4.4-rc1 incompatibility with future Emacs $EMACS Paul Eggert
2016-04-09 2:24 ` bug#20484: bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs' Glenn Morris
2016-04-09 8:43 ` Phillip Lord
2016-04-09 13:43 ` bug#20202: " Stefan Monnier
2016-04-09 21:56 ` Phillip Lord
2016-04-09 23:40 ` bug#20202: " Paul Eggert
2016-04-10 0:08 ` Stefan Monnier
2016-04-10 3:30 ` Paul Eggert
2016-04-10 13:57 ` Stefan Monnier
2016-04-11 5:50 ` bug#20202: " Paul Eggert
2016-04-10 8:26 ` bug#20484: " Phillip Lord
2016-04-10 13:59 ` Stefan Monnier
2016-04-11 12:32 ` bug#20484: " Phillip Lord
2016-04-10 8:25 ` Phillip Lord
2015-03-25 21:44 ` bug#20202: 24.3; Comint mode sets a bad $EMACS Eli Barzilay
2015-03-26 0:46 ` Stefan Monnier
2015-03-28 15:27 ` Eli Barzilay
2015-04-09 15:02 ` Stefan Monnier
2016-04-10 12:18 ` bug#20202: bug#20484: bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs' Markus Triska
2016-04-11 12:38 ` Phillip Lord
2018-05-24 20:46 ` bug#20202: EMACS=t Joy and Happiness Phillip Lord
2016-04-10 7:13 ` bug#20202: bug#20484: bug#20202: Considered Harmful 73d213: 'Comint, term, and compile new set Emacs' Michael Albinus
2016-04-10 8:51 ` Phillip Lord
2016-04-10 9:31 ` Michael Albinus
2016-04-08 16:46 ` Stefan Monnier
2016-04-08 17:12 ` Paul Eggert
2016-04-08 18:14 ` bug#20202: " Phillip Lord
2016-04-08 17:47 ` Phillip Lord
2016-04-08 13:15 ` Phillip Lord
2016-04-08 13:40 ` Eli Zaretskii
2016-04-08 15:45 ` bug#20202: " Glenn Morris
2016-04-08 16:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vb3sjlh9.fsf@russet.org.uk \
--to=phillip.lord@russet.org.uk \
--cc=20202@debbugs.gnu.org \
--cc=20484@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).