bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'

martin rudalics
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