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 @, a new patch Date: 24 Apr 2003 08:59:53 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1051199987.572.9.camel@zircon> References: <200303242005.h2OK57gr013285@rum.cs.yale.edu> <1048554010.20622.66.camel@zircon> <200303311740.h2VHeZNG017518@rum.cs.yale.edu> <1049242082.66437.15.camel@zircon> <200304020020.h320K4de023432@rum.cs.yale.edu> <1049245381.66437.33.camel@zircon> <20030403084549.2a5aca76.occitan@esperanto.org> <200304091626.h39GQlwc000430@rum.cs.yale.edu> <1050020736.419.11.camel@zircon> <200304112359.h3BNxpw5012335@rum.cs.yale.edu> <1050879051.74664.17.camel@zircon><1050975058.74664.30.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 1051200816 28301 80.91.224.249 (24 Apr 2003 16:13:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 24 Apr 2003 16:13:36 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 24 18:13:34 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 198jJz-000791-00 for ; Thu, 24 Apr 2003 18:11:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 198jQH-0006FU-00 for ; Thu, 24 Apr 2003 18:18:09 +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 198jHg-0000Cp-04 for emacs-devel@quimby.gnus.org; Thu, 24 Apr 2003 12:09:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 198jHQ-0000CS-00 for emacs-devel@gnu.org; Thu, 24 Apr 2003 12:09:00 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 198j8r-0006v2-00 for emacs-devel@gnu.org; Thu, 24 Apr 2003 12:00:09 -0400 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 198j8f-0006kT-00 for emacs-devel@gnu.org; Thu, 24 Apr 2003 11:59:58 -0400 Original-Received: (qmail 669 invoked from network); 24 Apr 2003 15:59:53 -0000 Original-Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 24 Apr 2003 15:59:53 -0000 Original-To: rms@gnu.org In-Reply-To: X-Mailer: Ximian Evolution 1.2.4 Original-cc: dapfy@t-online.de 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:13432 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13432 On Wed, 2003-04-23 at 18:50, Richard Stallman wrote: > The behavior I propose adds a new character whose only purpose is to > provide an alternate method to set skeleton-point without interacting > with regions at all. Therefore, the proposal I have made will set > skeleton-point to the first occurrence of either - or _ while preserving > the original semantics of both @ and _ otherwise. > > It seems logical. Are there skeletons that use - that might break > with this change? (Is it meaningful to use - in a skeleton now? Is > that an error?) A skeleton is basically a list. Each element of the list is either a string, a piece of lisp code, a sub-skeleton list or something to be reinterpreted by skeleton-internal-1, basically anything that lisp allows as a list member. The only reason a bare - would occur in an existing skeleton is if someone was using it as a variable name for some obscure purpoose. It is quite unlikely that any existing skeleton has any bare -'s, the only use would be as parts of strings or character constants using the usual lisp syntax for such. /Joe