Re: Listing markers in buffer

["Pascal J. Bourguignon" <pjb@informatimago.com>]

"ian.tegebo" <ian.tegebo@gmail.com> writes:

> On Friday, April 29, 2016 at 10:13:27 AM UTC-7, Pascal J. Bourguignon wrote:
>> "ian.tegebo" <ian.tegebo@gmail.com> writes:
>> 
>> > Looking at the C source, I can see that buffer to buffer_text structs
>> > point to a singly linked list of Lisp_marker structs [...]
>> 
>> Markers belong to their owners, and it would be very dangerous if you
>> could get them and set or reset them behind the back of their owners.
>
> Could you provide an example?
>
> Here's where I'm coming from:
>
> While writing a yas-snippet, I wanted to modify previous text
> depending on some event within a field.  I found that by doing so, it
> broke because I didn't understand how overlays and markers were being
> used [1].  Naively, I thought I could get a list of markers in the
> buffer, like one can get the text properties and overlays for at least
> the purposes of learning/debugging.

Yes, for debugging it might be interesting to get them.


> Instead, I read the code to determine exactly what was going on.  In
> retrospect, I might have saved myself some time if I'd have been able
> to see the details of the markers in the affected region.  Now, I see
> where the markers are being held in yas-snippet, so I can still get at
> them and muck about.
>
> When you say "dangerous", is it the same kind of danger I'm exposed to
> when changing the internal state elisp libraries *in general*?  Or do
> you mean "danger" in a specific sense, e.g. that some monstrous GC bug
> is hiding behind the scenes once a buffer's markers are exposed?
>
> [1]: I'm aware that this is a known no-no

No, it's a little danger: you might break an invariant for some code, so
it will do something wrong next time it's run, or at worse, signal an
error (and possibly enter the debugger, with a puzzled used).

However, little danger can grow big.

Assume you have a package with two commands:

    executor-select-command
    executor-execute-selected-command

You type a shell command in a buffer:

    ls -l

select it and M-x executor-select-command RET
This would put a pair of markers on the region, so that you can still
edit it, eg. into ls -aFCNl
and then M-x executor-execute-selected-command when you want to fork a
shell with it (call shell-command).

Now, if some code could get the list of markers, and move those marker
to a (hidden) region containing: rm -rf /
you would be in a dire situation.

(if your code modified the existing region, the user would see it and
hopefully wouldn't do M-x executor-execute-selected-command).


That said, there may be "public" markers. They's stored in public
variables, or packages may have functions to return them.  M-x apropos
RET markers RET gives a few of them, for example
org-refile-markers or forms--markers.

Perhaps yasnippet has such a list of public markers too?  Or perhaps you
could modify it to record and provide such a list?

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk