Listing markers in buffer

Listing markers in buffer

[ian.tegebo]

I see that `buffer-has-markers-at` will at least tell if there are markers pointing to a position, but not only has it been marked obsolete since 24.3, it doesn't provide one a means to actually get a marker object.

Looking at the C source, I can see that buffer to buffer_text structs point to a singly linked list of Lisp_marker structs, but I can't find any Elisp functions to access them. Also, there's a related thread from 1999:

https://groups.google.com/forum/#!topic/gnu.emacs.help/vNG9y5qCaxc/discussion

Lastly, please forgive me, I've cross-posted to SO:

http://stackoverflow.com/questions/36926513/are-there-elisp-functions-that-list-markers-in-a-given-buffer

Re: Listing markers in buffer

[Pascal J. Bourguignon]

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

> I see that `buffer-has-markers-at` will at least tell if there are
> markers pointing to a position, but not only has it been marked
> obsolete since 24.3, it doesn't provide one a means to actually get a
> marker object.
>
> Looking at the C source, I can see that buffer to buffer_text structs
> point to a singly linked list of Lisp_marker structs, but I can't find
> any Elisp functions to access them. Also, there's a related thread
> from 1999:
>
> https://groups.google.com/forum/#!topic/gnu.emacs.help/vNG9y5qCaxc/discussion

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.

That said, you can always patch GNU emacs C sources to provide a lisp
access to them.

-- 
__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

Re: Listing markers in buffer

[ian.tegebo]

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.

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

Re: Listing markers in buffer

[Pascal J. Bourguignon]

"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

Re: Listing markers in buffer

[ian.tegebo]

On Saturday, April 30, 2016 at 2:16:32 AM UTC-7, Pascal J. Bourguignon wrote:
> [...] 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?

Indeed, `yas--collect-snippet-markers` gets me pretty close.  Thanks for pointing out that convention of public markers. I hadn't noticed that before.