From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: skeleton.el _ versus @ Date: Mon, 31 Mar 2003 12:40:35 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200303311740.h2VHeZNG017518@rum.cs.yale.edu> References: <200303242005.h2OK57gr013285@rum.cs.yale.edu> <1048554010.20622.66.camel@zircon> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1049132748 31543 80.91.224.249 (31 Mar 2003 17:45:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 31 Mar 2003 17:45:48 +0000 (UTC) Cc: Stefan Monnier Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Mar 31 19:45:45 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1903Ls-0008C4-00 for ; Mon, 31 Mar 2003 19:45:44 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 1903M5-00076b-00 for ; Mon, 31 Mar 2003 19:45:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 1903KL-0007ix-03 for emacs-devel@quimby.gnus.org; Mon, 31 Mar 2003 12:44:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 1903K0-0007eH-00 for emacs-devel@gnu.org; Mon, 31 Mar 2003 12:43:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 1903Jy-0007dR-00 for emacs-devel@gnu.org; Mon, 31 Mar 2003 12:43:47 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10.13) id 1903Gz-0006El-00; Mon, 31 Mar 2003 12:40:42 -0500 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h2VHebPe017520; Mon, 31 Mar 2003 12:40:37 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h2VHeZNG017518; Mon, 31 Mar 2003 12:40:35 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Joe Kelsey Original-cc: occitan@esperanto.org Original-cc: Richard Stallman Original-cc: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12769 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12769 > > The current code allows the following trick: > > > > "fun f (" @ ")" \n "{" \n _ \n "}" > > > > such that selecting a region and calling the skeleton will > > put the region in the body of the function (because of the _) > > and point will be put at the right place for you to enter the > > arglist (because of the @). > > This is using skeletons in "region" mode. I am not changing region > mode, or at least I can modify the @ behavior so that it works in region > mode this way. But I also want point to end up at the "args" position in simple insertion which your patch would break. > A multi-mode region is defined by a front-tag, the body and a back-tag. > Therefore skeletons look like > > (nil "" @) > > where the @'s mark the front-tag and back-tag begin and end points and > the _ marks the position of the point after insertion so that you can > begin editing there. > > However, I can imagine using an mmm-mode skeleton in region mode where I > want to wrap the front-tag and back-tag around some existing text. In > that case, *I* want the point to end up at the beginning of the region, > i.e., at the _ and *not* at the @. This is clearly a case of > conflicting goals. There is no doubt that there are conflicting goals. But in order to change the current behavior, you'd have to demonstrate that your goal is sufficiently more worthy to justify breaking existing skeletons. Your example is rather weak in this case since the difference between what skeleton does and what you'd like it to do is a addressed by a mere C-f from the user after inserting the skeleton. > A better skeleton for your purposes would be one which prompted the user > for each of the function arguments using the recursive prompting mode of > skeleton input. I hate such modal interfaces, sorry. As for how you could get what you want with the current skeleton, how about something like: (nil "" @) -- Stefan