From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ian Zimmerman Newsgroups: gmane.emacs.help Subject: Re: Browse skeleton positions Date: 18 Oct 2003 10:58:19 -0700 Organization: http://extra.newsguy.com Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <877k32jumc.fsf@newsguy.com> References: <87vfqnygi7.fsf@newsguy.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1066501916 5255 80.91.224.253 (18 Oct 2003 18:31:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2003 18:31:56 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Oct 18 20:31:54 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AAvrm-0001Bb-00 for ; Sat, 18 Oct 2003 20:31:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AAvqf-0004T2-IP for geh-help-gnu-emacs@m.gmane.org; Sat, 18 Oct 2003 14:30:45 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!newsfeed.berkeley.edu!ucberkeley!cyclone-sf.pbi.net!129.250.175.17!pln-w!spln!dex!extra.newsguy.com!newsp.newsguy.com!enews1 Original-Newsgroups: gnu.emacs.help Original-Lines: 85 Original-NNTP-Posting-Host: p-153.newsdawg.com User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Original-Xref: shelby.stanford.edu gnu.emacs.help:117397 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:13328 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13328 >> (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 >> "\\\ 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 >> "\\\ 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.