GNU bug report logs -
#20484
25.0.50; Directory tracking in ansi-term broken.
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20484 in the body.
You can then email your comments to 20484 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#20484; Package
emacs.
(Sat, 02 May 2015 00:46:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jacob Oursland <jacob.oursland <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 02 May 2015 00:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
My inferior shell is bash. I have confirmed that this problem exists
with 'emacs -Q'. Re-setting my PS1 to the bash default PS1='\h:\w\$ '
and starting Emacs didn't help either.
Steps to reproduce:
1. emacs -Q
2. M-x ansi-term RET RET
3. cd /tmp (or any other directory)
4. C-x C-f
Expected behavior:
Emacs will indicate the shell's working directory (/tmp) in the
find-file minibuffer prompt.
Actual behavior:
Emacs indicates the Emacs working directory working directory ($HOME,
for me) in the find-file minibuffer prompt.
I found that if I revert commit aad65192332dfc4a1df0cd2953554c21da243b51
the problem goes away.
In GNU Emacs 25.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.8)
of 2015-04-19 on lgw01-10
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description: Ubuntu 14.04.2 LTS
Configured using:
`configure --build=x86_64-linux-gnu --prefix=/usr
'--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
'--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
'--libdir=${prefix}/lib/x86_64-linux-gnu'
'--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
--program-suffix=-snapshot --with-x=yes --with-x-toolkit=gtk3
'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security' CPPFLAGS=-D_FORTIFY_SOURCE=2
'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
TeX-PDF-mode: t
global-auto-complete-mode: t
dirtrack-debug-mode: t
magit-auto-revert-mode: t
diff-auto-refine-mode: t
elisp-slime-nav-mode: t
display-time-mode: t
shell-dirtrack-mode: t
global-company-mode: t
company-mode: t
xterm-mouse-mode: t
winner-mode: t
which-function-mode: t
show-paren-mode: t
global-auto-revert-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
Recent messages:
Creating group entries...done
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
Auto-saving...done
Save all settings in this buffer? (y or n) y
Saving file /home/jso/.emacs.d/init.el...
Wrote /home/jso/.emacs.d/init.el [2 times]
Mark set [4 times]
Buffer *unsent mail to bug-gnu-emacs <at> gnu.org* modified; kill anyway? (y or
n) y
Load-path shadows:
/home/jso/.emacs.d/elpa/cmake-mode-20150120.620/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/site-lisp/rst hides
/usr/share/emacs/25.0.50/lisp/textmodes/rst
/usr/share/emacs/site-lisp/dictionaries-common/ispell hides
/usr/share/emacs/25.0.50/lisp/textmodes/ispell
/usr/share/emacs/site-lisp/dictionaries-common/flyspell hides
/usr/share/emacs/25.0.50/lisp/textmodes/flyspell
~/.emacs.d/cc-mode/cc-guess hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-guess
~/.emacs.d/cc-mode/cc-vars hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-vars
~/.emacs.d/cc-mode/cc-mode hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-mode
~/.emacs.d/cc-mode/cc-bytecomp hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-bytecomp
~/.emacs.d/cc-mode/cc-styles hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-styles
~/.emacs.d/cc-mode/cc-fonts hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-fonts
~/.emacs.d/cc-mode/cc-menus hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-menus
~/.emacs.d/cc-mode/cc-cmds hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-cmds
~/.emacs.d/cc-mode/cc-align hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-align
~/.emacs.d/cc-mode/cc-engine hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-engine
~/.emacs.d/cc-mode/cc-defs hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-defs
~/.emacs.d/cc-mode/cc-awk hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-awk
~/.emacs.d/cc-mode/cc-langs hides
/usr/share/emacs/25.0.50/lisp/progmodes/cc-langs
/usr/share/emacs/site-lisp/latex-cjk-thai/thai-word hides
/usr/share/emacs/25.0.50/lisp/language/thai-word
~/.emacs.d/cc-mode/cc-compat hides
/usr/share/emacs/25.0.50/lisp/obsolete/cc-compat
Features:
(uudecode uce supercite regi spam-report spam spam-stat gnus-uu yenc
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig smtpmail
sieve-manage rmail pop3 mspools mh-e mh-compat mh-acros mh-buffers
mh-loaddefs mairix mailclient browse-url mailalias mail-hist imap
hashcash gnus-dired fortune feedmail eudc-vars ecomplete binhex apropos
footnote shadow sort mail-extr emacsbug sendmail mm-archive url-handlers
eieio-opt speedbar sb-image ezimage dframe pcmpl-unix em-unix em-term
em-script em-prompt em-ls em-hist em-pred em-glob em-dirs em-cmpl
em-basic em-banner em-alias magit-blame cmake-mode ruler-mode hl-line
hexl smerge-mode ert timezone texinfo toolbar-x prv-emacs reporter
desktop frameset context plain-tex latex tex-style tex-buf tex dbus xml
crm tempo company-dabbrev hippie-exp debug json irony-cdb jedi-core
python-environment epc ctable concurrent deferred ediff-merg ediff-wind
ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff dired-x
org-rmail org-mhe org-irc org-info org-gnus org-docview org-bibtex
org-bbdb org-w3m rng-loc rng-uri rng-parse rng-match rng-dt rng-util
rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar ox-html table ox-ascii ox-publish ox org-element org-table
org-agenda esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg
esh-groups eshell esh-module esh-mode esh-util doc-view jka-compr
image-mode bibtex org-id org org-macro org-footnote org-pcomplete
org-list org-faces org-entities org-version ob-python ob-emacs-lisp
org-loaddefs cal-menu calendar cal-loaddefs gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc
nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems
nnheader ob-octave noutline outline calc calc-loaddefs calc-macs ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs rx auto-complete rtags popup repeat
bookmark company-template warnings autoload lisp-mnt tar-mode url-http
url-gw url-cache url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
url-vars mailcap sgml-mode make-mode novice dirtrack sql socks
network-stream nsm starttls tls rlogin proced metamail gud flyspell
ispell pp cus-edit wid-edit magit-key-mode magit view grep epa derived
epg git-rebase-mode git-commit-mode log-edit message dired rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader pcvs-util xterm
conf-mode add-log sh-script smie executable thingatpt misearch
multi-isearch vc vc-dispatcher vc-git diff-mode cpp cc-mode cc-fonts
cc-awk cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-langs
cc-vars cc-defs cc-bytecomp tabify man tramp-cache elisp-slime-nav
help-mode company-cmake company-irony irony-completion irony-snippet
server term disp-table ehelp powerline time cl windmove ido tramp
tramp-compat auth-source gnus-util mm-util mail-prsvr password-cache
tramp-loaddefs trampver shell pcomplete format-spec advice help-fns
irony find-func company easy-mmode cl-macs ggtags etags xref eieio
eieio-core cl-generic byte-opt gv bytecomp byte-compile cl-extra seq
cconv compile comint ansi-color ewoc edmacro kmacro cl-loaddefs pcase
cl-lib finder-inf tex-site info easymenu package epg-config saveplace
leuven-theme xt-mouse winner ring which-func imenu paren autorevert
filenotify cus-start cus-load mule-util time-date tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face
macroexp files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind gfilenotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)
Memory information:
((conses 16 5101727 455519)
(symbols 48 74114 0)
(miscs 40 12397 14840)
(strings 32 207635 114021)
(string-bytes 1 6335085)
(vectors 16 79150)
(vector-slots 8 2022361 83492)
(floats 8 982 3084)
(intervals 56 838741 22842)
(buffers 976 184)
(heap 1024 216591 159638))
[Message part 2 (text/html, inline)]
Added indication that bug 20484 blocks19759
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 02 May 2015 00:48:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sat, 02 May 2015 02:18:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 20484 <at> debbugs.gnu.org (full text, mbox):
Jacob Oursland wrote:
> 1. emacs -Q
> 2. M-x ansi-term RET RET
> 3. cd /tmp (or any other directory)
> 4. C-x C-f
>
> Expected behavior:
> Emacs will indicate the shell's working directory (/tmp) in the
> find-file minibuffer prompt.
>
> Actual behavior:
> Emacs indicates the Emacs working directory working directory ($HOME,
> for me) in the find-file minibuffer prompt.
I can reproduce this problem.
> I found that if I revert commit aad65192332dfc4a1df0cd2953554c21da243b51
> the problem goes away.
However, I cannot reproduce this commit being the problem.
Since that commit only touches shell.el, which is not even loaded in the
above recipe, it's hard to see how it could be.
Instead I find commit beaab89896 ("Stop messing with the EMACS env var")
causes this. But that was just a quick experiment, not a proper bisection.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sat, 02 May 2015 02:44:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 20484 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Instead I find commit beaab89896 ("Stop messing with the EMACS env var")
> causes this. But that was just a quick experiment, not a proper bisection.
You should be able to verify this by using eg
EMACS='24.5.1 (term:0.96)' emacs -Q -f ansi-term
and seeing that it works again.
I don't get
http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01034.html
It's just going to break things for anybody running any released version
of bash (as predicted in the preceding message). It will be a long time
before all the systems Emacs supports default to a suitably recent bash.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sat, 02 May 2015 19:34:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Glenn,
You are absolutely correct. I'm not sure how I found the other commit at
fault, user error most definitely.
I'm not entirely sure how to approach this, locally even. I guess I'll
have to build my own debian packages to revert this change.
Git master for Bash on Savannah doesn't even mention the INSIDE_EMACS
environment variable, so the current software simply will not work. I
believe that beaab89896 only serves to break things with little gain (to
those who inappropriately used EMACS in their scripts). It certainly
breaks things for users like me who exist almost entirely in Emacs. Has
the intent to move away from the EMACS environment variable been
communicated to the Bash folks?
Thanks,
Jake
On Fri, May 1, 2015 at 7:43 PM Glenn Morris <rgm <at> gnu.org> wrote:
> Glenn Morris wrote:
>
> > Instead I find commit beaab89896 ("Stop messing with the EMACS env var")
> > causes this. But that was just a quick experiment, not a proper
> bisection.
>
> You should be able to verify this by using eg
>
> EMACS='24.5.1 (term:0.96)' emacs -Q -f ansi-term
>
> and seeing that it works again.
>
> I don't get
> http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01034.html
>
> It's just going to break things for anybody running any released version
> of bash (as predicted in the preceding message). It will be a long time
> before all the systems Emacs supports default to a suitably recent bash.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 05:46:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 20484 <at> debbugs.gnu.org (full text, mbox):
> Git master for Bash on Savannah doesn't even mention the INSIDE_EMACS
> environment variable, so the current software simply will not work. I
> believe that beaab89896 only serves to break things with little gain (to
> those who inappropriately used EMACS in their scripts). It certainly
> breaks things for users like me who exist almost entirely in Emacs. Has
> the intent to move away from the EMACS environment variable been
> communicated to the Bash folks?
The old $EMACS setting was declared obsolete many years ago. It looks
like "the Bash folks" didn't notice yet.
Hopefully beaab89896 will make them notice,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 06:16:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Stefan,
It made Emacs users like me notice, mainly by previously-working
functionality in Emacs breaking. Looking at the old bug report, the $EMACS
setting was determined to be obsolete because a few Bash users incorrectly
used the $EMACS variable in their scripts.
According to the Bash documentation, Bash considers the $EMACS variable to
be special and alters its behavior based on the contents. I would argue
this indicates that it's the script writers in error and no action
should've been taken besides a kind pointer to refer to the Bash manual to
the script writers.
Regards,
Jake
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 16:30:05 GMT)
Full text and
rfc822 format available.
Message #25 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Hopefully beaab89896 will make them notice,
That is an unfriendly way to treat another free software project (and
this one is a GNU package).
The problem here is a conflict of conventions between Emacs and Bash.
The best way to handle this is by a discussion between the developers
on both sides. Have you talked with Chet Ramey to look for the right
solution?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 17:37:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In the mean time, can we revert this commit so that Bash directory tracking
will work until a coordinated solution is achieved?
Thanks,
Jake
On Sun, May 3, 2015 at 9:29 AM Richard Stallman <rms <at> gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > Hopefully beaab89896 will make them notice,
>
> That is an unfriendly way to treat another free software project (and
> this one is a GNU package).
>
> The problem here is a conflict of conventions between Emacs and Bash.
> The best way to handle this is by a discussion between the developers
> on both sides. Have you talked with Chet Ramey to look for the right
> solution?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org www.gnu.org
> Skype: No way! See stallman.org/skype.html.
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 17:58:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 20484 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> The old $EMACS setting was declared obsolete many years ago. It looks
> like "the Bash folks" didn't notice yet.
>
> Hopefully beaab89896 will make them notice,
Paul mailed them:
http://lists.gnu.org/archive/html/bug-bash/2015-03/msg00179.html
It was applied to the "devel" branch soon after:
http://git.savannah.gnu.org/cgit/bash.git/diff/shell.c?h=devel&id=0385211bb5cb01e0259c64ec2c5cc6337d4e215c
So, the point has been made, but it will take a long time for this to
get into the default bash on all the systems Emacs supports.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sun, 03 May 2015 19:10:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I see. I misunderstood the master branch to be development, but it's the
release branch.
Can we compromise a little and revert this patch just until the commit has
made into a Bash release? I, like other Emacs users, can afford the risks
to run a development Emacs, but I cannot risk a development Bash.
Thanks,
Jake
On Sun, May 3, 2015 at 10:57 AM Glenn Morris <rgm <at> gnu.org> wrote:
> Stefan Monnier wrote:
>
> > The old $EMACS setting was declared obsolete many years ago. It looks
> > like "the Bash folks" didn't notice yet.
> >
> > Hopefully beaab89896 will make them notice,
>
> Paul mailed them:
> http://lists.gnu.org/archive/html/bug-bash/2015-03/msg00179.html
>
> It was applied to the "devel" branch soon after:
>
> http://git.savannah.gnu.org/cgit/bash.git/diff/shell.c?h=devel&id=0385211bb5cb01e0259c64ec2c5cc6337d4e215c
>
> So, the point has been made, but it will take a long time for this to
> get into the default bash on all the systems Emacs supports.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Mon, 04 May 2015 02:07:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 20484 <at> debbugs.gnu.org (full text, mbox):
> on both sides. Have you talked with Chet Ramey to look for the right
> solution?
The right solution is easy: Bash should use $INSIDE_EMACS rather
than $EMACS.
IOW the right thing to do is to file a bug report to the Bash
maintainers telling them they need to use $INSIDE_EMACS rather
than $EMACS because $EMACS is finally being retired.
I see no reason to revert beaab89896 until bash's master code has been
updated to stop using $EMACS.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Mon, 04 May 2015 02:09:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 20484 <at> debbugs.gnu.org (full text, mbox):
> It was applied to the "devel" branch soon after:
> http://git.savannah.gnu.org/cgit/bash.git/diff/shell.c?h=devel&id=0385211bb5cb01e0259c64ec2c5cc6337d4e215c
> So, the point has been made, but it will take a long time for this to
> get into the default bash on all the systems Emacs supports.
Good. So we can revert beaab89896 before 25.1.
We should still keep it a bit longer, in case some other project has
failed to notice the obsolescence of $EMACS.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Mon, 04 May 2015 16:16:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 20484 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > on both sides. Have you talked with Chet Ramey to look for the right
> > solution?
> The right solution is easy: Bash should use $INSIDE_EMACS rather
> than $EMACS.
You may be right, but please talk with him about it. He may agree and
fix Bash right away. Or he may show you good reasons for some other
solution. Please work together with the Bash maintainers.
The way to communicate with other GNU package maintainers is by
talking with them constructively -- not by making changes that will
lead their users to complain to them. Talking with someone via
the public is not a good way to get people working together.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! See stallman.org/skype.html.
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Wed, 23 Mar 2016 22:16:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Jacob Oursland <jacob.oursland <at> gmail.com>:
bug acknowledged by developer.
(Wed, 23 Mar 2016 22:16:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 20484-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> *From:* Stefan Monnier <monnier <at> iro.umontreal.ca>
> *Date:* Sun, 03 May 2015 22:07:57 -0400
>
> >http://git.savannah.gnu.org/cgit/bash.git/diff/shell.c?h=devel&id=0385211bb5cb01e0259c64ec2c5cc6337d4e215c
>
> > So, the point has been made, but it will take a long time for this to
> > get into the default bash on all the systems Emacs supports.
>
> Good. So we can revert beaab89896 before 25.1.
> We should still keep it a bit longer, in case some other project has
> failed to notice the obsolescence of $EMACS.
OK, it's been ten months and that should be long enough, so I reverted
it in emacs-25 (see attached patch) and am closing this bug report. Yay!
One less blocker for Emacs 25! (The fixed Bash isn't out yet, alas.)
[0001-Comint-term-and-compile-now-set-EMACS.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Thu, 07 Apr 2016 15:02:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 15:19:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 15:26:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 16:03:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 16:08:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 16:27:01 GMT)
Full text and
rfc822 format available.
Message #66 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 16:52:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 17:00:03 GMT)
Full text and
rfc822 format available.
Message #72 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 18:59:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 19:27:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 19:56:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 21:43:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 22:02:02 GMT)
Full text and
rfc822 format available.
Message #87 received at 20484 <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#20484; Package
emacs.
(Thu, 07 Apr 2016 22:21:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 07:02:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 07:03:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 07:05:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 07:07:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 07:35:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 13:10:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 13:13:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 13:16:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 13:41:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 15:34:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 15:47:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 16:01:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 16:02:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 16:47:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 16:50:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 17:13:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 17:49:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 18:13:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 18:15:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 18:48:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 20:51:01 GMT)
Full text and
rfc822 format available.
Message #153 received at 20484 <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#20484; Package
emacs.
(Fri, 08 Apr 2016 21:21:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 20484 <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#20484; Package
emacs.
(Sat, 09 Apr 2016 02:26:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 20484 <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#20484; Package
emacs.
(Sat, 09 Apr 2016 08:44:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 20484 <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#20484; Package
emacs.
(Sat, 09 Apr 2016 13:44:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 20484 <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#20484; Package
emacs.
(Sat, 09 Apr 2016 21:57:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 20484 <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#20484; Package
emacs.
(Sat, 09 Apr 2016 23:41:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 00:10:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 03:31:02 GMT)
Full text and
rfc822 format available.
Message #177 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 07:15:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 08:26:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 08:27:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 08:52:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 09:33:02 GMT)
Full text and
rfc822 format available.
Message #192 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 13:58:02 GMT)
Full text and
rfc822 format available.
Message #195 received at 20484 <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#20484; Package
emacs.
(Sun, 10 Apr 2016 14:00:03 GMT)
Full text and
rfc822 format available.
Message #198 received at 20484 <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#20484; Package
emacs.
(Mon, 11 Apr 2016 05:51:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 20484 <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#20484; Package
emacs.
(Mon, 11 Apr 2016 12:33:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 20484 <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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 10 May 2016 11:24:03 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Stefan Monnier <monnier <at> IRO.UMontreal.CA>
to
control <at> debbugs.gnu.org.
(Thu, 24 May 2018 21:01:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Thu, 24 May 2018 22:05:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 02:26:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 06:14:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 06:17:02 GMT)
Full text and
rfc822 format available.
Message #220 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 07:29:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 08:04:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 18:00:03 GMT)
Full text and
rfc822 format available.
Message #229 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 20:37:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 22:35:02 GMT)
Full text and
rfc822 format available.
Message #235 received at 20484 <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#20484; Package
emacs.
(Fri, 25 May 2018 22:50:02 GMT)
Full text and
rfc822 format available.
Message #238 received at 20484 <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#20484; Package
emacs.
(Sat, 26 May 2018 07:21:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 20484 <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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#20484; Package
emacs.
(Sat, 26 May 2018 20:55:01 GMT)
Full text and
rfc822 format available.
Message #244 received at 20484 <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#20484; Package
emacs.
(Thu, 31 May 2018 21:14:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 20484 <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#20484; Package
emacs.
(Thu, 31 May 2018 23:47:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 20484 <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#20484; Package
emacs.
(Fri, 01 Jun 2018 01:57:02 GMT)
Full text and
rfc822 format available.
Message #253 received at 20484 <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#20484; Package
emacs.
(Fri, 01 Jun 2018 07:06:01 GMT)
Full text and
rfc822 format available.
Message #256 received at 20484 <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#20484; Package
emacs.
(Fri, 01 Jun 2018 14:10:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 20484 <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#20484; Package
emacs.
(Fri, 01 Jun 2018 14:15:01 GMT)
Full text and
rfc822 format available.
Message #262 received at 20484 <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#20484; Package
emacs.
(Thu, 14 Jun 2018 20:55:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 20484 <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:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 287 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.