unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Reuben Thomas <rrt@sc3d.org>
Cc: 18133@debbugs.gnu.org
Subject: bug#18133: Suppressing asynchronous command output
Date: Fri, 23 Dec 2016 20:55:12 +0100	[thread overview]
Message-ID: <585D8120.1090300@gmx.at> (raw)
In-Reply-To: <CAOnWdoj+tqhLJdXRB_b2R_Ak_S0ihuNnjNyqSJdweE49oGRF7A@mail.gmail.com>

 > ​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






  reply	other threads:[~2016-12-23 19:55 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-28 18:47 bug#18133: Suppressing asynchronous command output Reuben Thomas
2014-07-29 23:47 ` Juri Linkov
2014-07-30  9:16   ` Reuben Thomas
2014-07-30  9:48     ` Reuben Thomas
2014-07-30 16:35       ` Juri Linkov
2016-12-19 15:48 ` Reuben Thomas
2016-12-21 17:55   ` Eli Zaretskii
2016-12-21 22:44     ` Reuben Thomas
2016-12-22 16:28       ` Eli Zaretskii
2016-12-22 17:53         ` martin rudalics
2016-12-22 18:32           ` Eli Zaretskii
2016-12-22 19:42           ` Reuben Thomas
2016-12-22 20:15             ` martin rudalics
2016-12-22 20:26               ` Reuben Thomas
2016-12-23 18:59                 ` martin rudalics
2016-12-23 19:10                   ` Reuben Thomas
2016-12-23 19:55                     ` martin rudalics [this message]
2016-12-23 21:07                       ` Reuben Thomas
2016-12-24  9:16                         ` martin rudalics
2016-12-24 11:11                           ` Reuben Thomas
2016-12-24 12:06                             ` Eli Zaretskii
2016-12-24 13:54                               ` martin rudalics
2016-12-24 14:45                                 ` Reuben Thomas
2016-12-24 16:32                                   ` martin rudalics
2016-12-24 16:03                                 ` Eli Zaretskii
2016-12-24 16:33                                   ` martin rudalics
2016-12-24 16:56                                     ` Eli Zaretskii
2016-12-24 18:14                                       ` martin rudalics
2016-12-25  2:23                                         ` Reuben Thomas
2016-12-26 23:43                                         ` Reuben Thomas
2016-12-27  7:29                                           ` martin rudalics
2016-12-26 23:27                         ` Juri Linkov
2016-12-27  1:09                           ` Reuben Thomas
2016-12-27  1:20                             ` Reuben Thomas
2016-12-27  6:23                               ` Eli Zaretskii
2016-12-27  9:01                                 ` Reuben Thomas
2016-12-27  9:28                                   ` Eli Zaretskii
2016-12-27 22:21                                     ` Reuben Thomas
2016-12-28 16:01                                       ` Eli Zaretskii
2016-12-28 20:58                                         ` Reuben Thomas
2016-12-29 15:50                                           ` Eli Zaretskii
2016-12-29 23:08                                           ` Juri Linkov
2016-12-30 18:28                                             ` Reuben Thomas
2016-12-30 20:50                                               ` Eli Zaretskii
2016-12-30 22:33                                                 ` Reuben Thomas
2016-12-30 22:56                                               ` Juri Linkov
2016-12-31  0:19                                                 ` Reuben Thomas
2016-12-31  8:41                                                   ` Eli Zaretskii
2017-06-28 21:45                                                     ` Reuben Thomas
2017-06-28 21:53                                                       ` Reuben Thomas
2017-06-28 22:05                                                         ` Reuben Thomas
2017-08-07 12:31                                                           ` Reuben Thomas
2017-08-07 16:25                                                             ` Eli Zaretskii
2020-09-18 13:40                                                               ` Lars Ingebrigtsen
2020-09-18 13:51                                                                 ` Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-18 14:04                                                                   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=585D8120.1090300@gmx.at \
    --to=rudalics@gmx.at \
    --cc=18133@debbugs.gnu.org \
    --cc=rrt@sc3d.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).