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

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

> 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

Copying in Stefan Monnier as the author of smerge.

Best regards,
Stefan Kangas