GNU bug report logs - #38456
27.0.50; Assertion failure in 'smerge-match-conflict'

Previous Next

Full log

Message #8 received at 38456 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38456 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
Date: Sat, 18 Jan 2020 11:06:58 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.