[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Browse skeleton positions
From: |
Ian Zimmerman |
Subject: |
Re: Browse skeleton positions |
Date: |
18 Oct 2003 10:58:19 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>> (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.