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: Sun, 19 Oct 2003 23:36:08 GMT Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <87vfqnygi7.fsf@newsguy.com> <877k32jumc.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 1066607188 28142 80.91.224.253 (19 Oct 2003 23:46:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Oct 2003 23:46:28 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Oct 20 01:46:26 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 1ABNFi-00019U-00 for ; Mon, 20 Oct 2003 01:46:26 +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 1ABNFI-0003W8-3h for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Oct 2003 19:46:00 -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.help Original-Lines: 48 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 1066606568 132.204.24.42 (Sun, 19 Oct 2003 19:36:08 EDT) Original-NNTP-Posting-Date: Sun, 19 Oct 2003 19:36:08 EDT Original-Xref: shelby.stanford.edu gnu.emacs.help:117424 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:13355 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13355 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. Darn! 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. Stefan