From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, 19012@debbugs.gnu.org
Subject: bug#19012: 25.0.50; `help-window-select'
Date: Tue, 11 Nov 2014 09:29:53 +0100 [thread overview]
Message-ID: <5461C901.6060707@gmx.at> (raw)
In-Reply-To: <8e78202d-5ac0-4df5-8195-9849dd7509b7@default>
> This is the relevant code:
>
> (add-to-list
> 'special-display-buffer-names
> (list "*Help*" '1on1-display-*Help*-frame
> (list (cons 'background-color 1on1-help-frame-background)
> (cons 'mouse-color 1on1-help-frame-mouse+cursor-color)
> (cons 'cursor-color 1on1-help-frame-mouse+cursor-color)
> '(height . 40))))
>
> (defun 1on1-display-*Help*-frame (buf &optional args)
> "Display *Help* buffer in its own frame.
> `special-display-function' is used to do the actual displaying.
> BUF and ARGS are the arguments to `special-display-function'."
> (let ((old-ptr-shape (and (boundp 'x-pointer-shape) x-pointer-shape))
> return-window)
> (when (boundp 'x-pointer-xterm) (setq x-pointer-shape x-pointer-xterm))
> (setq return-window
> (select-window (funcall special-display-function buf args)))
> (raise-frame)
> (setq x-pointer-shape old-ptr-shape)
> return-window))
>
> Does that mean that `with-help-window' is not involved?
Who creates the *Help* buffer and who calls `display-buffer' in the case
at hand?
> Maybe so,
> but it's not obvious to me. How is a user supposed to know whether
> this option applies, i.e., whether "the help window was created by
> `with-help-window'?
By trial and error, I suppose. I wrote `with-help-window' seven years
ago because there were many complaints about the previous behavior. And
I hardly had any complaints since that. `with-help-window' has to cater
for people who don't know what an option is or how it can be
customized. Still, those people want to get help via C-h and get rid of
that help afterwards. When such people later find that the help window
gets selected in some unintuitive way they can tune the behavior using
this option.
> And why shouldn't such an option apply in general for the help window?
> Why must it depend on how the window is created?
Because it relies on things set up correctly at the time the window is
created. Most of the work I put into `with-help-window' was about
storing information that would allow quitting to return to the previous
state as smoothly as possible.
> Maybe so, but it's not very clear, IMO. The vacuous case should be
> mentioned explicitly, I think, and not depend for its understanding on
> finessing the logic. Just say, for value `other', that "if the help
> window is alone in its frame then it is selected".
I'll do that.
> With the scenario I described (*Help* is alone in its frame, in a
> dedicated window, and the *Help* frame exists prior to calling the
> help command) and with a value of `other' or `t', the *Help* window
> is *not* selected.
>
> With your interpretation, the "unless" condition is false, so the
> *Help* window should be selected
Indeed. It would be a bug if it didn't get selected.
> (except that perhaps
> `with-help-window' is not involved - dunno about that).
martin
next prev parent reply other threads:[~2014-11-11 8:29 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-10 16:42 bug#19012: 25.0.50; `help-window-select' Drew Adams
2014-11-10 17:28 ` martin rudalics
2014-11-10 18:23 ` Drew Adams
2014-11-11 8:29 ` martin rudalics [this message]
2014-11-11 14:26 ` Drew Adams
2014-11-11 18:31 ` martin rudalics
2014-11-11 19:01 ` Drew Adams
2014-11-11 21:04 ` Drew Adams
2014-11-13 5:12 ` Drew Adams
2014-11-13 7:44 ` martin rudalics
2014-11-13 15:23 ` Drew Adams
2014-11-13 16:28 ` martin rudalics
2014-11-13 16:56 ` Drew Adams
2014-11-13 18:47 ` martin rudalics
2014-11-13 19:21 ` Drew Adams
2014-11-14 11:37 ` martin rudalics
2014-11-14 15:11 ` Drew Adams
2014-11-14 16:38 ` martin rudalics
2014-11-14 17:09 ` Drew Adams
2014-11-14 17:39 ` martin rudalics
2014-11-14 17:47 ` Drew Adams
2014-11-14 18:10 ` martin rudalics
2014-11-14 18:28 ` Drew Adams
2014-11-14 18:33 ` martin rudalics
2014-11-14 18:44 ` Drew Adams
2014-11-14 19:08 ` martin rudalics
2014-11-14 21:21 ` Drew Adams
2014-11-15 11:24 ` martin rudalics
2014-11-15 14:40 ` Drew Adams
2014-11-16 11:36 ` martin rudalics
2014-11-16 16:20 ` Drew Adams
2014-11-16 17:36 ` martin rudalics
2014-11-16 20:06 ` Drew Adams
2014-11-17 9:29 ` martin rudalics
2014-11-17 14:29 ` Drew Adams
2014-12-25 19:30 ` martin rudalics
2014-11-11 22:16 ` Stefan Monnier
2014-11-11 23:10 ` Drew Adams
2014-11-12 1:49 ` Stefan Monnier
2014-11-12 2:36 ` Drew Adams
2014-11-12 4:11 ` Stefan Monnier
2014-11-12 7:18 ` Drew Adams
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5461C901.6060707@gmx.at \
--to=rudalics@gmx.at \
--cc=19012@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.