[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Final" version of tty child frames
From: |
Gerd Möllmann |
Subject: |
Re: "Final" version of tty child frames |
Date: |
Tue, 22 Oct 2024 10:21:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Tue, 22 Oct 2024 06:46:15 +0200
>>
>> I have (re-)created the scratch/tty-child-frames branch today, which
>> contains the code for child frames on ttys, based on a recent master.
>>
>> I'm a happy user of this for a while now with corfu, vertico +
>> vertico-posframe + consult, transient + transient-posframe,
>> which-key + which-key-posframe. And my current todo list is now empty,
>> so here it is.
>
> Is there a way to test the feature without using corfu? If so, can
> you suggest some simple Lisp to see if the child frames work in a
> build of this branch?
Thanks for taking a look.
Something built-in you could try is show-paren-mode with
show-paren-context-when-offscreen set to 'child-frame. Not very useful,
but it should display a child frame at (0,0) of a window.
Or maybe
(defun my-make-child ()
(interactive)
(make-frame `((parent-frame . ,(selected-frame))
(background-color . "gray10")
(foreground-color . "white")
(internal-border-width . 1)
(top . 15)
(left . 40)
(width . 80)
(height . 25))))
which is not really the use case I have in mind but anyway.
>> Disclaimer: As I mentioned already in other contexts, I don't want to
>> be the maintainer of anything, for personal reasons.
>>
>> Have fun!
>
> Does this compile cleanly for you? I get gobs of warnings like this:
Yes it does, with clang.
> dispnew.c: In function ‘gui_update_window_end’:
> dispnew.c:4495:34: warning: potential null pointer dereference
> [-Wnull-dereference]
> 4495 | hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
> | ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> This seems to be because you've changed the definition of
> MOUSE_HL_INFO to be this:
>
> # define MOUSE_HL_INFO(F) \
> (FRAME_WINDOW_P (F) \
> ? (FRAME_OUTPUT_DATA (F) \
> ? &FRAME_DISPLAY_INFO (F)->mouse_highlight \
> : NULL) \
> : &(F)->output_data.tty->display_info->mouse_highlight)
>
> I don't understand the need for this NULL there. What is its purpose,
> and what will we lose by going back to the original definition? I
> believe that NULL is what's causing these warnings.
It probably crept in when I ported this. I can remove that if you want.
- Re: "Final" version of tty child frames, (continued)
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22
- Re: "Final" version of tty child frames, Po Lu, 2024/10/22
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22
- Re: "Final" version of tty child frames, martin rudalics, 2024/10/22
Re: "Final" version of tty child frames, Dr. Arne Babenhauserheide, 2024/10/22
Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames,
Gerd Möllmann <=
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22
- Re: "Final" version of tty child frames, Eli Zaretskii, 2024/10/22
- Re: "Final" version of tty child frames, Paul Eggert, 2024/10/22
- Re: "Final" version of tty child frames, Gerd Möllmann, 2024/10/22