* bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
@ 2019-12-02 9:54 martin rudalics
2020-01-18 10:06 ` Stefan Kangas
2020-01-21 19:24 ` Stefan Monnier
0 siblings, 2 replies; 6+ messages in thread
From: martin rudalics @ 2019-12-02 9:54 UTC (permalink / raw)
To: 38456
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
2019-12-02 9:54 bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict' martin rudalics
@ 2020-01-18 10:06 ` Stefan Kangas
2020-01-21 19:24 ` Stefan Monnier
1 sibling, 0 replies; 6+ messages in thread
From: Stefan Kangas @ 2020-01-18 10:06 UTC (permalink / raw)
To: martin rudalics; +Cc: 38456, Stefan Monnier
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
2019-12-02 9:54 bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict' martin rudalics
2020-01-18 10:06 ` Stefan Kangas
@ 2020-01-21 19:24 ` Stefan Monnier
2020-01-21 19:54 ` Eli Zaretskii
2020-01-22 17:44 ` martin rudalics
1 sibling, 2 replies; 6+ messages in thread
From: Stefan Monnier @ 2020-01-21 19:24 UTC (permalink / raw)
To: martin rudalics; +Cc: 38456
> 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)
Oh, yes, thank you. I've suffered through those many times as well ;-)
The patch below should fix it.
Eli, is it OK to put it into `emacs-27`?
OT1H it's an old bug, so there's no urgency, but OTOH it's "obviously
safe" (turns an assertion failure into a `search-failed` signal).
Stefan
diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index d4984bbd38..85868b91ec 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -797,7 +797,10 @@ smerge-match-conflict
(filename (or (match-string 1) ""))
(_ (re-search-forward smerge-end-re))
- (_ (cl-assert (< orig-point (match-end 0))))
+ (_ (when (< (match-end 0) orig-point)
+ ;; Point is not within the conflict we found,
+ ;; so this conflict is not ours.
+ (signal 'search-failed (list smerge-begin-re))))
(lower-end (match-beginning 0))
(end (match-end 0))
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
2020-01-21 19:24 ` Stefan Monnier
@ 2020-01-21 19:54 ` Eli Zaretskii
2020-01-21 20:59 ` Stefan Monnier
2020-01-22 17:44 ` martin rudalics
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-01-21 19:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 38456
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 21 Jan 2020 14:24:23 -0500
> Cc: 38456@debbugs.gnu.org
>
> Eli, is it OK to put it into `emacs-27`?
Yes, thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict'
2020-01-21 19:24 ` Stefan Monnier
2020-01-21 19:54 ` Eli Zaretskii
@ 2020-01-22 17:44 ` martin rudalics
1 sibling, 0 replies; 6+ messages in thread
From: martin rudalics @ 2020-01-22 17:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 38456
> Oh, yes, thank you. I've suffered through those many times as well ;-)
> The patch below should fix it.
Thanks for the fix. I'll check the next time I see a conflict. One
thing that should be fixed too, if easily possible, is to gray out the
previous/next conflict menu entries whenever we are at the first/last
conflict. Smerging can be a painful job (often enough I don't even know
whether the upper or lower represents the one I want to keep) so
avoiding any possible confusions should be a main goal IMHO.
martin
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-22 17:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-02 9:54 bug#38456: 27.0.50; Assertion failure in 'smerge-match-conflict' martin rudalics
2020-01-18 10:06 ` Stefan Kangas
2020-01-21 19:24 ` Stefan Monnier
2020-01-21 19:54 ` Eli Zaretskii
2020-01-21 20:59 ` Stefan Monnier
2020-01-22 17:44 ` martin rudalics
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.