From: Joe Kelsey <joe@zircon.seattle.wa.us>
Cc: emacs-devel@gnu.org
Subject: Re: skeleton.el _ versus @
Date: 30 Mar 2003 10:51:56 -0800 [thread overview]
Message-ID: <1049050316.532.8.camel@zircon> (raw)
In-Reply-To: <1048554010.20622.66.camel@zircon>
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
>
>
next prev parent reply other threads:[~2003-03-30 18:51 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-24 19:27 [joe@zircon.seattle.wa.us: skeleton.el _ versus @] Richard Stallman
2003-03-24 20:05 ` skeleton.el _ versus @ Stefan Monnier
2003-03-25 1:00 ` Joe Kelsey
2003-03-30 18:51 ` Joe Kelsey [this message]
2003-03-31 17:40 ` Stefan Monnier
2003-04-01 1:58 ` Joe Kelsey
2003-04-01 7:25 ` Miles Bader
2003-04-01 18:41 ` Stefan Monnier
2003-04-02 0:08 ` Joe Kelsey
2003-04-02 0:20 ` Stefan Monnier
2003-04-02 1:03 ` Joe Kelsey
2003-04-02 1:17 ` Thien-Thi Nguyen
2003-04-02 1:33 ` Stefan Monnier
2003-04-03 0:16 ` Joe Kelsey
2003-04-03 0:28 ` Miles Bader
2003-04-03 6:45 ` Daniel Pfeiffer
2003-04-09 16:26 ` Stefan Monnier
2003-04-10 0:00 ` Joe Kelsey
2003-04-10 22:47 ` Richard Stallman
2003-04-11 0:25 ` Joe Kelsey
2003-04-11 23:45 ` Richard Stallman
2003-04-11 23:59 ` Stefan Monnier
2003-04-12 0:11 ` Joe Kelsey
2003-04-12 8:51 ` Kai Großjohann
2003-04-13 11:23 ` Richard Stallman
2003-04-13 16:41 ` Stefan Monnier
2003-04-13 18:54 ` Kai Großjohann
2003-04-13 19:11 ` Joe Kelsey
2003-04-20 22:50 ` skeleton.el _ versus @, a new patch Joe Kelsey
2003-04-21 13:11 ` Stefan Monnier
2003-04-22 0:32 ` Joe Kelsey
2003-04-22 13:31 ` Stefan Monnier
2003-04-23 0:27 ` Joe Kelsey
2003-04-22 0:45 ` Richard Stallman
2003-04-22 1:30 ` Joe Kelsey
2003-04-24 1:50 ` Richard Stallman
2003-04-24 15:59 ` Joe Kelsey
2003-04-26 2:31 ` Richard Stallman
2003-04-28 21:51 ` Stefan Monnier
2003-04-29 19:29 ` Richard Stallman
2003-05-18 1:31 ` Joe Kelsey
2003-04-02 19:26 ` skeleton.el _ versus @ Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1049050316.532.8.camel@zircon \
--to=joe@zircon.seattle.wa.us \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).