GNU bug report logs - #77924
31.0.50; [Feature branch] Change marker implementation

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, Juri Linkov <juri <at> linkov.net>,
 martin rudalics <rudalics <at> gmx.at>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 77924 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com
Subject: Re: bug#77924: 31.0.50; [Feature branch] Change marker implementation
Date: Thu, 24 Apr 2025 13:29:43 +0200

Pip Cet <pipcet <at> protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> So, one could, theoretically store the charpos in a field of a marker
>>> when "unchaining" it. Ugly, but doable.
>>
>> And one could do something practically, which I now pushed to savannah.
>
> Can you explain how that works in the non-indirect buffer case?  

Yes, it doesn't :-).

> AFAICT, we call marker_vector_reset but not marker_vector_remove in
> that case, and there is no code in marker_vector_reset to remember the
> last charpos. And the comment in marker_vector_reset sounds like it's
> not called at all in the IGC case?

You mean this:

  /* The old GC contains at least one assertion that unchaining markers
     in kill-buffer resets the markers' buffers.  IGC does not do this,
     can't do this, and does not need it.  */

What I meant there is what I described in my mistaken mail before, that
it can't do anything with the markers. But if they are dead, who cares.
CLassic thinko.

I'll remove these comments.

Thanks!

Previous Next

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