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

Previous Next

Full log

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35536 <at> debbugs.gnu.org, maurooaranda <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#35536: 27.0.50; Expose buffer's marker list to Elisp
Date: Thu, 02 May 2019 17:51:12 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
>> Date: Thu, 02 May 2019 16:44:52 +0100
>> Cc: Mauro Aranda <maurooaranda <at> gmail.com>,
>> 	Stefan Monnier <monnier <at> iro.umontreal.ca>
>> 
>> I attach a patch implementing this based on BUF_MARKERS, as per Martin's
>> suggestion.  Any reasons not to expose such a function?
>
> I'm not yet convinced we need something like that, but in any case, is
> the order important?  Because the code you propose produces a list in
> reverse order.

The order of the returned list is in increasing buffer position, thanks
to the call to Fsort.  Is that not a reasonable order?

> More generally, I think we should discuss the need for this in more
> detail.  Markers are used for several features, and there's internal
> stuff like conversion from character to byte positions that depends on
> them.  Changing markers could thus easily crash Emacs, especially if
> it comes in some in-opportune moment.

Are you saying that BUF_MARKERS could include markers created by
internal functions which could crash if these markers are changed across
calls to other Lisp functions?

If so, that sounds like a valid concern to a non-expert like me, but it
also sounds like a bug waiting to happen, given that other C code
also traverses and manipulates BUF_MARKERS.

If not, I don't see how manipulating markers returned by marker-list is
any worse than manipulating those created at the Lisp level, with the
usual and documented risks associated with manipulating markers not
owned by the caller.

> It is possible that people actually need higher-level primitives that
> manipulate markers internally.  We should first identify the use cases
> where this could be needed, and then see how to help solving those use
> cases by something like a new marker-related primitive.

I have yet to see a use-case for marker-list which can't be engineered
in a different way (other than as a replacement for the obsolete
buffer-has-markers-at, FWIW).  Perhaps some of the CCed parties might
have examples.

Thanks,

-- 
Basil

Previous Next

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