From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: About the 'minibuffer' frame parameter
Date: Sat, 06 Aug 2016 11:32:45 +0200 [thread overview]
Message-ID: <57A5AEBD.9040805@gmx.at> (raw)
In-Reply-To: <3e5c74c4-40ae-4b6e-8e8e-444306abb189@default>
> They are not clear to me, even on re-reading.
Sorry for being unclear. Let me try once more: With emacs -Q, yank the
following forms into *scratch*
(defvar initial-frame (selected-frame))
(defvar minibuffer-less-frame (make-frame '((minibuffer . nil))))
(defvar minibuffer-only-frame (make-frame '((minibuffer . only))))
and evaluate them. You should see three frames - the "normal" initial
one, a minibuffer-less frame, and a minibuffer-only one. Correct?
Now in the minibuffer-less frame evaluate
(frame-parameter minibuffer-less-frame 'minibuffer)
and Emacs will print nil in the minibuffer window of the initial frame.
Next evaluate
(set-frame-parameter
minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))
and you will see nil in the minibuffer window of the minibuffer-only
frame. Now evaluate
(set-frame-parameter
minibuffer-less-frame 'minibuffer (minibuffer-window initial-frame))
and you will see nil in the minibuffer window of the initial frame
again.
From this we can conclude the following:
(1) Emacs does redirect output to the minibuffer window of the frame
specified via ‘set-frame-parameter’. This follows from the
experiment above because you see the value reported by
‘frame-parameter’ appear in different minibuffer windows.
(2) Any such redirection is not reflected in the 'minibuffer' value
reported by ‘frame-parameter’: That value remains nil invariably.
Do you agree so far? Then I see the following problems.
From (2) the 'minibuffer' value assigned by ‘set-frame-parameter’ is not
reflected in the 'minibuffer' value returned by ‘frame-parameter’. This
is not critical per se (a similar thing may happen to geometry
parameters) but it's misleading because, as we can conclude from (1),
something has changed.
Moreover in section 28.4.3.5 Buffer Parameters of the Elisp manual we
say:
`minibuffer'
Whether this frame has its own minibuffer. The value `t' means
yes, `nil' means no, `only' means this frame is just a minibuffer.
If the value is a minibuffer window (in some other frame), the
frame uses that minibuffer.
This frame parameter takes effect when the frame is created, and
can not be changed afterwards.
But apparently it is possible to change the 'minibuffer' frame parameter
after a frame was created since otherwise we were not able to redirect
output as mentioned in (1).
Regardless of whatever ‘frame-parameter’ reports, the value of the frame
parameter stored by Emacs internally is the window specified by
(frame-root-window minibuffer-only-frame). The routine constructing the
‘frame-parameters’ alist replaces the real internal value by the value
nil.
Finally evaluate the form
(frame-parameter initial-frame 'minibuffer)
You will see something like
#<window 4 on *Minibuf-0*>
appear in the minibuffer window. This is a window on the initial frame.
‘frame-parameter’ returns a minibuffer window if and only if that
minibuffer window is on the _same_ frame as the one whose minibuffer
value I try to retrieve. You can't convince ‘frame-parameter’ to report
a minibuffer window "in some other frame" as the manual suggests.
Am I still unclear?
>> Because IIUC they do not care much about "testing" it. Otherwise they
>> would have complained already.
>
> What is the problem with testing it?
That the "reported" value does not reflect the "set" value as described
above.
> frameset.el tests it. And I test it. I `redirect-frame-focus' of a
> minibuffer-less frame for *Completions* to my standalone minibuffer
> frame, for example:
[...]
> Okay, I don't actually test the frame parameter here explicitly, but
> the code depends on it being and acting as it does, I think.
I don't think so. You just use the return value of ‘make-frame’ invoked
with a (minibuffer . only) parameter. Alternatively, you might use
(window-frame (minibuffer-window my-minibuffer-less-frame))
In general, ‘frame-parameter’ is useless for finding the minibuffer frame.
As long as nobody works with the return value of ‘frame-parameter’ there
are no problems. On the C-level code works with the "real" value of the
parameter as set by ‘set-frame-parameter’ and does not have the problems
I mentioned here. Actually, C-code never even consults that value - it
only sets it.
martin
next prev parent reply other threads:[~2016-08-06 9:32 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-31 18:12 About the 'minibuffer' frame parameter martin rudalics
2016-08-05 13:33 ` Eli Zaretskii
2016-08-05 16:37 ` martin rudalics
2016-08-05 17:18 ` Drew Adams
2016-08-05 17:35 ` martin rudalics
2016-08-05 17:52 ` Drew Adams
2016-08-05 18:19 ` martin rudalics
2016-08-05 18:37 ` Drew Adams
2016-08-06 9:32 ` martin rudalics [this message]
2016-08-06 16:46 ` Drew Adams
2016-08-07 8:46 ` martin rudalics
2017-01-14 0:59 ` Juanma Barranquero
2017-01-14 7:47 ` Eli Zaretskii
2017-01-14 9:18 ` Juanma Barranquero
2017-01-14 10:42 ` Eli Zaretskii
2017-01-14 11:05 ` martin rudalics
2017-01-14 14:01 ` Juanma Barranquero
2017-01-19 3:54 ` John Wiegley
2017-01-14 15:56 ` Drew Adams
2017-01-15 3:01 ` Richard Stallman
2016-08-05 19:25 ` Eli Zaretskii
2016-08-06 9:33 ` martin rudalics
2016-08-07 13:54 ` Eli Zaretskii
2016-08-08 8:27 ` martin rudalics
2016-08-08 15:34 ` Eli Zaretskii
2016-08-09 8:27 ` martin rudalics
2016-08-09 14:51 ` Eli Zaretskii
2016-08-09 16:07 ` martin rudalics
2016-08-09 16:21 ` Eli Zaretskii
2016-08-09 17:34 ` martin rudalics
2016-08-09 17:51 ` Eli Zaretskii
2016-08-10 12:15 ` martin rudalics
2016-08-10 14:23 ` Stefan Monnier
2016-08-10 14:54 ` Eli Zaretskii
2016-08-10 14:49 ` Eli Zaretskii
2016-08-21 9:41 ` martin rudalics
2016-08-21 20:51 ` Kaushal Modi
2016-08-22 12:49 ` Kaushal Modi
2016-08-22 13:03 ` Kaushal Modi
2016-08-22 15:51 ` Kaushal Modi
2016-08-22 16:01 ` martin rudalics
2016-08-22 16:27 ` Kaushal Modi
2016-08-23 8:19 ` martin rudalics
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=57A5AEBD.9040805@gmx.at \
--to=rudalics@gmx.at \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.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 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.