Re: Browse skeleton positions

[Ian Zimmerman <bayard@newsguy.com>]

>> (define-key kmap [ return ] 'skeleton-position-exit)

Stefan> Please use [?\C-m] (or "\C-m"), unless you really mean that this
Stefan> binding should not work in a tty.

Good point.

>> (defsubst turn-on-skeleton-position-mode ()

Stefan> I recommend you use `defun' here, since it's unlikely that the
Stefan> advantages of defsubst will outweigh its disadvantages in this
Stefan> case.

I think both advantages and disadvantages are small here, but I'll take
your recommendation.

>> (defvar skeleton-position-marker-list nil "Global list of markers
>> pointing to skeleton positions.")  (make-variable-buffer-local
>> 'skeleton-position-marker-list)

Stefan> "Global" for a defvarred variable in elisp generally means
Stefan> "non-local to any buffer".

Yes, this is a typo; I have changed the code, but not the doc :-)
Thanks for spotting it.

>> (defvar skeleton-position-push-mark nil
>> "\\<skeleton-position-mode-map>\ When set, causes
>> \\[skeleton-position-next] and \\[skeleton-position-prev] \ in
>> Skeleton Position mode to push a mark at point.")

Stefan> Instead of using this state variable, you could maybe push the
Stefan> mark directly when you enter skeleton-position-mode ?

Yes, but it isn't exactly the same.  That way it would be pushed even if
users never move to any of the points.

>> (defvar skeleton-position-current nil
>> "\\<skeleton-position-mode-map>\ The last position visited by
>> \\[skeleton-position-next] or \\[skeleton-position-prev] \ in
>> Skeleton Position mode, as a pointer into
>> `skeleton-position-marker-list'.")

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> It's generally preferable to only add function symbols onto
Stefan> hooks, so it's easier to remove and so there's less/no risk of
Stefan> adding it a second time.

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.

Stefan> Maybe it's better to process skeleton-positions only when
Stefan> requested, i.e. in skeleton-position-mode (or maybe in
Stefan> skeleton-position-next if you want to do it JIT-style).

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.

Stefan> How about a less in-yuor-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.

-- 
Wer Schoenheit angeschaut mit Augen, hat dem Tode schon Anheim gegeben.
Von Platen.