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: 01 Apr 2003 17:03:02 -0800 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1049245381.66437.33.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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1049245559 25748 80.91.224.249 (2 Apr 2003 01:05:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 2 Apr 2003 01:05:59 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Apr 02 03:05:58 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 190WhS-0006hA-00 for ; Wed, 02 Apr 2003 03:05:58 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 190WiI-0000JN-00 for ; Wed, 02 Apr 2003 03:06:50 +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 190Wg2-00064P-00 for emacs-devel@quimby.gnus.org; Tue, 01 Apr 2003 20:04:30 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 190Wf8-0005En-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 20:03:34 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 190Wf0-0004t3-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 20:03:28 -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 190Wed-0003gL-00 for emacs-devel@gnu.org; Tue, 01 Apr 2003 20:03:03 -0500 Original-Received: (qmail 69731 invoked from network); 2 Apr 2003 01:03:02 -0000 Original-Received: from localhost (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; 2 Apr 2003 01:03:02 -0000 Original-To: Stefan Monnier In-Reply-To: <200304020020.h320K4de023432@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:12821 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12821 On Tue, 2003-04-01 at 16:20, Stefan Monnier wrote: > 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 ? It seems clear to me that the "backing-up" of _ with @ was an ill-conceived back-of-the-hand programming insertion to solve someone's region-mode problem. It clearly was ill-thought out because it completely fails in normal insertion mode when you mix @ and _, as mmm-mode does. I believe that there was no reason to add this behavior which mixes two incompatible concepts. I believe that the fix for this bad design implemented by bad programming has to come from outside of the current design. As you say, someone has to give in. I personally have never thought of a reason to use the region-mode of sekeltons. mmm-mode makes very good use of the @'s to mark positions and expects that _ marks skeleton-point. It is very surprising when skeleton ignores the naive use of @ and _. I can imagine that a solution is to have skeleton-insert examine the use made of @ and _ ex-post-facto. I believe that _ should *always* be preferred over @ because there is no other use for _ in simple insertions, so in a simple insertion, _ should *always* win. In region-insertions, there is a hazy preference for @ winning, but I cannot imagine any real preference accruing to what I believe is a mis-use of @ to solve something that the original designer of skeletons clearly considered an after-thought. When you look at the design of skeleton-mode, _ is clearly the preferred way to set skeleton-point. I really just cannot see how to justify completely abandoning the meaning of _ in any situation at all. I can see no justification for the programming/design error introduced by the perversion of the clear separation between _ and @. My question is when was the _ @ distinction ruined by allowing @ to override the meaning of _. Was it introduced by the original skeleton author, or was it inserted on-the-sly by someone else? What does the cvs history say, or is it even recorded in the cvs history? /Joe