From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Joe Kelsey Newsgroups: gmane.emacs.devel Subject: Re: skeleton.el _ versus @ Date: 24 Mar 2003 17:00:11 -0800 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1048554010.20622.66.camel@zircon> References: <200303242005.h2OK57gr013285@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1048554279 14694 80.91.224.249 (25 Mar 2003 01:04:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 25 Mar 2003 01:04:39 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 25 02:04:37 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 18xcrl-0003os-00 for ; Tue, 25 Mar 2003 02:04:37 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18xcsU-0006pV-00 for ; Tue, 25 Mar 2003 02:05:22 +0100 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 18xcqD-0006EZ-04 for emacs-devel@quimby.gnus.org; Mon, 24 Mar 2003 20:03:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18xcpN-0005cZ-00 for emacs-devel@gnu.org; Mon, 24 Mar 2003 20:02:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18xcoi-00055h-00 for emacs-devel@gnu.org; Mon, 24 Mar 2003 20:01:30 -0500 Original-Received: from dsl231-043-165.sea1.dsl.speakeasy.net ([216.231.43.165] helo=zircon.seattle.wa.us) by monty-python.gnu.org with smtp (Exim 4.10.13) id 18xcnW-0004c1-00 for emacs-devel@gnu.org; Mon, 24 Mar 2003 20:00:14 -0500 Original-Received: (qmail 35051 invoked from network); 25 Mar 2003 01:00:11 -0000 Original-Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 25 Mar 2003 01:00:11 -0000 Original-To: Stefan Monnier In-Reply-To: <200303242005.h2OK57gr013285@rum.cs.yale.edu> X-Mailer: Ximian Evolution 1.2.2 Original-cc: Richard Stallman Original-cc: occitan@esperanto.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:12588 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12588 On Mon, 2003-03-24 at 12:05, Stefan Monnier wrote: > > My contention is that the use of @ as a backup to _ in setting > > skeleton-point is incorrect. When a skeleton contains both @ and _ > > markers, obviously the _ should be used to set the skeleton-point and > > the @ should be used to set skeleton-positions when the skeleton is used > > in simple insertion mode. > > The current code allows the following trick: > > "fun f (" @ ")" \n "{" \n _ \n "}" The actual skeleton you wanted is (nil "fun f (" @ ")" \n "{" \n _ \n "}") You did not include the INTERACTOR. > 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. > Your suggestion would break such usage. > Could you describe concrete cases where your suggestion would > be helpful ? mmm-mode uses skeletons to insert multi-mode regions. A multi-mode region is, for example, a section of Javascript embedded in an .html page. mmm-mode allows dynamic switching between html-mode and c++-mode depending on the position of the point. 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. 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. Consider this skeleton: ("function name: " "fun " str " (" (read-string "first argument: ") ( "next argument: " "," \n > str) resume: ")" \n "{" \n _ \n "}") It prompts for the funstion name, then reads the first argument, then enters a subskeleton prompting for each successive argument. When you type ^G to the subskeleton, it proceeds to resume:, finishing the argument list and the function wrapper. Of course, some work is left to be done to get the indentation right... My transformation of your skeleton removes the need for @ to substitute for _. I think that maybe skeleton.el could do with some examples. There are a lot of complex examples in progmodes/sh-script.el for people to look at. /Joe