Question about minibuffer and child frames (Posframe)

Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Hi Martin,

I have a question about minibuffer handling with child frames. Actually,
it's something that currently behaves differently on GUI and tty with
Posframe, via Vertico-Posframe, plus consult-buffer and similar. Since
I've looked at this for two hours today without being able to tell what
I'm missing here, I thought I'd just ask if you, or anyone else, has an
idea where to look.

Here's what I see:

On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
minibuffer at the top. The cursor is in that minibuffer. The minibuffer
ih the parent frame looks inactive. There is no prompt or anything else.
That's how it should be.

With my new code on tty, the same child frame pops up, but this time the
child frame's minibuffer contains a prompt and what I type is displayed
there and so on, but it doesn't have a visible cursor. The parent
frame's minibuffer this time contains the prompt and the cursor, too.

Any idea what that could be?

Re: Question about minibuffer and child frames (Posframe)

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Hi Martin,
>
> I have a question about minibuffer handling with child frames. Actually,
> it's something that currently behaves differently on GUI and tty with
> Posframe, via Vertico-Posframe, plus consult-buffer and similar. Since
> I've looked at this for two hours today without being able to tell what
> I'm missing here, I thought I'd just ask if you, or anyone else, has an
> idea where to look.
>
> Here's what I see:
>
> On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
> minibuffer at the top. The cursor is in that minibuffer. The minibuffer
> ih the parent frame looks inactive. There is no prompt or anything else.
> That's how it should be.
>
> With my new code on tty, the same child frame pops up, but this time the
> child frame's minibuffer contains a prompt and what I type is displayed
> there and so on, but it doesn't have a visible cursor. The parent
> frame's minibuffer this time contains the prompt and the cursor, too.
>
> Any idea what that could be?

Not Martin, but as I recall, posframe's "cursor" is actually emulated
by applying faces to SPC characters.

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Hi Martin,
>>
>> I have a question about minibuffer handling with child frames. Actually,
>> it's something that currently behaves differently on GUI and tty with
>> Posframe, via Vertico-Posframe, plus consult-buffer and similar. Since
>> I've looked at this for two hours today without being able to tell what
>> I'm missing here, I thought I'd just ask if you, or anyone else, has an
>> idea where to look.
>>
>> Here's what I see:
>>
>> On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
>> minibuffer at the top. The cursor is in that minibuffer. The minibuffer
>> ih the parent frame looks inactive. There is no prompt or anything else.
>> That's how it should be.
>>
>> With my new code on tty, the same child frame pops up, but this time the
>> child frame's minibuffer contains a prompt and what I type is displayed
>> there and so on, but it doesn't have a visible cursor. The parent
>> frame's minibuffer this time contains the prompt and the cursor, too.
>>
>> Any idea what that could be?
>
> Not Martin, but as I recall, posframe's "cursor" is actually emulated
> by applying faces to SPC characters.

Thanks.

Can't find that in posframe.el, though. AFICT, it uses the cursor-type
frame parameter. Or maybe Veritco or Consult do something? Have to
look, but that would be super strange.

Also, another strange thing is that on GUI, the oarent frame's
minibuffer doesn't show anything, while on tty it also shows the
prompt (with cursor).

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > I have a question about minibuffer handling with child frames. Actually,
 > it's something that currently behaves differently on GUI and tty with
 > Posframe, via Vertico-Posframe, plus consult-buffer and similar. Since
 > I've looked at this for two hours today without being able to tell what
 > I'm missing here, I thought I'd just ask if you, or anyone else, has an
 > idea where to look.
 >
 > Here's what I see:
 >
 > On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
 > minibuffer at the top. The cursor is in that minibuffer. The minibuffer
 > ih the parent frame looks inactive. There is no prompt or anything else.
 > That's how it should be.
 >
 > With my new code on tty, the same child frame pops up, but this time the
 > child frame's minibuffer contains a prompt and what I type is displayed
 > there and so on, but it doesn't have a visible cursor. The parent
 > frame's minibuffer this time contains the prompt and the cursor, too.
 >
 > Any idea what that could be?

Remember what I asked earlier?

 > >> Looks good.  But where does the user's answer appear?  In the
 > >> child-frame's minibuffer window?
 > >
 > > If you mean the 'y' when I type y at the prompt, that appears just after
 > > the prompt, that should be the echo area I think.
 >
 > Good.  I asked because I didn't see the cursor in the minibuffer window.
 > But screenshots often don't capture cursors.

Cursor handling on ttys is an arcane art as I recently noticed.  I have
no idea how it works.  Does the echo area work normally when you are in
the child frame in the sense that text does not appear in the normal
minibuffer frame too?  Does the cursor show up as expected in normal
text areas when you switch between parent and child frame?  If so, I see
no way around tracing cursor movement during a dialogue and look where
the cursor_to commands come from.  Also the fact that the prompt appears
in both minibuffer windows is obviously fishy but IMHO it's a redisplay
issue as well.

Maybe as a first step I would not give child frames on ttys their own
minibuffer windows.  Let them use the minibuffer window of the normal
frame that hosts them and you're done (making sure that a child frame
never obscures a minibuffer window).  User input always goes to the same
terminal window so there are no focusing or redirecting issues you have
to resolve.  And displaying dialogues from minibuffer-less child frames
should be handled correctly anyway.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

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

martin rudalics <rudalics@gmx.at> writes:

>> I have a question about minibuffer handling with child frames. Actually,
>> it's something that currently behaves differently on GUI and tty with
>> Posframe, via Vertico-Posframe, plus consult-buffer and similar. Since
>> I've looked at this for two hours today without being able to tell what
>> I'm missing here, I thought I'd just ask if you, or anyone else, has an
>> idea where to look.
>>
>> Here's what I see:
>>
>> On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
>> minibuffer at the top. The cursor is in that minibuffer. The minibuffer
>> ih the parent frame looks inactive. There is no prompt or anything else.
>> That's how it should be.
>>
>> With my new code on tty, the same child frame pops up, but this time the
>> child frame's minibuffer contains a prompt and what I type is displayed
>> there and so on, but it doesn't have a visible cursor. The parent
>> frame's minibuffer this time contains the prompt and the cursor, too.
>>
>> Any idea what that could be?
>
> Remember what I asked earlier?
>
>> >> Looks good.  But where does the user's answer appear?  In the
>> >> child-frame's minibuffer window?
>> >
>> > If you mean the 'y' when I type y at the prompt, that appears just after
>> > the prompt, that should be the echo area I think.
>>
>> Good.  I asked because I didn't see the cursor in the minibuffer window.
>> But screenshots often don't capture cursors.

I'm attaching an example, where I hope one can see that in a "normal"
child window this seems to work ATM. (Didn't get the blinking cursor in
the capture, but it's in the minibuffer in the child frae.) Please note
that the parent frame's minibuffer is inactive, everything happens in
the minibuffer of the child frame.


[-- Attachment #2: Screenshot 2024-10-02 at 17.05.33.png --]
[-- Type: image/png, Size: 359361 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2916 bytes --]


That's a frame made by

(defun my-make-child ()
  (interactive)
  (make-frame `((parent-frame . ,(selected-frame))
		(background-color . "gray10")
		(foreground-color . "white")
		(top . 15)
		(left . 40)
		(width . 80)
		(height . 25))))

> Cursor handling on ttys is an arcane art as I recently noticed.

Not only cursor handling :-).

I think I've meanwhile spent umpfteen times more time with the whole
frame handling than the redisplay part. It's a maze.

> I have no idea how it works. Does the echo area work normally when you
> are in the child frame in the sense that text does not appear in the
> normal minibuffer frame too?

Yes, I think the child behaves pretty much as if it were a normal
non-child frame, only that it is displayed on top of the parent.

(We display the cursor at the position that the selected window tells
us, while writing to the terminal. Which was how it also worked on GUIs
pre-21, when each window got a cursor. I had of course to change that
slightly because the selected window can be in a child, and we have to
take the child frame top/left into account.)

> Does the cursor show up as expected in normal
> text areas when you switch between parent and child frame?

I think so, yes. The selected window determines where the cursor is
displayed. If that is on the child frame, the cursor appears in the
child frame, if I select a window in the parent frame, it's there.

> If so, I see no way around tracing cursor movement during a dialogue
> and look where the cursor_to commands come from. Also the fact that
> the prompt appears in both minibuffer windows is obviously fishy but
> IMHO it's a redisplay issue as well.

Hm, if the window on the posframe isn't selected, that could explain it,
maybe. That could be an idea, but why wouldn't it be selected? Questions
about questions.

Thanks! Good that we spoke about that.

>
> Maybe as a first step I would not give child frames on ttys their own
> minibuffer windows.  Let them use the minibuffer window of the normal
> frame that hosts them and you're done (making sure that a child frame
> never obscures a minibuffer window).  

That's what current happening, in a way. And I at least find it
confusing because the music plays in the posframe, so to say,
user-interface-wise, not in the minibuffer at the bottom of the frame.

> User input always goes to the same terminal window so there are no
> focusing or redirecting issues you have to resolve. And displaying
> dialogues from minibuffer-less child frames should be handled
> correctly anyway.

Tja well the problem is that I don't want to mess with posframe and
packages using it. I'd rather have something working as much as possible
as on GUIs.

(It does pretty much that, including Corfu now, except for the remaining
problems, and the minibuffer stuff is not the only one. But none of that
in redisolay but in differences in frame handling. Frustrating.)

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > I'm attaching an example, where I hope one can see that in a "normal"
 > child window this seems to work ATM. (Didn't get the blinking cursor in
 > the capture, but it's in the minibuffer in the child frae.) Please note
 > that the parent frame's minibuffer is inactive, everything happens in
 > the minibuffer of the child frame.

The modeline of the "Completions* window seems to have the same
background as the modeline of the normal frame's *scratch* window.
Doesn't that hint at redisplay believing that both windows are the
selected one?

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> I'm attaching an example, where I hope one can see that in a "normal"
>> child window this seems to work ATM. (Didn't get the blinking cursor in
>> the capture, but it's in the minibuffer in the child frae.) Please note
>> that the parent frame's minibuffer is inactive, everything happens in
>> the minibuffer of the child frame.
>
> The modeline of the "Completions* window seems to have the same
> background as the modeline of the normal frame's *scratch* window.
> Doesn't that hint at redisplay believing that both windows are the
> selected one?

Probably. They are the (frame-selected-window) of their respective
frames. I guess that has previously not been possible to see on a tty.
Cab't check at the moment--I've made me a todo to check if xdisp.c does
this differently on ttys.

Got an idea while eating: Does Emacs get a window system focus event
when we unhide a frame? Or something like it? And do we select the frame
then maybe?

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 >> The modeline of the "Completions* window seems to have the same
 >> background as the modeline of the normal frame's *scratch* window.
 >> Doesn't that hint at redisplay believing that both windows are the
 >> selected one?
 >
 > Probably. They are the (frame-selected-window) of their respective
 > frames. I guess that has previously not been possible to see on a tty.
 > Cab't check at the moment--I've made me a todo to check if xdisp.c does
 > this differently on ttys.

At any time there's only one selected window.  When it changes,
redisplay is told to update all possibly involved frames and update the
background of the mode line of the selected and previously selected
windows appropriately.

 > Got an idea while eating: Does Emacs get a window system focus event
 > when we unhide a frame? Or something like it? And do we select the frame
 > then maybe?

When that frame gets focus by the WM; it depends on the WM's settings.
A frame can get focused by making it, moving the mouse over it,
clicking with the mouse into it, Alt-tabbing to it, or by having an
application ask to give it focus.  I suppose that Emacs has the
invariant that the focused frame is also the selected one even if it is
hidden.  In either case, for a tty we have to do the "focusing"
ourselves.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>>> The modeline of the "Completions* window seems to have the same
>>> background as the modeline of the normal frame's *scratch* window.
>>> Doesn't that hint at redisplay believing that both windows are the
>>> selected one?
>>
>> Probably. They are the (frame-selected-window) of their respective
>> frames. I guess that has previously not been possible to see on a tty.
>> Cab't check at the moment--I've made me a todo to check if xdisp.c does
>> this differently on ttys.
>
> At any time there's only one selected window.  When it changes,
> redisplay is told to update all possibly involved frames and update the
> background of the mode line of the selected and previously selected
> windows appropriately.

I've made me a todo entry for that. One thing after the other :-).

(And for Alacritty users reading this: 0.13.2 (1) KKP support is
currently broken for me on macOS 15.)

>> Got an idea while eating: Does Emacs get a window system focus event
>> when we unhide a frame? Or something like it? And do we select the frame
>> then maybe?
>
> When that frame gets focus by the WM; it depends on the WM's settings.
> A frame can get focused by making it, moving the mouse over it,
> clicking with the mouse into it, Alt-tabbing to it, or by having an
> application ask to give it focus.  I suppose that Emacs has the
> invariant that the focused frame is also the selected one even if it is
> hidden.  In either case, for a tty we have to do the "focusing"
> ourselves.

Yeah, if that's not the current problem, there lie dragons. Shit. Did I
mention that I just wanted Corfu and Posframe?

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>>> The modeline of the "Completions* window seems to have the same
>>>> background as the modeline of the normal frame's *scratch* window.
>>>> Doesn't that hint at redisplay believing that both windows are the
>>>> selected one?
>>>
>>> Probably. They are the (frame-selected-window) of their respective
>>> frames. I guess that has previously not been possible to see on a tty.
>>> Cab't check at the moment--I've made me a todo to check if xdisp.c does
>>> this differently on ttys.
>>
>> At any time there's only one selected window.  When it changes,
>> redisplay is told to update all possibly involved frames and update the
>> background of the mode line of the selected and previously selected
>> windows appropriately.
>
> I've made me a todo entry for that. One thing after the other :-).
>
> (And for Alacritty users reading this: 0.13.2 (1) KKP support is
> currently broken for me on macOS 15.)
>
>>> Got an idea while eating: Does Emacs get a window system focus event
>>> when we unhide a frame? Or something like it? And do we select the frame
>>> then maybe?
>>
>> When that frame gets focus by the WM; it depends on the WM's settings.
>> A frame can get focused by making it, moving the mouse over it,
>> clicking with the mouse into it, Alt-tabbing to it, or by having an
>> application ask to give it focus.  I suppose that Emacs has the
>> invariant that the focused frame is also the selected one even if it is
>> hidden.  In either case, for a tty we have to do the "focusing"
>> ourselves.
>
> Yeah, if that's not the current problem, there lie dragons. Shit. Did I
> mention that I just wanted Corfu and Posframe?

Just FYI. when I manually select-frame-set-input-focus to the posframe,
the display looks okay. The cursor is shown in the posframe and the
parent's mini-window is empty, like in the GUI case.

Downside is that Emacs doesn't accept input anymore, and has to be
killed :-).

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > Just FYI. when I manually select-frame-set-input-focus to the posframe,
 > the display looks okay. The cursor is shown in the posframe and the
 > parent's mini-window is empty, like in the GUI case.

But the pos-frame based functions do call 'select-frame-set-input-focus'
IIUC.  How else would they focus the child frame for user input?

 > Downside is that Emacs doesn't accept input anymore, and has to be
 > killed :-).

That should be real fun to debug.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> Just FYI. when I manually select-frame-set-input-focus to the posframe,
>> the display looks okay. The cursor is shown in the posframe and the
>> parent's mini-window is empty, like in the GUI case.
>
> But the pos-frame based functions do call 'select-frame-set-input-focus'
> IIUC.  How else would they focus the child frame for user input?
>
>> Downside is that Emacs doesn't accept input anymore, and has to be
>> killed :-).
>
> That should be real fun to debug.
>
Yeah :-(.

But I think I understand a little bit better now how that posframe stuff
works. I was always convinced that the posframe had a mini-window
because I had seen before that it displays a minibuffer. But
window-minibuffer-p says no for the single window on the posframe.
Surprise, surprise. There is only one miniwindow, the one of the parent.

What Posframe does instead is adding a frame parameter (minibuffer .
MINI) where MINI is the minibuffer window of the parent. I guess that's
what is not working for ttys. Or something in its vicinity.

Haven't found out yet where and how that is done for GUIs. Something for
another day.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > What Posframe does instead is adding a frame parameter (minibuffer .
 > MINI) where MINI is the minibuffer window of the parent. I guess that's
 > what is not working for ttys. Or something in its vicinity.
 >
 > Haven't found out yet where and how that is done for GUIs. Something for
 > another day.

But can you verify that on a GUI frame the question _is_ asked in the
minibuffer window of the parent frame?  ISTRC that earlier you said that
it asks the question in the child frame.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> What Posframe does instead is adding a frame parameter (minibuffer .
>> MINI) where MINI is the minibuffer window of the parent. I guess that's
>> what is not working for ttys. Or something in its vicinity.
>>
>> Haven't found out yet where and how that is done for GUIs. Something for
>> another day.
>
> But can you verify that on a GUI frame the question _is_ asked in the
> minibuffer window of the parent frame?  ISTRC that earlier you said that
> it asks the question in the child frame.

The prompt appears indeed on the posframe frame on GUI, indeed. The
mini-window of the parent frame remains completely empty.

I can only guess that that is part of how the `minibuffer' frame
parameter is supposed to work, but I really have no ideda. The Elisp
manual simply says

     If the value is a minibuffer window (in some other frame), the
     frame uses that minibuffer.

I wouldn't exclude the possibility that there is more stuff involved.
It's a maze :-).

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > I can only guess that that is part of how the `minibuffer' frame
 > parameter is supposed to work, but I really have no ideda. The Elisp
 > manual simply says
 >
 >       If the value is a minibuffer window (in some other frame), the
 >       frame uses that minibuffer.

If the posframe uses its own minibuffer window as value, then this would
probably work.  store_frame_param would set the parameter value to t in
that case as follows

	  else if (FRAME_HAS_MINIBUF_P (f))
	    {
	      if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
		val = Qt;

You would have to verify via

(frame-parameter posframe 'minibuffer)

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> I can only guess that that is part of how the `minibuffer' frame
>> parameter is supposed to work, but I really have no ideda. The Elisp
>> manual simply says
>>
>>       If the value is a minibuffer window (in some other frame), the
>>       frame uses that minibuffer.
>
> If the posframe uses its own minibuffer window as value, then this would
> probably work.  store_frame_param would set the parameter value to t in
> that case as follows
>
> 	  else if (FRAME_HAS_MINIBUF_P (f))
> 	    {
> 	      if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
> 		val = Qt;
>
> You would have to verify via
>
> (frame-parameter posframe 'minibuffer)

Thanks, that was an interesting hint. I'll try that maybe tomorrow.

I found something interesting too. I forgot to call window-list on the
posframe in a way that it includes mini-windows. When I fix that
I see that the GUI posframe has 1 window, but the tty posframe has 2,
one of which is a mini-window.

Whatever the effect of that is overall, it explains why the posframes
and the Corfu frames are consistently 1 line too tall. Nice!

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> I can only guess that that is part of how the `minibuffer' frame
>>> parameter is supposed to work, but I really have no ideda. The Elisp
>>> manual simply says
>>>
>>>       If the value is a minibuffer window (in some other frame), the
>>>       frame uses that minibuffer.
>>
>> If the posframe uses its own minibuffer window as value, then this would
>> probably work.  store_frame_param would set the parameter value to t in
>> that case as follows
>>
>> 	  else if (FRAME_HAS_MINIBUF_P (f))
>> 	    {
>> 	      if (EQ (val, FRAME_MINIBUF_WINDOW (f)))
>> 		val = Qt;
>>
>> You would have to verify via
>>
>> (frame-parameter posframe 'minibuffer)
>
> Thanks, that was an interesting hint. I'll try that maybe tomorrow.
>
> I found something interesting too. I forgot to call window-list on the
> posframe in a way that it includes mini-windows. When I fix that
> I see that the GUI posframe has 1 window, but the tty posframe has 2,
> one of which is a mini-window.
>
> Whatever the effect of that is overall, it explains why the posframes
> and the Corfu frames are consistently 1 line too tall. Nice!

Well, make-terminal-frame has this:

  /* On terminal frames the `minibuffer' frame parameter is always
     virtually t.  Avoid that a different value in parms causes
     complaints, see Bug#24758.  */
  store_in_alist (&parms, Qminibuffer, Qt);

So, no experiments with the minibuffer frame parameter possible.

I think I have to implement the moral equivalent of x-create-frame's
minibuffer handling first, at least for child frames. I don't think
it makes sense for root frames. Will probably take me a bit, depending
what "virtually t" encompasses.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 >> I thought when the two windows are neighbors (which they often enough
 >> are) we could flip them.
 >
 > Flip windows would work to swap when they are sibling windows, and
 > neigbor windows can sometimes not be siblings.

Right.  I meant siblings (it was the typical two windows frame I had in
mind).

 > I can't comment much cuz I'm not really familiar with these functions,
 > but one thing that pops out is would maintaining a dead windows table
 > take up lot of resources?

No.  It's already here via the variable 'window-dead-windows-table'.

 > Also do you think a function like 'window-rebuild-tree' would be useful,
 > and it accepts the a tree like the output of window-tree-pixel-sizes.
 > rn this is possible by using the following arguments for
 > window--transpose-1:
 > (window--transpose-1 tree-you-want (below . left) t)
 > However this is not really obvious.
 >
 > I think it could be useful to add a wrapper with more obvious name

You would have to tell me in more detail what 'window-rebuild-tree'
would do.  One thing 'window-tree-pixel-sizes' should then possibly do
is to include the identity of internal windows so 'window-rebuild-tree'
could resurrect them as well.

martin
 > Well, make-terminal-frame has this:
 >
 >    /* On terminal frames the `minibuffer' frame parameter is always
 >       virtually t.  Avoid that a different value in parms causes
 >       complaints, see Bug#24758.  */
 >    store_in_alist (&parms, Qminibuffer, Qt);
 >
 > So, no experiments with the minibuffer frame parameter possible.
 >
 > I think I have to implement the moral equivalent of x-create-frame's
 > minibuffer handling first, at least for child frames. I don't think
 > it makes sense for root frames. Will probably take me a bit, depending
 > what "virtually t" encompasses.

You'll just have to fix that for child frames.  I'd do it both ways:

- Normal frames should be allowed to have their minibuffer on one of
   their child frames.

- Child frames should be allowed to have their minibuffer on another
   child frame with the same parent or on any of their ancestors.

You would, however, have to be careful when reparenting/deleting child
frames

- if the child frame uses its normal frame as the one hosting the
   minibuffer window (reparenting only)

- or if the normal frame uses the child frame as the one hosting the
   minibuffer window.

It's up to you whether you want to do it.  But if users should be given
the same look and feel on ttys as they have on GUIs, I see no other way.
If you have any doubts, please ask.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> Well, make-terminal-frame has this:
>>
>>    /* On terminal frames the `minibuffer' frame parameter is always
>>       virtually t.  Avoid that a different value in parms causes
>>       complaints, see Bug#24758.  */
>>    store_in_alist (&parms, Qminibuffer, Qt);
>>
>> So, no experiments with the minibuffer frame parameter possible.
>>
>> I think I have to implement the moral equivalent of x-create-frame's
>> minibuffer handling first, at least for child frames. I don't think
>> it makes sense for root frames. Will probably take me a bit, depending
>> what "virtually t" encompasses.
>
> You'll just have to fix that for child frames.  I'd do it both ways:
>
> - Normal frames should be allowed to have their minibuffer on one of
>   their child frames.

I've seen that as a possible value of the minibuffer frame parameter in
the Elisp manual, but couldn't figure out how that would be used.
Probably I'm missing something. Is the child frame then automatically
shown/hidden? Why would someone want to do that, especially on a tty?

Oh, and then there are minibuffer-only frames, which I'd bet are not
implemented for ttys. 

> - Child frames should be allowed to have their minibuffer on another
>   child frame with the same parent or on any of their ancestors.

And prevent cycles and so on...

I'll have to see how involved that all gets. I'll probably start with
allowing a root frame's mini-window for a child frame, because that's my
immediate use case, and then see how that goes.

> You would, however, have to be careful when reparenting/deleting child
> frames
>
> - if the child frame uses its normal frame as the one hosting the
>   minibuffer window (reparenting only)
>
> - or if the normal frame uses the child frame as the one hosting the
>   minibuffer window.

Yeah, frame deletion in general is another open point on my todo list.
I've also seen frame parameters delete-before/after which I don't know
if I need them. And z-group or what the name was.

> It's up to you whether you want to do it.  But if users should be given
> the same look and feel on ttys as they have on GUIs, I see no other way.
> If you have any doubts, please ask.

Well, another approach might be to let users/developers complain when
they are trying to use or write something that requires these advanced
capabilites, and add that then. That prevents investing time in
something no one uses.

The only packages I have encountered personally using child frames are
Posframe and Corfu. (If someone knows of other packages using child
windows, I'd be interested, BTW.)

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > I've seen that as a possible value of the minibuffer frame parameter in
 > the Elisp manual, but couldn't figure out how that would be used.
 > Probably I'm missing something. Is the child frame then automatically
 > shown/hidden? Why would someone want to do that, especially on a tty?

Users have often asked how to show the minibuffer only when it is really
used in order to save screen estate.  Minibuffer-only top-level frames
are one way to do that but they don't work on ttys.  Child frames could
be used, if implemented accordingly.

 > Oh, and then there are minibuffer-only frames, which I'd bet are not
 > implemented for ttys.

Right.

 >> - Child frames should be allowed to have their minibuffer on another
 >>    child frame with the same parent or on any of their ancestors.
 >
 > And prevent cycles and so on...

The child frame code hopefully does that already.

 > I'll have to see how involved that all gets. I'll probably start with
 > allowing a root frame's mini-window for a child frame, because that's my
 > immediate use case, and then see how that goes.

Agreed.  But you would have to document it.

 > Yeah, frame deletion in general is another open point on my todo list.
 > I've also seen frame parameters delete-before/after which I don't know
 > if I need them.

They are obeyed by 'delete-frame' already.  You don't have to bother.

 > And z-group or what the name was.

You need the z-order when you have two overlapping child frames.  One of
the things the window manager handles on GUIs.

 > Well, another approach might be to let users/developers complain when
 > they are trying to use or write something that requires these advanced
 > capabilites, and add that then. That prevents investing time in
 > something no one uses.

Fully agreed.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> I've seen that as a possible value of the minibuffer frame parameter in
>> the Elisp manual, but couldn't figure out how that would be used.
>> Probably I'm missing something. Is the child frame then automatically
>> shown/hidden? Why would someone want to do that, especially on a tty?
>
> Users have often asked how to show the minibuffer only when it is really
> used in order to save screen estate.  Minibuffer-only top-level frames
> are one way to do that but they don't work on ttys.  Child frames could
> be used, if implemented accordingly.
>
>> Oh, and then there are minibuffer-only frames, which I'd bet are not
>> implemented for ttys.
>
> Right.
>

Hm, I think I'll omit that for now.

>>> - Child frames should be allowed to have their minibuffer on another
>>>    child frame with the same parent or on any of their ancestors.
>>
>> And prevent cycles and so on...
>
> The child frame code hopefully does that already.

Good news!

>> I'll have to see how involved that all gets. I'll probably start with
>> allowing a root frame's mini-window for a child frame, because that's my
>> immediate use case, and then see how that goes.
>
> Agreed.  But you would have to document it.
>
>> Yeah, frame deletion in general is another open point on my todo list.
>> I've also seen frame parameters delete-before/after which I don't know
>> if I need them.
>
> They are obeyed by 'delete-frame' already.  You don't have to bother.

Also good news!

>> And z-group or what the name was.
>
> You need the z-order when you have two overlapping child frames.  One of
> the things the window manager handles on GUIs.

Yes, I needed a z-order pretty much from the start, to be able to
construct the combined root frame + children matrix that is written to
the terminal. Struct frame has a z_order member here which raise-frame
and so on manipulate (by calling a hook), and which redisplay can use to
compute child frames in z-order. No grouping though.

>
>> Well, another approach might be to let users/developers complain when
>> they are trying to use or write something that requires these advanced
>> capabilites, and add that then. That prevents investing time in
>> something no one uses.
>
> Fully agreed.

Thanks! I'll holler when I have something working, or think I have.

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Thanks! I'll holler when I have something working, or think I have.

So, I have the 'minibuffer' frame parameter, but I'm ignoring
(minibuffer-only) for now. And voila, the posframes have to right
height, unsurprisingly.

Secondly, you might remember that I said that I expected a cursor to be
displayed in the posframe because that's what I see in the GUI. I rest
my case. I should have checked Vertico without Posframe on a tty.
Because it's doing the exact same thing then: completions appear in a
normal window on the parent frame, and the cursor is in the frame's
mini-window. Would be nice if it showed a cursor, if that's possible,
but anyhow, at least it is consistent.

Two todo items "fixed" :-).

Re: Question about minibuffer and child frames (Posframe)

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Date: Wed, 02 Oct 2024 19:17:33 +0200
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> > The modeline of the "Completions* window seems to have the same
> > background as the modeline of the normal frame's *scratch* window.
> > Doesn't that hint at redisplay believing that both windows are the
> > selected one?
> 
> Probably. They are the (frame-selected-window) of their respective
> frames. I guess that has previously not been possible to see on a tty.
> Cab't check at the moment--I've made me a todo to check if xdisp.c does
> this differently on ttys.

I think the starting point is the macro
CURRENT_MODE_LINE_ACTIVE_FACE_ID_3, which is used to determine which
face to use for the mode line of a window.

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> Date: Wed, 02 Oct 2024 19:17:33 +0200
>> 
>> martin rudalics <rudalics@gmx.at> writes:
>> 
>> > The modeline of the "Completions* window seems to have the same
>> > background as the modeline of the normal frame's *scratch* window.
>> > Doesn't that hint at redisplay believing that both windows are the
>> > selected one?
>> 
>> Probably. They are the (frame-selected-window) of their respective
>> frames. I guess that has previously not been possible to see on a tty.
>> Cab't check at the moment--I've made me a todo to check if xdisp.c does
>> this differently on ttys.
>
> I think the starting point is the macro
> CURRENT_MODE_LINE_ACTIVE_FACE_ID_3, which is used to determine which
> face to use for the mode line of a window.

Thanks! 

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

Wow, this is a good feature.

posframe do not handle focus in most situation, for it is too complicate
to let focus work. posframe just *show* the content of a buffer.

When enable vertico-posframe, we just let the content of minibuffer is
showed in a posframe, but input handle is in parent frame, we lock the
height of parent minibuffer window and vscroll minibuffer window to hide
minibuffer content in below function.


(defun vertico-posframe--handle-minibuffer-window ()
  "Handle minibuffer window."
  (let ((show-minibuffer-p (vertico-posframe--show-minibuffer-p))
        (minibuffer-window (active-minibuffer-window)))
    (setq-local max-mini-window-height 1)
    (window-resize minibuffer-window
                   (- (window-pixel-height minibuffer-window))
                   nil nil 'pixelwise)
    (set-window-vscroll minibuffer-window 100)
    (when show-minibuffer-p
      (set-window-vscroll minibuffer-window 0))))


>
> On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
> minibuffer at the top. The cursor is in that minibuffer. The minibuffer

the minibuffer showed in posframe is not real minibuffer :-) 

> ih the parent frame looks inactive. There is no prompt or anything else.
> That's how it should be.

No, it's content is hide, but it active.

>
> With my new code on tty, the same child frame pops up, but this time the
> child frame's minibuffer contains a prompt and what I type is displayed
> there and so on, but it doesn't have a visible cursor. The parent


in posframe, cursor just a space with face of cursor.

> frame's minibuffer this time contains the prompt and the cursor, too.

Maybe the below hack is not work well in tty

   (set-window-vscroll minibuffer-window 100)



In my opinion, hide minibuffer's content just hack way, I can not find a
better way to hide minibuffer window's content.







>
> Any idea what that could be?

-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
> Wow, this is a good feature.

Thanks :-).

And BTW, thanks for Posframe! As you can see I value it enough to go to
great lengths to get it :-).

>
> posframe do not handle focus in most situation, for it is too complicate
> to let focus work. posframe just *show* the content of a buffer.
>
> When enable vertico-posframe, we just let the content of minibuffer is
> showed in a posframe, but input handle is in parent frame, we lock the
> height of parent minibuffer window and vscroll minibuffer window to hide
> minibuffer content in below function.
>
>
> (defun vertico-posframe--handle-minibuffer-window ()
>   "Handle minibuffer window."
>   (let ((show-minibuffer-p (vertico-posframe--show-minibuffer-p))
>         (minibuffer-window (active-minibuffer-window)))
>     (setq-local max-mini-window-height 1)
>     (window-resize minibuffer-window
>                    (- (window-pixel-height minibuffer-window))
>                    nil nil 'pixelwise)
>     (set-window-vscroll minibuffer-window 100)
>     (when show-minibuffer-p
>       (set-window-vscroll minibuffer-window 0))))

Very interesting, I hadn't noticed that at all! That explains why the
minibuffer appears empty on GUI frames because set-window-vscroll has no
effect on ttys. When I added the vscroll, I thought it wouldn't be
needed on terminals because there are no partially visible lines or
images or anything like that. And adding it would be quite difficult I
think, so it's not an option.

>> On GUI, consult-buffer pops up a child frame, which has, AFAICT, a
>> minibuffer at the top. The cursor is in that minibuffer. The minibuffer
>
> the minibuffer showed in posframe is not real minibuffer :-)

Yeah, that was quite confusing for w while :-).

>> ih the parent frame looks inactive. There is no prompt or anything else.
>> That's how it should be.
>
> No, it's content is hide, but it active.

Got it. By setting vscroll.

>> With my new code on tty, the same child frame pops up, but this time the
>> child frame's minibuffer contains a prompt and what I type is displayed
>> there and so on, but it doesn't have a visible cursor. The parent
>
>
> in posframe, cursor just a space with face of cursor.

So Po Lu was remembering right!

Do you perhaps know where that is done? I can't find it.

Because it's definitely not working on ttys ATM. I mean the cursor in
the parent frame's minibuffer doesn't bother me too much. But I would
love it if something like a cursor appeared on the posframe.

>> frame's minibuffer this time contains the prompt and the cursor, too.
>
> Maybe the below hack is not work well in tty
>
>    (set-window-vscroll minibuffer-window 100)

Yes, that's it. It's a no-op on terminals. 

> In my opinion, hide minibuffer's content just hack way, I can not find a
> better way to hide minibuffer window's content.

Well, nobody could forsee that there would ever be child frames on tty
;-). 

P.S.:

As an aside, because that might affect Posframe maybe in the future. I
also implemented borders around child frames now, but in a strange way,
with the 'undecorated' frame parameter. If a tty child frame is not
undecorated, a border is drawn around it, otherwise it isn't.

The reason for this strange way of doing things is that I quit in a rage
when trying to add the normal border handling for tty frames. Works for
me. Just mentioning it so that others can comment how terrible that is :-).

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> in posframe, cursor just a space with face of cursor.
>
> So Po Lu was remembering right!
>
> Do you perhaps know where that is done? I can't find it.
>
> Because it's definitely not working on ttys ATM. I mean the cursor in
> the parent frame's minibuffer doesn't bother me too much. But I would
> love it if something like a cursor appeared on the posframe.

Sorry, I remeber wrong, in vertico-posframe, we use real cursor, see
cursor-type in below function.

(defun vertico-posframe--show (buffer window-point)
  "`posframe-show' of vertico-posframe.

BUFFER will be showed by `posframe-show'.  After `posframe-show'
is called, window-point will be set to WINDOW-POINT."
  (let ((posframe
         ;; Some posframe poshandlers need infos of last-window.
         (with-selected-window (vertico-posframe-last-window)
           (apply #'posframe-show
                  buffer

                  ...

                  (funcall (buffer-local-value 'vertico-posframe-size-function buffer) buffer)))))
    ;; NOTE: `posframe-show' will force set window-point to 0, so we
    ;; need reset it again after `posframe-show'.
    (when (numberp window-point)
      (let ((window (frame-root-window posframe)))
        (when (window-live-p window)
          (set-window-point window window-point))))
    ;; NOTE: posframe will hide cursor, so we need let it show again.
    (with-current-buffer buffer
      (setq-local cursor-type t)
      (setq-local cursor-in-non-selected-windows 'box))))


But in ivy-posframe, we use space emular cursor instead:

(defun ivy-posframe--add-prompt (fn &rest args)
  "Add the ivy prompt to the posframe.  Advice FN with ARGS."
  (apply fn args)
  (when (and (display-graphic-p)
             (not ivy-posframe--ignore-prompt))
    (with-current-buffer (window-buffer (active-minibuffer-window))
      (let ((point (point))
            (prompt (buffer-string)))
        (remove-text-properties 0 (length prompt) '(read-only nil) prompt)
        (with-current-buffer ivy-posframe-buffer
          (goto-char (point-min))
          (delete-region (point) (line-beginning-position 2))
          (insert prompt "  \n")
          (add-text-properties point (1+ point) '(face ivy-posframe-cursor))))))


>
>>> frame's minibuffer this time contains the prompt and the cursor, too.
>>
>> Maybe the below hack is not work well in tty
>>
>>    (set-window-vscroll minibuffer-window 100)
>
> Yes, that's it. It's a no-op on terminals. 
>
>> In my opinion, hide minibuffer's content just hack way, I can not find a
>> better way to hide minibuffer window's content.
>
> Well, nobody could forsee that there would ever be child frames on tty
> ;-). 

Yes, I have tried many way to hide minibuffer's content, for example:
creating a new posframe to mask minibuffer window, let minibuffer
forecolor = backgroundcolor, but vscroll way is most stable, vertico's
author tell me this way:


>
> P.S.:
>
> As an aside, because that might affect Posframe maybe in the future. I
> also implemented borders around child frames now, but in a strange way,
> with the 'undecorated' frame parameter. If a tty child frame is not
> undecorated, a border is drawn around it, otherwise it isn't.
>
> The reason for this strange way of doing things is that I quit in a rage
> when trying to add the normal border handling for tty frames. Works for
> me. Just mentioning it so that others can comment how terrible that is
> :-).

OK, border setting in posframe is not simple, by the way, how to handle
border width in tty?

------------------------------------------------------------------

By default, posframe shows no borders, but users can specify
borders by setting BORDER-WIDTH to a positive number.  Border
color can be specified by BORDER-COLOR.

INTERNAL-BORDER-WIDTH and INTERNAL-BORDER-COLOR are same as
BORDER-WIDTH and BORDER-COLOR, but do not suggest to use for the
reason:

   Add distinct controls for child frames' borders (Bug#45620)
   http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ff7b1a133bfa7f2614650f8551824ffaef13fadc






-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>>> in posframe, cursor just a space with face of cursor.
>>
>> So Po Lu was remembering right!
>>
>> Do you perhaps know where that is done? I can't find it.
>>
>> Because it's definitely not working on ttys ATM. I mean the cursor in
>> the parent frame's minibuffer doesn't bother me too much. But I would
>> love it if something like a cursor appeared on the posframe.
>
> Sorry, I remeber wrong, in vertico-posframe, we use real cursor, see
> cursor-type in below function.
>
> (defun vertico-posframe--show (buffer window-point)
>   "`posframe-show' of vertico-posframe.
>
> BUFFER will be showed by `posframe-show'.  After `posframe-show'
> is called, window-point will be set to WINDOW-POINT."
>   (let ((posframe
>          ;; Some posframe poshandlers need infos of last-window.
>          (with-selected-window (vertico-posframe-last-window)
>            (apply #'posframe-show
>                   buffer
>
>                   ...
>
>                   (funcall (buffer-local-value 'vertico-posframe-size-function buffer) buffer)))))
>     ;; NOTE: `posframe-show' will force set window-point to 0, so we
>     ;; need reset it again after `posframe-show'.
>     (when (numberp window-point)
>       (let ((window (frame-root-window posframe)))
>         (when (window-live-p window)
>           (set-window-point window window-point))))
>     ;; NOTE: posframe will hide cursor, so we need let it show again.
>     (with-current-buffer buffer
>       (setq-local cursor-type t)
>       (setq-local cursor-in-non-selected-windows 'box))))

Ahhhh, thanks! That explains it, because on ttys we have only one
cursor, the one of the terminal, and cursor-type is not implemented in
any way.

> But in ivy-posframe, we use space emular cursor instead:
>
> (defun ivy-posframe--add-prompt (fn &rest args)
>   "Add the ivy prompt to the posframe.  Advice FN with ARGS."
>   (apply fn args)
>   (when (and (display-graphic-p)
>              (not ivy-posframe--ignore-prompt))
>     (with-current-buffer (window-buffer (active-minibuffer-window))
>       (let ((point (point))
>             (prompt (buffer-string)))
>         (remove-text-properties 0 (length prompt) '(read-only nil) prompt)
>         (with-current-buffer ivy-posframe-buffer
>           (goto-char (point-min))
>           (delete-region (point) (line-beginning-position 2))
>           (insert prompt "  \n")
>           (add-text-properties point (1+ point) '(face ivy-posframe-cursor))))))

Nice! I haven't tried it, but that should probably work fine on ttys. I
guess Vertico-posframe could do something similar.

I think I'll leave that alone for now, since the same problem occurs in
Vertico without Posframe.

>
>>
>>>> frame's minibuffer this time contains the prompt and the cursor, too.
>>>
>>> Maybe the below hack is not work well in tty
>>>
>>>    (set-window-vscroll minibuffer-window 100)
>>
>> Yes, that's it. It's a no-op on terminals. 
>>
>>> In my opinion, hide minibuffer's content just hack way, I can not find a
>>> better way to hide minibuffer window's content.
>>
>> Well, nobody could forsee that there would ever be child frames on tty
>> ;-). 
>
> Yes, I have tried many way to hide minibuffer's content, for example:
> creating a new posframe to mask minibuffer window, let minibuffer
> forecolor = backgroundcolor, but vscroll way is most stable, vertico's
> author tell me this way:

Yes, it's good. Nothing to say against it.

>> P.S.:
>>
>> As an aside, because that might affect Posframe maybe in the future. I
>> also implemented borders around child frames now, but in a strange way,
>> with the 'undecorated' frame parameter. If a tty child frame is not
>> undecorated, a border is drawn around it, otherwise it isn't.
>>
>> The reason for this strange way of doing things is that I quit in a rage
>> when trying to add the normal border handling for tty frames. Works for
>> me. Just mentioning it so that others can comment how terrible that is
>> :-).
>
> OK, border setting in posframe is not simple, by the way, how to handle
> border width in tty?

The corresponding frame parameters are completely ignored on ttys with
what I have. They always were ignored because they made no sense on
ttys. When I tried to add them for child frames, which I think would
admittedly be the right thing, I finally gave up after 2 hours.
Everything stopped working or crashed. Don't know if I pick that up
again. It cost me anough nerves that I finally git reset --hard :-/.

> ------------------------------------------------------------------
>
> By default, posframe shows no borders, but users can specify
> borders by setting BORDER-WIDTH to a positive number.  Border
> color can be specified by BORDER-COLOR.
>
> INTERNAL-BORDER-WIDTH and INTERNAL-BORDER-COLOR are same as
> BORDER-WIDTH and BORDER-COLOR, but do not suggest to use for the
> reason:
>
>    Add distinct controls for child frames' borders (Bug#45620)
>    http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ff7b1a133bfa7f2614650f8551824ffaef13fadc

My workaround for now (which I added because I wanted borders :-)) is
that redisplay adds borders to child frames, unless (undecored . nil) is
specified. It's basically acting like a window manager on X that adds
decorations. No changes to frame positions or size are necessary for a
user, everything works as befoer, except that one needs the frame
parameter.

The color of the border can be specified with the 'border' face. Haven't
checked yet if the border-color frame param works, but I believe it
does. Border widths can't be changed, they are always 1. The glyphs
displayed can be changed with display-table entries like so:

    (when (and (featurep 'tty-child-frames)
	       (get 'box-vertical 'display-table-slot))
      (set-display-table-slot standard-display-table
			      'box-vertical (make-glyph-code #x2502))
      (set-display-table-slot standard-display-table
			      'box-horizontal (make-glyph-code #x2500))
      (set-display-table-slot standard-display-table
			      'box-down-right (make-glyph-code #x250c))
      (set-display-table-slot standard-display-table
			      'box-down-left (make-glyph-code #x2510))
      (set-display-table-slot standard-display-table
			      'box-up-right (make-glyph-code #x2514))
      (set-display-table-slot standard-display-table
			      'box-up-left (make-glyph-code #x2518))))

That's make it use Unicode box-drawing chars instead of +-|. Maybe
Unicode should be the default... Don't know.

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

> Nice! I haven't tried it, but that should probably work fine on ttys. I
> guess Vertico-posframe could do something similar.

I don't know, ivy-posframe and vertico-posframe work different a bit, so
we should to test.


by the way, I have tested with the below line

 (posframe-show " abc" :string "a" :background-color "red")

posframe will show 3 lines instead of 1 line,

but the below code work well.

(posframe-show " abc" :string "a                                                                                                       
b                                                                                                                                      
c                                                                                                                                      
d" :background-color "red")


so does chile frame's height in tty must >= 3 line?



-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

>> Nice! I haven't tried it, but that should probably work fine on ttys. I
>> guess Vertico-posframe could do something similar.
>
> I don't know, ivy-posframe and vertico-posframe work different a bit, so
> we should to test.
>
>
> by the way, I have tested with the below line
>
>  (posframe-show " abc" :string "a" :background-color "red")
>
> posframe will show 3 lines instead of 1 line,
>
> but the below code work well.
>
> (posframe-show " abc" :string "a
> b
> c
> d" :background-color "red")
>
>
> so does chile frame's height in tty must >= 3 line?

I think the wrong height was because I believed the posframe showed a
mini-window only, while it actually had a normal window showing a
minibuffer plus a mini-window.

That should be fixed on github.

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Feng Shu <tumashu@163.com> writes:
>
>>> Nice! I haven't tried it, but that should probably work fine on
>>> ttys. I
>>> guess Vertico-posframe could do something similar.
>>
>> I don't know, ivy-posframe and vertico-posframe work different a
>> bit, so
>> we should to test.
>>
>>
>> by the way, I have tested with the below line
>>
>>  (posframe-show " abc" :string "a" :background-color "red")
>>
>> posframe will show 3 lines instead of 1 line,
>>
>> but the below code work well.
>>
>> (posframe-show " abc" :string "a
>> b
>> c
>> d" :background-color "red")
>>
>>
>> so does chile frame's height in tty must >= 3 line?
>
> I think the wrong height was because I believed the posframe showed a
> mini-window only, while it actually had a normal window showing a
> minibuffer plus a mini-window.
>
> That should be fixed on github.

I have tested your branch in github, seem to not fixed.



[-- Attachment #2: 2024-10-07_18-02.png --]
[-- Type: image/png, Size: 15458 bytes --]

[-- Attachment #3: Type: text/plain, Size: 7 bytes --]




-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

>>> by the way, I have tested with the below line
>>>
>>>  (posframe-show " abc" :string "a" :background-color "red")
>>>
>>
>> I think the wrong height was because I believed the posframe showed a
>> mini-window only, while it actually had a normal window showing a
>> minibuffer plus a mini-window.
>>
>> That should be fixed on github.
>
> I have tested your branch in github, seem to not fixed.

In that case it looks indeed as if there is some minimum height/width
requirement, although I can't it see in the code right now. I've made me
a todo item for this. Thanks!

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > In that case it looks indeed as if there is some minimum height/width
 > requirement, although I can't it see in the code right now. I've made me
 > a todo item for this. Thanks!

The minimum height of the minibuffer window is one frame line with
IGNORE t in

(window-min-size (minibuffer-window) nil t)

and (due to a bug, see Bug#73022) 'window-min-height' with IGNORE nil.

You have to make a minibuffer-less child frame to get less.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> In that case it looks indeed as if there is some minimum height/width
>> requirement, although I can't it see in the code right now. I've made me
>> a todo item for this. Thanks!
>
> The minimum height of the minibuffer window is one frame line with
> IGNORE t in
>
> (window-min-size (minibuffer-window) nil t)
>
> and (due to a bug, see Bug#73022) 'window-min-height' with IGNORE nil.
>
> You have to make a minibuffer-less child frame to get less.
>
> martin

Feng Shu made a posframe in his example with posframe-show which
presumably has no minibuffer. At least that was the fix for my Corfu and
Posframes being 1 line too large. This seems to be something ddifferent.

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> In that case it looks indeed as if there is some minimum height/width
>>> requirement, although I can't it see in the code right now. I've made me
>>> a todo item for this. Thanks!
>>
>> The minimum height of the minibuffer window is one frame line with
>> IGNORE t in
>>
>> (window-min-size (minibuffer-window) nil t)
>>
>> and (due to a bug, see Bug#73022) 'window-min-height' with IGNORE nil.
>>
>> You have to make a minibuffer-less child frame to get less.
>>
>> martin
>
> Feng Shu made a posframe in his example with posframe-show which
> presumably has no minibuffer. At least that was the fix for my Corfu and
> Posframes being 1 line too large. This seems to be something ddifferent.

if string >= 3 lines, posframe-show works well too, have problem when <
3 line.


-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>
>>>> In that case it looks indeed as if there is some minimum height/width
>>>> requirement, although I can't it see in the code right now. I've made me
>>>> a todo item for this. Thanks!
>>>
>>> The minimum height of the minibuffer window is one frame line with
>>> IGNORE t in
>>>
>>> (window-min-size (minibuffer-window) nil t)
>>>
>>> and (due to a bug, see Bug#73022) 'window-min-height' with IGNORE nil.
>>>
>>> You have to make a minibuffer-less child frame to get less.
>>>
>>> martin
>>
>> Feng Shu made a posframe in his example with posframe-show which
>> presumably has no minibuffer. At least that was the fix for my Corfu and
>> Posframes being 1 line too large. This seems to be something ddifferent.
>
> if string >= 3 lines, posframe-show works well too, have problem when <
> 3 line.

Could be this in frame_windows_min_size:

  /* Don't allow too small height of text-mode frames, or else cm.c
     might abort in cmcheckmagic.  */
  if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)) && NILP (horizontal))
    {
      int min_height = (FRAME_MENU_BAR_LINES (f)
			+ FRAME_TAB_BAR_LINES (f)
			+ FRAME_WANTS_MODELINE_P (f)
			+ 2);	/* one text line and one echo-area line */

--------------------------^^^

      if (retval < min_height)
	retval = min_height;
    }

Must find out something else firwt though. With master pulled today
C-x o errors with "no next window". But of course not with -q and not
right from the beginning but caused by something unknown 👀.

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Could be this in frame_windows_min_size:
>
>   /* Don't allow too small height of text-mode frames, or else cm.c
>      might abort in cmcheckmagic.  */
>   if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)) && NILP (horizontal))
>     {
>       int min_height = (FRAME_MENU_BAR_LINES (f)
> 			+ FRAME_TAB_BAR_LINES (f)
> 			+ FRAME_WANTS_MODELINE_P (f)
> 			+ 2);	/* one text line and one echo-area line */
>
> --------------------------^^^
>
>       if (retval < min_height)
> 	retval = min_height;
>     }

I've pushed a fix that takes into account that frames without
mini-windows now exist on ttys. Works for me with your example. Could
you please confirm, Feng Shu?

> Must find out something else firwt though. With master pulled today
> C-x o errors with "no next window". But of course not with -q and not
> right from the beginning but caused by something unknown 👀.

FWIW workaround: Use windmove with windmove-allow-all-windows set to t
:-/. Hope someone fixes that soon.

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Could be this in frame_windows_min_size:
>>
>>   /* Don't allow too small height of text-mode frames, or else cm.c
>>      might abort in cmcheckmagic.  */
>>   if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)) && NILP (horizontal))
>>     {
>>       int min_height = (FRAME_MENU_BAR_LINES (f)
>> 			+ FRAME_TAB_BAR_LINES (f)
>> 			+ FRAME_WANTS_MODELINE_P (f)
>> 			+ 2);	/* one text line and one echo-area line */
>>
>> --------------------------^^^
>>
>>       if (retval < min_height)
>> 	retval = min_height;
>>     }
>
> I've pushed a fix that takes into account that frames without
> mini-windows now exist on ttys. Works for me with your example. Could
> you please confirm, Feng Shu?

Tested, works well now!


>
>> Must find out something else firwt though. With master pulled today
>> C-x o errors with "no next window". But of course not with -q and not
>> right from the beginning but caused by something unknown 👀.
>
> FWIW workaround: Use windmove with windmove-allow-all-windows set to t
> :-/. Hope someone fixes that soon.

-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Could be this in frame_windows_min_size:
>>>
>>>   /* Don't allow too small height of text-mode frames, or else cm.c
>>>      might abort in cmcheckmagic.  */
>>>   if ((FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)) && NILP (horizontal))
>>>     {
>>>       int min_height = (FRAME_MENU_BAR_LINES (f)
>>> 			+ FRAME_TAB_BAR_LINES (f)
>>> 			+ FRAME_WANTS_MODELINE_P (f)
>>> 			+ 2);	/* one text line and one echo-area line */
>>>
>>> --------------------------^^^
>>>
>>>       if (retval < min_height)
>>> 	retval = min_height;
>>>     }
>>
>> I've pushed a fix that takes into account that frames without
>> mini-windows now exist on ttys. Works for me with your example. Could
>> you please confirm, Feng Shu?
>
> Tested, works well now!

Thanks! 👍

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> Must find out something else firwt though. With master pulled today
>> C-x o errors with "no next window". But of course not with -q and not
>> right from the beginning but caused by something unknown 👀.
>
> FWIW workaround: Use windmove with windmove-allow-all-windows set to t
> :-/. Hope someone fixes that soon.

I think I found it: it's transient-posframe.

When transient-posframe falls back to using a window instead of a frame
because Posframe is not workable, it uses an existing Emacs window, the
selected window:

  (defun transient-posframe--show-buffer (buffer _alist)
    "Show BUFFER in posframe and we do not use _ALIST at this period."
    (when (posframe-workable-p)
      (let* ((posframe
              (posframe-show buffer ...
        (frame-selected-window posframe))))
--------^

Transient puts a `no-other-window' window property on the window it is
using, and that property is not removed, and stays on that window after
the Transient is done.

So don't use transient-posframe-mode on terminals unless your Emacs
has child frames on ttys. Which is probably the reason I've not noticed
beforem because I'n using my tty-child-franes for a while now.

Yanghao Xie, the author of transient-posframe, is in CC. Maybe he's
interested because it can take a while until tty child frames land.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > My workaround for now (which I added because I wanted borders :-)) is
 > that redisplay adds borders to child frames, unless (undecored . nil) is
 > specified. It's basically acting like a window manager on X that adds
 > decorations. No changes to frame positions or size are necessary for a
 > user, everything works as befoer, except that one needs the frame
 > parameter.

Are the two lines and columns need for the borders payed for by the
child frame or its parent?

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>> My workaround for now (which I added because I wanted borders :-)) is
>> that redisplay adds borders to child frames, unless (undecored . nil) is
>> specified. It's basically acting like a window manager on X that adds
>> decorations. No changes to frame positions or size are necessary for a
>> user, everything works as befoer, except that one needs the frame
>> parameter.
>
> Are the two lines and columns need for the borders payed for by the
> child frame or its parent?

The child frame is unaffected. It doesn't "know" if redisplay puts a
border around it, and there is no way for it to know. So it's much like
with a window manager on X, more or less.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 >> Are the two lines and columns need for the borders payed for by the
 >> child frame or its parent?
 >
 > The child frame is unaffected. It doesn't "know" if redisplay puts a
 > border around it, and there is no way for it to know. So it's much like
 > with a window manager on X, more or less.

So the parent pays?  If so, please say that somewhere because it will
affect the position of the child frame within the parent.  On a GUI the
position is the one specified by the user and the child frame pays for
the border (is "affected").

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>>> Are the two lines and columns need for the borders payed for by the
>>> child frame or its parent?
>>
>> The child frame is unaffected. It doesn't "know" if redisplay puts a
>> border around it, and there is no way for it to know. So it's much like
>> with a window manager on X, more or less.
>
> So the parent pays?  If so, please say that somewhere because it will
> affect the position of the child frame within the parent.  On a GUI the
> position is the one specified by the user and the child frame pays for
> the border (is "affected").

I don't know what you mean by "parent pays".

Anyway, it's true that you want a +1 x and y with a border on ttys as it
stands because otherwise the border could hide something. BTW, that
works nicely at least for what I'm using (Corfu, Vertico-Posframe,
Transient-Posframe).

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>>> Are the two lines and columns need for the borders payed for by the
>>>> child frame or its parent?
>>>
>>> The child frame is unaffected. It doesn't "know" if redisplay puts a
>>> border around it, and there is no way for it to know. So it's much like
>>> with a window manager on X, more or less.
>>
>> So the parent pays?  If so, please say that somewhere because it will
>> affect the position of the child frame within the parent.  On a GUI the
>> position is the one specified by the user and the child frame pays for
>> the border (is "affected").
>
> I don't know what you mean by "parent pays".
>
> Anyway, it's true that you want a +1 x and y with a border on ttys as it
> stands because otherwise the border could hide something. BTW, that
> works nicely at least for what I'm using (Corfu, Vertico-Posframe,
> Transient-Posframe).

yes, it will hide something, for company-posframe, it maybe have
problem, by the way, ascii border looks not beautiful :-)



[-- Attachment #2: 2024-10-07_18-03.png --]
[-- Type: image/png, Size: 16405 bytes --]

[-- Attachment #3: Type: text/plain, Size: 7 bytes --]




-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> yes, it will hide something, for company-posframe, it maybe have
> problem, 

Too bad. Let's see if I can bring myself to make a second attempt to
support border-width and so on. Not soon though, that's for sure.

> by the way, ascii border looks not beautiful :-)

I know, I know :-). What I don't know is if we can safely rely on all
terminals to support Unicode.

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Feng Shu <tumashu@163.com> writes:
>
>> yes, it will hide something, for company-posframe, it maybe have
>> problem, 
>
> Too bad. Let's see if I can bring myself to make a second attempt to
> support border-width and so on. Not soon though, that's for sure.

Not too bad: company and other complete package may draw pop-menu with
background color, so they may do not use border in generally :-)

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Feng Shu <tumashu@163.com> writes:
>>
>>> yes, it will hide something, for company-posframe, it maybe have
>>> problem, 
>>
>> Too bad. Let's see if I can bring myself to make a second attempt to
>> support border-width and so on. Not soon though, that's for sure.
>
> Not too bad: company and other complete package may draw pop-menu with
> background color, so they may do not use border in generally :-)

Yeah, if they don't use borders, like Corfu, everything is probably fine.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 >> So the parent pays?  If so, please say that somewhere because it will
 >> affect the position of the child frame within the parent.  On a GUI the
 >> position is the one specified by the user and the child frame pays for
 >> the border (is "affected").
 >
 > I don't know what you mean by "parent pays".

Whenever you show a border, it will obscure the part of the display that
would be otherwise shown instead.  So someone has to pay for that border
in terms of screen estate that is lost to that border.  For normal GUI
frames it usually doesn't matter - borders are narrow and the loser is
the desktop background.  Maximized and full screen frames usually don't
have a border, so there's no problem at all (IIRC maximized MS Windows
frames did have a border but it was drawn outside the screen).

So basically, these border spaces are payed for by the desktop and
possible other applications when frames overlap.  Some window managers
even make an invisible border around a frame which can be felt when a
user tries in vain to move a window to a position of (0, 0) on the
screen.

With Emacs the situation becomes more complicated because there are up
to three border types: One drawn by the window manager and our own ones
- the one specified by the border_width slot which is hardly ever seen
and the one specified by the internal_border_width slot (the
child_frame_border_width slot for child frames).

Now when you show a child frame on top of a normal frame you have two
ways to draw the internal borders:

(1) Keep the bounding rectangle of the child frame as specified.  In
     this case the child frame pays for the borders since it will have
     less space for showing its text.

(2) Enlarge the bounding rectangle of the child frame.  In this case the
     parent frame pays for the borders since it will have less space for
     showing its text.

On TTY frames drawing borders that are one character wide and high
inflicts the additional problem that in case (1) the size specified by
the application (maybe via 'fit-frame-to-buffer') is not met by what the
user sees.  In case (2) the position specified by the application may
not be met - the left edge of the child frame may overlap an interesting
part of the parent frame.

In addition, (2) may not be entirely easy to realize when the child
frame is positioned at an edge of the parent frame.

martin

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

martin rudalics <rudalics@gmx.at> writes:

>>> So the parent pays?  If so, please say that somewhere because it will
>>> affect the position of the child frame within the parent.  On a GUI the
>>> position is the one specified by the user and the child frame pays for
>>> the border (is "affected").
>>
>> I don't know what you mean by "parent pays".
>
> Whenever you show a border, it will obscure the part of the display that
> would be otherwise shown instead.  So someone has to pay for that border
> in terms of screen estate that is lost to that border.

Thanks, that makes it clear what you mean with paying. Sorry, I wasn't
sure. 

> For normal GUI frames it usually doesn't matter - borders are narrow
> and the loser is the desktop background. Maximized and full screen
> frames usually don't have a border, so there's no problem at all (IIRC
> maximized MS Windows frames did have a border but it was drawn outside
> the screen).
>
> So basically, these border spaces are payed for by the desktop and
> possible other applications when frames overlap.  Some window managers
> even make an invisible border around a frame which can be felt when a
> user tries in vain to move a window to a position of (0, 0) on the
> screen.
>
> With Emacs the situation becomes more complicated because there are up
> to three border types: One drawn by the window manager and our own ones
> - the one specified by the border_width slot which is hardly ever seen
> and the one specified by the internal_border_width slot (the
> child_frame_border_width slot for child frames).
>
> Now when you show a child frame on top of a normal frame you have two
> ways to draw the internal borders:
>
> (1) Keep the bounding rectangle of the child frame as specified.  In
>     this case the child frame pays for the borders since it will have
>     less space for showing its text.
>
> (2) Enlarge the bounding rectangle of the child frame.  In this case the
>     parent frame pays for the borders since it will have less space for
>     showing its text.
>
> On TTY frames drawing borders that are one character wide and high
> inflicts the additional problem that in case (1) the size specified by
> the application (maybe via 'fit-frame-to-buffer') is not met by what the
> user sees.  

Yes, that was why I excluded that possibility in my attempt with
border-width and so on, and chose (2) only that I failed to get that
working in the "normal" way (FRAME_BORDER_WIDTH etc.).

> In case (2) the position specified by the application may not be met -
> the left edge of the child frame may overlap an interesting part of
> the parent frame.
>
> In addition, (2) may not be entirely easy to realize when the child
> frame is positioned at an edge of the parent frame.

What I do now, the WM-like approach if you will, is to draw the border
with clipping. Parts of the borders that are outside of the terminal are
not drawn, likewise for the child frames themselves. I don't clip
grandchildren to their parents though. For exmaple a Corfu candidates
window, or a Transient posframe or something like that.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > INTERNAL-BORDER-WIDTH and INTERNAL-BORDER-COLOR are same as
 > BORDER-WIDTH and BORDER-COLOR, but do not suggest to use for the
 > reason:
 >
 >     Add distinct controls for child frames' borders (Bug#45620)
 >     http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ff7b1a133bfa7f2614650f8551824ffaef13fadc

Do you mean separate child frame borders don't work?

martin

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

martin rudalics <rudalics@gmx.at> writes:

>> INTERNAL-BORDER-WIDTH and INTERNAL-BORDER-COLOR are same as
>> BORDER-WIDTH and BORDER-COLOR, but do not suggest to use for the
>> reason:
>>
>>     Add distinct controls for child frames' borders (Bug#45620)
>>     http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ff7b1a133bfa7f2614650f8551824ffaef13fadc
>
> Do you mean separate child frame borders don't work?

No, before child frame have it own border, posframe use internal-border,
so we have both just for back compatibility.


>
> martin
>

-- 

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> As an aside, because that might affect Posframe maybe in the future. I
> also implemented borders around child frames now, but in a strange way,
> with the 'undecorated' frame parameter. If a tty child frame is not
> undecorated, a border is drawn around it, otherwise it isn't.


I have tested (undecorated . nil) in emacs, but show segmentation fault.


feng@Guix ~/projects/emacs$ EMACSLOADPATH=/home/feng/projects/emacs/lisp:$EMACSLOADPATH ./src/emacs -nw
Fatal error 11: Segmentation fault
Backtrace:
./src/emacs[0x5607db]
./src/emacs[0x4223ea]
./src/emacs[0x4228d4]
./src/emacs[0x55ee08]
./src/emacs[0x55ee79]
/gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/libc.so.6(+0x3e560)[0x7f046411a560]
./src/emacs[0x433445]
./src/emacs[0x433719]
./src/emacs[0x47adc5]
./src/emacs[0x54e317]
./src/emacs[0x5512e9]
./src/emacs[0x553141]
./src/emacs[0x5c7597]
./src/emacs[0x53fd0a]
./src/emacs[0x5c74f1]
./src/emacs[0x53fcaf]
./src/emacs[0x547513]
./src/emacs[0x54788e]
./src/emacs[0x42ad38]
/gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/libc.so.6(+0x29bf7)[0x7f0464105bf7]
/gnu/store/zvlp3n8iwa1svxmwv4q22pv1pb1c9pjq-glibc-2.39/lib/libc.so.6(__libc_start_main+0x7c)[0x7f0464105cac]
./src/emacs[0x42b1e1]


>
> The reason for this strange way of doing things is that I quit in a rage
> when trying to add the normal border handling for tty frames. Works for
> me. Just mentioning it so that others can comment how terrible that is :-).

-- 

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Feng Shu <tumashu@163.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> As an aside, because that might affect Posframe maybe in the future. I
>> also implemented borders around child frames now, but in a strange way,
>> with the 'undecorated' frame parameter. If a tty child frame is not
>> undecorated, a border is drawn around it, otherwise it isn't.
>
> I have tested (undecorated . nil) in emacs, but show segmentation
> fault.

Oh, you tried to use scratch/tty-child-frames from savannah? That is a
bit old :-) and doesn't have the borders stuff.

The real deal is

  https://github.com/gerd-moellmann/emacs-with-cl-packages/tree/tty-child-frames

I'm currently not keeping savannah in sync because I think it's too
early for that. It was just meant for people having a first look.

Downside of using the original is that you'll inherit CL packages, as
you'll see on the github page ;-). It also has MPS supprt, but you can
ignore that, it should build and run without.

Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> The real deal is
>
>   https://github.com/gerd-moellmann/emacs-with-cl-packages/tree/tty-child-frames

Just FYI. I made

  https://github.com/gerd-moellmann/emacs-with-cl-packages

contain a "stable" version of the childi frames code, and I'm using the
tty-child-frames in a more unstable way. The README.md shows what I do
in my init.el for Posframe and Corfu.

Re: Question about minibuffer and child frames (Posframe)

[martin rudalics]

 > posframe do not handle focus in most situation, for it is too complicate
 > to let focus work. posframe just *show* the content of a buffer.

What if the user clicks into a child frame with the mouse?  Do you have
the frame's 'no-accept-focus' parameter set?  Does it work everywhere?
I never got any feedback on this.

 > When enable vertico-posframe, we just let the content of minibuffer is
 > showed in a posframe, but input handle is in parent frame, we lock the
 > height of parent minibuffer window and vscroll minibuffer window to hide
 > minibuffer content in below function.

This sounds awfully tricky.  Did you never try to do that in a "cleaner"
way?  Here I _always_ have one single minibuffer window in a child frame
and with the exception of some minor modifications that were necessary
when redirecting frame focus got broken I have no problems.  The child
frame pops up when and where needed and is not visible otherwise.

martin

Re: Question about minibuffer and child frames (Posframe)

[Feng Shu]

martin rudalics <rudalics@gmx.at> writes:

>> posframe do not handle focus in most situation, for it is too complicate
>> to let focus work. posframe just *show* the content of a buffer.
>
> What if the user clicks into a child frame with the mouse?  Do you have
> the frame's 'no-accept-focus' parameter set?  Does it work everywhere?
> I never got any feedback on this.

by default, posframe use 'no-accept-focus', but it seem to not work
everywhere, it seem to depend on window manager used. if user clicks
poframe, sometimes it will get focus and insert user input, sometimes
not.

by default, posframe do not support user clicks :-)

>
>> When enable vertico-posframe, we just let the content of minibuffer is
>> showed in a posframe, but input handle is in parent frame, we lock the
>> height of parent minibuffer window and vscroll minibuffer window to hide
>> minibuffer content in below function.
>
> This sounds awfully tricky.  Did you never try to do that in a "cleaner"
> way?  Here I _always_ have one single minibuffer window in a child
> frame

Haha, My Emacs level is unable to handle focus bugs, and posframe do not
consider focus at the begin of design :-)


> and with the exception of some minor modifications that were necessary
> when redirecting frame focus got broken I have no problems.  The child
> frame pops up when and where needed and is not visible otherwise.
>
> martin
>

--