GNU bug report logs -
#20202
24.3; Comint mode sets a bad $EMACS
Previous Next
Reported by: Eli Barzilay <eli <at> barzilay.org>
Date: Wed, 25 Mar 2015 21:46:02 UTC
Severity: minor
Found in version 24.3
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20202 in the body.
You can then email your comments to 20202 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Wed, 25 Mar 2015 21:46:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eli Barzilay <eli <at> barzilay.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 25 Mar 2015 21:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I was surprised to see that compiling some random Emacs code via a
Makefile fails when running inside Emacs with an obscure
/bin/sh: t: command not found
I found this setting in comint.el:
(unless (getenv "EMACS")
(list "EMACS=t"))
And that would obviously break such Makefile uses (and IIUC, $EMACS is
a popular choice for specifying which emacs binary to use).
It looks like this was done in this commit:
commit cfefbbf4404963cdf042fb794e0456503aa8b591
Author: Chong Yidong <cyd <at> stupidchicken.com>
Date: 2006-11-18 21:01:33 +0000
(comint-exec-1): Set EMACS and INSIDE_EMACS to t.
Before this commit, EMACS was set with
(concat "EMACS=" invocation-directory invocation-name)
which doesn't look like a good idea either (if you happen to use some
other Emacs version, you still expect the shell to be a plain shell),
but it at least didn't break it. But this change was done shortly
after:
commit 4b1aaa8b07cf2797b5a57e2a1fd88f3ec0aa41e2
Author: Paul Eggert <eggert <at> twinsun.com>
Date: 2006-09-12 16:43:25 +0000
* etc/NEWS: In terminal-oriented subshells, the EMACS environment
variable now defaults to Emacs's absolute file name, instead of
to "t".
and before that (all the way to the initial comint version in git), it
was always "t". It looks like this was intended as a way to tell if
you're running inside emacs, which was superseded by $INSIDE_EMACS --
misc.texi says
(It also sets the @env{EMACS} environment variable to @code{t}, if
that environment variable is not already defined. However, this
environment variable is deprecated; programs that use it should
switch to using @env{INSIDE_EMACS} instead.)
and the changelog dates this to the same date as the first commit
above.
So, since it has been deprecated for almost 8 years, it looks fine to
remove it. If not, then setting it back to the running Emacs would
work too, but better to not do such an unexpected change, so something
like "EMACS=emacs" is probably going to be unobtrusive.
Or if there's some motivation behind intentionally making it some
string that is not an executable, then "EMACS=some-descriptive-text"
would be better.
As a sidenote, misc/efaq.texi uses $EMACS still. (But for tcsh, so
not that anyone should care...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 26 Mar 2015 00:48:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> So, since it has been deprecated for almost 8 years, it looks fine to
> remove it.
Agreed.
> If not, then setting it back to the running Emacs would work too, but
It's never really been set that way, except for some very brief window
(I don't think it made it into a release, for example).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 28 Mar 2015 15:28:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 25, 2015 at 8:46 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> So, since it has been deprecated for almost 8 years, it looks fine to
>> remove it.
>
> Agreed.
>
>> If not, then setting it back to the running Emacs would work too, but
>
> It's never really been set that way, except for some very brief window
> (I don't think it made it into a release, for example).
Yeah, that's what I thought. FWIW, to avoid it for now, I've made my
Emacs set it to "emacs" and it looks like that works fine for builds.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Reply sent
to
Stefan Monnier <monnier <at> IRO.UMontreal.CA>:
You have taken responsibility.
(Thu, 09 Apr 2015 15:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eli Barzilay <eli <at> barzilay.org>:
bug acknowledged by developer.
(Thu, 09 Apr 2015 15:03:03 GMT)
Full text and
rfc822 format available.
Message #16 received at 20202-done <at> debbugs.gnu.org (full text, mbox):
> Yeah, that's what I thought. FWIW, to avoid it for now, I've made my
> Emacs set it to "emacs" and it looks like that works fine for builds.
I've just installed the patch below into master, which should fix this
problem,
Stefan
diff --git a/lisp/comint.el b/lisp/comint.el
index 31649ff..2769c87 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -816,8 +816,6 @@ series of processes in the same Comint buffer. The hook
(format "COLUMNS=%d" (window-width)))
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:" (window-width))))
- (unless (getenv "EMACS")
- (list "EMACS=t"))
(list (format "INSIDE_EMACS=%s,comint" emacs-version))
process-environment))
(default-directory
diff --git a/lisp/net/tramp-sh.el b/lisp/net/tramp-sh.el
index f59c5fb..3f006e8 100644
--- a/lisp/net/tramp-sh.el
+++ b/lisp/net/tramp-sh.el
@@ -496,7 +496,6 @@ as given in your `~/.profile'."
(defcustom tramp-remote-process-environment
`("TMOUT=0" "LC_CTYPE=''"
,(format "TERM=%s" tramp-terminal-type)
- "EMACS=t" ;; Deprecated.
,(format "INSIDE_EMACS='%s,tramp:%s'" emacs-version tramp-version)
"CDPATH=" "HISTORY=" "MAIL=" "MAILCHECK=" "MAILPATH=" "PAGER=cat"
"autocorrect=" "correct=")
diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 362bbf5..9d36e91 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -1666,11 +1666,7 @@ Returns the compilation buffer created."
(list "TERM=emacs"
(format "TERMCAP=emacs:co#%d:tc=unknown:"
(window-width))))
- ;; Set the EMACS variable, but
- ;; don't override users' setting of $EMACS.
- (unless (getenv "EMACS")
- (list "EMACS=t"))
- (list "INSIDE_EMACS=t")
+ (list (format "INSIDE_EMACS=%s,compile" emacs-version))
(copy-sequence process-environment))))
(set (make-local-variable 'compilation-arguments)
(list command mode name-function highlight-regexp))
diff --git a/lisp/term.el b/lisp/term.el
index 43138fa..4c82986 100644
--- a/lisp/term.el
+++ b/lisp/term.el
@@ -1505,11 +1505,6 @@ Using \"emacs\" loses, because bash disables editing if $TERM == emacs.")
(format "TERMINFO=%s" data-directory)
(format term-termcap-format "TERMCAP="
term-term-name term-height term-width)
- ;; We are going to get rid of the binding for EMACS,
- ;; probably in Emacs 23, because it breaks
- ;; `./configure' of some packages that expect it to
- ;; say where to find EMACS.
- (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
(format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
(format "LINES=%d" term-height)
(format "COLUMNS=%d" term-width))
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 08 May 2015 11:24:04 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 07 Apr 2016 14:51:02 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org.
(Thu, 07 Apr 2016 14:54:01 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 07 Apr 2016 14:54:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 14:58:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 04/07/2016 12:18 AM, Phillip Lord wrote:
> I will submit a new bug
> report to reopen 20202 which is now not fixed.
I reopened Bug#20202, so there should be no need to submit a new bug report.
For those joining this this via Bug#20202, this message is following up
on a thread starting here:
http://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00184.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 15:02:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 04/07/2016 12:35 AM, Phillip Lord wrote:
> As a better alternatively, would it be possible to find a solution to
> 20484 which does not involve EMACS=t?
>
> This would both address 20484 and 20202, rather than robbing Peter to pay
> Paul.
I'm afraid nothing comes to mind. I'll CC: this to both bug reports to
see if others have ideas.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 15:19:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Thu, April 7, 2016 4:01 pm, Paul Eggert wrote:
> On 04/07/2016 12:35 AM, Phillip Lord wrote:
>
>> As a better alternatively, would it be possible to find a solution to
>> 20484 which does not involve EMACS=t?
>>
>>
>> This would both address 20484 and 20202, rather than robbing Peter to
>> pay Paul.
>>
> I'm afraid nothing comes to mind. I'll CC: this to both bug reports to
> see if others have ideas.
I can think of several possibilities. In particular, the EMACS=t behaviour
of bash should also be replicable with bash -o emacs. I'm happy to try
these out and see if it works, so long as the EMACS=t is not considered to
be a closed issue for Emacs 25.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 15:26:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 04/07/2016 08:18 AM, Phillip Lord wrote:
> I can think of several possibilities. In particular, the EMACS=t behaviour
> of bash should also be replicable with bash -o emacs.
I expect that this problem affects programs other than bash. For
example, tcsh 6.19.00 (the latest version of the first other shell that
I checked) tests whether EMACS is "t".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 16:03:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> On 04/07/2016 08:18 AM, Phillip Lord wrote:
>> I can think of several possibilities. In particular, the EMACS=t behaviour
>> of bash should also be replicable with bash -o emacs.
> I expect that this problem affects programs other than bash. For
> example, tcsh 6.19.00 (the latest version of the first other shell
> that I checked) tests whether EMACS is "t".
IMO this issue is effectively going to be impossible to change.
Eg is there any sign of tcsh adapting?
How long for that change to make it into the long-term stable release of
all major distributions?
How many other things need similar changes?
Just resign yourself to the fact that EMACS has a not-very useful value
inside comint.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 16:08:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Thu, April 7, 2016 4:25 pm, Paul Eggert wrote:
> On 04/07/2016 08:18 AM, Phillip Lord wrote:
>
>> I can think of several possibilities. In particular, the EMACS=t
>> behaviour of bash should also be replicable with bash -o emacs.
> I expect that this problem affects programs other than bash. For
> example, tcsh 6.19.00 (the latest version of the first other shell that I
> checked) tests whether EMACS is "t".
Well, I need to scope this. If the issue is tcsh and bash, then I will
look at both. I cannot, of course, look at any arbitrary program which
might be affected.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 16:27:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 04/07/2016 09:07 AM, Phillip Lord wrote:
> Well, I need to scope this. If the issue is tcsh and bash, then I will
> look at both. I cannot, of course, look at any arbitrary program which
> might be affected.
I think we'd be OK if we work with the "common" shells. But that would
include zsh, whose current FAQ says the following:
Probably the most reliable way of dealing with this is to look for
the environment variable `$EMACS', which is set to `t' in
Emacs' shell mode. Putting
[[ $EMACS = t ]] && unsetopt zle
in your .zshrc should be sufficient.
So here it's not merely a matter of fixing zsh, it's also fixing all the
users' .zshrc files that are following this (obsolescent) advice.
So far we've looked at three shells (bash, tcsh, zsh), and found
compatibility issues with all three. This is not a good sign.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 16:52:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 20202 <at> debbugs.gnu.org (full text, mbox):
>> I can think of several possibilities. In particular, the EMACS=t behaviour
>> of bash should also be replicable with bash -o emacs.
> I expect that this problem affects programs other than bash. For example,
> tcsh 6.19.00 (the latest version of the first other shell that I checked)
> tests whether EMACS is "t".
It's not clear to me what "affects" means here.
The problem explicitly reported in 20484 is that directory tracking is
"turned off". This doesn't sound particularly terrible (as long as
there's an easy way to get back the desired directory tracking).
So I think to make an informed decision, we first need to figure out *how*
all those shells are affected by having $EMACS be set to something else
than "t".
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.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 17:00:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 07 Apr 2016 12:51:51 -0400
> Cc: Phillip Lord <phillip.lord <at> russet.org.uk>, 20202 <at> debbugs.gnu.org,
> 20484 <at> debbugs.gnu.org
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 18:59:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 20202 <at> debbugs.gnu.org (full text, mbox):
>> 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.
There's clearly a tradeoff to be made between bug#20202 and bug#20484.
IOW, right now people who suffer from bug#20202 are not satisfied either.
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.
It will most likely involve a bit of annoyance to some users along
the way.
But I think replacing $EMACS by $INSIDE_EMACS in their ~/.zshrc, or
adding some magic one-liner in their ~/.emacs is a rather
minor annoyance.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 19:27:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, phillip.lord <at> russet.org.uk, 20202 <at> debbugs.gnu.org, 20484 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 19:56:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 04/07/2016 09:07 AM, Phillip Lord wrote:
>> Well, I need to scope this. If the issue is tcsh and bash, then I will
>> look at both. I cannot, of course, look at any arbitrary program which
>> might be affected.
>
> I think we'd be OK if we work with the "common" shells. But that would include
> zsh, whose current FAQ says the following:
>
> Probably the most reliable way of dealing with this is to look for
> the environment variable `$EMACS', which is set to `t' in
> Emacs' shell mode. Putting
>
> [[ $EMACS = t ]] && unsetopt zle
>
> in your .zshrc should be sufficient.
>
> So here it's not merely a matter of fixing zsh, it's also fixing all the
> users' .zshrc files that are following this (obsolescent) advice.
>
> So far we've looked at three shells (bash, tcsh, zsh), and found compatibility
> issues with all three. This is not a good sign.
So, bash has a command line option to achieve the same thing as EMACS=t.
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.
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.
So, zsh users already explicitly tell their zsh what to do.
Possible solutions:
1) For bash, launch with -o emacs, or call set -o emacs after launch.
2) zsh, launch and call unsetopt zle.
3) For tcsh, EMACS=t only needs to be correct during init. So, EMACS=t,
launch tcsh, set EMACS=what-ever-it-was-before.
4) Everything else -- move the "call-process" call to a single function
which people can advice as they choose.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 21:43:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 04/07/2016 09:07 AM, Phillip Lord wrote:
>> Well, I need to scope this. If the issue is tcsh and bash, then I will
>> look at both. I cannot, of course, look at any arbitrary program which
>> might be affected.
>
> I think we'd be OK if we work with the "common" shells. But that would include
> zsh, whose current FAQ says the following:
>
> Probably the most reliable way of dealing with this is to look for
> the environment variable `$EMACS', which is set to `t' in
> Emacs' shell mode. Putting
>
> [[ $EMACS = t ]] && unsetopt zle
>
> in your .zshrc should be sufficient.
>
> So here it's not merely a matter of fixing zsh, it's also fixing all the
> users' .zshrc files that are following this (obsolescent) advice.
>
> So far we've looked at three shells (bash, tcsh, zsh), and found compatibility
> issues with all three. This is not a good sign.
Incidentally, I have looked again at #20484. What ever it is that is
supporting the directory tracking, it is not the EMACS=t behaviour of
bash, since in ansi-term we have:
(format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
This usage will happily not break cask, since it was never supported in
the first place.
On the other hand, directory tracking works just fine in M-x shell in
both Emacs-25.0.91, and Emacs-25 head. So, the EMACS=t setting is not
an issue there either. And, dir tracking is not an issue at all for M-x
compile.
This suggests a simple fix: restore beaab89, except for the bit dealing
with ansi-term, which remains for the sake of future compatability. Both
bug reports are fixed. Anyone launching cask (or the make files Eli
Barzilay talked about in #20202) inside ansi-term may still have
problems.
ansi-term is already exceptional, note, because it does not obey the
"don't fiddle with EMACS if EMACS is already set" semantics.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 22:02:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> in the next few years. As long as shells are in use which want
> EMACS=t, we must leave that in place.
No, nothing forces us to leave that in place. What is true is:
As long as shells are in use which want EMACS=t, we should make sure
that the affected users can still get the right behavior
> Waiting is the only way I see.
We've tried that for about 10 years now.
I'd be surprised if another 10 years will make any difference in
this respect.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 07 Apr 2016 22:21:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 07:02:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu, phillip.lord <at> russet.org.uk, 20202 <at> debbugs.gnu.org, 20484 <at> debbugs.gnu.org
> Date: Thu, 07 Apr 2016 18:01:37 -0400
>
> > in the next few years. As long as shells are in use which want
> > EMACS=t, we must leave that in place.
>
> No, nothing forces us to leave that in place. What is true is:
>
> As long as shells are in use which want EMACS=t, we should make sure
> that the affected users can still get the right behavior
We will never recover from bug reports if the behavior they want is
not the default.
> > Waiting is the only way I see.
>
> We've tried that for about 10 years now.
> I'd be surprised if another 10 years will make any difference in
> this respect.
Maybe so, but I don't see any problem with that. We just tried to
make the wait shorter, and see what happened. We should try again in
few years, maybe the results will be better then. Hopefully.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 07:03:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: phillip.lord <at> russet.org.uk (Phillip Lord)
> Date: Thu, 07 Apr 2016 22:42:40 +0100
> Cc: 20202 <at> debbugs.gnu.org, 20484 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>
> Incidentally, I have looked again at #20484. What ever it is that is
> supporting the directory tracking, it is not the EMACS=t behaviour of
> bash, since in ansi-term we have:
>
> (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
>
> This usage will happily not break cask, since it was never supported in
> the first place.
>
> On the other hand, directory tracking works just fine in M-x shell in
> both Emacs-25.0.91, and Emacs-25 head. So, the EMACS=t setting is not
> an issue there either. And, dir tracking is not an issue at all for M-x
> compile.
>
> This suggests a simple fix: restore beaab89, except for the bit dealing
> with ansi-term, which remains for the sake of future compatability. Both
> bug reports are fixed. Anyone launching cask (or the make files Eli
> Barzilay talked about in #20202) inside ansi-term may still have
> problems.
>
> ansi-term is already exceptional, note, because it does not obey the
> "don't fiddle with EMACS if EMACS is already set" semantics.
EMACS=t is for the old versions of Bash and other shells that look at
that. So your proposal doesn't solve those problems, AFAIU.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 07:05:01 GMT)
Full text and
rfc822 format available.
Message #78 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: phillip.lord <at> russet.org.uk (Phillip Lord)
> Date: Thu, 07 Apr 2016 20:55:02 +0100
> Cc: 20202 <at> debbugs.gnu.org, 20484 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
>
> 1) For bash, launch with -o emacs, or call set -o emacs after launch.
> 2) zsh, launch and call unsetopt zle.
> 3) For tcsh, EMACS=t only needs to be correct during init. So, EMACS=t,
> launch tcsh, set EMACS=what-ever-it-was-before.
> 4) Everything else -- move the "call-process" call to a single function
> which people can advice as they choose.
Thanks. Such solution, if it indeed works, could be OK for master,
but not for emacs-25.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 07:07:01 GMT)
Full text and
rfc822 format available.
Message #81 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 07 Apr 2016 18:20:08 -0400
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 20484 <at> debbugs.gnu.org,
> 20202 <at> debbugs.gnu.org
>
> So, does anything break if we don't have EMACS=t?
> It sounds like it's a non-issue.
That's not my conclusion, as I already wrote.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 07:35:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 20202 <at> debbugs.gnu.org (full text, mbox):
phillip.lord <at> russet.org.uk (Phillip Lord) writes:
> 1) For bash, launch with -o emacs, or call set -o emacs after launch.
set -o emacs has nothing to do with no_line_editing.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 13:10:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 13:13:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> phillip.lord <at> russet.org.uk (Phillip Lord) writes:
>
>> 1) For bash, launch with -o emacs, or call set -o emacs after launch.
>
> set -o emacs has nothing to do with no_line_editing.
Apologies, you are correct. It is emacs line_editing mode.
As it turns out, but #20202 is not actually related to line_editing_mode
anyway.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 13:16:01 GMT)
Full text and
rfc822 format available.
Message #93 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Cc: eggert <at> cs.ucla.edu, phillip.lord <at> russet.org.uk, 20202 <at> debbugs.gnu.org, 20484 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 13:41:01 GMT)
Full text and
rfc822 format available.
Message #96 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: phillip.lord <at> russet.org.uk (Phillip Lord)
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, eggert <at> cs.ucla.edu, 20202 <at> debbugs.gnu.org, 20484 <at> debbugs.gnu.org
> Date: Fri, 08 Apr 2016 14:15:07 +0100
>
> > 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?
Yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 15:34:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Maybe so, but I don't see any problem with that. We just tried to
> make the wait shorter, and see what happened. We should try again in
> few years, maybe the results will be better then. Hopefully.
Waiting won't do anything. One should actively contact maintainers of
affected packages. It's our fault, not theirs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 15:46:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Should we patch the Emacs makefiles to stop making use of $(EMACS) then?
>
> Yes.
Why? Emacs builds fine with "EMACS=blah" in the environment, since it
explicitly sets EMACS as needed. The only issue here is with Makefiles
that use their environment unsanitised.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 16:01:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, phillip.lord <at> russet.org.uk, eggert <at> cs.ucla.edu, 20484 <at> debbugs.gnu.org, 20202 <at> debbugs.gnu.org
> Date: Fri, 08 Apr 2016 11:32:08 -0400
>
> Eli Zaretskii wrote:
>
> > Maybe so, but I don't see any problem with that. We just tried to
> > make the wait shorter, and see what happened. We should try again in
> > few years, maybe the results will be better then. Hopefully.
>
> Waiting won't do anything. One should actively contact maintainers of
> affected packages. It's our fault, not theirs.
We already did. "Waiting" here means wait until the old versions of
the shells die peacefully and people stop using them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 16:03:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: phillip.lord <at> russet.org.uk (Phillip Lord), 20202 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, 20484 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> Date: Fri, 08 Apr 2016 11:45:07 -0400
>
> Eli Zaretskii wrote:
>
> >> Should we patch the Emacs makefiles to stop making use of $(EMACS) then?
> >
> > Yes.
>
> Why?
Because it's safer, and doesn't do any harm.
I agree it isn't the utmost urgency, though.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 16:47:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> We will never recover from bug reports if the behavior they want is
> not the default.
The problem in bug#20484 is not due to a wrong behavior in Emacs but to
a wrong behavior in shells (or at the very least a bad interaction
between the two), so there's no point trying to "fix it" on our
side only, since that just introduces other bugs (witness bug#20202).
Regarding bug#20484 as pointed out by Philip Lord we can address it
without breaking bug#20484 by only reverting the behavior in ansi-term.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 16:50:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> EMACS=t is for the old versions of Bash and other shells that look at
> that.
What change in behavior has been observed by removing EMACS=t from comint?
As far as I can tell, nobody has reported any change of behavior yet.
Bug#20484 is about another removal (the one in ansi-term), so it's
actually not relevant.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 17:13:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 04/08/2016 09:46 AM, Stefan Monnier wrote:
> Regarding bug#20484 as pointed out by Philip Lord we can address it
> without breaking bug#20484 by only reverting the behavior in ansi-term.
Yes, this is the direction I'm heading as well. Thanks, Philip, for
doing all the legwork on other shells. As Philip implies, Bash will need
another fix before Bash 4.4 goes out, and I'm working on that now. I'll
CC: here.
What a mess, eh?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 17:49:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Fri, April 8, 2016 5:46 pm, Stefan Monnier wrote:
>> We will never recover from bug reports if the behavior they want is
>> not the default.
>
> The problem in bug#20484 is not due to a wrong behavior in Emacs but to
> a wrong behavior in shells (or at the very least a bad interaction between
> the two), so there's no point trying to "fix it" on our side only, since
> that just introduces other bugs (witness bug#20202).
I think the problem, at heart, stems from bash trying do the right thing
for Emacs. This is not made any easier by the fact that Emacs needs
different things, depending on whether we are in shell or ansi-term.
Really, Emacs should just explicitly request which features it needs,
rather than saying "I am Emacs, now be right".
> Regarding bug#20484 as pointed out by Philip Lord we can address it
> without breaking bug#20484 by only reverting the behavior in ansi-term.
And there is a simple workaround should we wish for consistent EMACS
behaviour in shell and term, which can be applied with in .bashrc or
having Emacs inject a command into the new shell.
It's "Phillip" actually --- the misspelling is one of the reasons I
normally go by "Phil".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 18:13:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Fri, April 8, 2016 5:49 pm, Stefan Monnier wrote:
>> EMACS=t is for the old versions of Bash and other shells that look at
>> that.
>
> What change in behavior has been observed by removing EMACS=t from
> comint?
>
> As far as I can tell, nobody has reported any change of behavior yet.
>
I worried about this -- why did line-editing not cause problems, given
that it is this that EMACS=t disables.
So I tested this by doing this:
bind -x '"\C-r"':reset
which gives a warning
bash: bind: warning: line editing not enabled
It turns out that M-x shell gives a warning in emacs-25 head AND
emacs-25.0.91. So it appears that the bash EMACS=t handling is redundant,
at least with respect to line editing. M-x shell passed --noediting
through explicit-bash-args.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 18:15:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Fri, April 8, 2016 6:12 pm, Paul Eggert wrote:
> On 04/08/2016 09:46 AM, Stefan Monnier wrote:
>
>> Regarding bug#20484 as pointed out by Philip Lord we can address it
>> without breaking bug#20484 by only reverting the behavior in ansi-term.
>
> Yes, this is the direction I'm heading as well. Thanks, Philip, for
> doing all the legwork on other shells. As Philip implies, Bash will need
> another fix before Bash 4.4 goes out, and I'm working on that now. I'll
> CC: here.
>
>
> What a mess, eh?
A whole set of decisions which, individually, make sense all conspiring to
produce a disaster.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 18:48:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 20202 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/tmp/prefix/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DDEBUG -DMALLOC_DEBUG -I. -I.
-I./include -I./lib -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux penguin.cs.ucla.edu 4.4.6-300.fc23.x86_64 #1 SMP Wed
Mar 16 22:10:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 0
Release Status: rc1
Description:
Please see attached patch.
Repeat-By:
Please see attached patch.
Fix:
Please see attached patch.
[0001-Fix-compatibility-problem-with-INSIDE_EMACS-etc.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 20:51:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 20202 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for persisting with this, Phillip, and for doing the legwork in
seeing what other shells do. It does seem that the EMACS='t' setting can
safely be removed, given what we've seen. We will still need the
EMACS='25.1 (term:0.96)' setting in term-exec-1 for quite some time, for
compatibility with Bash 4.3 and earlier. I installed the attached patch
into emacs-25 to try to get this done for the next release. This should
not affect Bug#20484, which should still be fixed. Most of Bug#20202
should be fixed now; the exceptions are M-x term and the like.
[0001-Comint-and-compile-no-longer-set-EMACS.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 08 Apr 2016 21:21:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Thanks for persisting with this, Phillip, and for doing the legwork in seeing
> what other shells do.
No worries, and apologies for being somewhat grumpy at the start. We
seem to have a solution now, which is the main thing.
> It does seem that the EMACS='t' setting can safely be removed, given
> what we've seen. We will still need the EMACS='25.1 (term:0.96)'
> setting in term-exec-1 for quite some time, for compatibility with
> Bash 4.3 and earlier. I installed the attached patch into emacs-25 to
> try to get this done for the next release. This should not affect
> Bug#20484, which should still be fixed. Most of Bug#20202 should be
> fixed now; the exceptions are M-x term and the like.
I think this is a good compromise. Although, it's too late for Emacs
25.1, it would be possible to work around #20484 in other ways, and
maybe get dir-tracking working for other shells also.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 09 Apr 2016 02:26:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> Waiting won't do anything. One should actively contact maintainers of
>> affected packages. It's our fault, not theirs.
>
> We already did.
Please note that the list of affected applications may include things
other than shells; eg
http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00035.html
http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00084.html
http://www.swi-prolog.org/pldoc/man?section=flags
"SWI-Prolog assumes this is the case if the environment variable EMACS
is t"
Since it is impossible to construct the definitive list of affected
applications, that is why I am personally pessimistic about being able
to change this without use of Emacs SOP: change it and see what breaks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 09 Apr 2016 08:44:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Sat, April 9, 2016 3:24 am, Glenn Morris wrote:
> Eli Zaretskii wrote:
>
> Please note that the list of affected applications may include things
> other than shells; eg
>
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00035.html
>
> http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-11/msg00084.html
>
>
> http://www.swi-prolog.org/pldoc/man?section=flags
> "SWI-Prolog assumes this is the case if the environment variable EMACS
> is t"
>
> Since it is impossible to construct the definitive list of affected
> applications, that is why I am personally pessimistic about being able to
> change this without use of Emacs SOP: change it and see what breaks.
So SWI-Prolog does still do this...
if ( ((s = Getenv("EMACS", envbuf, sizeof(envbuf))) && s[0]) ||
((s = Getenv("INFERIOR", envbuf, sizeof(envbuf))) && streq(s,
"yes")) )
although, AFAICT, it just checks for EMACS=anything at all, so it's
possible to workaround this in a way consistent with
EMACS=location-of-emacs.
I'll contact them.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 09 Apr 2016 13:44:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> http://www.swi-prolog.org/pldoc/man?section=flags
> "SWI-Prolog assumes this is the case if the environment variable EMACS
> is t"
And here again, the page doesn't actually describe what would be the
consequence of a missing EMACS=t setting. For all we know, it works
just fine without it.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 09 Apr 2016 21:57:01 GMT)
Full text and
rfc822 format available.
Message #147 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Sat, April 9, 2016 2:43 pm, Stefan Monnier wrote:
>> http://www.swi-prolog.org/pldoc/man?section=flags
>> "SWI-Prolog assumes this is the case if the environment variable EMACS
>> is t"
>
> And here again, the page doesn't actually describe what would be the
> consequence of a missing EMACS=t setting. For all we know, it works just
> fine without it.
They've just patched SWI-Prolog to look at INSIDE_EMACS anyway.
I'm guessing that anyone who wants the EMACS=t behaviour should be able to
get it back by adding (setenv "EMACS" "t") to their .emacs?
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 09 Apr 2016 23:41:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Phillip Lord wrote:
> They've just patched SWI-Prolog to look at INSIDE_EMACS anyway.
Amusingly enough, the SWI-Prolog implementation (both unpatched and patched)
disagrees with its documentation, which says SWI-Prolog assumes it is running
under Emacs "if the environment variable EMACS is 't' and INFERIOR is 'yes'."
Note the restriction to 't' in the documentation (which the code does not
enforce). Note also the "and" in the documentation (the code uses "||").
It sounds like this stuff isn't exercised much....
> I'm guessing that anyone who wants the EMACS=t behaviour should be able to
> get it back by adding (setenv "EMACS" "t") to their .emacs?
Yes, that works. Or in practice for SWI-Prolog (setenv "INFERIOR" "yes") should
also do the trick.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 00:10:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Yes, that works. Or in practice for SWI-Prolog (setenv "INFERIOR" "yes")
> should also do the trick.
"Do the trick" to get what, exactly?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 03:31:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 20202 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan Monnier wrote:
> "Do the trick" to get what, exactly?
It causes the predicate 'current_prolog_flag(emacs_inferior_process, X)' to
succeed with X=true, and it causes SWI-Prolog to not attempt to put the terminal
into raw mode. Although the former doesn't seem to do much of anything, latter
affects the UI, notably the debugger. For example, SWI-Prolog 7.2.3 in Emacs 24
under M-x run-prolog:
?- trace, member(X, [a,b,c]).
Call: (8) lists:member(_G2, [a, b, c]) ? a
% Execution Aborted
?-
The same interaction in emacs-25 now:
1 ?- trace, member(X, [a,b,c]).
Call: (8) lists:member(_G2, [a, b, c]) ? a
abort
% Execution Aborted
2 ?-
I suppose the differences might be annoying to someone who does a lot of Prolog
debugging. To give some perspective, although I am annoyed whenever I have to
debug GNU Prolog under Emacs due to gprolog's mishandling of tty modes under
Emacs, this is something I've never gotten sufficiently annoyed at to fix, even
though it's been ten years since I first ran afoul of it.
One possible workaround would be something like the attached patch, which relies
on SWI-Prolog's behavior of assuming GNU Emacs when INFERIOR=yes in the environment.
[prolog.diff (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 07:15:01 GMT)
Full text and
rfc822 format available.
Message #159 received at 20202 <at> debbugs.gnu.org (full text, mbox):
"Phillip Lord" <phillip.lord <at> russet.org.uk> writes:
> I'm guessing that anyone who wants the EMACS=t behaviour should be able to
> get it back by adding (setenv "EMACS" "t") to their .emacs?
Not for remote processes.
> Phil
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 08:26:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Sun, April 10, 2016 12:40 am, Paul Eggert wrote:
> Phillip Lord wrote:
>
>> They've just patched SWI-Prolog to look at INSIDE_EMACS anyway.
>>
>
> Amusingly enough, the SWI-Prolog implementation (both unpatched and
> patched) disagrees with its documentation, which says SWI-Prolog assumes
> it is running under Emacs "if the environment variable EMACS is 't' and
> INFERIOR is 'yes'."
>
>
> Note the restriction to 't' in the documentation (which the code does not
> enforce). Note also the "and" in the documentation (the code uses "||").
Yes, I noticed that as well. I couldn't patch the documentation because I
couldn't find the source.
> It sounds like this stuff isn't exercised much....
I wouldn't conclude that; more likely, it just works so no one has looked.
The situation with bash is the same -- Emacs requests --noediting, but
bash detects Emacs and enforces noediting anyway.
Phil
>
>> I'm guessing that anyone who wants the EMACS=t behaviour should be able
>> to get it back by adding (setenv "EMACS" "t") to their .emacs?
>
> Yes, that works. Or in practice for SWI-Prolog (setenv "INFERIOR" "yes")
> should also do the trick.
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 08:27:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Sun, April 10, 2016 1:08 am, Stefan Monnier wrote:
>> Yes, that works. Or in practice for SWI-Prolog (setenv "INFERIOR"
>> "yes")
>> should also do the trick.
>
> "Do the trick" to get what, exactly?
Didn't look at the code deeply, but to switch off line editing.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 08:52:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On Sun, April 10, 2016 8:13 am, Michael Albinus wrote:
> "Phillip Lord" <phillip.lord <at> russet.org.uk> writes:
>
>
>> I'm guessing that anyone who wants the EMACS=t behaviour should be able
>> to get it back by adding (setenv "EMACS" "t") to their .emacs?
>
> Not for remote processes.
Didn't think of that. Can tramp be hooked to add this back, if needed?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 09:33:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 20202 <at> debbugs.gnu.org (full text, mbox):
"Phillip Lord" <phillip.lord <at> russet.org.uk> writes:
>>> I'm guessing that anyone who wants the EMACS=t behaviour should be able
>>> to get it back by adding (setenv "EMACS" "t") to their .emacs?
>>
>> Not for remote processes.
>
> Didn't think of that. Can tramp be hooked to add this back, if needed?
One could add it to tramp-remote-process-environment.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 12:19:01 GMT)
Full text and
rfc822 format available.
Message #174 received at submit <at> debbugs.gnu.org (full text, mbox):
"Phillip Lord" <phillip.lord <at> russet.org.uk> writes:
> Yes, I noticed that as well. I couldn't patch the documentation because I
> couldn't find the source.
The source of the SWI documentation is in the "man" directory, see
overview.doc. Please file pull requests for swipl-devel (not swipl).
Thank you for looking into this!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 13:58:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> ?- trace, member(X, [a,b,c]).
> Call: (8) lists:member(_G2, [a, b, c]) ? a
> % Execution Aborted
> ?-
>
> The same interaction in emacs-25 now:
>
> 1 ?- trace, member(X, [a,b,c]).
> Call: (8) lists:member(_G2, [a, b, c]) ? a
> abort
> % Execution Aborted
> 2 ?-
Hmm.. what are those "abort" and "2" in the output?
When running swipl inside a terminal I don't see these, so why do we see
them in M-x run-prolog?
> I suppose the differences might be annoying to someone who does a lot of
> Prolog debugging.
Indeed.
> I have to debug GNU Prolog under Emacs due to gprolog's mishandling of tty
> modes under Emacs, this is something I've never gotten sufficiently annoyed
> at to fix, even though it's been ten years since I first ran afoul of it.
FWIW, the current prolog.el has some tweaks for GNU Prolog which might
be relevant. So you might like to try again and see if the problem is
still present. If not, report it as a bug (and put me in X-Debbugs-Cc).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sun, 10 Apr 2016 14:00:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Didn't look at the code deeply, but to switch off line editing.
That still doesn't say what changes, concretely.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Mon, 11 Apr 2016 05:51:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> Hmm.. what are those "abort" and "2" in the output?
>
> When running swipl inside a terminal I don't see these, so why do we see
> them in M-x run-prolog?
I'm afraid I don't know, and don't have the patience to find out. The SWI-Prolog
source code is not immediately obvious, and it doesn't appear to agree with its
documentation. Rather than fool around with it I simply installed the
INFERIOR=yes workaround into emacs-25/lisp/progmodes/prolog.el.
> FWIW, the current prolog.el has some tweaks for GNU Prolog which might
> be relevant. So you might like to try again and see if the problem is
> still present. If not, report it as a bug (and put me in X-Debbugs-Cc).
Thanks. Until yesterday I didn't know about M-x run-prolog. I just ran gprolog
in a M-x shell window, which doesn't work well. I'll try to remember to use M-x
run-prolog from now on.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Mon, 11 Apr 2016 12:33:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Didn't look at the code deeply, but to switch off line editing.
>
> That still doesn't say what changes, concretely.
Well, what ever it doesn't do without EMACS=t, it will now, since it's
all been patched. I think I can stop worrying about it.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Mon, 11 Apr 2016 12:39:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Markus Triska <triska <at> metalevel.at> writes:
> "Phillip Lord" <phillip.lord <at> russet.org.uk> writes:
>
>> Yes, I noticed that as well. I couldn't patch the documentation because I
>> couldn't find the source.
>
> The source of the SWI documentation is in the "man" directory, see
> overview.doc. Please file pull requests for swipl-devel (not swipl).
I sent the PR here, and it's been merged.
https://github.com/SWI-Prolog/swipl/pull/6
Are you saying that this is wrong?
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 24 May 2018 20:48:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Well, it hardly seems like Mon, 11 Apr 2016 since last we discussed this
issue.
If you remember, we managed to blitz, EMACS=t everywhere, then Paul
restored it in term.el because it broke bash otherwise. master currently
looks like this:
;; This is for backwards compatibility with Bash 4.3 and earlier.
;; Remove this hack once Bash 4.4-or-later is common, because
;; it breaks './configure' of some packages that expect it to
;; say where to find EMACS.
(format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
I worry that "Bash 4.4 or later is common" is rather indeterminate; my
desktop is now 4.4.19. but another machine I am using has bash
4.2.46. Given that Emacs-26 is now destined to come out with
EMACS=26.1.0, I would like to propose that we now remove this on master,
i.e. make it happen for Emacs-27 which should be in about 2020.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 24 May 2018 20:54:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> I worry that "Bash 4.4 or later is common" is rather indeterminate; my
At least Debian's stable (stretch) is on bash-4.4 (but still at 4.3 in
oldstable (jessie)).
> desktop is now 4.4.19. but another machine I am using has bash
> 4.2.46. Given that Emacs-26 is now destined to come out with
> EMACS=26.1.0, I would like to propose that we now remove this on master,
> i.e. make it happen for Emacs-27 which should be in about 2020.
Sounds good to me: by the time Emacs-27 comes out, Debian's oldstable
will be stretch (hence at 4.4).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 24 May 2018 22:05:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Bash 4.4 came out only in September 2016, and it's too soon to assume
it. For example, my students regularly use Emacs on a server running
RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
most recent RHEL available.
How about this idea: At Emacs build time, we check whether Bash is 4.4
or later, and if so we use a term.el that assumes bash 4.4 or later.
Otherwise, we use a term.el that interrogates the shell dynamically for
whether it is shell and if so what its version number is, the first time
that Emacs runs a process under a shell.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 02:26:01 GMT)
Full text and
rfc822 format available.
Message #201 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Paul Eggert writes:
>
> this is the most recent RHEL available
You could have your sclerotic institution’s IT manager provide Enterprise RHEL for students studying topics as old as the hills and mountains (and they won’t change) and request them to “think" about the latest unstable Fedora or Debian or Ubuntu releases for research oriented experimental AI & CS “work” which are hot career topics and ought not to be held back by bureaucratically convenient RHEL IT hell. Ask them for what Tesla or Uber or Facebook or Google use to keep up with “innovation” before it is "too late" on RHEL.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 06:14:01 GMT)
Full text and
rfc822 format available.
Message #204 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Van L <van <at> scratch.space> writes:
>> Paul Eggert writes:
>>
>> this is the most recent RHEL available
>
> You could have your sclerotic institution’s IT manager provide
> Enterprise RHEL for students studying topics as old as the hills and
> mountains (and they won’t change) and request them to “think" about
> the latest unstable Fedora or Debian or Ubuntu releases for research
> oriented experimental AI & CS “work” which are hot career topics and
> ought not to be held back by bureaucratically convenient RHEL IT
> hell. Ask them for what Tesla or Uber or Facebook or Google use to
> keep up with “innovation” before it is "too late" on RHEL.
This is not constructive.
There are even RHEL 6 deployments out there, because it’s still
supported until 2020. There are people who pay for the privilege of not
having to upgrade.
--
Ricardo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 06:17:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 24 May 2018 15:03:56 -0700
> Cc: 20202 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 20484 <at> debbugs.gnu.org
>
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it.
I agree, 1.5 years is too soon. I think we need 5 years at least.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or later.
> Otherwise, we use a term.el that interrogates the shell dynamically for
> whether it is shell and if so what its version number is, the first time
> that Emacs runs a process under a shell.
The first part will only work if Emacs is used on the same system
where it is built, right? Is that a good assumption, given all the
binary distributions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 07:29:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Eli Zaretskii writes:
>
>> Bash 4.4 came out only in September 2016, and it's too soon to assume
>> it.
>
> I agree, 1.5 years is too soon. I think we need 5 years at least.
How about applying the 5-multiplier to 9-month cycles?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 08:05:01 GMT)
Full text and
rfc822 format available.
Message #213 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Van L <van <at> scratch.space>
> Date: Fri, 25 May 2018 17:28:31 +1000
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, emacs-devel <at> gnu.org,
> 20202 <at> debbugs.gnu.org, 20484 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca, phillip.lord <at> russet.org.uk
>
> > I agree, 1.5 years is too soon. I think we need 5 years at least.
>
> How about applying the 5-multiplier to 9-month cycles?
I think you are confusing this with an entirely different domain.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 18:00:02 GMT)
Full text and
rfc822 format available.
Message #216 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 05/24/2018 07:25 PM, Van L wrote:
> Ask them for what Tesla or Uber or Facebook or Google use
I just checked the first company mentioned on your list (Tesla) and it
is posting want-ads that ask for Red Hat expertise. Unfortunately I
can't disclose what I privately know about Tesla, but suffice it to say
that like most other successful companies they use a wide variety of
systems in their work, and not all of these systems are the very latest
version of everything.
> I can understand the excuse for long-term-support system contracts but not for the poster’s student environment.
>
> You refer to lazy privileged people
I'm afraid there's a misunderstanding here. At UCLA we have a wide
variety of systems running many different OSes. Servers at UCLA run many
operating systems; it's quite a gamut, as we have a lot of departments
and research groups, most of which focus on areas other than computer
science and who have a lot of software of varying quality that they
don't necessarily have time or budget to upgrade or maintain
extensively. The courses I teach are assigned to a batch of RHEL 7
servers that support many different courses, not just mine. I do not
specify or maintain the server OSes; that's a responsibility of the
operations staff of the School of Engineering, and they're busy people
who do not report to me.
To help keep my course material up-to-date I install copies of the
latest released versions of Emacs (currently 25.3), Bash (currently
4.4.19), and many other free software programs. (I don't overwrite
/usr/bin of course; I install into a separate directory that students
put into their PATH settings.) So it'll be little trouble to me or my
students if Emacs requires Bash 4.4 or later. When I mentioned RHEL 7, I
wasn't simply talking about my personal situation; I was observing that
requiring Bash 4.4 would be a hassle for people installing newer Emacs
versions onto Red Hat servers, as it would require these people to also
install newer Bash versions. If it's important for Emacs to require Bash
4.4 of course Emacs can do so; still, I expect that the overall hassle
to Emacs users of requiring Bash 4.4 still outweighs the relatively
minor technical benefit in question. Sorry, but that's how things often
work in production software.
With all this in mind you might want to rethink your comments that among
other things seem to imply that the staff at UCLA consists of "lazy
privileged people".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 20:37:02 GMT)
Full text and
rfc822 format available.
Message #219 received at 20202 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/24/2018 01:46 PM, Phillip Lord wrote:
> I would like to propose that we now remove this on master,
>
Given the compatibility concerns expressed, how about the attached patch
instead? The idea is to remove the need to setenv EMACS with newer
Bashes, while still setting EMACS for older Bashes, for backward
compatibility.
[0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 22:35:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Bash 4.4 came out only in September 2016, and it's too soon to assume
> it. For example, my students regularly use Emacs on a server running
> RHEL 7, which ships Bash 4.2.46, and as I understand it, this is the
> most recent RHEL available.
Well, Emacs-27 will come out in 2020, so that's 4 years lead time. And
the most recent of RHEL also ships with Emacs-24. So, by the time RHEL
ships Emacs-27, good chance it will ship Bash 4.4.
> How about this idea: At Emacs build time, we check whether Bash is 4.4
> or later, and if so we use a term.el that assumes bash 4.4 or
> later. Otherwise, we use a term.el that interrogates the shell
> dynamically for whether it is shell and if so what its version number
> is, the first time that Emacs runs a process under a shell.
Well, the latter half we could do (I don't think the build idea makes
sense). But I was hoping to make life simpler, not more complex.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 25 May 2018 22:50:02 GMT)
Full text and
rfc822 format available.
Message #225 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 05/24/2018 01:46 PM, Phillip Lord wrote:
>> I would like to propose that we now remove this on master,
>>
>
> Given the compatibility concerns expressed, how about the attached
> patch instead? The idea is to remove the need to setenv EMACS with
> newer Bashes, while still setting EMACS for older Bashes, for backward
> compatibility.
>
> From f7efdc4d21c22a81398b06cdc58144ec2f9c7697 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 25 May 2018 13:25:51 -0700
> Subject: [PROPOSED] =?UTF-8?q?Don=E2=80=99t=20set=20EMACS=3Dt=20if=20Bash?=
> =?UTF-8?q?=20is=204.4=20or=20newer?=
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> * lisp/term.el (term--bash-needs-EMACS-status): New var.
> (term--bash-needs-EMACSp): New function.
> (term-exec-1): Use it instead of always setting EMACS.
> ---
> lisp/term.el | 31 +++++++++++++++++++++++++------
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/lisp/term.el b/lisp/term.el
> index 017b0221ec..fa43774ae8 100644
> --- a/lisp/term.el
> +++ b/lisp/term.el
> @@ -1489,6 +1489,26 @@ term-termcap-format
> ;; don't define :te=\\E[2J\\E[?47l\\E8:ti=\\E7\\E[?47h\
> "Termcap capabilities supported.")
>
> +;; This is for backwards compatibility with Bash 4.3 and earlier.
> +;; Remove this hack once Bash 4.4-or-later is reasonably universal, because
> +;; it slows down execution slightly, just before the first subshell.
> +(defvar term--bash-needs-EMACS-status nil
> + "43 if Bash is so old that it needs EMACS set.
> +Some other integer if Bash is new or not in use.
> +Nil if unknown.")
> +(defun term--bash-needs-EMACSp ()
> + "t if Bash is old, nil if it is new or not in use."
> + (unless term--bash-needs-EMACS-status
> + (let ((process-environment (copy-sequence process-environment)))
> + (setenv "BASH_ENV")
> + (setq term--bash-needs-EMACS-status
> + (condition-case nil
> + (call-process
> + "bash" nil nil nil "-c"
> + "case $BASH_VERSION in [0123].*|4.[0123].*) exit 43;; esac")
> + (error 0)))))
> + (eq 43 term--bash-needs-EMACS-status))
> +
> ;; This auxiliary function cranks up the process for term-exec in
> ;; the appropriate environment.
>
> @@ -1506,12 +1526,6 @@ term-exec-1
> (format term-termcap-format "TERMCAP="
> term-term-name term-height term-width)
>
> - ;; This is for backwards compatibility with Bash 4.3 and earlier.
> - ;; Remove this hack once Bash 4.4-or-later is common, because
> - ;; it breaks './configure' of some packages that expect it to
> - ;; say where to find EMACS.
> - (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
> -
> (format "INSIDE_EMACS=%s,term:%s" emacs-version term-protocol-version)
> (format "LINES=%d" term-height)
> (format "COLUMNS=%d" term-width))
> @@ -1523,6 +1537,11 @@ term-exec-1
> ;; escape codes, so we need to see the raw output. We will have to
> ;; do the decoding by hand on the parts that are made of chars.
> (coding-system-for-read 'binary))
> + (when (term--bash-needs-EMACSp)
> + (setq process-environment
> + (cons
> + (format "EMACS=%s (term:%s)" emacs-version term-protocol-version)
> + process-environment)))
> (apply 'start-process name buffer
> "/bin/sh" "-c"
> (format "stty -nl echo rows %d columns %d sane 2>/dev/null;\
It's a solution, afaict. However, one which is more complex than we
already have. The problem with RHEL probably only effects weird people
like you (and me!) who use a stock bash on an old RHEL, then compile the
latest Emacs. And us weird people could probably circumvent the problem
with term anyway.
You, Stefan and Eli have far more experience here clearly. Happy with
what ever you decide.
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Sat, 26 May 2018 07:22:01 GMT)
Full text and
rfc822 format available.
Message #228 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 25 May 2018 13:36:03 -0700
> Cc: 20202 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 20484 <at> debbugs.gnu.org
>
> Given the compatibility concerns expressed, how about the attached patch
> instead?
I like it because it is future proof, and makes our burden of
remembering this issue easier.
Thanks.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sat, 26 May 2018 20:55:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Eli Barzilay <eli <at> barzilay.org>:
bug acknowledged by developer.
(Sat, 26 May 2018 20:55:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 20202-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii wrote:
> I like it because it is future proof, and makes our burden of
> remembering this issue easier.
>
> Thanks.
You're welcome. Stefan privately emailed me some helpful comments that improved
the patch (thanks!), and I installed the attached into master. In the hope that
this has laid Bug#20202 to rest (at least on modern GNU systems running Bash 4.4
or later), I'm boldly closing the bug report.
[0001-Don-t-set-EMACS-t-if-Bash-is-4.4-or-newer.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 31 May 2018 21:14:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 20202-done <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> Eli Zaretskii wrote:
>
>> I like it because it is future proof, and makes our burden of
>> remembering this issue easier.
>>
>> Thanks.
>
> You're welcome. Stefan privately emailed me some helpful comments that
> improved the patch (thanks!), and I installed the attached into
> master. In the hope that this has laid Bug#20202 to rest (at least on
> modern GNU systems running Bash 4.4 or later), I'm boldly closing the
> bug report.
Not wishing to reopen the bug report that you have so boldly closed,
given that this would appear to be a conservative change rather than the
breaking one I was suggesting, any reason why this can't be installed
on emacs-26?
Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 31 May 2018 23:47:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 20202-done <at> debbugs.gnu.org (full text, mbox):
On 05/31/2018 02:07 PM, Phillip Lord wrote:
> any reason why this can't be installed
> on emacs-26?
None that I know of. Will there be a 26.2, though?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 01 Jun 2018 01:57:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 20202-done <at> debbugs.gnu.org (full text, mbox):
> None that I know of. Will there be a 26.2, though?
I'd be surprised if we don't need to make a 26.2 before 27.1.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 01 Jun 2018 07:05:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 20484 <at> debbugs.gnu.org, emacs-devel <at> gnu.org,
> 20202-done <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> Eli Barzilay <eli <at> barzilay.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 31 May 2018 16:45:59 -0700
>
> On 05/31/2018 02:07 PM, Phillip Lord wrote:
> > any reason why this can't be installed
> > on emacs-26?
>
> None that I know of. Will there be a 26.2, though?
Yes, I'm quite sure it will be. So if we want this change backported
to Emacs 26.2, we can do that now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 01 Jun 2018 14:10:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 20202 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> if we want this change backported to Emacs 26.2, we can do that now.
Phillip prefers that, and I do too. Any objections?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Fri, 01 Jun 2018 14:16:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 20202 <at> debbugs.gnu.org (full text, mbox):
> Cc: eli <at> barzilay.org, emacs-devel <at> gnu.org, 20202 <at> debbugs.gnu.org,
> phillip.lord <at> russet.org.uk, 20484 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 1 Jun 2018 07:08:56 -0700
>
> Eli Zaretskii wrote:
> > if we want this change backported to Emacs 26.2, we can do that now.
>
> Phillip prefers that, and I do too. Any objections?
Not from me.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20202; Package
emacs.
(Thu, 14 Jun 2018 20:55:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 20202 <at> debbugs.gnu.org (full text, mbox):
On 06/01/2018 07:14 AM, Eli Zaretskii wrote:
>> Eli Zaretskii wrote:
>>> if we want this change backported to Emacs 26.2, we can do that now.
>> Phillip prefers that, and I do too. Any objections?
> Not from me.
>
> Thanks.
You're welcome. I installed that patch into the emacs-26 branch.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 13 Jul 2018 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 37 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.