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: 30 Mar 2003 10:51:56 -0800 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1049050316.532.8.camel@zircon> 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 Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1049050383 26548 80.91.224.249 (30 Mar 2003 18:53:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 30 Mar 2003 18:53:03 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Mar 30 20:53:00 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 18zhvQ-0006ta-00 for ; Sun, 30 Mar 2003 20:53:00 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18zhys-0002Z2-00 for ; Sun, 30 Mar 2003 20:56:34 +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 18zhvC-0008TB-09 for emacs-devel@quimby.gnus.org; Sun, 30 Mar 2003 13:52:46 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18zhui-0008Rr-00 for emacs-devel@gnu.org; Sun, 30 Mar 2003 13:52:16 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18zhud-0008Qw-00 for emacs-devel@gnu.org; Sun, 30 Mar 2003 13:52:14 -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 18zhuQ-0008HU-00 for emacs-devel@gnu.org; Sun, 30 Mar 2003 13:51:59 -0500 Original-Received: (qmail 52241 invoked from network); 30 Mar 2003 18:51:56 -0000 Original-Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 30 Mar 2003 18:51:56 -0000 Original-To: Stefan Monnier In-Reply-To: <1048554010.20622.66.camel@zircon> 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:12751 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12751 Since noone has responded to my e-mail, do I assume that there is no opposition to fixing the _ versus @ thing in skeleton? mmm-mode needs this fix. /Joe On Mon, 2003-03-24 at 17:00, Joe Kelsey wrote: > 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 > >