GNU bug report logs - #1973
Bug in simple.el (Emacs version 22.2.1)

Previous Next

Full log

Message #107 received at 1973 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sebastian Tennant <sebyte <at> smolny.plus.com>
Cc: 1973 <at> debbugs.gnu.org
Subject: Re: bug#1973: Bug in simple.el (Emacs version 22.2.1)
Date: Sat, 24 Jan 2009 16:14:23 -0500

> > I guess it's using shell-mode, but somehow fails to setup the process's
> > output filter?
> Now you're making it sound like a bug, just as I'm starting to accept
> that it's a misfeature :)

One part is whether it should use shell-mode or not.
Another is whether, when using shell-mode, it should behave like
M-x shell.

The second part is clearly a bug.  If we decide it shouldn't use
shell-mode, then the bug needn't be fixed.  But given that it currently
uses shell-mode, it seems that (contrary to what I thought) the current
intention is for it to behave like shell-mode, in which case it should
be fixed.

> And I've found a solution, but it's ugly:

>  (add-hook 'shell-mode-hook
>            (lambda ()
>              (set-process-filter proc 'comint-output-filter)))

> No one likes to see the guts of a function (local variable 'proc') in
> their mode hooks.

Yes, that's not a good option.  Better use neither shell-mode-hook, nor
some magic variable name.  I think that all that's needed is a good
(set-process-filter (get-buffer-process <buf>) 'comint-output-filter)
at the right place.  Tho, maybe a better option is to change the way the
process is started along the lines of what you originally proposed.

> We have two buffers (*shell* and *Async Command Output*) that both claim
> to be in Shell mode, yet process output is handled completely
> differently in each case.

Indeed, that's a bug.

> Why is *Async Command Output* in Shell mode at all if we're not to
> assume it will only be used for shell commands (that require ^M
> character handling)?

It's probably historical: shell mode hasn't always processed those
chars, so in the past the lack of comint-output-filter was simply
not noticed.

> Even replacing the call to shell-mode with a call to comint-mode makes
> no difference to the way ^M characters are handled.  In either case the
> process filter must be explicitly set to 'comint-ouput-filter.  I'd
> expect something as visually arresting as mangled output to be handled
> by a mode setting, but hey ho.

This is a more difficult decision: should calling a major-mode affect
the filter of a process that happens to be running in this buffer?
Usually, the expectation is that shell-mode (or comint-mode) is not
called directly, so the process filter is set by the calling code.

> If it were up to me, I'd rewrite the asynchronous part of shell-command
> so that make-comint-in-buffer is used to create a Comint mode buffer
> called *Async Shell Command Output* and leave it at that.

I'm beginning to agree.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.