bug#73544: smerge key bindings awkward

[Daniel Colascione <dancol@dancol.org>]

On October 13, 2024 7:06:11 AM EDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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?

The default is what produces the problem.