GNU bug report logs - #34420
[PATCH 2/2] smerge-mode: new function to go to next conflict

Previous Next

Package: emacs;

Reported by: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>

Date: Sun, 10 Feb 2019 21:18:01 UTC

Severity: wishlist

Tags: patch

Merged with 34421

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> IRO.UMontreal.CA, 34420 <at> debbugs.gnu.org
Subject: bug#34420: [PATCH 2/2] smerge-mode: new function to go to next conflict
Date: Sun, 17 Feb 2019 18:59:24 +0300
On 17.02.2019 18:37, Eli Zaretskii wrote:
>> Cc: 34420 <at> debbugs.gnu.org
>> From: Konstantin Kharlamov <hi-angel <at> yandex.ru>
>> Date: Sun, 17 Feb 2019 12:18:53 +0300
>>
>>> In terms of UI it's a question of taste: I didn't provide such a command
>>> because I never felt the need for it (I think I like to be in control of
>>> changing buffer).  Maybe I'd change it to first emit a warning "no more
>>> conflicts in this buffer" and only go to the next buffer if you repeat
>>> the command (as a form of confirmation that you're done with the current
>>> buffer).
>>
>> Well, I wouldn't call changing a buffer upon explicit command from a
>> user a "taking control from them". The command name being explicit (at
>> least should be — I'm not a native English speaker, please tell me if
>> it's not) about going to the next conflict in the repository, and
>> conflicts are markers in different files.
> 
> I'm not sure this is always the case.  I can certainly envision a user
> who might be surprised by being switched to another buffer.  Asking a
> question like "No more conflicts in this file; go to next one?" might
> in that case be a good idea.

The thing is, we already have a function that only works within focused 
buffer, it is smerge-next.

This patch is about adding a more "global" function, one that works 
within the focused repository instead of just the focused buffer.

>> Emitting a warning in this case would be annoying, because the user
>> expects to be taken to the next conflict if there's any.
> 
> We could have an option to control this behavior.
> 




This bug report was last modified 6 years and 144 days ago.

Previous Next


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