Re: Question about minibuffer and child frames (Posframe)

[Gerd Möllmann]

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.

Screenshot 2024-10-02 at 17.05.33.png
Description: PNG image

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