[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35536: 27.0.50; Expose buffer's marker list to Elisp
From: |
Basil L. Contovounesios |
Subject: |
bug#35536: 27.0.50; Expose buffer's marker list to Elisp |
Date: |
Thu, 02 May 2019 17:51:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Date: Thu, 02 May 2019 16:44:52 +0100
>> Cc: Mauro Aranda <maurooaranda@gmail.com>,
>> Stefan Monnier <monnier@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
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Eli Zaretskii, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp,
Basil L. Contovounesios <=
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Eli Zaretskii, 2019/05/02
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Basil L. Contovounesios, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Stefan Monnier, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Stefan Monnier, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Drew Adams, 2019/05/03
- bug#35536: 27.0.50; Expose buffer's marker list to Elisp, Richard Stallman, 2019/05/04