GNU bug report logs - #72426
29.2.50; comint-pager doesn't affect async-shell-command

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: sbaugh <at> janestreet.com, 72426 <at> debbugs.gnu.org
Subject: bug#72426: 29.2.50; comint-pager doesn't affect async-shell-command
Date: Sat, 14 Sep 2024 09:27:46 +0300

> Date: Sat, 14 Sep 2024 02:45:00 +0300
> Cc: sbaugh <at> janestreet.com, 72426 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 13/09/2024 09:08, Eli Zaretskii wrote:
> >> FWIW async-shell-command's behavior is affected by a bunch of other
> >> comint-* variables as well because it uses a major mode which inherits
> >> from comint-mode (previously it was shell-mode, now shell-command-mode,
> >> but that aspect didn't change).
> > Yes, and that is baaad!
> 
> It might be non-obvious, but I don't see how else it would work: comint 
> is the only built-in subsystem we have that implement a general 
> read-evel-print-loop. So we have 'M-x shell' and 'M-x ielm', for 
> example, both using it as well (not to mention inf-python, inf-ruby, etc).

Very simply: such options should be specific to applications
(shell-command, inf-python, etc.), not to comint.  Comint should have
_variables_ that applications could bind depending on the
application-level user options.

> An alternative would be to have separate user options for each of the 
> above features which would bind comint's options under the cover.

Exactly!

> But that's not very economical.

I don't see why.  It would certainly be much cleaner and more
flexible: users could have different behaviors in different callers of
comint.

But all of this is academical at this point, so why are we still
arguing?

Previous Next

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