Subject: Re: bug#77924: 31.0.50; [Feature branch] Change marker implementation

From: Gerd Möllmann <[email-masked]>
Date: Thu, 24 Apr 2025 21:53:05 +0200

Pip Cet <[email-masked]> writes:

> Gerd Möllmann <[email-masked]> writes:
>
>> Eli Zaretskii <[email-masked]> writes:
>>
>>>> +  DO_MARKERS (b, m)
>>>> +    {
>>>> +      if (!vectorlike_marked_p (&m->header))
>>>> +	marker_vector_remove (XVECTOR (BUF_MARKERS (b)), m);
>>>> +    }
>>>> +  END_DO_MARKERS;
>>>
>>> Would it be possible not to introduce macros that modify the C syntax?
>>> These are problematic for more than one reason (one being that they
>>> are not recognized by C modes we use).  We have macros whose names
>>> start with FOR_EACH_ (like FOR_EACH_FRAME); can we introduce
>>> FOR_EACH_MARKER instead, and not hide opening/closing braces inside
>>> macros?
>>
>> I tried, already in igc, but failed. IOW, I don't now a way to get rid
>> of the END_DO_MARKERS.
>
> Okay, I'll bite.

:-)

> I think what we should do is mimic FOR_EACH_TAIL, and use
> FOR_EACH_MARKER like this:
>
> struct Lisp_Marker *m;
> FOR_EACH_MARKER (b, m)
>   {
>     /* do something with m */
>   }

We need an if somewhere for the MARKERP, don't we? So...

> However, if we wanted to, we could do this (the "continued" thing is
> overkill to make "break" work in a FOR_EACH_MARKER loop):

... we'll need this.

The continued thing is quite clever, didn't think of it. I dismissed the
two for loops because of the break/continue. So, since it's already
done, and can be pilfered, that's fine with me :-). Let's see if the
others find it too complicated.