GNU bug report logs - #77336
[PATCH] Fix mouse highlighting for compact mode lines

Previous Next

Full log

Message #17 received at 77336 <at> debbugs.gnu.org (full text, mbox):

From: Pengji Zhang <me <at> pengjiz.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77336 <at> debbugs.gnu.org
Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines
Date: Mon, 31 Mar 2025 11:31:36 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Pengji Zhang <me <at> pengjiz.com>
>> Cc: 77336 <at> debbugs.gnu.org
>> Date: Sun, 30 Mar 2025 19:44:59 +0800
>> 
>> > Thanks, but why do we need to make the value of this mode-line-element
>> > property be the element itself?  Why not give it some simple value,
>> > like the ordinal number of the element (which should be incremented
>> > whenever we process another element)?  So we could call this property
>> > mode-line-elt-number and assign the elements values 1, 2, 3, etc.
>> 
>> Is casting the 'Lisp_Object' to a number acceptable here?
>
> No, because Lisp_Object could be a struct (if Emacs was configured with
> "--enable-check-lisp-object-type").

Sorry I did not make it clear. I meant 'make_fixnum(XLI(elt))'. I
suppose 'XLI' will handle that case correctly?

I am actually concerned that there could be a collision between two
different 'elt's, e.g., a symbol and a string, because 'make_fixnum'
alters the tag of 'elt'. I think it might be fine because 'elt' should
always be a 'Lisp_String' when this is called.

> What I had in mind was to have a static global int variable named, say
> elt_no, initialized to zero when display_mode_line is called, and then
> give each segment of the mode line a value like this:
>
>    AUTO_LIST2 (src, Qmode_line_element, make_fixnum (elt_no++));
>    n += store_mode_line_string (NULL, elt, true, 0, prec, src);   
>
>> I tried an incremental counter but gave up. Because
>> 'display_mode_element' could be called recursively, we may have to
>> change its signature or introduce a new global variable. That feels a
>> bit less clean to me.
>
> A global variable is what I had in mind.  I don't see why it would be
> less clean.

It is just that maintaining a global state is not as tasteful to me. If
'make_fixnum(XLI(elt))' is not good here, I am happy to go this way.

>> > I'm concerned that having the elements themselves be values will
>> > prevent them from being GC'd, which might increase the memory
>> > pressure.  By contrast, fixnums are immediate values that don't need
>> > to be GC'ed, and the element itself will not have any references after
>> > the mode line is processed.
>> 
>> I thought all objects would be GC'd. Since fixnums are not, I guess now
>> we do not need to remove the text property before displaying the string?
>> Please let me know what you think and I will update the patch if needed.
>
> If you remove the text property because of GC, then indeed you don't
> need to do that anymore with fixnums.

Thanks. I will update the patch accordingly.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.