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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: 38456 <at> debbugs.gnu.org
Subject: bug#38456: 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

Previous Next

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