unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Maguire\, Andrew \(GE Infra\, Energy\)" <andrew.maguire@ge.com>
Cc: Chong Yidong <cyd@stupidchicken.com>, 5805@debbugs.gnu.org
Subject: bug#5805: 23.1; abbrev-insert does not protext itself with save-excursion
Date: Mon, 12 Apr 2010 09:31:17 -0400	[thread overview]
Message-ID: <jwvy6gsvm6n.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <A6A1CC87D715C143988ED94326B583D301F7BD0A@BUDMLVEM09.e2k.ad.ge.com> (Andrew Maguire's message of "Mon, 12 Apr 2010 13:28:50 +0200")

> I do appreciate the need for some abbrevs to move point and that I am
> reporting a perceived change in behaviour.
> However, the question is whether the change in behaviour is deliberate
> or not.

The change was not deliberate, no.

> If a user wishes to create an abbrev that requires point to move
> presumably they have to create the abbrev in a certain way.
> The example you give below would still require user code to move point
> to between the LaTeX statements.
> i.e If I created a simple global abbrev to expand "begi" point would be
> left after the \end{itemize}^

Yes, the abbrev would need to be defined differently, but the
point-movement would be done by the abbrev itself, i.e. the caller would
still just call expand-abbrev.

> So how should I fix my code that uses expand-abbrev to work in Emacs 23?
> It currently works as is in Emacs 20, 21 and 22.

I think you need to add a save-excursion around the call to
expand-abbrev to make it clear that you don't want this call to
move point.
This will also save you in the case where the user has setup an abbrev
like "begi", which is a case that could also happen in previous Emacsen.

But that really depends on what behavior you expect in the case where
your code encounters a "begi"-like abbrev.


        Stefan


> Thanks,
> Andrew
> -----Original Message-----
> From: Stefan Monnier [mailto:monnier@iro.umontreal.ca] 
> Sent: 10 April 2010 20:10
> To: Maguire, Andrew (GE Infra, Energy)
> Cc: Chong Yidong; 5805@debbugs.gnu.org
> Subject: Re: bug#5805: 23.1; abbrev-insert does not protext itself with
> save-excursion

>> Create a global abbrev, abbrv => abbrev
>> Type the following, ^ indicating point location.

>> abbrv ()
>> ^
>> Then press C-x ' to expand the abbrev on the line.
>> abbrev ()
>> ^
>> Observe that point ^ is now before the ()s.

> Right.  The question now is: why is that a problem?

> I ask because for some abbrevs, moving point isa feature, e.g. an abbrev
> that uses skeletons to expand

>     begi
>         ^
> into

>     \begin{itemize}  \end{itemize}
>                     ^

> so maybe the problem is that your code makes unwarranted assumptions
> about what abbrevs can do, or maybe your code knows that it won't
> encounter such abbreviations or that it wouldn't care about their
> point-placement feature, so it could/should use save-excursion.

>> ;; Emacs 23 has a lisp implementation for abbrevs.

> BTW, the problem is not that the implementation is in Lisp, but that it
> behaves differently.


>         Stefan






  reply	other threads:[~2010-04-12 13:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <201003291206.NAA17706@ultimate.Smallworld.co.uk>
2010-03-30 16:33 ` bug#5805: Returned mail: Cannot send message within 3 days Maguire, Andrew (GE Infra, Energy)
2010-04-10 16:04   ` bug#5805: 23.1; abbrev-insert does not protext itself with save-excursion Chong Yidong
2010-04-10 17:06     ` Maguire, Andrew (GE Infra, Energy)
2010-04-10 19:10       ` Stefan Monnier
2010-04-12 11:28         ` Maguire, Andrew (GE Infra, Energy)
2010-04-12 13:31           ` Stefan Monnier [this message]
2010-04-12 15:02             ` Maguire, Andrew (GE Infra, Energy)
2010-04-12 18:13               ` Stefan Monnier
2011-07-07 14:48   ` bug#5805: 23.3 abbrev-insert needs a limited save-excursion Bob Nnamtrop
2011-07-07 20:59     ` Stefan Monnier
2011-07-07 21:46       ` Bob Nnamtrop
2011-07-08  0:02         ` Bob Nnamtrop
2011-07-08  1:03           ` Stefan Monnier
2011-07-08 14:43     ` Stefan Monnier

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=jwvy6gsvm6n.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=5805@debbugs.gnu.org \
    --cc=andrew.maguire@ge.com \
    --cc=cyd@stupidchicken.com \
    /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).