[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Browse skeleton positions

From: Stefan Monnier
Subject: Re: Browse skeleton positions
Date: Sun, 19 Oct 2003 23:36:08 GMT
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Stefan> Maybe it would be better to just use (point) instead, and when
Stefan> you do `next' or `prev', go through the list looking for the
Stefan> nearest marker in the requested direction ?

> Hmmmm.  Again, interesting suggestion, but the behavior could be
> significantly different in case there are multiple overlapping skeletons.


Stefan> As for the behavior, the above has the nasty side effect that
Stefan> just loading "skelposn" into your Emacs will cause all your
Stefan> skeleton positions to accumulate in the form of markers (at
Stefan> least until you finally call skeleton-position-exit which will
Stefan> likely be never if you don't actually use skelposn).  This can
Stefan> lead to a significant slowdown because of the way markers are
Stefan> implemented.

> Note the kill-buffer-hook.

But that's too late.  The hook is actually pretty useless because
you're kill markers that will be killed by `kill-buffer' anyway
and you're setting variables to nil which will be destroyed by
`kill-buffer' as well.

> Won't do.  Much editing can happen between inserting the skeleton and
> starting to browse, and then the positions will be all wrong.  In
> particular, I fully intend to keep _multiple_ preceding skeletons'
> positions available until explicitly discarded.

Well, then.  Maybe the "many markers" will not be a real problem (it
typically only shows up once you have hundreds of markers in the current
buffer, so maybe it won't affect your code in practice).  Otherwise, you
might want to put an upper-limit, maybe using a ring.

Stefan> How about a less in-your-face mode that lets you edit the text
Stefan> at the same time as you navigate between the different markers ?

> But then you'd need more complicated, harder to type (and to retype, in
> particular) keybindings.  This is a general dilemma which I have
> resolved for myself in favor of special modes like this one.  See also
> wmanip.el which I have posted some time ago, similar idea.

You could maybe have an alternate minor mode, providing the
same bindings but under a prefix key, so users can choose between
the two styles.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]