Re: "Final" version of tty child frames

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Jared Finder <jared@finder.org> writes:

> On 2024-12-11 23:04, Gerd Möllmann wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> Date: Thu, 12 Dec 2024 00:11:01 -0500
>>>> From: Jared Finder <jared@finder.org>
>>>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>>>> rudalics@gmx.at
>>>> 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"?
>>> I think minibuffer-only frames _are_ implemented on TTYs (albeit
>>> not
>>> very useful there).  They are not implemented as child frames, I
>>> think.
>>> But yes, emitting an explicit error message about something not
>>> implemented would be definitely better.
>> Pushed something like that to the branch.
>
> Thanks.
>
> Things otherwise seem fine with tty child frames. There's certainly
> oddness with mouse interaction, but it's not fundamentally broken in
> any way, just more things that don't work. In particular:
>
> With xterm-mouse, as I highlighted earlier, I can select the child
> frame even if it is set as not selectable. Once a window in a child
> frame is selected, I can type there normally.
>
> With gpm mouse, I have the opposite problem. I can never select the
> child frame and in fact the mouse behaves as if the child frame isn't
> there. Clicking and tooltip text both pay no attention to the child
> frame and just act on whatever is behind the child frame.
>
> For both of these, I couldn't get mouse-face or clicking to work on
> child frames. I was doing the following:
>
> (setq button (buttonize "[Click me]" (lambda (&rest _) (message
> "Clicked!"))))
> (posframe-show " *buffer*" :string (concat "A\n" button "\nB"))
>
> The posframe would show, but the mouse can't interact with the
> buttonized text. This may be a limitation of posframe though, it also
> didn't work in graphical mode.
>
> That's really it. I don't see any major issues with child frames. As
> long as we're ok with saying that mouse support is not mature, it
> seems fine to me.
>
>   -- MJF

Hi Jared, thanks for testing!

And what you write is certainly true - if one wants to have child frames
like on GUI, with all bells and whistles, there are probably a lot of
things that await implementation :-).

WRT GPM: Sounds to me like this is because GPM hasn't been changes to
act analogous to xt-mouse. I think there only two commits to xt-mouse.el
in the branch. It's not much, if you look at the diffs, basically only

  - determine the frame F under (x, y) as reported by the terminal
  
  - Give Emacs (F, x', y'), where x' and y' are the coordinates
    relative to F

That was all I needed, in principle, at least for xterm-mouse, to make
things work. Don't know if that also fits for GPm.