bug#73544: smerge key bindings awkward

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 30 Sep 2024 07:50:50 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: dmitry@gutov.dev, 73544@debbugs.gnu.org
> 
> 
> 
> On September 30, 2024 5:43:09 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: Dmitry Gutov <dmitry@gutov.dev>,  dancol@dancol.org,  73544@debbugs.gnu.org
> >> 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?