GNU bug report logs -
#77924
31.0.50; [Feature branch] Change marker implementation
Previous Next
Full log
View this message in rfc822 format
Pip Cet <pipcet <at> protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> 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.
This bug report was last modified 105 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.