About the 'minibuffer' frame parameter

About the 'minibuffer' frame parameter

[martin rudalics]

With emacs -Q evaluate:

(progn
   (setq minibuffer-less-frame (make-frame '((minibuffer . nil))))
   (setq minibuffer-only-frame (make-frame '((minibuffer . only))))

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

This reveals a number of problems with how we currently handle the
'minibuffer' frame parameter and how it's documented.  In section
28.4.3.5 we say about this parameter:

`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.

The sentence "If the value is a minibuffer window (in some other frame),
the frame uses that minibuffer." is misleading.  A minibuffer window is
reported iff that window is on the _same_ frame and that frame is not a
minibuffer-only frame.  A minibuffer window in some other frame is never
reported.

But if the frame is minibuffer-less and uses the minibuffer window of
some other frame, we return as value nil although the real, internal
frame parameter's value (not the one produced by the

   store_in_alist (&alist, Qminibuffer,
		  (! FRAME_HAS_MINIBUF_P (f) ? Qnil
		   : FRAME_MINIBUF_ONLY_P (f) ? Qonly
		   : FRAME_MINIBUF_WINDOW (f)));

construct) is actually that window.  Otherwise, evaluating the
‘set-frame-parameter’ above would have produced an error.  Which means
that the sentence "This frame parameter takes effect when the frame is
created, and can not be changed afterwards." is misleading as well.  In
fact, setting the 'minibuffer' frame parameter is the only way to change
the minibuffer window for a specific frame.

Note in this context that ‘minibuffer-window’ returns the correct
minibuffer window for its FRAME argument while ‘set-minibuffer-window’
does not allow to set the minibuffer window for a specific frame.

I'm not sure how to deal with this situation.  Personally, I'd prefer to
report the real, internal 'minibuffer' parameter but am afraid that
might break existing code.  In any case, the documentation should be
fixed.  Somehow.

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Sun, 31 Jul 2016 20:12:46 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> I'm not sure how to deal with this situation.  Personally, I'd prefer to
> report the real, internal 'minibuffer' parameter but am afraid that
> might break existing code.

You mean, you think there's some code out there that expects to
receive nil in that case?  Do we have any code in our tree that might
expect that?

> In any case, the documentation should be fixed.  Somehow.

Before fixing the docs we should decide what the code should do.

Thanks.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 >> I'm not sure how to deal with this situation.  Personally, I'd prefer to
 >> report the real, internal 'minibuffer' parameter but am afraid that
 >> might break existing code.
 >
 > You mean, you think there's some code out there that expects to
 > receive nil in that case?  Do we have any code in our tree that might
 > expect that?

I'm afraid so, yes.  Otherwise this rigmarole would hardly make sense.

But I haven't checked all places because I rather soonish stumbled upon
things like

(eq (cdr (or (assq 'minibuffer initial-frame-alist)
	     (assq 'minibuffer window-system-frame-alist)
	     (assq 'minibuffer default-frame-alist)
	     '(minibuffer . t)))
     t)

in ‘frame-notice-user-settings’.  And one revealing comment is in
‘set-frame-configuration’:

                ;; Since we can't set a frame's minibuffer status,
                ;; we might as well omit the parameter altogether.

 >> In any case, the documentation should be fixed.  Somehow.
 >
 > Before fixing the docs we should decide what the code should do.

That's what I tried to initiate.  Is there anyone out there who has an
idea how the 'minibuffer' parameter should be set and used?  Maybe
nobody uses them any more.

martin

RE: About the 'minibuffer' frame parameter

[Drew Adams]

> Is there anyone out there who has an idea how the 'minibuffer'
> parameter should be set and used?  Maybe nobody uses them any more.

If by "them" you mean frame parameter `minibuffer' then yes, I use it.

I create a standalone minibuffer frame, so my `minibuffer-frame-alist'
has (minibuffer . only), using (setq minibuffer-frame-alist ...).

And my `default-frame-alist' has (minibuffer), aka (minibuffer . nil).
I do that similarly: (setq default-frame-alist...).

But I think you probably knew all that, so it is perhaps not really
what you are asking.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 >> Is there anyone out there who has an idea how the 'minibuffer'
 >> parameter should be set and used?  Maybe nobody uses them any more.
 >
 > If by "them" you mean frame parameter `minibuffer' then yes, I use it.
 >
 > I create a standalone minibuffer frame, so my `minibuffer-frame-alist'
 > has (minibuffer . only), using (setq minibuffer-frame-alist ...).
 >
 > And my `default-frame-alist' has (minibuffer), aka (minibuffer . nil).
 > I do that similarly: (setq default-frame-alist...).
 >
 > But I think you probably knew all that, so it is perhaps not really
 > what you are asking.

I know that you use stand-alone minibuffers and that you have to _set_
the 'minibuffer' frame parameter for that.  I wanted to know how people
_use_ that parameter after, for example, doing

(frame-parameter nil 'minibuffer)

If nobody _uses_ it then we don't have to care about it.

martin

RE: About the 'minibuffer' frame parameter

[Drew Adams]

>  >> Is there anyone out there who has an idea how the 'minibuffer'
>  >> parameter should be set and used?  Maybe nobody uses them any more.
>  >
>  > If by "them" you mean frame parameter `minibuffer' then yes, I use it.
>  > I create a standalone minibuffer frame, so my `minibuffer-frame-alist'
>  > has (minibuffer . only), using (setq minibuffer-frame-alist ...).
>  > And my `default-frame-alist' has (minibuffer), aka (minibuffer . nil).
>  > I do that similarly: (setq default-frame-alist...).
> 
> I know that you use stand-alone minibuffers and that you have to _set_
> the 'minibuffer' frame parameter for that.  I wanted to know how people
> _use_ that parameter after, for example, doing
> 
> (frame-parameter nil 'minibuffer)
> 
> If nobody _uses_ it then we don't have to care about it.

Dunno what you mean by "care about it".  Just what are you proposing
to change, so as to no longer "care about it"?

I have code that does things to frames, and checks whether a given
frame is a standalone minibuffer frame.  My code typically checks
whether it is just MY standalone minibuffer frame, by checking variable
`1on1-minibuffer-frame'.  But more generally such code would check
the `minibuffer' frame parameter.  I don't see why we would eliminate
that possibility.

And I believe that Juanma's frameset code carefully distinguishes
standalone minibuffer frames from others, by checking that parameter.

I think that Emacs users should continue to be able to test, as well
as set the `minibuffer' frame parameter.  Why shouldn't they?

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > Dunno what you mean by "care about it".

Care about the issue(s) that started this thread.

 > Just what are you proposing
 > to change, so as to no longer "care about it"?

Nothing.  As long as nobody cares about these issues.

 > I have code that does things to frames, and checks whether a given
 > frame is a standalone minibuffer frame.  My code typically checks
 > whether it is just MY standalone minibuffer frame, by checking variable
 > `1on1-minibuffer-frame'.  But more generally such code would check
 > the `minibuffer' frame parameter.  I don't see why we would eliminate
 > that possibility.

I don't want to eliminate anything.

 > And I believe that Juanma's frameset code carefully distinguishes
 > standalone minibuffer frames from others, by checking that parameter.
 >
 > I think that Emacs users should continue to be able to test, as well
 > as set the `minibuffer' frame parameter.  Why shouldn't they?

Because IIUC they do not care much about "testing" it.  Otherwise they
would have complained already.

martin

RE: About the 'minibuffer' frame parameter

[Drew Adams]

>  > Dunno what you mean by "care about it".
> 
> Care about the issue(s) that started this thread.

They are not clear to me, even on re-reading.

>  > Just what are you proposing
>  > to change, so as to no longer "care about it"?
> 
> Nothing.  As long as nobody cares about these issues.

I don't know what the issues are.  But I definitely care about
frame parameter `minibuffer'.  But if you are proposing doing
"Nothing" then I guess I have nothing to worry about. ;-)

> I don't want to eliminate anything.

Good.

>  > And I believe that Juanma's frameset code carefully distinguishes
>  > standalone minibuffer frames from others, by checking that parameter.
>  >
>  > I think that Emacs users should continue to be able to test, as well
>  > as set the `minibuffer' frame parameter.  Why shouldn't they?
> 
> Because IIUC they do not care much about "testing" it.  Otherwise they
> would have complained already.

What is the problem with testing it?

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:

(let ((redirect  (if (active-minibuffer-window)
                     1on1-minibuffer-frame
                   (and completion-reference-buffer
                        (get-buffer-window completion-reference-buffer
                                           'visible)
                        (not (eq (get-buffer "*Completions*")
                                 completion-reference-buffer))
                        (window-frame
                          (get-buffer-window
                             completion-reference-buffer t))))))
  (when redirect (redirect-frame-focus (selected-frame) redirect)))

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.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > 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

RE: About the 'minibuffer' frame parameter

[Drew Adams]

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

Yes.

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

Yes.

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

Yes.

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

Yes.

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

Yes.

> (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?

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?)

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.

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

Yes, it is misleading.  But why is it not critical (a problem)?
And why does it happen also for geometry parameters?  (And why
does it happen for `frame-parameter'?)

> 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.
     ^^^^^^^
     cannot (typo)
 
> 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 (?).

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

Hm.

> Finally evaluate the form
> (frame-parameter initial-frame 'minibuffer)
> You will see something like #<window 4 on  *Minibuf-0*>

Yes.

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

No.

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

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 (?).

> In general, ‘frame-parameter’ is useless for finding the 
> minibuffer frame.

If that is the correct behavior then it should be doc'd.
Is it the correct behavior?

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

It seems that Lisp code generally does likewise: set it but
not test it.  The `frameset.el' code does seem to test it,
however.

Thanks for explaining.

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

Re: About the 'minibuffer' frame parameter

[Juanma Barranquero]

[Answering to something from a few months ago...]

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

It had its moments (so the long comment/rant section), but it was also fun.

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

I didn't gave up, life just dealt me a really weird couple of years.

    Juanma

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 14 Jan 2017 01:59:59 +0100
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> > I slowly begin to understand why Juanma gave up coding for Emacs :-(
> 
> I didn't gave up, life just dealt me a really weird couple of years.

Are we lucky to have you back?

Re: About the 'minibuffer' frame parameter

[Juanma Barranquero]

On Sat, Jan 14, 2017 at 8:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Are we lucky to have you back?

I think so. But first I'll have to spend a little time setting my
building environment.

     Juanma

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 14 Jan 2017 10:18:36 +0100
> Cc: martin rudalics <rudalics@gmx.at>, Drew Adams <drew.adams@oracle.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Jan 14, 2017 at 8:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Are we lucky to have you back?
> 
> I think so. But first I'll have to spend a little time setting my
> building environment.

Great, thanks.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

> I think so. But first I'll have to spend a little time setting my
> building environment.

We've been missing you.

martin

Re: About the 'minibuffer' frame parameter

[Juanma Barranquero]

On Sat, Jan 14, 2017 at 12:05 PM, martin rudalics <rudalics@gmx.at> wrote:

> We've been missing you.

Thanks, I've been missing Emacs and its motley crew.

Re: About the 'minibuffer' frame parameter

[John Wiegley]

>>>>> "JB" == Juanma Barranquero <lekktu@gmail.com> writes:

JB> Thanks, I've been missing Emacs and its motley crew.

Welcome back, Juanma!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

RE: About the 'minibuffer' frame parameter

[Drew Adams]

> > I think so. But first I'll have to spend a little time setting my
> > building environment.
> 
> We've been missing you.

+1

Re: About the 'minibuffer' frame parameter

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thank you for rejoining us.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Fri, 05 Aug 2016 18:37:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > You mean, you think there's some code out there that expects to
>  > receive nil in that case?  Do we have any code in our tree that might
>  > expect that?
> 
> I'm afraid so, yes.  Otherwise this rigmarole would hardly make sense.
> 
> But I haven't checked all places because I rather soonish stumbled upon
> things like
> 
> (eq (cdr (or (assq 'minibuffer initial-frame-alist)
> 	     (assq 'minibuffer window-system-frame-alist)
> 	     (assq 'minibuffer default-frame-alist)
> 	     '(minibuffer . t)))
>      t)
> 
> in ‘frame-notice-user-settings’.  And one revealing comment is in
> ‘set-frame-configuration’:
> 
>                 ;; Since we can't set a frame's minibuffer status,
>                 ;; we might as well omit the parameter altogether.

We could simply change the above code to follow suit.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > We could simply change the above code to follow suit.

Change what?  Initially I only wanted to simplify code like

(FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f))

because once f has been created, FRAME_HAS_MINIBUF_P (f) and
!FRAME_MINIBUF_ONLY_P (f) invariantly hold for the entire lifetime of f.
A bit field telling whether a frame owns a minibuffer or is
minibuffer-only/-less seems more practical instead of these macros.  The
value stored in that bit field would have to reflect the value stored in
the 'minibuffer' frame parameter.  But for a minibuffer-less frame we
OT1H store the minibuffer window in that parameter and OTOH we report
the value nil for that parameter in ‘frame-parameters’.

We could either modify that code in store_frame_param

   if (EQ (prop, Qminibuffer) && WINDOWP (val))
     {
       if (! MINI_WINDOW_P (XWINDOW (val)))
	error ("Surrogate minibuffer windows must be minibuffer windows");

       if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f))
	  && !EQ (val, f->minibuffer_window))
	error ("Can't change the surrogate minibuffer of a frame with its own minibuffer");

       /* Install the chosen minibuffer window, with proper buffer.  */
       fset_minibuffer_window (f, val);
     }

to store Qnil instead of the minibuffer window or do away with the
special treatment of the 'minibuffer' parameter in ‘frame-parameters’ as
I mentioned earlier.

The former should be sane because so far C-code always goes for the
value of FRAME_MINIBUF_WINDOW to find the minibuffer window of a frame.
However, we'd still have to explain that ‘set-frame-parameter’ can
change a frame's minibuffer window without reflecting the change in the
return value of ‘frame-parameters’.

As mentioned before, removing the special treatment of the 'minibuffer'
parameter in ‘frame-parameters’ would imply that Elisp code relying on
the values we report currently might be broken in the future.  The doc
change required for this solution would be marginal.

Things would be much clearer if we had provided some orthogonality of
‘minibuffer-window’ and ‘set-minibuffer-window’.

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Sat, 06 Aug 2016 11:33:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org

I must admit I'm a bit confused about the issues you raise.  So let me
make a step or two back, before we continue.

You started by saying:

> (progn
>   (setq minibuffer-less-frame (make-frame '((minibuffer . nil))))
>   (setq minibuffer-only-frame (make-frame '((minibuffer . only))))
> 
>   (set-frame-parameter
>    minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))
>   (frame-parameter minibuffer-less-frame 'minibuffer))
> [...]
> But if the frame is minibuffer-less and uses the minibuffer window of
> some other frame, we return as value nil although the real, internal
> frame parameter's value (not the one produced by the
> 
>   store_in_alist (&alist, Qminibuffer,
>                   (! FRAME_HAS_MINIBUF_P (f) ? Qnil
>                    : FRAME_MINIBUF_ONLY_P (f) ? Qonly
>                    : FRAME_MINIBUF_WINDOW (f)));
> 
> construct) is actually that window.  Otherwise, evaluating the
> ‘set-frame-parameter’ above would have produced an error.

I don't understand the last sentence: it starts with "otherwise",
which seems to imply that if frame-parameter did not produce nil for a
minibuffer-less frame, the call to set-frame-parameter would somehow
signal an error.  However, I don't see any relation between what
(frame-parameter FRAME 'minibuffer) returns and any calls to
set-frame-parameter for the same frame.  So what error were you
talking about?

Next, the documentation issue:

  `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.

  The sentence "If the value is a minibuffer window (in some other frame),
  the frame uses that minibuffer." is misleading.  A minibuffer window is
  reported iff that window is on the _same_ frame and that frame is not a
  minibuffer-only frame.  A minibuffer window in some other frame is never
  reported.

So when do we report t?  It sounds like the answer is "never", right?
IOW, the documentation seems to describe some situation that existed
in the past, and is now OBE due to code changes.  Correct?

> Note in this context that ‘minibuffer-window’ returns the correct
> minibuffer window for its FRAME argument while ‘set-minibuffer-window’
> does not allow to set the minibuffer window for a specific frame.

IMO, this is a separate, albeit probably related, issue.  Are there
any problems to let set-minibuffer-window allow setting the minibuffer
window of a frame?

> I'm not sure how to deal with this situation.  Personally, I'd prefer to
> report the real, internal 'minibuffer' parameter

And I implicitly agreed with that.

> but am afraid that might break existing code.

And for that, I proposed:

> > But I haven't checked all places because I rather soonish stumbled upon
> > things like
> > 
> > (eq (cdr (or (assq 'minibuffer initial-frame-alist)
> >            (assq 'minibuffer window-system-frame-alist)
> >            (assq 'minibuffer default-frame-alist)
> >            '(minibuffer . t)))
> >      t)
> > 
> > in ‘frame-notice-user-settings’.  And one revealing comment is in
> > ‘set-frame-configuration’:
> > 
> >                 ;; Since we can't set a frame's minibuffer status,
> >                 ;; we might as well omit the parameter altogether.
> 
> We could simply change the above code to follow suit.

To which you replied:

> Change what?

Obviously, change the Lisp snippet shown above, which expects to see a
nil minibuffer parameter for minibuffer-less frames.  Change it not to
expect that, and instead test the minibuffer window for whether it is
on the same frame or not.

> Initially I only wanted to simplify code like
> 
> (FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f))
> 
> because once f has been created, FRAME_HAS_MINIBUF_P (f) and
> !FRAME_MINIBUF_ONLY_P (f) invariantly hold for the entire lifetime of f.
> A bit field telling whether a frame owns a minibuffer or is
> minibuffer-only/-less seems more practical instead of these macros.  The
> value stored in that bit field would have to reflect the value stored in
> the 'minibuffer' frame parameter.  But for a minibuffer-less frame we
> OT1H store the minibuffer window in that parameter and OTOH we report
> the value nil for that parameter in ‘frame-parameters’.

I think we should report the window, i.e. the actual value stored in
that parameter.

> We could either modify that code in store_frame_param
> 
>   if (EQ (prop, Qminibuffer) && WINDOWP (val))
>     {
>       if (! MINI_WINDOW_P (XWINDOW (val)))
>         error ("Surrogate minibuffer windows must be minibuffer windows");

>       if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f))
>           && !EQ (val, f->minibuffer_window))
>         error ("Can't change the surrogate minibuffer of a frame with its own 
> minibuffer");
> 
>       /* Install the chosen minibuffer window, with proper buffer.  */
>       fset_minibuffer_window (f, val);
>     }
> 
> to store Qnil instead of the minibuffer window or do away with the
> special treatment of the 'minibuffer' parameter in ‘frame-parameters’ as
> I mentioned earlier.

I like the latter possibility much better.  In general, I prefer to
report the actual values whenever possible, especially when we have no
reason to hide the value from Lisp applications.

> As mentioned before, removing the special treatment of the 'minibuffer'
> parameter in ‘frame-parameters’ would imply that Elisp code relying on
> the values we report currently might be broken in the future.

And my suggestion to that was to fix that code, wherever we find it.

> Things would be much clearer if we had provided some orthogonality of
> ‘minibuffer-window’ and ‘set-minibuffer-window’.

Not sure what you mean by "orthogonality" here.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > You started by saying:
 >
 >> (progn
 >>    (setq minibuffer-less-frame (make-frame '((minibuffer . nil))))
 >>    (setq minibuffer-only-frame (make-frame '((minibuffer . only))))
 >>
 >>    (set-frame-parameter
 >>     minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))
 >>    (frame-parameter minibuffer-less-frame 'minibuffer))
 >> [...]
 >> But if the frame is minibuffer-less and uses the minibuffer window of
 >> some other frame, we return as value nil although the real, internal
 >> frame parameter's value (not the one produced by the
 >>
 >>    store_in_alist (&alist, Qminibuffer,
 >>                    (! FRAME_HAS_MINIBUF_P (f) ? Qnil
 >>                     : FRAME_MINIBUF_ONLY_P (f) ? Qonly
 >>                     : FRAME_MINIBUF_WINDOW (f)));
 >>
 >> construct) is actually that window.  Otherwise, evaluating the
 >> ‘set-frame-parameter’ above would have produced an error.
 >
 > I don't understand the last sentence: it starts with "otherwise",
 > which seems to imply that if frame-parameter did not produce nil for a
 > minibuffer-less frame, the call to set-frame-parameter would somehow
 > signal an error.

If with emacs -Q I do

(let ((minibuffer-only-frame (make-frame '((minibuffer . only)))))
   (set-frame-parameter
    nil 'minibuffer (frame-root-window minibuffer-only-frame)))

I get an error like "Can’t change the surrogate minibuffer of a frame
with its own minibuffer".  Now, an application that wants to assign a
new minibuffer window for an arbitrary frame has two ways to avoid that
error: Either it uses

(not (eq (window-frame (minibuffer-window frame))) frame)

or

(not (frame-parameter frame 'minibuffer))

The former is pretty contrived.  For example, the coder would have to
know that the frame of a minibuffer-only frame's minibuffer window is
that frame.  So I expect that most applications would prefer the latter.
But in order to make that feasible, ‘frame-parameter’ has to report nil
for the 'minibuffer' parameter of a minibuffer-less frame.

However, the judgment whether to raise an error is based on evaluating
FRAME_HAS_MINIBUF_P and _not_ on checking the frame parameter.  So when
you look at the implementation of ‘set-frame-parameter’, my sentence is
indeed misleading.

 > However, I don't see any relation between what
 > (frame-parameter FRAME 'minibuffer) returns and any calls to
 > set-frame-parameter for the same frame.  So what error were you
 > talking about?

I'm not talking about an error here but about the fact that setting a
frame's minibuffer window via ‘set-frame-parameter’ is not reflected in
the value returned by ‘frame-parameter’ for that frame's 'minibuffer'
parameter.  You have to call ‘minibuffer-window’ for that frame to see
whether something has effectively changed.

 > Next, the documentation issue:
 >
 >    `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.
 >
 >    The sentence "If the value is a minibuffer window (in some other frame),
 >    the frame uses that minibuffer." is misleading.  A minibuffer window is
 >    reported iff that window is on the _same_ frame and that frame is not a
 >    minibuffer-only frame.  A minibuffer window in some other frame is never
 >    reported.
 >
 > So when do we report t?  It sounds like the answer is "never", right?

Yes.

 > IOW, the documentation seems to describe some situation that existed
 > in the past, and is now OBE due to code changes.  Correct?

Not really.  While t never gets reported, it can be used either in alist
specifications or in the 'minibuffer' frame parameter of ‘make-frame’.
It is redundant in both but allowed AFAICT.  You can even get away with
nonsense like

(let ((minibuffer-only-frame (make-frame '((minibuffer . only)))))
   (set-frame-parameter minibuffer-only-frame 'minibuffer t)
   (frame-parameter minibuffer-only-frame 'minibuffer))

No error gets reported and the parameter of the minibuffer-only frame
appears unchanged.  It simply does not matter that it has been set to t
internally.

 >> Note in this context that ‘minibuffer-window’ returns the correct
 >> minibuffer window for its FRAME argument while ‘set-minibuffer-window’
 >> does not allow to set the minibuffer window for a specific frame.
 >
 > IMO, this is a separate, albeit probably related, issue.  Are there
 > any problems to let set-minibuffer-window allow setting the minibuffer
 > window of a frame?

Certainly not - if checked and documented orderly.  But when you already
have a minibuffer window at hand and want to make a new minibuffer-less
frame use that window, you currently can write

(let ((window (minibuffer-window)))
   (make-frame `((minibuffer . ,window))))

BTW ‘set-minibuffer-window’ is a very obscure function.  It's nowhere
used and I wouldn't know why and how to use it.

 > And for that, I proposed:
 >
 >>> But I haven't checked all places because I rather soonish stumbled upon
 >>> things like
 >>>
 >>> (eq (cdr (or (assq 'minibuffer initial-frame-alist)
 >>>             (assq 'minibuffer window-system-frame-alist)
 >>>             (assq 'minibuffer default-frame-alist)
 >>>             '(minibuffer . t)))
 >>>       t)
 >>>
 >>> in ‘frame-notice-user-settings’.  And one revealing comment is in
 >>> ‘set-frame-configuration’:
 >>>
 >>>                  ;; Since we can't set a frame's minibuffer status,
 >>>                  ;; we might as well omit the parameter altogether.
 >>
 >> We could simply change the above code to follow suit.
 >
 > To which you replied:
 >
 >> Change what?
 >
 > Obviously, change the Lisp snippet shown above, which expects to see a
 > nil minibuffer parameter for minibuffer-less frames.  Change it not to
 > expect that, and instead test the minibuffer window for whether it is
 > on the same frame or not.

If you mean the snippet

(eq (cdr (or (assq 'minibuffer initial-frame-alist) ... t)

then I suppose that it is correct: The value t _is_ meaningful for the
alist variables.  It just never gets reported for an actual frame.  In
frameset.el Juanma wrote about the 'minibuffer' frame parameter:

;; - `minibuffer': It can contain a reference to a live window, which cannot
;;   be serialized.  Because of Emacs' idiosyncratic treatment of this
;;   parameter, frames created with (minibuffer . t) have a parameter
;;   (minibuffer . #<window...>), while frames created with
;;   (minibuffer . #<window...>) have (minibuffer . nil), which is madness
;;   but helps to differentiate between minibufferless and "normal" frames.

Here I think that Juanma's wrong BTW.  It does not help IMHO.

;;   So, changing (minibuffer . #<window...>) to (minibuffer . t) allows
;;   Emacs to set up the new frame correctly.  Nice, uh?

But for the rest I fully agree with him.  And his (local) fix explains
why t would be a good value.  So I still do not know what you propose to
change.

 >> But for a minibuffer-less frame we
 >> OT1H store the minibuffer window in that parameter and OTOH we report
 >> the value nil for that parameter in ‘frame-parameters’.
 >
 > I think we should report the window, i.e. the actual value stored in
 > that parameter.
[...]
 > In general, I prefer to
 > report the actual values whenever possible, especially when we have no
 > reason to hide the value from Lisp applications.

Modulo the fact that, as I mentioned above, some application might want
to use (not (frame-parameter frame 'minibuffer)) to check whether it is
allowed to change the minibuffer window of an arbitrary frame.

 >> As mentioned before, removing the special treatment of the 'minibuffer'
 >> parameter in ‘frame-parameters’ would imply that Elisp code relying on
 >> the values we report currently might be broken in the future.
 >
 > And my suggestion to that was to fix that code, wherever we find it.

frameset.el already fixes the code internally so we would have to revert
those fixes.  That's hairy.  And I don't know how many times anyone else
already has invented a workaround for all these idiosyncrasies.

 >> Things would be much clearer if we had provided some orthogonality of
 >> ‘minibuffer-window’ and ‘set-minibuffer-window’.
 >
 > Not sure what you mean by "orthogonality" here.

I meant "duality".  In the sense that both should take a FRAME argument.

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Mon, 08 Aug 2016 10:27:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > In general, I prefer to
>  > report the actual values whenever possible, especially when we have no
>  > reason to hide the value from Lisp applications.
> 
> Modulo the fact that, as I mentioned above, some application might want
> to use (not (frame-parameter frame 'minibuffer)) to check whether it is
> allowed to change the minibuffer window of an arbitrary frame.
> 
>  >> As mentioned before, removing the special treatment of the 'minibuffer'
>  >> parameter in ‘frame-parameters’ would imply that Elisp code relying on
>  >> the values we report currently might be broken in the future.
>  >
>  > And my suggestion to that was to fix that code, wherever we find it.
> 
> frameset.el already fixes the code internally so we would have to revert
> those fixes.  That's hairy.  And I don't know how many times anyone else
> already has invented a workaround for all these idiosyncrasies.

So what is your suggestion for the course of actions?

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > So what is your suggestion for the course of actions?

(1) Make sure that store_frame_param doesn't store invalid parameter
     values.

(2) Never store a minibuffer window as frame parameter.

(3) Have ‘frame-parameter’ return the 'minibuffer' parameter as stored
     internally.  If no stored value is available, return t.

(4) Wait for regression reports.

(5) Fix the documentation.

(6) Fix/remove related comments.

Together (1) and (2) mean that the parameter becomes immutable as
occasionally already claimed.  (3) will require changes to frameset.el.
FWIW, the only code in frameset.el that seems to depend on the old
behavior is:

			    (let ((w (frame-parameter f 'minibuffer)))
			      (and (window-live-p w)
				   (window-minibuffer-p w)
				   (eq (window-frame w) f))))

This would be probably replaced by:

			    (let ((w (minibuffer-window f)))
			      (and (window-live-p w)
				   (eq (window-frame w) f))))

If anyone knows about code that does similar things in this or any other
package please tell us.

One open question is how to handle the minibuffer window in frame
configurations.  For example, the valid form

(let ((minibuffer-less-frame (make-frame '((minibuffer . nil))))
       (configuration (current-frame-configuration))
       (minibuffer-only-frame (make-frame '((minibuffer . only)))))
   (set-frame-parameter
    minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))
   (set-frame-configuration configuration))

currently throws an error while

(let ((initial-frame (selected-frame))
       (minibuffer-less-frame (make-frame '((minibuffer . nil))))
       (configuration (current-frame-configuration))
       (minibuffer-only-frame (make-frame '((minibuffer . only)))))
   (set-frame-parameter
    minibuffer-less-frame 'minibuffer (frame-root-window minibuffer-only-frame))
   (delete-frame initial-frame)
   (set-frame-configuration configuration))

in addition leaves me with a minibuffer-less frame I can't neither make
visible nor deiconify.

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Tue, 09 Aug 2016 10:27:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > So what is your suggestion for the course of actions?
> 
> (1) Make sure that store_frame_param doesn't store invalid parameter
>      values.
> 
> (2) Never store a minibuffer window as frame parameter.
> 
> (3) Have ‘frame-parameter’ return the 'minibuffer' parameter as stored
>      internally.  If no stored value is available, return t.
> 
> (4) Wait for regression reports.
> 
> (5) Fix the documentation.
> 
> (6) Fix/remove related comments.

I'm okay with that, but I'm surprised by (2): won't storing the
minibuffer window there allow us to report the correct value in (3)?
What am I missing?

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 >> (1) Make sure that store_frame_param doesn't store invalid parameter
 >>       values.
 >>
 >> (2) Never store a minibuffer window as frame parameter.
 >>
 >> (3) Have ‘frame-parameter’ return the 'minibuffer' parameter as stored
 >>       internally.  If no stored value is available, return t.
 >>
 >> (4) Wait for regression reports.
 >>
 >> (5) Fix the documentation.
 >>
 >> (6) Fix/remove related comments.
 >
 > I'm okay with that, but I'm surprised by (2): won't storing the
 > minibuffer window there allow us to report the correct value in (3)?
 > What am I missing?

If we did that we would invert the values returned by ‘frame-parameter’
for the "normal" frame and minibuffer-less frame cases.  Currently, we
return the minibuffer window for a normal frame and nil for a
minibuffer-less frame.  You would return the minibuffer window for a
minibuffer-less frame and t for a normal frame.  Correct?

This would have the benefit that after

   (set-frame-parameter minibuffer-less-frame 'minibuffer some-minibuffer-window)

the value returned by ‘frame-parameter’ would be consistent with the
requested value.  However, most minibuffer-less frames are created via

   (make-frame '((minibuffer . nil)))

and whatever we do here we would introduce another inconsistency: Either
the stored value is the minibuffer window chosen by Emacs and the value
returned by ‘frame-parameter’ would not be the value from the PARAMETERS
argument of ‘make-frame’.  Or we would sometimes return nil and
sometimes a window as value of the 'minibuffer' frame parameter of a
minibuffer-less frame.

Given the fact that changing the frame parameter of a minibuffer-less
frame is a pretty rare operation, I would prefer the solution sketched
in (2).  WDYT?

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Tue, 09 Aug 2016 18:07:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >> (1) Make sure that store_frame_param doesn't store invalid parameter
>  >>       values.
>  >>
>  >> (2) Never store a minibuffer window as frame parameter.
>  >>
>  >> (3) Have ‘frame-parameter’ return the 'minibuffer' parameter as stored
>  >>       internally.  If no stored value is available, return t.
>  >>
>  >> (4) Wait for regression reports.
>  >>
>  >> (5) Fix the documentation.
>  >>
>  >> (6) Fix/remove related comments.
>  >
>  > I'm okay with that, but I'm surprised by (2): won't storing the
>  > minibuffer window there allow us to report the correct value in (3)?
>  > What am I missing?
> 
> If we did that we would invert the values returned by ‘frame-parameter’
> for the "normal" frame and minibuffer-less frame cases.  Currently, we
> return the minibuffer window for a normal frame and nil for a
> minibuffer-less frame.  You would return the minibuffer window for a
> minibuffer-less frame and t for a normal frame.  Correct?

Maybe.  Another alternative would be to return a window in both cases.

> This would have the benefit that after
> 
>    (set-frame-parameter minibuffer-less-frame 'minibuffer some-minibuffer-window)
> 
> the value returned by ‘frame-parameter’ would be consistent with the
> requested value.  However, most minibuffer-less frames are created via
> 
>    (make-frame '((minibuffer . nil)))
> 
> and whatever we do here we would introduce another inconsistency: Either
> the stored value is the minibuffer window chosen by Emacs and the value
> returned by ‘frame-parameter’ would not be the value from the PARAMETERS
> argument of ‘make-frame’.  Or we would sometimes return nil and
> sometimes a window as value of the 'minibuffer' frame parameter of a
> minibuffer-less frame.

We have already a few cases where frame-parameter returns a value
different from the one specified when make-frame was called.  There's
nothing wrong about that, if it's Emacs that chooses the actual value.

> Given the fact that changing the frame parameter of a minibuffer-less
> frame is a pretty rare operation, I would prefer the solution sketched
> in (2).  WDYT?

Do you still prefer (2)?  I prefer storing a window because then we
could naturally return it, like we do with frame colors.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > Another alternative would be to return a window in both cases.

But then we can't discriminate minibuffer-less from normal frames by
looking at the parameter value only.

 > We have already a few cases where frame-parameter returns a value
 > different from the one specified when make-frame was called.  There's
 > nothing wrong about that, if it's Emacs that chooses the actual value.

This goes both ways.  With (2) Emacs would choose nil when
‘set-frame-position’ explicitly asks for a window.  And with no
'minibuffer' specified we'd have to return t or a window in any case.

 > Do you still prefer (2)?  I prefer storing a window because then we
 > could naturally return it, like we do with frame colors.

C code never consults the frame parameter.  Elisp code currently
consults the parameter in four places only, three of them to find out
whether the frame is minibuffer-only.  If Elisp code wants the window,
it uses ‘minibuffer-window’ which handles all types of frames.  And with
(2) the values t, nil and 'only' would immediately tell the type of any
frame.

martin

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Tue, 09 Aug 2016 19:34:20 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > Another alternative would be to return a window in both cases.
> 
> But then we can't discriminate minibuffer-less from normal frames by
> looking at the parameter value only.

We can look at what window-frame returns for that window, can't we?

>  > We have already a few cases where frame-parameter returns a value
>  > different from the one specified when make-frame was called.  There's
>  > nothing wrong about that, if it's Emacs that chooses the actual value.
> 
> This goes both ways.  With (2) Emacs would choose nil when
> ‘set-frame-position’ explicitly asks for a window.  And with no
> 'minibuffer' specified we'd have to return t or a window in any case.

Yes, but IMO nil is not a meaningful value.  If we know better, we
should return a more concrete value.

>  > Do you still prefer (2)?  I prefer storing a window because then we
>  > could naturally return it, like we do with frame colors.
> 
> C code never consults the frame parameter.  Elisp code currently
> consults the parameter in four places only, three of them to find out
> whether the frame is minibuffer-only.  If Elisp code wants the window,
> it uses ‘minibuffer-window’ which handles all types of frames.  And with
> (2) the values t, nil and 'only' would immediately tell the type of any
> frame.

Yes, of course, the current situation is not impossible.  We are
talking about improving it.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

 >> But then we can't discriminate minibuffer-less from normal frames by
 >> looking at the parameter value only.
 >
 > We can look at what window-frame returns for that window, can't we?

Tediously so, yes.

 >> This goes both ways.  With (2) Emacs would choose nil when
 >> ‘set-frame-position’ explicitly asks for a window.  And with no
 >> 'minibuffer' specified we'd have to return t or a window in any case.
 >
 > Yes, but IMO nil is not a meaningful value.  If we know better, we
 > should return a more concrete value.

Sounds convincing.

 > Yes, of course, the current situation is not impossible.  We are
 > talking about improving it.

I attached a preliminary version of the code changes.  Please have a
look.

Thanks, martin

[-- Attachment #2: minibuffer-frame-parameter.diff --]
[-- Type: text/plain, Size: 4532 bytes --]

diff --git a/lisp/frameset.el b/lisp/frameset.el
index 2453f57..aa16647 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -908,10 +908,7 @@ frameset--reuse-frame
 	   (unless (or frame (eq (cdr (assq 'minibuffer parameters)) 'only))
 	     (setq frame (frameset--find-frame-if
 			  (lambda (f)
-			    (let ((w (frame-parameter f 'minibuffer)))
-			      (and (window-live-p w)
-				   (window-minibuffer-p w)
-				   (eq (window-frame w) f))))
+			    (eq (frame-parameter f 'minibuffer) t))
 			  display))))
 	  (mini
 	   ;; For minibufferless frames, check whether they already exist,
@@ -1028,7 +1025,7 @@ frameset-keep-original-display-p

 (defun frameset-minibufferless-first-p (frame1 _frame2)
   "Predicate to sort minibufferless frames before other frames."
-  (not (frame-parameter frame1 'minibuffer)))
+  (windowp (frame-parameter frame1 'minibuffer)))

 ;;;###autoload
 (cl-defun frameset-restore (frameset
diff --git a/src/frame.c b/src/frame.c
index 899c315..e550e51 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -658,6 +658,7 @@ struct frame *
       mw->mini = 1;
       wset_frame (mw, frame);
       fset_minibuffer_window (f, mini_window);
+      store_frame_param (f, Qminibuffer, Qt);
     }
   else
     {
@@ -770,6 +771,7 @@ struct frame *
     }

   fset_minibuffer_window (f, mini_window);
+  store_frame_param (f, Qminibuffer, mini_window);

   /* Make the chosen minibuffer window display the proper minibuffer,
      unless it is already showing a minibuffer.  */
@@ -807,6 +809,7 @@ struct frame *

   mini_window = f->root_window;
   fset_minibuffer_window (f, mini_window);
+  store_frame_param (f, Qminibuffer, Qonly);
   XWINDOW (mini_window)->mini = 1;
   wset_next (XWINDOW (mini_window), Qnil);
   wset_prev (XWINDOW (mini_window), Qnil);
@@ -2404,6 +2407,46 @@ of them (the selected terminal frame) is actually displayed.
 {
   register Lisp_Object old_alist_elt;

+  if (EQ (prop, Qminibuffer))
+    {
+      if (WINDOWP (val))
+	{
+	  if (!MINI_WINDOW_P (XWINDOW (val)))
+	    error ("The 'minibuffer' parameter does not specify a valid minibuffer window");
+	  else if (FRAME_HAS_MINIBUF_P (f))
+	    {
+	      if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
+		val = Qt;
+	      else
+		error ("Can't change the minibuffer window of a frame with its own minibuffer");
+	    }
+	  else if (FRAME_MINIBUF_ONLY_P (f))
+	    {
+	      if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
+		val = Qonly;
+	      else
+		error ("Can't change the minibuffer window of a minibuffer-only frame");
+	    }
+	  else
+	    /* Store the chosen minibuffer window.  */
+	    fset_minibuffer_window (f, val);
+	}
+      else
+	{
+	  Lisp_Object old_val = Fcdr (Fassq (Qminibuffer, f->param_alist));
+
+	  if (!NILP (old_val))
+	    {
+	      if (WINDOWP (old_val) && NILP (val))
+		/* Don't change the value for a minibuffer-less frame if
+		   only nil was specified as new value.  */
+		val = old_val;
+	      else if (!EQ (old_val, val))
+		error ("Can't change the 'minibuffer' parameter of this frame");
+	    }
+	}
+    }
+
   /* The buffer-list parameters are stored in a special place and not
      in the alist.  All buffers must be live.  */
   if (EQ (prop, Qbuffer_list))
@@ -2475,19 +2518,6 @@ of them (the selected terminal frame) is actually displayed.
       else if (EQ (prop, Qname))
 	set_term_frame_name (f, val);
     }
-
-  if (EQ (prop, Qminibuffer) && WINDOWP (val))
-    {
-      if (! MINI_WINDOW_P (XWINDOW (val)))
-	error ("Surrogate minibuffer windows must be minibuffer windows");
-
-      if ((FRAME_HAS_MINIBUF_P (f) || FRAME_MINIBUF_ONLY_P (f))
-	  && !EQ (val, f->minibuffer_window))
-	error ("Can't change the surrogate minibuffer of a frame with its own minibuffer");
-
-      /* Install the chosen minibuffer window, with proper buffer.  */
-      fset_minibuffer_window (f, val);
-    }
 }

 /* Return color matches UNSPEC on frame F or nil if UNSPEC
@@ -2565,10 +2595,6 @@ It is a list of elements of the form (PARM . VALUE), where PARM is a symbol.
 	   : FRAME_COLS (f));
   store_in_alist (&alist, Qwidth, make_number (width));
   store_in_alist (&alist, Qmodeline, (FRAME_WANTS_MODELINE_P (f) ? Qt : Qnil));
-  store_in_alist (&alist, Qminibuffer,
-		  (! FRAME_HAS_MINIBUF_P (f) ? Qnil
-		   : FRAME_MINIBUF_ONLY_P (f) ? Qonly
-		   : FRAME_MINIBUF_WINDOW (f)));
   store_in_alist (&alist, Qunsplittable, (FRAME_NO_SPLIT_P (f) ? Qt : Qnil));
   store_in_alist (&alist, Qbuffer_list, f->buffer_list);
   store_in_alist (&alist, Qburied_buffer_list, f->buried_buffer_list);

Re: About the 'minibuffer' frame parameter

[Stefan Monnier]

>>> But then we can't discriminate minibuffer-less from normal frames by
>>> looking at the parameter value only.
>> We can look at what window-frame returns for that window, can't we?
> Tediously so, yes.

For minibuffer-free frames, we could return the *frame* whose minibuffer
we use.


        Stefan

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 10 Aug 2016 10:23:55 -0400
> 
> >>> But then we can't discriminate minibuffer-less from normal frames by
> >>> looking at the parameter value only.
> >> We can look at what window-frame returns for that window, can't we?
> > Tediously so, yes.
> 
> For minibuffer-free frames, we could return the *frame* whose minibuffer
> we use.

Why?  The frame parameter's value is a window, so the most natural
value would be the window used for the minibuffer.  Given the window,
accessing its frame, if it's needed, is trivial.

Re: About the 'minibuffer' frame parameter

[Eli Zaretskii]

> Date: Wed, 10 Aug 2016 14:15:45 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  >> This goes both ways.  With (2) Emacs would choose nil when
>  >> ‘set-frame-position’ explicitly asks for a window.  And with no
>  >> 'minibuffer' specified we'd have to return t or a window in any case.
>  >
>  > Yes, but IMO nil is not a meaningful value.  If we know better, we
>  > should return a more concrete value.
> 
> Sounds convincing.
> 
>  > Yes, of course, the current situation is not impossible.  We are
>  > talking about improving it.
> 
> I attached a preliminary version of the code changes.  Please have a
> look.

I took a cursory look, and it looks OK to me.

Thanks.

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > I took a cursory look, and it looks OK to me.

I installed a slightly modified version on master/trunk.  Doc and
comments will be changed later.  If people notice any problems with
desktop-saving please complain immediately.

Thanks, martin

Re: About the 'minibuffer' frame parameter

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Sun, Aug 21, 2016 at 5:41 AM martin rudalics <rudalics@gmx.at> wrote:

> I installed a slightly modified version on master/trunk.  Doc and
> comments will be changed later.



> If people notice any problems with
> desktop-saving please complain immediately.
>

This is not a complaint. Just emailing to say that everything works as
before. I use desktop-mode with frame/window restore (default) using
emacsclient and it works as before.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 998 bytes --]

Re: About the 'minibuffer' frame parameter

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

Actually I noticed some pretty strange minibuffer behavior today. I don't
know what caused that to happen so I cannot explain how to recreate that.

I am on the aed22ca build of master.

Here's my best attempt to explain this:

- The minibuffer height increased to 2 characters (so I saw 2 rows instead
of 1)
- And I got 2 cursors in there.. one cursor had the default cursor face,
and other looked like the cursor face in inactive window.

That probably doesn't give you any hint.. but I thought of at least
mentioning it. I hope to get a recipe for that so that you can recreate the
issue consistently.

On Sun, Aug 21, 2016 at 4:51 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> On Sun, Aug 21, 2016 at 5:41 AM martin rudalics <rudalics@gmx.at> wrote:
>
>> I installed a slightly modified version on master/trunk.  Doc and
>> comments will be changed later.
>
>
>
>> If people notice any problems with
>> desktop-saving please complain immediately.
>>
>
> This is not a complaint. Just emailing to say that everything works as
> before. I use desktop-mode with frame/window restore (default) using
> emacsclient and it works as before.
> --
>
> Kaushal Modi
>
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2375 bytes --]

Re: About the 'minibuffer' frame parameter

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 1968 bytes --]

Actually, it seems like one of the existing windows gets cloned and that is
put on top of the minibuffer without modeline.

It looks something like this.

So the minibuffer looks completely fused with Win 2 of Buf x (that somehow
got created automatically when I enabled debug-on-error).
After some window switching, the mode line for Win 2 appears automatically.

==============================================
| Win 1 - Buf x                              |
----------------------------------------------
| Mode-line for Win 1                        |
==============================================
| Win 2 - Buf x                              |
----------------------------------------------
| Minibuffer                                 |
==============================================

(I put to white box there to mask my work stuff. If I close that window,
the missing modeline for the bottom "Win 2 - Buf x" is created
automatically. Note that the same "-Searchd" string is shown in the actual
window on the top right and the bottom window auto-created exactly above
the minibuffer (so I thought earlier that the minibuffer had 2 rows; it was
in fact an inactive window and thus that inactive window cursor face).

[image: pasted1]

On Mon, Aug 22, 2016 at 8:49 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Actually I noticed some pretty strange minibuffer behavior today. I don't
> know what caused that to happen so I cannot explain how to recreate that.
>
> I am on the aed22ca build of master.
>
> Here's my best attempt to explain this:
>
> - The minibuffer height increased to 2 characters (so I saw 2 rows instead
> of 1)
> - And I got 2 cursors in there.. one cursor had the default cursor face,
> and other looked like the cursor face in inactive window.
>
> That probably doesn't give you any hint.. but I thought of at least
> mentioning it. I hope to get a recipe for that so that you can recreate the
> issue consistently.
>
-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 3476 bytes --]

[-- Attachment #2: pasted1 --]
[-- Type: image/png, Size: 29108 bytes --]

Re: About the 'minibuffer' frame parameter

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --]

Please ignore that.. that bug is there but has nothing to do with your
recent commit.
I see it on emacs 25.1 RC2 too when I end up causing a timer error in
pdf-tools package:

=====
Interleave enabled
doc-view-goto-page: Wrong type argument: stringp, nil
Error running timer ‘pdf-cache--prefetch-start’: (error "epdfinfo: No such
page 0")
=====



On Mon, Aug 22, 2016 at 9:03 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Actually, it seems like one of the existing windows gets cloned and that
> is put on top of the minibuffer without modeline.
>
> It looks something like this.
>
> So the minibuffer looks completely fused with Win 2 of Buf x (that somehow
> got created automatically when I enabled debug-on-error).
> After some window switching, the mode line for Win 2 appears automatically.
>
> ==============================================
> | Win 1 - Buf x                              |
> ----------------------------------------------
> | Mode-line for Win 1                        |
> ==============================================
> | Win 2 - Buf x                              |
> ----------------------------------------------
> | Minibuffer                                 |
> ==============================================
>
-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 2551 bytes --]

[-- Attachment #2: pasted1 --]
[-- Type: image/png, Size: 29108 bytes --]

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > Actually, it seems like one of the existing windows gets cloned and that is
 > put on top of the minibuffer without modeline.
 >
 > It looks something like this.
 >
 > So the minibuffer looks completely fused with Win 2 of Buf x (that somehow
 > got created automatically when I enabled debug-on-error).
 > After some window switching, the mode line for Win 2 appears automatically.
 >
 > ==============================================
 > | Win 1 - Buf x                              |
 > ----------------------------------------------
 > | Mode-line for Win 1                        |
 > ==============================================
 > | Win 2 - Buf x                              |
 > ----------------------------------------------
 > | Minibuffer                                 |
 > ==============================================
 >
 > (I put to white box there to mask my work stuff. If I close that window,

You mean "If I delete Win 1"?

 > the missing modeline for the bottom "Win 2 - Buf x" is created
 > automatically.

And what else do you see now in Win 2 besides the "- Searchd" string?

 > Note that the same "-Searchd" string is shown in the actual
 > window on the top right and the bottom window auto-created exactly above
 > the minibuffer (so I thought earlier that the minibuffer had 2 rows; it was
 > in fact an inactive window and thus that inactive window cursor face).

In any case please do (window--dump-frame) for that frame - the result
of that dump is in a buffer called *window-frame-dump* and post the
result here.  I think that the appearance of that one line window is
more or less intentional but I have no idea who's responsible for it.
At least that someone seems to do very tricky things to your window
layout ;-)

 > Please ignore that.. that bug is there but has nothing to do with your
 > recent commit.
 > I see it on emacs 25.1 RC2 too when I end up causing a timer error in
 > pdf-tools package:

I'd still want to see the output of ‘window--dump-frame’ for this frame
(no fear - it doesn't reveal any buffer contents).

martin

Re: About the 'minibuffer' frame parameter

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]

On Mon, Aug 22, 2016 at 12:01 PM martin rudalics <rudalics@gmx.at> wrote:

>  > ==============================================
>  > | Win 1 - Buf x                              |
>  > ----------------------------------------------
>  > | Mode-line for Win 1                        |
>  > ==============================================
>  > | Win 2 - Buf x                              |
>  > ----------------------------------------------
>  > | Minibuffer                                 |
>  > ==============================================
>  >
>  > (I put to white box there to mask my work stuff. If I close that window,
>
> You mean "If I delete Win 1"?
>

Correct (C-x 0).


>  > the missing modeline for the bottom "Win 2 - Buf x" is created
>  > automatically.
>
> And what else do you see now in Win 2 besides the "- Searchd" string?
>

I see just one line and I can scroll that window up/down (but now I know
exactly what's causing there.. copying Oleh to throw some light here too;
more detail below).


>  > Note that the same "-Searchd" string is shown in the actual
>  > window on the top right and the bottom window auto-created exactly above
>  > the minibuffer (so I thought earlier that the minibuffer had 2 rows; it
> was
>  > in fact an inactive window and thus that inactive window cursor face).
>
> In any case please do (window--dump-frame) for that frame - the result
> of that dump is in a buffer called *window-frame-dump* and post the
> result here.


frame pixel: 1910 x 1096   cols/lines: 212 x 57   units: 9 x 19
frame text pixel: 1894 x 1096   cols/lines: 210 x 57
tool: 0  scroll: 0/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 9>   parent: nil
pixel left: 0   top: 0   size: 1910 x 1077   new: 906
char left: 0   top: 0   size: 212 x 56   new: 48
normal: 1.0 x 1.0   new: nil

#<window 7>   parent: #<window 9>
pixel left: 0   top: 0   size: 1910 x 1001   new: 830
char left: 0   top: 0   size: 212 x 52   new: 44
normal: 1.0 x 0.9294336118848654   new: nil

#<window 6 on Quick_Start_for_RTL_Users_9June16.pdf>   parent: #<window 7>
pixel left: 0   top: 0   size: 956 x 1001   new: 830
char left: 0   top: 0   size: 106 x 52   new: 44
normal: 0.5 x 1.0   new: nil
body pixel: 940 x 981   char: 104 x 51
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 8 on Quick_Start_for_RTL_Users_9June16.org>   parent: #<window 7>
pixel left: 956   top: 0   size: 954 x 1001   new: 830
char left: 106   top: 0   size: 106 x 52   new: 44
normal: 0.5 x 1.0   new: nil
body pixel: 938 x 981   char: 104 x 51
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 10 on Quick_Start_for_RTL_Users_9June16.pdf>   parent: #<window 9>
pixel left: 0   top: 1001   size: 1910 x 76   new: 76
char left: 0   top: 52   size: 212 x 4   new: 4
normal: 1.0 x 0.07056638811513463   new: nil
body pixel: 1894 x 56   char: 210 x 2
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1077   size: 1910 x 19   new: 190
char left: 0   top: 56   size: 212 x 1   new: 10
normal: 1.0 x 1.0   new: 0
body pixel: 1894 x 19   char: 210 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0


> I think that the appearance of that one line window is
> more or less intentional but I have no idea who's responsible for it.
> At least that someone seems to do very tricky things to your window
> layout ;-)
>

I strongly believe it's this:
http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/hydra/lv.el

The mode-line-less window is exactly what lv.el does for creating hydras.
What seems to happen is that the pdf-tools timer error does not allow a
hydra to finish doing its job.

=====
Error running timer ‘pdf-cache--prefetch-start’: (error "epdfinfo: No such
page 0")
=====

.. and I had bound toggling debug-on-error to a hydra head (hydra package
jargon).
I was able to recreate the same issue when calling any hydra.


>  > Please ignore that.. that bug is there but has nothing to do with your
>  > recent commit.
>  > I see it on emacs 25.1 RC2 too when I end up causing a timer error in
>  > pdf-tools package:
>
> I'd still want to see the output of ‘window--dump-frame’ for this frame
> (no fear - it doesn't reveal any buffer contents).
>

Thanks for the retained interest in fixing this :)

There are 2 things here:
- I need to figure out why the pdf-tools timer issue is caused. Once that
is fixed, with window issue should not happen as the hydras I launch will
be allowed to do all the needed window layout cleanup.
- Hopefully Oleh gets a chance to investigate the hydra/lv behavior under
the timer error circumstances.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 7227 bytes --]

Re: About the 'minibuffer' frame parameter

[martin rudalics]

 > #<window 10 on Quick_Start_for_RTL_Users_9June16.pdf>   parent: #<window 9>
 > pixel left: 0   top: 1001   size: 1910 x 76   new: 76
 > char left: 0   top: 52   size: 212 x 4   new: 4
 > normal: 1.0 x 0.07056638811513463   new: nil
 > body pixel: 1894 x 56   char: 210 x 2
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 0  divider: 0
 > height header-line: 0  mode-line: 20  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 1077   size: 1910 x 19   new: 190
 > char left: 0   top: 56   size: 212 x 1   new: 10
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1894 x 19   char: 210 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 0  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0

That's not what I see in the image you posted earlier.  In the dump,
Window 9 is 76 pixels high (4 lines) while the minibuffer window is 19
pixels high (one line).  In the image, the window corresponding to
window 9 is only one line high as the minibuffer window.  Also, I doubt
that deleting the other windows via C-x 1 will automatically give Window
9 its modeline back.

 > I strongly believe it's this:
 > http://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/packages/hydra/lv.el
 >
 > The mode-line-less window is exactly what lv.el does for creating hydras.
 > What seems to happen is that the pdf-tools timer error does not allow a
 > hydra to finish doing its job.

lv should give that window a different background so it can be
distinguished as such.  As a rule, if people use neither dividers nor
scrollbars/modelines, they should find some other way to distinguish
windows.  Otherwise, it's too easy to mix up their contents.

martin