[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Listing markers in buffer
Pascal J. Bourguignon
Re: Listing markers in buffer
Thu, 02 Jun 2016 15:20:50 -0000
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
"ian.tegebo" <address@hidden> writes:
> On Friday, April 29, 2016 at 10:13:27 AM UTC-7, Pascal J. Bourguignon wrote:
>> "ian.tegebo" <address@hidden> 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 . 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?
> : 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:
You type a shell command in a buffer:
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