bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18133: Suppressing asynchronous command output


From: martin rudalics
Subject: bug#18133: Suppressing asynchronous command output
Date: Sat, 24 Dec 2016 14:54:00 +0100

> display-buffer-alist is a defcustom.  The issue at hand is to offer
> users a way of customizing display-buffer-alist such that buffers
> whose names match "*Async Shell Command*" will not be displayed unless
> they have something to show the user.
>
> Martin, what can we add to the display-buffer-alist's defcustom to
> allow users easy customization to that effect?

Let me try to explain this once more: The idea of ‘display-buffer-alist’
was to provide an option with a default value of nil.  An option
entirely in the hands of the user, which means that no code is allowed
to change its value.  In the five years since its introduction, new
Emacs code has followed this convention.

As soon as we allow new code to change this as Reuben proposed, nothing
will prevent users from saying that they like a non-nil default value
for the entry in question and a few years later we'll be in the very
situation we had before, namely that of users' customizations dwarfed by
applications adding their own preferences.  We've been there and it was
a mess.

Applications have three ways to affect what ‘display-buffer’ does:

(1) Provide the function to use via an argument.  This can be overridden
    by ‘display-buffer-alist’.

(2) Let-bind ‘display-buffer-alist’ temporarily to a value of its
    preference.  This is a work-around for the case where the
    application does not call ‘display-buffer’ directly.

(3) Use ‘display-buffer-overriding-action’.  This overrides
    ‘display-buffer-alist’ completely.

Is it really so difficult to provide an extra option which allows to
have either of these trigger the wanted behavior?  Also taking into
account that the lazy pop-up behavior Reuben aims at cannot be obtained
by customizing an existing option anyway?

martin






reply via email to

[Prev in Thread] Current Thread [Next in Thread]