Subject: Re: bug#73544: smerge key bindings awkward

From: Eli Zaretskii <[email-masked]>
Date: Sun, 13 Oct 2024 14:06:11 +0300

> Date: Mon, 30 Sep 2024 07:50:50 -0700
> From: Daniel Colascione <[email-masked]>
> CC: [email-masked], [email-masked]
> 
> 
> 
> On September 30, 2024 5:43:09 AM PDT, Eli Zaretskii <[email-masked]> wrote:
> >> From: Stefan Monnier <[email-masked]>
> >> Cc: Dmitry Gutov <[email-masked]>,  [email-masked],  [email-masked]
> >> Date: Mon, 30 Sep 2024 08:28:33 -0400
> >> 
> >> > Why does smerge-mode have to turn itself off when all conflicts are
> >> > resolved?  Stefan?
> >> 
> >> It doesn't have to.  It's just useless when all conflicts are resolved,
> >> so it's convenient for it to turn itself off in that case.  It also lets
> >> you use the `SMerge` lighter in the mode line as an indication that
> >> there are still merge conflicts to resolve in the buffer.
> >
> >That's what I thought.
> >
> >So maybe a possible solution to Daniel's problem would be a (maybe
> >optional) behavior, whereby when conflicts are resolved, smerge-mode
> >doesn't turn itself off, but instead changes the lighter to indicate
> >that there are no more conflicts?
> >
> >Daniel, would that solve your problem?  If it would, I think it's
> >better than making the "C-x ^" keymap global, which would have a
> >significant global effect, and might break someone's key bindings.
> 
> 
> That's a solution, sure. We could also have the lighter contain a visual indication of the number of conflict regions in the buffer, like flymake. 

Actually, I see that the first part of this is already there: we have
a defcustom smerge-auto-leave, whose default is t.  So does it mean we
can consider this bug fixed?