GNU bug report logs -
#21722
25.0.50; Unexpected point position after undo
Previous Next
Reported by: Markus Triska <triska <at> metalevel.at>
Date: Tue, 20 Oct 2015 23:15:02 UTC
Severity: normal
Tags: fixed
Merged with 1095
Found in version 25.0.50
Fixed in version 25.1
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21722 in the body.
You can then email your comments to 21722 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21722
; Package
emacs
.
(Tue, 20 Oct 2015 23:15:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Markus Triska <triska <at> metalevel.at>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 20 Oct 2015 23:15:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
In "emacs -Q", when I insert into *scratch* the form:
(progn (end-of-line) (insert "\nhi"))
then place point on the "g" and press C-M-x C-/, then the insertion is
undone, and point remains on the "g", as expected. When I then press:
C-h f C-g C-M-x C-/
the insertion is undone, and point is unexpectedly placed at the end of
the form instead of remaining on the "g". When I then place point on the
"g" again, and again press C-M-x C-/, point again stays on the "g".
Thus, point position after undo is sometimes unexpected.
For comparison: In Emacs 22.2, point remains on the "g" in all these
cases. This is more consistent, and, in my view, therefore preferable.
In GNU Emacs 25.0.50.5 (x86_64-apple-darwin14.1.0, X toolkit, Xaw3d scroll bars)
of 2015-10-04
Repository revision: acfb5cd0353406784f085ddb6edfb0d0587048c8
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
Configured using:
'configure --without-ns CFLAGS=-I/opt/local/include
LDFLAGS=-L/opt/local/lib'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG IMAGEMAGICK GSETTINGS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21722
; Package
emacs
.
(Sun, 03 Jul 2016 15:21:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21722 <at> debbugs.gnu.org (full text, mbox):
I think the reason for this problem is in keyboard.c. C-g causes us
to throw to top-level right after reading the key, and the
undo-related variables are set up in the command loop after that. I
guess something in this sequence interferes with recording of point
position.
Merged 1095 21722.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sun, 03 Jul 2016 16:47:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) unreproducible.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sun, 03 Jul 2016 19:19:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21722
; Package
emacs
.
(Thu, 11 Aug 2016 01:17:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 21722 <at> debbugs.gnu.org (full text, mbox):
Markus Triska <triska <at> metalevel.at> writes:
> In "emacs -Q", when I insert into *scratch* the form:
>
> (progn (end-of-line) (insert "\nhi"))
>
> then place point on the "g" and press C-M-x C-/, then the insertion is
> undone, and point remains on the "g", as expected. When I then press:
>
> C-h f C-g C-M-x C-/
>
> the insertion is undone, and point is unexpectedly placed at the end of
> the form instead of remaining on the "g". When I then place point on the
> "g" again, and again press C-M-x C-/, point again stays on the "g".
>
> Thus, point position after undo is sometimes unexpected.
In 25.1-rc1 the point position stays in place for both cases. So I
guess this can be considered fixed?
(In 25.0.93 (which I happened to have lying around), it moves in both
cases)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21722
; Package
emacs
.
(Fri, 12 Aug 2016 06:38:01 GMT)
Full text and
rfc822 format available.
Message #18 received at 21722 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> In 25.1-rc1 the point position stays in place for both cases. So I
> guess this can be considered fixed?
Yes, this is fixed. Phillip Lord corrected this in #23871, thank you!
All the best,
Markus
Added tag(s) fixed.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 12 Aug 2016 22:44:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 25.1, send any further explanations to
21722 <at> debbugs.gnu.org and Markus Triska <triska <at> metalevel.at>
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 12 Aug 2016 22:44:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#21722
; Package
emacs
.
(Fri, 19 Aug 2016 15:46:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 21722 <at> debbugs.gnu.org (full text, mbox):
npostavs <at> users.sourceforge.net writes:
> Markus Triska <triska <at> metalevel.at> writes:
>
>> In "emacs -Q", when I insert into *scratch* the form:
>>
>> (progn (end-of-line) (insert "\nhi"))
>>
>> then place point on the "g" and press C-M-x C-/, then the insertion is
>> undone, and point remains on the "g", as expected. When I then press:
>>
>> C-h f C-g C-M-x C-/
>>
>> the insertion is undone, and point is unexpectedly placed at the end of
>> the form instead of remaining on the "g". When I then place point on the
>> "g" again, and again press C-M-x C-/, point again stays on the "g".
>>
>> Thus, point position after undo is sometimes unexpected.
>
> In 25.1-rc1 the point position stays in place for both cases. So I
> guess this can be considered fixed?
>
> (In 25.0.93 (which I happened to have lying around), it moves in both
> cases)
Sorry, think I just forgot to close this one. Thanks for checking.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 17 Sep 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 278 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.