From: "Pascal J. Bourguignon" <pjb@informatimago.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Listing markers in buffer
Date: Sat, 30 Apr 2016 11:16:28 +0200 [thread overview]
Message-ID: <87r3dnv4lv.fsf@kuiper.lan.informatimago.com> (raw)
In-Reply-To: 3b7d39b5-8fc6-4ceb-869b-691e27884cd0@googlegroups.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
next prev parent reply other threads:[~2016-04-30 9:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 23:18 Listing markers in buffer ian.tegebo
2016-04-29 17:13 ` Pascal J. Bourguignon
2016-04-29 21:14 ` ian.tegebo
2016-04-30 9:16 ` Pascal J. Bourguignon [this message]
2016-04-30 18:36 ` ian.tegebo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3dnv4lv.fsf@kuiper.lan.informatimago.com \
--to=pjb@informatimago.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.