unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Juri Linkov <juri@linkov.net>
Cc: 33258@debbugs.gnu.org
Subject: bug#33258: inhibit-select-window
Date: Wed, 07 Nov 2018 10:22:38 +0100	[thread overview]
Message-ID: <5BE2AEDE.1090109@gmx.at> (raw)
In-Reply-To: <878t25vpd7.fsf@mail.linkov.net>

 > A prototype that demonstrates a problem-free implementation is:
 >
 > (advice-add 'vc-diff :around
 > 	    (lambda (orig-fun &rest args)
 > 	      (save-selected-window
 > 		(apply orig-fun args)))
 > 	    '((name . inhibit-select-window)))
 >
 > A question is how to do something like this using 'display-buffer-alist'
 > with 'inhibit-select-window'.

You cannot do that in a systematical way - 'display-buffer-alist' is
agnostic of its clients.  And don't forget clients of 'vc-diff' who
might rely on the fact that the latter selects the window chosen.
Ironically, they might do that for exactly the same reason as yours -
they don't want the diffs window to get selected.  Now suppose they do
that by selecting the window preceding or following the diffs window
in the cyclic order of windows right after the 'vc-diff' call ...  So
even your advice is not problem-free.

 > This is a huge task to inspect all existing pop-to-buffer calls
 > and to add 'allow-inhibit-select-window' where it's safe, or to change
 > the existing code to be safe (if this is possible at all).

Nobody will ever acquire enough knowledge to do that.

 >> We could convert 'pop-to-buffer' calls to 'display-buffer' calls with
 >> a 'force-select-window' t alist entry.  Users could override that with
 >> a 'force-select-window' nil entry.  This would be the contrapositive
 >> of the 'inhibit-select-window' approach.
 >
 > Does this have the same problem of not making the displayed buffer
 > current?

The task would remain the same: Inspect all 'pop-to-buffer' calls,
possibly their callers and decide whether converting them is safe.

In the 'vc-diff' case the following stretch already looks hairy:

       ;; Display the buffer, but at the end because it can change point.
       (pop-to-buffer (current-buffer))
       ;; The diff process may finish early, so call `vc-diff-finish'
       ;; after `pop-to-buffer'; the former assumes the diff buffer is
       ;; shown in some window.
       (let ((buf (current-buffer)))
         (vc-run-delayed (vc-diff-finish buf (when verbose messages))))

I suppose the 'buf' binding is superfluous because 'pop-to-buffer'
cannot "pop away" from the current buffer even if a user inhibits
selecting the window chosen.  But if that binding had a real purpose,
then using 'inhibit-select-window' would probably affect it and
'vc-diff-finish' would work on the wrong buffer.

Worse even.  The brutal 'set-buffer' call in 'vc-diff' (right before
entering 'diff-mode') already suggests that eventually selecting the
diffs window becomes unavoidable.  Otherwise, returning from 'vc-diff'
would leave you with the diffs buffer current and a window not showing
the diffs buffer selected - a very unpleasing configuration.

Replacing the 'set-buffer' with 'with-current-buffer' is not devoid of
its problems either: You cannot reliably nest a 'display-buffer' call
in 'with-current-buffer' because 'display-buffer' might select a
window on another frame at any time.

martin





  reply	other threads:[~2018-11-07  9:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-04 21:17 bug#33258: inhibit-select-window Juri Linkov
2018-11-05  9:34 ` martin rudalics
2018-11-05 21:30   ` Juri Linkov
2018-11-06  8:45     ` martin rudalics
2018-11-06 21:59       ` Juri Linkov
2018-11-07  9:22         ` martin rudalics [this message]
2018-11-07 21:32           ` Juri Linkov
2018-11-08  8:52             ` martin rudalics
2018-11-08 21:56               ` Juri Linkov

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=5BE2AEDE.1090109@gmx.at \
    --to=rudalics@gmx.at \
    --cc=33258@debbugs.gnu.org \
    --cc=juri@linkov.net \
    /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).