emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: scroll-bars


From: Helmut Eller
Subject: Re: MPS: scroll-bars
Date: Tue, 07 May 2024 08:07:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Mon, May 06 2024, Eli Zaretskii wrote:

>> > Btw, did we decide what to do with these chains:
>> >
>> >   struct frame
>> >   {
>> >   [...]
>> >   /* List of scroll bars on this frame.
>> >      Actually, we don't specify exactly what is stored here at all; the
>> >      scroll bar implementation code can use it to store anything it likes.
>> >      This field is marked by the garbage collector.  It is here
>> >      instead of in the `device' structure so that the garbage
>> >      collector doesn't need to look inside the window-system-dependent
>> >      structure.  */
>> >   Lisp_Object scroll_bars;
>> >   Lisp_Object condemned_scroll_bars;
>> >
>> > They are doubly-linked lists via the ->next and ->prev fields in the C
>> > 'struct scroll_bar', in X as well as w32, see XSCROLL_BAR.  The
>> > Lisp_Object's above are the last scroll bar on the frame's windows,
>> > and the rest are reachable via the ->next and ->prev pointers.  Do we
>> > need to do anything about those ->next and ->prev pointers?
[...]
> Helmut, WDYT about the scroll bars on X (and by extension on w32)?

On X, the struct scroll_bar is allocated as a PVEC_OTHER pseudovector.
And I think the next/prev links are traced because of that.
xterm.c:mark_xterm doesn't do anything special for scrollbars, so I
think it's all covered.  The only complication so far was that a struct
scroll_bar* was handed to GTK that was not traced; after I turned that
into a root with a pointer to the scroll_bar* it is traced.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]