Subject: Re: bug#77336: [PATCH] Fix mouse highlighting for compact mode lines

From: Eli Zaretskii <[email-masked]>
Date: Sat, 05 Apr 2025 12:36:46 +0300

> From: Pengji Zhang <[email-masked]>
> Cc: [email-masked]
> Date: Wed, 02 Apr 2025 21:02:19 +0800
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Pengji Zhang <[email-masked]>
> >> Cc: [email-masked]
> >> Date: Mon, 31 Mar 2025 11:31:36 +0800
> >> 
> >> Eli Zaretskii <[email-masked]> writes:
> >> 
> >> >> 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'd prefer not to do that unless there's no other reasonable solution.
> >
> >> 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.
> >
> > Sorry, I don't understand: what do you mean by "alters the tag of
> > 'elt'", and how could make_fixnum affect 'elt'?
> 
> It does not affect 'elt'. I meant that 'make_fixnum' may change the
> value of the number from the tagged pointer:
> 
>     INLINE Lisp_Object
>     make_fixnum (EMACS_INT n)
>     {
>       ...
>         {
>           n &= INTMASK;
>           n += (int0 << VALBITS);
>         }
>       return XIL (n);
>     }
> 
> So if I understand it correctly, that means 'make_fixnum(XLI(x))' could
> give the same result for, e.g., a fixnum and a string.
> 
> >> > 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.
> >
> > Yes, a global variable is cleaner than using XLI for this purpose.
> 
> Thanks. Please see the attached patch.

Thanks, I've now installed this on the master branch, and I'm
therefore closing this bug.