GNU bug report logs - #18133
Suppressing asynchronous command output

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18133 <at> debbugs.gnu.org
Subject: bug#18133: Suppressing asynchronous command output
Date: Fri, 23 Dec 2016 20:55:12 +0100

> ​Again, you are describing the behaviour of my original patch. ​I then
> suggested adding an option to display-buffer-alist's defcustom
> specification. But you said that is not allowed (if I understood correctly).

Yes.  But I still do not understand what that option would be.

> I will try to outline the current position again:
>
> 1. I agree that the current default behaviour should remain as it is.
>
> 2. I would like to add the ability to easily turn off displaying the Async
> Command output buffer until there is some output.

Isn't this much more than changing the way ‘display-buffer’ behaves?
IIUC, you want the buffer to pop up whenever some output arrives, the
user should be allowed to delete the window, and when new output arrives
the buffer should pop up again.  Correct?  Then this is a perfect
candidate for a minor mode where you would remove the ‘allow-no-window’
entry in every ‘display-buffer’ call when new output arrives.

> 3. I suggested achieving this by i) adding an option to
> display-buffer-alist, and ii) documenting this in shell-command.
>
> 4. You stated that it is not allowed for code to change
> display-buffer-alist.

Earlier we had a number of options affecting the behavior of
‘display-buffer’ which still exist in some way like
‘same-window-buffer-names’, ‘display-buffer-reuse-frames’ or
‘pop-up-frames’.  These usually ended up being crowded by applications
that added their preferences and customizing these options became very
awkward, usually accompanied by alerts like "changed outside customize"
and similar annoyances.  That's why we disallow changing the value of
this option in our code.

In general, code should refrain from changing the value of user
customizable variables.  They are reserved for the user.

> I was puzzled by this, because other user variables
> such as auto-mode-alist

‘auto-mode-alist’ is not a user variable aka option.  Anyone is allowed
to set it.

> are changed by code as well as by the user. In any
> case, I am not suggesting automatically changing display-buffer-alist;
> rather I have suggested adding an option to the customization menu for
> display-buffer-alist.
>
> So, maybe you could give your opinion of my current suggestion (3),
> ignoring my original patch?
>
> Sorry if I have confused you, and I hope the above makes things clearer.

I have not read your original patch.  But I'm still confused by how you
want to add something to ‘display-buffer-alist’ and at the same time to
not change the behavior of ‘display-buffer’ ;-)

martin

Previous Next

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