From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Browse skeleton positions Date: Fri, 17 Oct 2003 20:42:14 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: 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 1066423651 26079 80.91.224.253 (17 Oct 2003 20:47:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 17 Oct 2003 20:47:31 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Oct 17 22:47:29 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 1AAbVR-0005z5-00 for ; Fri, 17 Oct 2003 22:47:29 +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 1AAbTy-00075S-FU for geh-help-gnu-emacs@m.gmane.org; Fri, 17 Oct 2003 16:45:58 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!cyclone.bc.net!snoopy.risq.qc.ca!charlie.risq.qc.ca!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.sources,gnu.emacs.help Original-Followup-To: gnu.emacs.help Original-Lines: 70 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-NNTP-Posting-Host: 132.204.24.42 Original-X-Complaints-To: abuse@umontreal.ca Original-X-Trace: charlie.risq.qc.ca 1066423334 132.204.24.42 (Fri, 17 Oct 2003 16:42:14 EDT) Original-NNTP-Posting-Date: Fri, 17 Oct 2003 16:42:14 EDT Original-Xref: shelby.stanford.edu gnu.emacs.sources:9749 gnu.emacs.help:117383 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:13313 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13313 > (define-key kmap [ return ] 'skeleton-position-exit) Please use [?\C-m] (or "\C-m"), unless you really mean that this binding should not work in a tty. > (defsubst turn-on-skeleton-position-mode () I recommend you use `defun' here, since it's unlikely that the advantages of defsubst will outweigh its disadvantages in this case. > (defvar skeleton-position-marker-list nil > "Global list of markers pointing to skeleton positions.") > (make-variable-buffer-local 'skeleton-position-marker-list) "Global" for a defvarred variable in elisp generally means "non-local to any buffer". > (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.") Instead of using this state variable, you could maybe push the mark directly when you enter skeleton-position-mode ? > (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'.") Maybe it would be better to just use (point) instead, and when you do `next' or `prev', go through the list looking for the nearest marker in the requested direction ? > (unless (featurep 'skelposn) > (add-hook 'skeleton-end-hook > (lambda () > (setq skeleton-position-marker-list > (append > (nreverse > (mapcar > (lambda (p) (set-marker (make-marker) p)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 'copy-marker > skeleton-positions)) > skeleton-position-marker-list)) > (when (and skeleton-position-marker-list > (null skeleton-position-current)) > (setq skeleton-position-push-mark t)))) It's generally preferable to only add function symbols onto hooks, so it's easier to remove and so there's less/no risk of adding it a second time. As for the behavior, the above has the nasty side effect that just loading "skelposn" into your Emacs will cause all your skeleton positions to accumulate in the form of markers (at least until you finally call skeleton-position-exit which will likely be never if you don't actually use skelposn). This can lead to a significant slowdown because of the way markers are implemented. Maybe it's better to process skeleton-positions only when requested, i.e. in skeleton-position-mode (or maybe in skeleton-position-next if you want to do it JIT-style). How about a less in-yuor-face mode that lets you edit the text at the same time as you navigate between the different markers ? Stefan