GNU bug report logs - #35536
27.0.50; Expose buffer's marker list to Elisp

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Mauro Aranda <maurooaranda <at> gmail.com>,
 "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35536 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#35536: 27.0.50; Expose buffer's marker list to Elisp
Date: Sat, 4 May 2019 19:34:08 +0200

>> A save+restore primitive like the one you suggested in your other
>> message sounds like it might do the trick without having to expose a
>> buffer's marker list to Lisp.
>
> Indeed.  I thought Martin was talking about something like this in his post
> in bug#18.  Given a region where text is going to be replaced, save the
> positions of markers that would be affected because of the delete+insert,
> and then restore them.

More precisely I would try to save the contexts of the old marker
positions similar to what we do with bookmarks and try to find these
contexts in the replaced region.  The important aspect is obviously
that this step can be skipped for regions left alone by compareseq (or
whatever was used) because in those (hopefully large) regions markers
are preserved automatically.  Some care would be needed for markers
that sit precisely at the bounds of these region and have the "wrong"
insertion type.  And maybe we should optionally give the cursor a
different color if it was not possible to restore it unequivocally.

The approach would be IMHO useful when reverting buffers after code
has been wrongly reindented or commented in or out.  I'm afraid that
it might not be overly useful for auto-reverted dired buffers and
buffers with many fine-grained modifications.

Which markers should be restored this way and whether the
corresponding code should be provided as a primitive or in Elisp is a
decision I leave to knowledgeable people.  I'd be already happy if
'point-marker' were handled that way.

martin

Previous Next

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