Subject: bug#72426: 29.2.50; comint-pager doesn't affect async-shell-command

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Sep 2024 09:27:46 +0300

> Date: Sat, 14 Sep 2024 02:45:00 +0300
> Cc: [email-masked], [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> 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?