unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Konstantin Kharlamov <hi-angel@yandex.ru>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>, Eli Zaretskii <eliz@gnu.org>
Cc: 34420@debbugs.gnu.org
Subject: bug#34420: [PATCH 2/2] smerge-mode: new function to go to next conflict
Date: Sun, 17 Feb 2019 12:18:53 +0300	[thread overview]
Message-ID: <4f8f43b4-a64c-6c90-52e2-3b20bc4e214f@yandex.ru> (raw)
In-Reply-To: <jwvr2c7kgcn.fsf-monnier+emacs@gnu.org>

On 16.02.2019 16:41, Stefan Monnier wrote:
>>> To give some context: these patches follow this thread
>>> http://lists.gnu.org/archive/html/help-gnu-emacs/2019-01/msg00111.html
>>> (note: the thread continues the next month, i.e. February, too).
>> I hope Stefan (CC'ed) could comment on those.
> 
> Hmm...
> 
> In terms of implementation, there's nothing very deep and it looks OK
> (tho maybe it points to the need to autoload vc-find-conflicted-file,
> and obviously I'd use (point-min) rather than a hardcoded 0 and change
> the docstring to use the imperative rather than present tense).

Thanks for your comments!

> 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.

Emitting a warning in this case would be annoying, because the user 
expects to be taken to the next conflict if there's any. Imagine the 
case with many files having one small conflict, and that the user have 
to press "take me to the next conflict" twice every time.

> Also, I'd save the file before switching to the next buffer.
Okay, I can add that. I can't really comment anything about usability in 
this case, because I have a habit of saving files myself way too often :)

------

Since this discussion may take time, and you even may not even like the 
change — please, could you push the first patch in the series? When I 
first started looking at smerge-mode.el, I was confused about how going 
to the next conflict is implemented, and why the code does not call 
`smerge-next` anywhere. Extracting the code to an inline function, I 
think, should make it a bit easier for future contributors.





  reply	other threads:[~2019-02-17  9:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-10 21:14 bug#34421: [PATCH 1/2] smerge-mode: factor out going to next conflict Konstantin Kharlamov
2019-02-10 21:14 ` bug#34420: [PATCH 2/2] smerge-mode: new function to go " Konstantin Kharlamov
2019-02-10 22:30   ` bug#34420: [PATCH v2 " Konstantin Kharlamov
2019-02-13 21:44   ` bug#34420: [PATCH " Konstantin Kharlamov
2019-02-16  7:32     ` Eli Zaretskii
2019-02-16  7:32     ` Eli Zaretskii
2019-02-16 13:41       ` Stefan Monnier
2019-02-17  9:18         ` Konstantin Kharlamov [this message]
2019-02-17 15:37           ` Eli Zaretskii
2019-02-17 15:59             ` Konstantin Kharlamov
2019-02-18  3:22           ` Stefan Monnier
2019-02-18 17:49             ` Stefan Monnier
2019-02-18 21:12               ` hi-angel
2019-02-18 21:51                 ` Stefan Monnier
2019-02-18 22:01                   ` hi-angel
2019-02-18 23:28                     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f8f43b4-a64c-6c90-52e2-3b20bc4e214f@yandex.ru \
    --to=hi-angel@yandex.ru \
    --cc=34420@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).