Re: "Final" version of tty child frames

[Gerd Möllmann]

Jared Finder <jared@finder.org> writes:

> On 2024-12-11 02:59, Gerd Möllmann wrote:
>> Jared Finder <jared@finder.org> writes:
>> 
>>> Spent time just playing with child frames to get familiar with things.
>>> A few bugs I noticed:
>> Nice!
>> 
>>> There's something in the C code that makes this branch not work with
>>> the mini-frame package
>>> (https://github.com/muffinmad/emacs-mini-frame). The package works
>>> fine in graphical mode.
>> The page says that the package is using mini-buffer-only frames,
>> which
>> are not implemented, because I wasn't interested. See the #if 0
>> make_terminal_frame.
>
> I think it would be good for unimplemented features to communicate
> that state to the user so users know clearly what is going on.  Right
> now the error a user sees is "Can’t change the ‘minibuffer’ parameter
> of this frame". Wouldn't it be better to have make-terminal-frame (a
> brand new function with no existing clients to support) error with
> something like "Minibuffer only frames are not supported in
> terminals"?
>
> This also would avoid the bug that currently a minibuffer-only child
> frame gets left around which looks weird and confusing.

Sure, we could do that, or someone implements minibuffer-only frames,
someone knowing how these work and are used on GUI. Or IOW, I feel
things are still a bit in undecided state, except on my side.

> Are there any other intentionally unimplemented features?  It'd be
> nice to have similarly clean errors to inform users.

Open things should all be marked them all with FIXME/tty. Frame
re-stacking (tty-frame-restack) is an example, or specifying frame
borders (what a WM would do).

>>> I'm using posframe for iteration. There's a minor thing where the
>>> cursor position is inconsistent when at the end of a line with a
>>> posframe on it in the tty. Maybe that's intentional? It's kinda
>>> confusing to me.
>> Could you please describe in detail what you are doing? I haven't
>> understood yet. Posframe and Corfu are BTW the reason I added the
>> child frames.
>> Child frames in the more general sense was not so interesting.
>> Always
>> talking about me personally of course. I think I talked with Martin
>> about adding stuff as needed if users really want it, or something, and
>> ISTR he agreed. But Martin can speak for himself :-).
>
> This was from me moving the cursor around (just using arrow keys) the
> text covered up by a child frame.

So you have a child frame open covering a line of text in the parent
frame. And then move the cursor in the parent through obscured line? And
what do you mean with the cursor position being inconsistent?

(That would BTW be a child frame use-case which is not so interesting
for me personally, and something GNU has to decide if it's
important/essential or whatever. When is write GNU I mean whoever
decides that at the end.)

>>> There's also a major thing where I can click on the child frame in the
>>> tty and then my cursor is actually in the child frame and I can just
>>> alter the text there. That behavior is inconsistent with the behavior
>>> on graphical displays and something I can investigate.
>> Could you please give a recipe? I don't understand yet what you
>> mean.
>> Or, if you want to investigate, please do :-). Please don't hesitate to
>> ask me any question. At least I still remember more stuff about this
>> than about igc :-).
>
> This is from me using the mouse while in xterm and clicking on the
> child frame.  Or just hovering over the child frame with
> mouse-autoselect-window set to t.  I'm guessing this is just due to
> the frame parameter no-accept-focus not being implemented.  Since this
> is a common path for posframe, I think it could be important to
> implement. Such an implementation probably needs to alter
> xt-mouse.el's generation of select-window events.
>
> To reproduce:
>
> (xterm-mouse-mode 1)
> (posframe-show "*scratch*" :poshandler
> 'posframe-poshandler-frame-center)
> Click on the posframe.
>
>   -- MJF

Could be no-accept-focus, I don't know. If so, and IIRC how that words,
this is another case where not having a window manager comes into play,
and one would have to decide If one wants to implement part of the
functionality of a WM in Emacs on ttys.

(One WM feature I've added because I think one cannot do without is
frame decoration/border. With the caveat that I could not get things to
work by using border-width and so on, with the result that git reset
--hard in a rage in the end (which doesn't happen often), and I don't
think I'll try again soon :-))