From: Jared Finder <jared@finder.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, rudalics@gmx.at
Subject: Re: "Final" version of tty child frames
Date: Thu, 12 Dec 2024 00:11:01 -0500 [thread overview]
Message-ID: <5fedec86bce470555814acbdf999f99d@finder.org> (raw)
In-Reply-To: <m2y10mr6pk.fsf@gmail.com>
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.
Are there any other intentionally unimplemented features? It'd be nice
to have similarly clean errors to inform users.
>> 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.
>> 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
next prev parent reply other threads:[~2024-12-12 5:11 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 4:46 "Final" version of tty child frames Gerd Möllmann
2024-10-22 5:29 ` Eli Zaretskii
2024-10-22 9:58 ` martin rudalics
2024-10-22 10:20 ` Eli Zaretskii
2024-10-22 14:01 ` martin rudalics
2024-10-22 14:23 ` Eli Zaretskii
2024-10-22 10:40 ` Gerd Möllmann
2024-10-22 11:43 ` Po Lu
2024-10-22 13:44 ` Eli Zaretskii
2024-10-22 14:01 ` Gerd Möllmann
2024-10-22 14:02 ` martin rudalics
2024-10-28 4:35 ` Jared Finder
2024-10-28 5:57 ` Gerd Möllmann
2024-11-30 11:25 ` Eli Zaretskii
2024-12-05 3:49 ` Jared Finder
2024-12-11 7:31 ` Jared Finder
2024-12-11 7:59 ` Gerd Möllmann
2024-12-12 5:11 ` Jared Finder [this message]
2024-12-12 6:20 ` Gerd Möllmann
2024-12-12 6:48 ` Gerd Möllmann
2024-12-12 6:30 ` Eli Zaretskii
2024-12-12 7:04 ` Gerd Möllmann
2024-12-18 5:35 ` Jared Finder
2024-12-18 6:25 ` Gerd Möllmann
2024-12-18 13:54 ` Eli Zaretskii
2024-12-18 16:01 ` Gerd Möllmann
2024-12-18 16:29 ` Eli Zaretskii
2024-12-18 16:39 ` Gerd Möllmann
2024-12-18 17:02 ` Eli Zaretskii
2024-12-18 17:22 ` Gerd Möllmann
2024-12-19 5:17 ` Jared Finder
2024-12-19 5:30 ` Gerd Möllmann
2024-12-19 7:44 ` Gerd Möllmann
2024-12-19 8:36 ` Eli Zaretskii
2024-12-19 9:04 ` Gerd Möllmann
2024-12-19 9:17 ` Gerd Möllmann
2024-12-19 10:34 ` Robert Pluim
2024-12-19 10:40 ` Gerd Möllmann
2024-12-18 21:06 ` Stefan Kangas
2024-12-19 8:00 ` Andrea Corallo
2024-12-11 9:39 ` martin rudalics
2024-10-22 7:34 ` Dr. Arne Babenhauserheide
2024-10-22 7:49 ` Gerd Möllmann
2024-10-22 7:49 ` Eli Zaretskii
2024-10-22 8:01 ` Eli Zaretskii
2024-10-22 8:21 ` Gerd Möllmann
2024-10-22 8:57 ` Eli Zaretskii
2024-10-22 9:42 ` Eli Zaretskii
2024-10-22 10:23 ` Gerd Möllmann
2024-10-22 13:35 ` Eli Zaretskii
2024-10-22 13:43 ` Gerd Möllmann
2024-10-22 13:55 ` Eli Zaretskii
2024-10-22 14:02 ` Gerd Möllmann
2024-10-22 14:40 ` Eli Zaretskii
2024-10-22 19:19 ` Paul Eggert
2024-10-23 3:18 ` Gerd Möllmann
2024-10-22 10:43 ` Gerd Möllmann
2024-10-23 3:05 ` Feng Shu
2024-10-23 3:13 ` Gerd Möllmann
2024-10-23 3:25 ` Feng Shu
2024-10-23 3:36 ` Gerd Möllmann
2024-10-23 3:44 ` Feng Shu
2024-10-23 4:09 ` Gerd Möllmann
2024-10-23 4:40 ` Gerd Möllmann
2024-10-23 5:00 ` Gerd Möllmann
2024-10-23 7:49 ` Eli Zaretskii
2024-10-23 8:12 ` Gerd Möllmann
2024-10-23 11:04 ` Gerd Möllmann
2024-10-23 17:23 ` Eli Zaretskii
2024-10-23 17:52 ` Gerd Möllmann
2024-10-23 6:54 ` Feng Shu
2024-10-23 7:25 ` Gerd Möllmann
2024-10-23 7:28 ` Eli Zaretskii
2024-10-23 7:37 ` Gerd Möllmann
2024-10-23 7:52 ` Feng Shu
2024-10-23 8:07 ` Gerd Möllmann
2024-10-23 9:07 ` Feng Shu
2024-10-23 9:58 ` Gerd Möllmann
2024-10-23 7:11 ` Eli Zaretskii
2024-10-26 8:15 ` Gerd Möllmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5fedec86bce470555814acbdf999f99d@finder.org \
--to=jared@finder.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.