GNU bug report logs -
#4342
23.1; smerge-next marks buffer as modified
Previous Next
Reported by: Tom Tromey <tromey <at> redhat.com>
Date: Fri, 4 Sep 2009 21:10:05 UTC
Severity: normal
Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 08 Sep 2009 15:47:57 -0400
with message-id <jwvpra18bi3.fsf-monnier+emacsbugreports <at> gnu.org>
and subject line Re: bug#4342: 23.1; smerge-next marks buffer as modified
has caused the Emacs bug report #4342,
regarding 23.1; smerge-next marks buffer as modified
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact help-debbugs <at> gnu.org
immediately.)
--
4342: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4342
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
I did a cvs update and had some conflicts.
I visited a file with a conflict and typed M-x smerge-mode.
Then I did C-c ^ n (smerge-next) to go to the first conflict.
This marked my buffer as modified.
AFAICT, though, nothing actually changed.
I think simply moving between conflicts should not modify the buffer.
If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.1/etc/DEBUG for instructions.
In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.5)
of 2009-08-24 on x86-2.fedora.phx.redhat.com
Windowing system distributor `The X.Org Foundation', version 11.0.10601901
configured using `configure '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Change Log
Minor modes in effect:
shell-dirtrack-mode: t
diff-auto-refine-mode: t
auto-fill-function: do-auto-fill
erc-list-mode: t
erc-menu-mode: t
erc-autojoin-mode: t
erc-ring-mode: t
erc-pcomplete-mode: t
erc-track-mode: t
erc-track-minor-mode: t
erc-match-mode: t
erc-button-mode: t
erc-fill-mode: t
erc-stamp-mode: t
erc-netsplit-mode: t
erc-spelling-mode: t
erc-truncate-mode: t
flyspell-mode: t
erc-status-mode: t
erc-services-mode: t
erc-networks-mode: t
erc-irccontrols-mode: t
erc-noncommands-mode: t
erc-move-to-prompt-mode: t
erc-readonly-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
y C-u C-n n n n n n n SPC M-> q SPC M-> q SPC 5 0 <return>
M-> q C-l s C-r o t h e r C-a SPC 5 0 <return> M->
C-u C-u C-p C-u C-p C-p p Q y s C-z o <f10> <f10> <f10>
<f10> C-c b <f10> <switch-frame> C-z n <f10> <f10>
<f10> <f10> <f10> <f10> <f10> <f10> M-v M-> <f10> <switch-frame>
<switch-frame> C-z o C-u C-u C-n p p SPC 5 0 <return>
M-> q s C-z o <f10> C-z o M-v C-l M-g M-g M-g M-g M-g
p SPC C-u C-n C-u d C-p C-p SPC q s C-u C-n p SPC M->
q s C-z n <f10> <f10> C-z o M-v M-v M-< M-g M-g M-g
M-g p SPC SPC q s C-u C-n C-u C-n C-u C-n C-p C-p C-p
M-g M-g M-g M-g s C-z o <f10> <f10> C-z o C-u C-u C-n
p M-g M-g M-g M-g s C-f C-z o <f10> <f10> <switch-frame>
C-z n <f10> <f10> <switch-frame> <switch-frame> <f10>
<f10> <f10> C-x C-f C h <tab> <return> y e s <return>
C-a C-p C-p C-p C-SPC C-u C-u C-n C-n C-n C-n C-n C-w
M-< C-y C-c a C-p C-p C-f C-f C-SPC C-u C-n C-w C-x
C-s n C-z o C-x C-f M-p <M-backspace> d w <tab> l o
<tab> c <return> y e s <return> C-s < < < < < C-a M-<
M-x s m e r g e - m o d e <return> C-c ^ n C-v C-v
C-v C-v C-s C-s C-s C-a C-/ C-h c C-c ^ n C-c ^ n C-c
^ p C-l C-/ M-< C-c ^ n C-z o M-x e <backspace> r e
p o r t - e m <tab> b <tab> <return>
Recent messages:
Wrote /home/tromey/gnu/baseline-gdb/src/gdb/ChangeLog
Mark saved where search started
Mark set
Smerge mode enabled
Mark saved where search started
Undo!
C-c ^ n runs the command smerge-next
Undo!
Mark set
C-c ^ n runs the command smerge-next
Quit
Tom
[Message part 3 (message/rfc822, inline)]
> Then I did C-c ^ n (smerge-next) to go to the first conflict.
> This marked my buffer as modified.
I believe I've now fixed this bug on the trunk.
Thank you,
Stefan
This bug report was last modified 15 years and 281 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.