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: Tue, 01 Apr 2003 19:20:04 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200304020020.h320K4de023432@rum.cs.yale.edu> References: <200303242005.h2OK57gr013285@rum.cs.yale.edu> <1048554010.20622.66.camel@zircon> <200303311740.h2VHeZNG017518@rum.cs.yale.edu> <1049242082.66437.15.camel@zircon> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1049243596 18362 80.91.224.249 (2 Apr 2003 00:33:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 2 Apr 2003 00:33:16 +0000 (UTC) Cc: Stefan Monnier Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 02 02:33:14 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 190WBm-0004m2-00 for ; Wed, 02 Apr 2003 02:33:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 190WCc-0008S4-00 for ; Wed, 02 Apr 2003 02:34:06 +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 190WBs-0004yV-00 for emacs-devel@quimby.gnus.org; Tue, 01 Apr 2003 19:33:20 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 190W3X-0007X0-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 19:24:43 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 190W2P-0005hD-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 19:23:42 -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 190Vz5-0003gJ-00; Tue, 01 Apr 2003 19:20:08 -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 h320K4x6023434; Tue, 1 Apr 2003 19:20:04 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h320K4de023432; Tue, 1 Apr 2003 19:20:04 -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:12820 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12820 > > > > The current code allows the following trick: > > > > > > > > "fun f (" @ ")" \n "{" \n _ \n "}" > > > As for how you could get what you want with the current skeleton, > > how about something like: > > > > (nil "" @) > > I believe that the correct fix is for *you* to change *your* skeletons > to be: > > (nil "fun f (" @ ")" \n "{" \n _ "}" > (setq skeleton-point (pop skeleton-positions)) I don't understand why you get so worked up about it. Having hacked on skeleton.el and used it, I know how to get it to do what I want. Just because changing the behavior to what you want doesn't prevent me from getting the behavior I was looking for, doesn't mean that your behavior is preferable. Obviously both your suggested behavior and the current one are acceptable and have their own pros and cons. I have admittedly a slight preference for the current behavior since I've taken advantage of it, but my main objection to your change is that it will break existing skeletons without providing a clearly superior behavior. > It makes more sense for you since you are using @ incorrectly. I see no evidence that it's incorrect usage. As a matter of fact, it is correct w.r.t the current code. > Simply because you have taken advantage of a programming error in the > past does not mean you can continue to do so in the future. That's interesting: what makes you think it was a programming error ? Stefan