bug#15399: 24.3.50; Eshell redirection broken in HEAD

bug#15399: 24.3.50; Eshell redirection broken in HEAD

[chad]

Eshell redirection causes an error (Symbol's value as variable is void: cmd) in HEAD for the last week or so:

	Emacs -Q
	M-x eshell RET
	~ $ addpath -b /usr/sbin >>> /dev/kill
	Symbol's value as variable is void: cmd
	~ $ addpath -b /usr/sbin > /dev/clip
	Symbol's value as variable is void: cmd
	~ $ addpath -b /usr/sbin > /tmp/foo.txt
	Symbol's value as variable is void: cmd

In GNU Emacs 24.3.50.1 (x86_64-apple-darwin12.5.0, NS apple-appkit-1187.39)
 of 2013-09-16 on protip.local
Bzr revision: 109427 yandros@mit.edu-20130916171024-rtwryjj6omvdtjpo
Windowing system distributor `Apple', version 10.3.1187
Configured using:
 `configure --with-ns --enable-checking'

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: EShell

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
s-x M-x e s h SPC <return> C-y <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
s-v <return> <down-mouse-1> <mouse-movement> <mouse-movement> 
<drag-mouse-1> M-x r e p o SPC r t SPC e b SPC <backspace> 
m SPC b u SPC <return>

Recent messages:
Loading em-dirs...done
Loading em-glob...done
Loading em-hist...done
Loading em-ls...done
Loading em-prompt...done
Loading em-script...done
Loading em-term...done
Loading em-unix...done
Mark set [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils help-mode pp em-unix em-term term disp-table
easymenu ehelp electric em-script em-prompt em-ls cl-loaddefs cl-lib
em-hist em-pred em-glob em-dirs em-cmpl em-basic em-banner em-alias
pcomplete comint ansi-color ring esh-var esh-io esh-cmd esh-opt esh-ext
esh-proc esh-arg eldoc help-fns esh-groups eshell esh-module esh-mode
esh-util time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
ns-win tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment 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 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 ns
multi-tty emacs)

bug#15399: 24.3.50; Eshell redirection broken in HEAD

[Stefan Monnier]

> Eshell redirection causes an error (Symbol's value as variable is void: cmd) in HEAD for the last week or so:

Thanks for the recipe.  Should be fixed now,


        Stefan

bug#15399: 24.3.50; Eshell redirection broken in HEAD

[chad]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]


On 17 Sep 2013, at 08:19, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> Eshell redirection causes an error (Symbol's value as variable is void: cmd) in HEAD for the last week or so:
> 
> Thanks for the recipe.  Should be fixed now,


I'm still having trouble, and I'm not sure if it's a symptom of the
problem, the solution, or the precipitate. Let me give a little
more detail. Until recently, I had the following lines in
~/.emacs.d/eshell/profile:

	addpath -b /usr/local/bin >>> #<buffer *Messages*>
	addpath -b /usr/local/sbin >>> #<buffer *Messages*>
	addpath -b ~/bin >>> #<buffer *Messages*>

A semi-recent change broke redirection in eshell, but Stefan fixed
it yesterday (thanks Stefen).  After the fix, though, I'm seeing,
for each addpath directive:

Buffer is read-only: #<buffer *Messages*>

Is this a side-effect of the solution? Should I file it as a different
bug? Should I stop trying to redirect into *Messages* (it's convenient
but not really necessary)?

Thanks,
~Chad


[-- Attachment #2: Type: text/html, Size: 2010 bytes --]

bug#15399: 24.3.50; Eshell redirection broken in HEAD

[Glenn Morris]

chad wrote:

> Buffer is read-only: #<buffer *Messages*>

That's unrelated. etc/NEWS:

    ** The *Messages* buffer is created in a new major mode
   `messages-buffer-mode', and read-only.

Why the change to *Messages*? [was: bug#15399...]

[Drew Adams]

> Subject: bug#15399: 24.3.50; Eshell redirection broken in HEAD
> 
> > Buffer is read-only: #<buffer *Messages*>
>
> That's unrelated. etc/NEWS:
>     ** The *Messages* buffer is created in a new major mode
>    `messages-buffer-mode', and read-only.

Why?  Where was the discussion in emacs-devel@gnu.org about this
change to *Messages*?  No other bug was referenced above, so I guess
this was not due to a reported bug or enhancement request.

Is this change perhaps a response to this old thread from 2010?
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00078.html
That is the only discussion I've seen about this question.

FWIW, I disagree with this change, and to similar changes, such as
what was done to *Help* - see bug #10308:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10308.

I often debug using `message' to write to *Messages*, if using
the debugger is problematic (typically during Isearch or minibuffer
interaction).  And I write stuff there directly also, to guide
myself.

Now (for what reason?), *Messages* is in its own mode, and it is
read-only.  I don't have an Emacs build with the change yet, so I
don't know just what `messages-buffer-mode' (a bad name, BTW) is.

But if this is anything like what was done to *Help* then toggling
`read-only' off will not suffice, and I will now need to change
the mode for yet another buffer.

And why?  Just because someone thought it convenient to hit `q'
(instead of, say, `C-x 0') to quit *Messages*?

Or was there some other reason?  A good reason?  Why no proposal
and discussion before this change was made?  Or did I somehow
miss the thread?

Yes, I can fiddle to work around this change, as one user.  But
why is this good for Emacs?  I edit text in *Messages* (and in
*Help*, to prepare doc strings), and I doubt I'm the only one who
does.  What is so beneficial about this change (after almost 40
years of *Messages* being normally editable)?

Re: Why the change to *Messages*? [was: bug#15399...]

[Glenn Morris]

Ah, the expected "where was the discussion" email arrives on schedule.

The discussion is referenced in the commit message.

RE: Why the change to *Messages*? [was: bug#15399...]

[Drew Adams]

> Ah, the expected "where was the discussion" email arrives on schedule.
> The discussion is referenced in the commit message.

Oh, wunderbar.  In place of your sarcasm, why not post the commit
message here, or provide a direct reference to the discussion?
Why make people hunt for it?

(FWIW, I can't even get to the ChangeLog file at http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/ChangeLog?sort=date now, which is where the commit message is, I guess.
It just times out.  But I'll keep trying, unless you decide to be
helpful and post the information here.)

RE: Why the change to *Messages*? [was: bug#15399...]

[Drew Adams]

> > Ah, the expected "where was the discussion" email arrives on schedule.
> > The discussion is referenced in the commit message.
> 
> Oh, wunderbar.  In place of your sarcasm, why not post the commit
> message here, or provide a direct reference to the discussion?
> Why make people hunt for it?
> 
> (FWIW, I can't even get to the ChangeLog file at
> http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/ChangeLog?sort
> =date now, which is where the commit message is, I guess.
> It just times out.  But I'll keep trying, unless you decide to be
> helpful and post the information here.)

OK, I finally got to it:
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00135.html

And that is the same thread I referenced,from 3 years ago.

(Much of that thread does not show up here:
http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00078.html.
But even though the link it shows appears as already visited, the `Next
by thread' link, does add another message at the bottom of the page
(one at a time).  Odd UI - you should be able to view another whole
page of the thread, not just one message at a time.)