GNU bug report logs - #71049
async-shell-command ends with "Process *Async Shell Command* finished" when remote "direct-async-process"

Previous Next

Full log

Message #137 received at 71049 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael.albinus <at> gmx.de, 71049 <at> debbugs.gnu.org
Subject: Re: bug#71049: async-shell-command ends with "Process *Async Shell
 Command* finished" when remote "direct-async-process"
Date: Fri, 31 May 2024 19:24:10 +0300

On 31/05/2024 08:53, Eli Zaretskii wrote:

>> 1) [first patch] We can add a new major mode, for 'M-&' to use instead
>> of the full-blown 'shell-mode' - it could be very simple: just apply
>> font-lock keywords and maybe set list-buffers-directory.
> 
> I think I'm okay with this.  (It needs to be prominently documented,
> of course.)

In NEWS?

> But we need a documented way for people to get previous
> behavior if they want that.  How would that work?

If we really needed the capability to rollback the change, I suppose we 
could add a defvar pointing to the major mode to use. I.e.

  (defvar async-shell-command-major-mode #'shell-command-mode)

>> Problems? I suppose someone might be using shell-mode-hook to do
>> something in the async-shell-command output buffer, and it won't fire
>> anymore. Seemingly very minor concern.
> 
> Can't we run shell-mode-hook inside this new mode's mode hook?  Then
> this problem goes away.

Doesn't seem worth it - it was just an offhand example I came up with. 
The syntax table and the keymap would also different, and some user, in 
theory, could depend on those as well.

Previous Next

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