Re: About the 'minibuffer' frame parameter

[martin rudalics]

> Yes...  Or maybe not.  Doesn't that conclusion depend on
> supposing that `set-frame-parameter' returns the new parameter
> value?  I don't see the return value of that function mentioned
> in its doc string or in the manual.  (Maybe it should be?)

It's irrelevant - the return value is that of ‘modify-frame-parameters’
and that's always nil.  Here I only care about _where_ nil gets printed,
that is, in which minibuffer window.

> But anyway, if you're sure that the value of `frame-parameter'
> is nil (I assume you checked this in the C code), then OK.

  (set-frame-parameter
   minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))

sets the internal value of the 'minibuffer' frame parameter to the
specified minibuffer window.  Only the value reported afterwards by
‘frame-parameter’ is nil.

> Yes, it is misleading.  But why is it not critical (a problem)?

Because internally Emacs ignores the frame parameter's value and relies
on the value returned by ‘minibuffer-window’ instead.  The corresponding
macro is FRAME_MINIBUF_WINDOW.  C code hardly ever consults frame
parameter alists, probably for two reasons: (1) Their values are either
inaccurate or don't exist, and (2) it might be too costly to do so.

> And why does it happen also for geometry parameters?  (And why
> does it happen for `frame-parameter'?)

Because the frame geometry changes for a number of reasons, for example,
when you maximize a frame or use the mouse to resize it.  In this case
Emacs has to tediously approximate the values of the 'height' or 'width'
parameters from the real ones, the ones the user sees on the screen.

The values of many parameters reported by ‘frame-parameters’ are
constructed ad-hoc from internal values (see Fframe_parameters for some
general parameters and x_report_frame_params for the X Window related
ones).

What annoys me about the 'minibuffer' parameter is that it OT1H does not
depend on any extraneous issue like a toolkit that is only able to draw
things in certain sizes (like scroll bars on GTK) and that OTOH someone
decided that in some cases it should specify a window which is not its
task.

>>     This frame parameter takes effect when the frame is created, and
>>     can not be changed afterwards.
>       ^^^^^^^
>       cannot (typo)

A Freudian one, perhaps.

>> 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).
>
> Yes.  And why not be able to do that?  And if there is a good
> reason not to, then maybe Emacs should be fixed to not do it (?).

Conceptually, it's a bad idea to set the value of that frame parameter:
When, for a minibuffer-less frame, you want to use another minibuffer
window, you do not (and cannot) change the frame's minibuffer-less
status.  So the frame parameter's value should stay unaltered indeed,
ideally.

But how else change the minibuffer window of a minibuffer-less frame?

> Yes.  I don't test it with `frame-parameter'.  And I understand
> that what you are saying is that it is only the value of
> `frame-parameter' that is useless.
>
> But `frameset.el' does test it, AFAICT.  Take a look at
> `frameset--record-minibuffer-relationships', for example.
> Perhaps there is a bug lurking there (?).

IIUC ‘frameset--record-minibuffer-relationships’ is an attempt to fix
what gets reported via ‘frame-parameters’.  It must have been a hair
raising experience for Juanma to code that.  Given a doc-string like


default-minibuffer-frame is a variable defined in ‘frame.c’.
Its value is #<frame frameset.el 02204f48>
It is a terminal-local variable; global value is the same.

Documentation:
Minibufferless frames use this frame’s minibuffer.
Emacs cannot create minibufferless frames unless this is set to an
appropriate surrogate.

Emacs consults this variable only when creating minibufferless
frames; once the frame is created, it sticks with its assigned
minibuffer, no matter what this variable is set to.  This means that
this variable doesn’t necessarily say anything meaningful about the
current set of frames, or where the minibuffer is currently being
displayed.

This variable is local to the current terminal and cannot be buffer-local.


which is wrong (because a frame does not necessarily "stick" with its
assigned minibuffer) and not useful either (what should I make of
information like "this variable doesn’t necessarily say anything
meaningful about the current set of frames, or where the minibuffer is
currently being displayed").

Also, ‘frameset-filter-minibuffer’ seems to do the right thing.  It's
doc-string says

  When saving, convert (minibuffer . #<window>) to (minibuffer . t).

which fixes the mind-boggling sillyness that ‘frame-parameter’ reports a
frame's own minibuffer window when it has one.

I slowly begin to understand why Juanma gave up coding for Emacs :-(

martin