[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: skeleton.el _ versus @, a new patch

From: Joe Kelsey
Subject: Re: skeleton.el _ versus @, a new patch
Date: 21 Apr 2003 18:30:58 -0700

On Mon, 2003-04-21 at 17:45, Richard Stallman wrote:
>     > Couldn't you get the same result with the old code
>     > by writing @ _?
>     Here is a patch to add - as an alternate skeleton character.  - operates
>     exactly as _ in setting skeleton-point, but does not interact with the
>     region wrapping effects.
> I don't want to say this is a bad idea, but before we consider it,
> could you possibly tell me the answer to my question?  Is @ in the new
> behavior equivalent to @ _ with the old behavior of @?  If not, could
> someone tell me why not?

The original behavior of @, as coded by Daniel Pfeiffer, was to *only*
set skeleton positions.  The original behavior of _ was twofold: one, to
set skeleton-point (the first occurrence of _ sets skeleton-point), and
two to mark positions for wrapping the skeleton around regions popped
off a stack (actually, the normal region markers).

Stefan added a second behavior for @, to have the first occurrence of
either @ or _ set skeleton-point, the position point goes to after
skeleton insertion.  This new behavior for @ broke the semantics for
skeletons which use _ to set skeleton-point and @ to only set

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.

> Perhaps the "region wrapping effects" make them different--if so, that
> might explain how your answer relates to my question--but I don't know
> if that is true.

The issue Stefan wanted to address was the ability to set skeleton-point
without interacting with the region effects.  Unfortunately, his change
broke the original semantics of @.  It could be argued that it also
broke the original semantics of _, but it is apparantly a benign issue
since _ started with multiple uses and continues with multiple uses
under the new system.  Instead of overloading @ with a new use, we
simply add a new character to take the role Stefan wanted to put on @.

Is this clear enough?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]