bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#5805: 23.1; abbrev-insert does not protext itself with save-excursio


From: Maguire, Andrew (GE Infra, Energy)
Subject: bug#5805: 23.1; abbrev-insert does not protext itself with save-excursion
Date: 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.

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

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.

Thanks,
Andrew
-----Original Message-----
From: Stefan Monnier [mailto:address@hidden 
Sent: 10 April 2010 20:10
To: Maguire, Andrew (GE Infra, Energy)
Cc: Chong Yidong; address@hidden
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 via email to

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