[joe@zircon.seattle.wa.us: skeleton.el _ versus @]

[joe@zircon.seattle.wa.us: skeleton.el _ versus @]

[Richard Stallman]

Does anyone know enough about skeleton.el to think intelligently
about this issue?

------- Start of forwarded message -------
Date: 23 Mar 2003 23:55:35 -0000
From: Joe Kelsey <joe@zircon.seattle.wa.us>
To: bug-gnu-emacs@gnu.org
cc: mmm-mode-discuss@lists.sourceforge.net
Subject: skeleton.el _ versus @
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

In GNU Emacs 21.2.1 (i386--freebsd, X toolkit, Xaw3d scroll bars)
 of 2002-11-08 on zircon.zircon.seattle.wa.us

skeleton.el confuses the roles of _ and @.

_ serves two purposes: mark the "interesting" skeleton-point, and mark
region-skip points, depending on whether or not the skeleton is being
inserted in a plain context, or in a "region" context.

@ serves as a "back-up" setting for skeleton-point and also to mark the
skeleton-positions.

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.

When the skeleton is used in region-list-context mode, there must be
multiple occurrences of _ to mark where the insertion code is supposed
to skip to the end of the next region.  In this case, there probably
aren't any @ markers.  The first _ can serve as skeleton-point.

If a simple skeleton is used without any _ markers, then the user hasn't
thought about where they want point to end up and it doesn't really
matter where it ends up.

I propose the following modification to skeleton.el:

- --- lisp/skeleton.el.orig	Sat Jul 14 04:21:08 2001
+++ lisp/skeleton.el	Sun Mar 23 15:28:03 2003
@@ -453,8 +453,7 @@
 	((eq element '|)
 	 (unless skeleton-modified (pop skeleton)))
 	((eq element '@)
- -	 (push (point) skeleton-positions)
- -	 (unless skeleton-point (setq skeleton-point (point))))
+	 (push (point) skeleton-positions))
 	((eq 'quote (car-safe element))
 	 (eval (nth 1 element)))
 	((or (stringp (car-safe element))

Basically, this removes the setting of skeleton-point from the @
actions.

/Joe


_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: skeleton.el _ versus @

[Stefan Monnier]

> 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 "}"

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 @).

Your suggestion would break such usage.
Could you describe concrete cases where your suggestion would
be helpful ?


	Stefan

Re: skeleton.el _ versus @

[Joe Kelsey]

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  "<script language=\"JavaScript\">" @ "\n" _ "\n" @ "</script>" @)

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

Re: skeleton.el _ versus @

[Joe Kelsey]

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  "<script language=\"JavaScript\">" @ "\n" _ "\n" @ "</script>" @)
> 
> 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
> 
> 

Re: skeleton.el _ versus @

[Stefan Monnier]

> > The current code allows the following trick:
> > 
> > 	"fun f (" @ ")" \n "{" \n _ \n "}"
> >
> > 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.

But I also want point to end up at the "args" position in simple
insertion which your patch would break.

> A multi-mode region is defined by a front-tag, the body and a back-tag. 
> Therefore skeletons look like
> 
> (nil  "<script language=\"JavaScript\">" @ "\n" _ "\n" @ "</script>" @)
> 
> 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.

There is no doubt that there are conflicting goals.  But in order
to change the current behavior, you'd have to demonstrate that your goal
is sufficiently more worthy to justify breaking existing skeletons.

Your example is rather weak in this case since the difference between
what skeleton does and what you'd like it to do is a addressed by
a mere C-f from the user after inserting the skeleton.

> 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.

I hate such modal interfaces, sorry.

As for how you could get what you want with the current skeleton,
how about something like:

 (nil  "<script language=\"JavaScript\">" @ '(setq skeleton-point nil)
       "\n" _ "\n" @ "</script>" @)


-- Stefan

Re: skeleton.el _ versus @

[Joe Kelsey]

On Mon, 2003-03-31 at 09:40, Stefan Monnier wrote:
> > > The current code allows the following trick:
> > > 
> > > 	"fun f (" @ ")" \n "{" \n _ \n "}"
> > >
> > > 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.
> 
> But I also want point to end up at the "args" position in simple
> insertion which your patch would break.

If you want the point to end at args in "simple insertion", put the _
between the parens.

Your skeleton is a "region-insertion", not a "simple insertion".

You cannot have it both ways.

> I hate such modal interfaces, sorry.

I am sorry.  Get over it.  Modal interfaces are a good thing.

I feel it is now incumbent upon you to propose an alternative patch.

/Joe

Re: skeleton.el _ versus @

[Miles Bader]

Joe Kelsey <joe@zircon.seattle.wa.us> writes:
> > I hate such modal interfaces, sorry.
> 
> I am sorry.  Get over it.  Modal interfaces are a good thing.

Maybe sometimes, but the one you suggested sucks big time.

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: skeleton.el _ versus @

[Stefan Monnier]

> > > > 	"fun f (" @ ")" \n "{" \n _ \n "}"
> > > >
> > > > 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.
> > 
> > But I also want point to end up at the "args" position in simple
> > insertion which your patch would break.
> 
> If you want the point to end at args in "simple insertion", put the _
> between the parens.

No, because region insertion won't work right.

> Your skeleton is a "region-insertion", not a "simple insertion".
> 
> You cannot have it both ways.

I do have it both ways right now.


	Stefan

Re: skeleton.el _ versus @

[Joe Kelsey]

On Mon, 2003-03-31 at 09:40, Stefan Monnier wrote:
> > > 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  "<script language=\"JavaScript\">" @ '(setq skeleton-point nil)
>        "\n" _ "\n" @ "</script>" @)

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))

It makes more sense for you since you are using @ incorrectly.

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.

/Joe

Re: skeleton.el _ versus @

[Stefan Monnier]

> > > > 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  "<script language=\"JavaScript\">" @ '(setq skeleton-point nil)
> >        "\n" _ "\n" @ "</script>" @)
> 
> 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

Re: skeleton.el _ versus @

[Joe Kelsey]

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

Re: skeleton.el _ versus @

[Thien-Thi Nguyen]

Joe Kelsey <joe@zircon.seattle.wa.us> writes:

   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?

if you ask these questions (and find the answers) before forming your belief,
perhaps your position would not need to rely so heavily on belief, and thus
(ironically) be more "believable".  please post your analysis of "cvs log
skeleton.el" output so i can learn your thought process.

thi

Re: skeleton.el _ versus @

[Stefan Monnier]

> 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.

Could ou give an real example where it "completely fails" ?
I understand that the behavior is different, but your previous
example is not very compelling since the difference is only
an "off by one" position.

> I can imagine that a solution is to have skeleton-insert examine the use
> made of @ and _ ex-post-facto.

No.  The two different situations can only be told apart by
asking the author.  In (nil "fun " str "(" @ ")" \n "{" \n _ "}"),
point should always end inside the parens.

> 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

_ indicates where to insert the region(s).

> perversion of the clear separation between _ and @.  My question is when
> was the _ @ distinction ruined by allowing @ to override the meaning of _.

In Emacs-21.1.

> Was it introduced by the original skeleton author, or was it
> inserted on-the-sly by someone else?

It was introduced by yours truly.  The reasoning behind it was
that editing generally takes place left-to-right, so point
should most naturally end up at the first interesting position.
Also it allowed to distinguish between where point should go
and where the region should go.


	Stefan

Re: skeleton.el _ versus @

[Richard Stallman]

    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))

    It makes more sense for you since you are using @ incorrectly.

    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.

If we are agreed that skeleton's behavior really ought to be different,
then it might be ok to say this to some of the users.  But I don't
think we are agreed on that.

Re: skeleton.el _ versus @

[Joe Kelsey]

On Tue, 2003-04-01 at 17:33, Stefan Monnier wrote:
> It was introduced by yours truly.  The reasoning behind it was
> that editing generally takes place left-to-right, so point
> should most naturally end up at the first interesting position.
> Also it allowed to distinguish between where point should go
> and where the region should go.

Aha!

This makes things *much* clearer to me.  You are defending your
*private* change to skeleton.el.  It is quite clear to me that
skeleton.el, prior to your *private* change, had a clear, consistent and
well-designed interface.

Somehow, you got your change accepted into the core, radically changing
the meaning of @ just because you wanted to be able to edit "left to
right".

I believe that this change to skeleton was sneaked in under the radar,
changing code which previously worked.  It is only because I cared to
probe why the default skeletons used by mmm-mode did not work, in spite
of the fact that the author is known by me to be very concientious and
would not have put these skeletons out without verifying that they
worked.

So, I can give you pointers to the mmm-mode cvs sources to show you how
the skeletons there have been unchanged since before your incompatible
change was introduced.  Therefore, your change broke existing code.  I
am sorry that I was not involved in mmm-mode when you did this, or I
would have screamed bloody murder then.

Please undo this incompatible change in skeleton.el.

Thank you.

/Joe

Re: skeleton.el _ versus @

[Miles Bader]

On Wed, Apr 02, 2003 at 04:16:05PM -0800, Joe Kelsey wrote:
> I am sorry that I was not involved in mmm-mode when you did this, or I
> would have screamed bloody murder then.

Your screaming is not helping.

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

Re: skeleton.el _ versus @

[Daniel Pfeiffer]

Joe Kelsey <joe@zircon.seattle.wa.us> skribis:
> 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.

I guess you mean me.  In the original skeleton meta-language, I didn't have
@ at all.  But since it's not something that's usually a variable name in
Emacs, adding it was no problem.

But then going and changing it incompatibly a few years later, breaking
existing skeletons is a behaviour worthy of the Bushs and Saddams of this
world!  At the very least this should be advertised to all those concerned,
and help offered in fixing the skeletons this breaks!

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- GPL 3: take the wind out of Palladium's sails! --
 ------
  -- My other stuff here too, sawfish, make.pl...: --
   ------
    -- http://dapfy.bei.t-online.de/ --

Re: skeleton.el _ versus @

[Stefan Monnier]

> But then going and changing it incompatibly a few years later, breaking
> existing skeletons is a behaviour worthy of the Bushs and Saddams of this
> world!  At the very least this should be advertised to all those concerned,
> and help offered in fixing the skeletons this breaks!

I actually did look around and didn't find any skeleton where the
change introduced problems.  Then (while pretesting 21.1) someone
pointed out a case where the new behavior was not as good
as before (the position of point after insertion was fine but
the fact that the first @ had not been put on skeleton-positions
was a problem), which I addressed (by adding the position to
skeleton-positions even when it also sets position-point).


	Stefan

Re: skeleton.el _ versus @

[Joe Kelsey]

On Wed, 2003-04-09 at 09:26, Stefan Monnier wrote:
> > But then going and changing it incompatibly a few years later, breaking
> > existing skeletons is a behaviour worthy of the Bushs and Saddams of this
> > world!  At the very least this should be advertised to all those concerned,
> > and help offered in fixing the skeletons this breaks!
> 
> I actually did look around and didn't find any skeleton where the
> change introduced problems.  Then (while pretesting 21.1) someone
> pointed out a case where the new behavior was not as good
> as before (the position of point after insertion was fine but
> the fact that the first @ had not been put on skeleton-positions
> was a problem), which I addressed (by adding the position to
> skeleton-positions even when it also sets position-point).

These are all very weak excuses.  The fact is, you *broke it* in an
incompatible way.

If you want this behavior, fork out skeleton.el from the distribution
and install it as a personal package.

The only reason you couldn't find skeletons which broke is beacuse you
did not look farther than the core sources.  If you had been an mmm-mode
user, you would have noticed the bad behavior immediately.

I formally request atht this bad change be withdrawn from the sources. 
Stefan can install his own personal version on his own personal machine.

/Joe

Re: skeleton.el _ versus @

[Richard Stallman]

    The only reason you couldn't find skeletons which broke is beacuse you
    did not look farther than the core sources.  If you had been an mmm-mode
    user, you would have noticed the bad behavior immediately.

When was this change installed?  I seem to recall it was several years ago
already.

Re: skeleton.el _ versus @

[Joe Kelsey]

On Thu, 2003-04-10 at 15:47, Richard Stallman wrote:
>     The only reason you couldn't find skeletons which broke is beacuse you
>     did not look farther than the core sources.  If you had been an mmm-mode
>     user, you would have noticed the bad behavior immediately.
> 
> When was this change installed?  I seem to recall it was several years ago
> already.

According to Stefan, he put it in Emacs 21.1.

/Joe

Re: skeleton.el _ versus @

[Richard Stallman]

    According to Stefan, he put it in Emacs 21.1.

That isn't too long ago, so I don't think it isn't too late
to change this back.

Stefan, could you give me a brief self-contained description of the
two behaviors, written for someone who doesn't use skeleton?

Re: skeleton.el _ versus @

[Stefan Monnier]

>     According to Stefan, he put it in Emacs 21.1.
> 
> That isn't too long ago, so I don't think it isn't too late
> to change this back.
> 
> Stefan, could you give me a brief self-contained description of the
> two behaviors, written for someone who doesn't use skeleton?

A simple skeleton could look like

       ... "(" _ ")" ...

If a region is active when executing the skeleton, it will end
up wrapping the region in parentheses. Otherwise, it will insert
"()" and point point in the middle.

Skeleton also has a special @ which pushes the corresponding position
onto a list of positions which elisp code can then use as it
sees fit (I don't actually know of any uses, so I'll let other
people describe what these are might be used for).

Before my patch, the behavior was that after insertion of
a skeleton, point would be placed at "the first occurrence of _
or at the end of the skeleton".

What my patch changed is that point after insertion of a skeleton
is now placed at "the first occurrence of _ or @
or at the end of the skeleton".


	Stefan

Re: skeleton.el _ versus @

[Joe Kelsey]

On Fri, 2003-04-11 at 16:59, Stefan Monnier wrote:
> >     According to Stefan, he put it in Emacs 21.1.
> > 
> > That isn't too long ago, so I don't think it isn't too late
> > to change this back.
> > 
> > Stefan, could you give me a brief self-contained description of the
> > two behaviors, written for someone who doesn't use skeleton?
> 
> A simple skeleton could look like
> 
>        ... "(" _ ")" ...
> 
> If a region is active when executing the skeleton, it will end
> up wrapping the region in parentheses. Otherwise, it will insert
> "()" and point point in the middle.
> 
> Skeleton also has a special @ which pushes the corresponding position
> onto a list of positions which elisp code can then use as it
> sees fit (I don't actually know of any uses, so I'll let other
> people describe what these are might be used for).

mmm-mode uses @ in skeletons to mark special positions around the
skeleton for use afterwards.  An mmm-mode skeleton looks like

... @ "front-tag" @ "other stuff" _ "other stuff" @ back tag" @

mmm-mode expects point to end up at the _.  Simply because Stefan could
not imagine what @ was used for, he discarded its behavior and ruined
all of the existing mmm-mode skeletons.


> Before my patch, the behavior was that after insertion of
> a skeleton, point would be placed at "the first occurrence of _
> or at the end of the skeleton".
> 
> What my patch changed is that point after insertion of a skeleton
> is now placed at "the first occurrence of _ or @
> or at the end of the skeleton".
> 
> 
> 	Stefan
> 

Re: skeleton.el _ versus @

[Kai Großjohann]

Joe Kelsey <joe@zircon.seattle.wa.us> writes:

> mmm-mode uses @ in skeletons to mark special positions around the
> skeleton for use afterwards.  An mmm-mode skeleton looks like
>
> ... @ "front-tag" @ "other stuff" _ "other stuff" @ back tag" @
>
> mmm-mode expects point to end up at the _.  Simply because Stefan could
> not imagine what @ was used for, he discarded its behavior and ruined
> all of the existing mmm-mode skeletons.

It may be useful to describe how does mmm-mode use the @ positions.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: skeleton.el _ versus @

[Richard Stallman]

    Before my patch, the behavior was that after insertion of
    a skeleton, point would be placed at "the first occurrence of _
    or at the end of the skeleton".

    What my patch changed is that point after insertion of a skeleton
    is now placed at "the first occurrence of _ or @
    or at the end of the skeleton".

Couldn't you get the same result with the old code
by writing @ _?

Re: skeleton.el _ versus @

[Stefan Monnier]

>     Before my patch, the behavior was that after insertion of
>     a skeleton, point would be placed at "the first occurrence of _
>     or at the end of the skeleton".
> 
>     What my patch changed is that point after insertion of a skeleton
>     is now placed at "the first occurrence of _ or @
>     or at the end of the skeleton".
> 
> Couldn't you get the same result with the old code
> by writing @ _?

That changes the place where the region is inserted
if the region is active when the skeleton is executed.


	Stefan

Re: skeleton.el _ versus @

[Kai Großjohann]

I've been following this discussion, and it seems that the following
features are needed:

* Specify that point goes to a spot that's not the first important
  spot.

* Specify two different locations for point and the region to go.

Let's say that _ says where the region goes, and @ defines
interesting spots.  Then define a new character (: perhaps) that
specifies where point goes.  If : is not present, point could go to
some other spot that is consistent with the old behavior.

That would make Stefan and Joe happy, I hope.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: skeleton.el _ versus @

[Joe Kelsey]

On Sun, 2003-04-13 at 04:23, Richard Stallman wrote:
>     Before my patch, the behavior was that after insertion of
>     a skeleton, point would be placed at "the first occurrence of _
>     or at the end of the skeleton".
> 
>     What my patch changed is that point after insertion of a skeleton
>     is now placed at "the first occurrence of _ or @
>     or at the end of the skeleton".
> 
> Couldn't you get the same result with the old code
> by writing @ _?

The real solution is to create a new character which has the semantice
"set skeleton-point like _ but don't interact with regions".  This can
easily be accomplished by using - or : (for instance) instead of
corrupting the @ semantics.

/Joe

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

[Joe Kelsey]

On Sun, 2003-04-13 at 04:23, Richard Stallman wrote:
>     Before my patch, the behavior was that after insertion of
>     a skeleton, point would be placed at "the first occurrence of _
>     or at the end of the skeleton".
> 
>     What my patch changed is that point after insertion of a skeleton
>     is now placed at "the first occurrence of _ or @
>     or at the end of the skeleton".
> 
> 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.  This means that @ is completely unaffected and
remains as just the method of setting the skeleton-positions.

--- skeleton.el.orig    Sat Jul 14 04:21:08 2001
+++ skeleton.el Sun Apr 20 15:44:44 2003
@@ -453,7 +453,8 @@
        ((eq element '|)
         (unless skeleton-modified (pop skeleton)))
        ((eq element '@)
-        (push (point) skeleton-positions)
+        (push (point) skeleton-positions))
+       ((eq element '-)
         (unless skeleton-point (setq skeleton-point (point))))
        ((eq 'quote (car-safe element))
         (eval (nth 1 element)))

This allows Stefan to have a character to use for marking skeleton-point
without wrapping the skeleton around the point.  It also allows mmm-mode
to continue to use both @ and _ in their skeletons without suffering
under the undesired semantics of the modified meaning of @ introduced by
Stefan's patch.  I hope that this solves the issue for everyone.

/Joe

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

[Stefan Monnier]

> 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.  This means that @ is completely unaffected and
> remains as just the method of setting the skeleton-positions.
> 
> --- skeleton.el.orig    Sat Jul 14 04:21:08 2001
> +++ skeleton.el Sun Apr 20 15:44:44 2003
> @@ -453,7 +453,8 @@
>         ((eq element '|)
>          (unless skeleton-modified (pop skeleton)))
>         ((eq element '@)
> -        (push (point) skeleton-positions)
> +        (push (point) skeleton-positions))
> +       ((eq element '-)
>          (unless skeleton-point (setq skeleton-point (point))))
>         ((eq 'quote (car-safe element))
>          (eval (nth 1 element)))

I think in that case, we should set skeleton-point unconditionally.


	Stefan

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

[Joe Kelsey]

On Mon, 2003-04-21 at 06:11, Stefan Monnier wrote:
> > 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.  This means that @ is completely unaffected and
> > remains as just the method of setting the skeleton-positions.
> > 
> > --- skeleton.el.orig    Sat Jul 14 04:21:08 2001
> > +++ skeleton.el Sun Apr 20 15:44:44 2003
> > @@ -453,7 +453,8 @@
> >         ((eq element '|)
> >          (unless skeleton-modified (pop skeleton)))
> >         ((eq element '@)
> > -        (push (point) skeleton-positions)
> > +        (push (point) skeleton-positions))
> > +       ((eq element '-)
> >          (unless skeleton-point (setq skeleton-point (point))))
> >         ((eq 'quote (car-safe element))
> >          (eval (nth 1 element)))
> 
> I think in that case, we should set skeleton-point unconditionally.

You *really* only want to set it on the first occurrence of the
appropriate character, not the last!

/Joe

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

[Richard Stallman]

    > 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?

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.

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

[Joe Kelsey]

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
skeleton-positions.

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?

/Joe

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

[Stefan Monnier]

> > > 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.  This means that @ is completely unaffected and
> > > remains as just the method of setting the skeleton-positions.
> > > 
> > > --- skeleton.el.orig    Sat Jul 14 04:21:08 2001
> > > +++ skeleton.el Sun Apr 20 15:44:44 2003
> > > @@ -453,7 +453,8 @@
> > >         ((eq element '|)
> > >          (unless skeleton-modified (pop skeleton)))
> > >         ((eq element '@)
> > > -        (push (point) skeleton-positions)
> > > +        (push (point) skeleton-positions))
> > > +       ((eq element '-)
> > >          (unless skeleton-point (setq skeleton-point (point))))
> > >         ((eq 'quote (car-safe element))
> > >          (eval (nth 1 element)))
> > 
> > I think in that case, we should set skeleton-point unconditionally.
> 
> You *really* only want to set it on the first occurrence of the
> appropriate character, not the last!

I don't see why anyone would want to put more than 1 such operator
in a skeleton anyway.  So reason why I want to make it unconditional
is so that you can do (nil "do {" \n _ \n "} while (" - ")") and be
sure that point will always end up between the parens (I wouldn't
want this behavior, personally, but given such a skeleton why would
the author have put the `-' if it's not to specify where to place
point).


	Stefan

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

[Joe Kelsey]

On Tue, 2003-04-22 at 06:31, Stefan Monnier wrote:
> > > > 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.  This means that @ is completely unaffected and
> > > > remains as just the method of setting the skeleton-positions.
> > > > 
> > > > --- skeleton.el.orig    Sat Jul 14 04:21:08 2001
> > > > +++ skeleton.el Sun Apr 20 15:44:44 2003
> > > > @@ -453,7 +453,8 @@
> > > >         ((eq element '|)
> > > >          (unless skeleton-modified (pop skeleton)))
> > > >         ((eq element '@)
> > > > -        (push (point) skeleton-positions)
> > > > +        (push (point) skeleton-positions))
> > > > +       ((eq element '-)
> > > >          (unless skeleton-point (setq skeleton-point (point))))
> > > >         ((eq 'quote (car-safe element))
> > > >          (eval (nth 1 element)))
> > > 
> > > I think in that case, we should set skeleton-point unconditionally.
> > 
> > You *really* only want to set it on the first occurrence of the
> > appropriate character, not the last!
> 
> I don't see why anyone would want to put more than 1 such operator
> in a skeleton anyway.  So reason why I want to make it unconditional
> is so that you can do (nil "do {" \n _ \n "} while (" - ")") and be
> sure that point will always end up between the parens (I wouldn't
> want this behavior, personally, but given such a skeleton why would
> the author have put the `-' if it's not to specify where to place
> point).

I now understand.

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

[Richard Stallman]

    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?)

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

[Joe Kelsey]

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

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

[Richard Stallman]

    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.

In that case I see no harm in this change.  Stephan, would you like
to install it?

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

[Stefan Monnier]

>     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.
> 
> In that case I see no harm in this change.  Stephan, would you like
> to install it?

I'm kind of away right now, so if someone else can do it, that would be best.


	Stefan

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

[Richard Stallman]

Could you send me the proper change, with change log entry and NEWS entry?
I will get it installed.

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

[Joe Kelsey]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

On Tue, 2003-04-29 at 12:29, Richard Stallman wrote:
> Could you send me the proper change, with change log entry and NEWS entry?
> I will get it installed.

Here is a diff for lisp/skeleton.el and a ChangeLog entry.

/Joe


[-- Attachment #2: skeleton.el.diff --]
[-- Type: text/plain, Size: 2217 bytes --]

--- skeleton.el.orig	Sat Jul 14 04:21:08 2001
+++ skeleton.el	Wed May  7 08:56:30 2003
@@ -262,6 +262,8 @@
 
 	\\n	go to next line and indent according to mode
 	_	interesting point, interregion here
+	-	interesting point, no interregion interaction, overrides
+		interesting point set by _
 	>	indent line (or interregion if > _) according to major mode
 	@	add position to `skeleton-positions'
 	&	do next ELEMENT iff previous moved point
@@ -270,8 +272,8 @@
 	resume:	skipped, continue here if quit is signaled
 	nil	skipped
 
-After termination, point will be positioned at the first occurrence
-of _ or @ or at the end of the inserted text.
+After termination, point will be positioned at the last occurrence of -
+or at the first occurrence of _ or at the end of the inserted text.
 
 Further elements can be defined via `skeleton-further-elements'.  ELEMENT may
 itself be a SKELETON with an INTERACTOR.  The user is prompted repeatedly for
@@ -295,6 +297,13 @@
 	input	initial input (string or cons with index) while reading str
 	v1, v2	local variables for memorizing anything you want
 
+Note that the internal skeleton processing modifies the first occurrence
+of str in each skeleton into a lisp form to set str to the value of
+`skeleton-read' called with the first skeleton list element.  Thus, if
+you intend to use the value of str in a complex lisp expression, it is
+best to simply inert the value first and then use it in a quoted lisp
+expression or one which returns nil (as in (progn (blah...) nil) )..
+
 When done with skeleton, but before going back to `_'-point call
 `skeleton-end-hook' if that is non-`nil'."
   (let ((skeleton-regions regions))
@@ -448,13 +457,14 @@
 		    (end-of-line 0)))
 	   (or skeleton-point
 	       (setq skeleton-point (point)))))
+	((eq element '-)
+	 (setq skeleton-point (point)))
 	((eq element '&)
 	 (when skeleton-modified (pop skeleton)))
 	((eq element '|)
 	 (unless skeleton-modified (pop skeleton)))
 	((eq element '@)
-	 (push (point) skeleton-positions)
-	 (unless skeleton-point (setq skeleton-point (point))))
+	 (push (point) skeleton-positions))
 	((eq 'quote (car-safe element))
 	 (eval (nth 1 element)))
 	((or (stringp (car-safe element))

[-- Attachment #3: ChangeLog --]
[-- Type: text/plain, Size: 185 bytes --]

2003-05-07  Joe Kelsey  <joek@flyingcroc.net>

	* skeleton.el (skeleton-internal-1): Allow - as alternate
	interesting point marker and revert @ to just setting
	skeleton-positions.
	


[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel