--- Begin Message ---
|
Subject: |
27.0.50; Assertion failure in 'smerge-match-conflict' |
|
Date: |
Mon, 2 Dec 2019 10:54:46 +0100 |
Whenever git reports conflicts in a file, Emacs automatically enters
'smerge-mode' when I visit that file and moves point to the first
conflict in its buffer. When 'debug-on-error' is non-nil and there is
no further conflict, typing C-c ^ n to invoke 'smerge-next' fails as
Debugger entered--Lisp error: (cl-assertion-failed ((< orig-point (match-end
0)) nil))
cl--assertion-failed((< orig-point (match-end 0)))
smerge-match-conflict()
smerge-refine()
smerge-next(1)
funcall-interactively(smerge-next 1)
call-interactively(smerge-next nil nil)
command-execute(smerge-next)
Whatever that means, it makes Emacs behave erratically from now on,
like no more popping up menu bar items or not recognizing some of my
key bindings. Quitting the debugger mitigates that but apparently
still leaves 'smerge-mode' unusable and I have to revert the buffer.
Note that all this happens in a situation where I am usually more
occupied about the reasons of the conflicts and how to resolve them
then about how the underlying resolution mechanism works.
I've been observing this behavior for years and never got around
reporting it because I always tried to understand the underlying
behaviors of 'smerge-match-conflict' and the debugger first.
Admittedly, I failed. Does anyone have an idea about what goes on
here internally and how to fix that?
TIA, martin
In GNU Emacs 27.0.50 (build 63, x86_64-w64-mingw32)
of 2019-12-01 built on MACHNO
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict' |
|
Date: |
Tue, 21 Jan 2020 15:59:04 -0500 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> Eli, is it OK to put it into `emacs-27`?
> Yes, thanks.
Done,
Stefan
--- End Message ---