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>
Cc: Eli Zaretskii <eliz@gnu.org>, 69220@debbugs.gnu.org
Subject: bug#69220: [PATCH] smerge-mode: add a function to resolve all conflicts in a file
Date: Tue, 20 Feb 2024 06:02:30 +0300	[thread overview]
Message-ID: <e7113d3e9afccc4d558df173c7d5da3c92590c28.camel@yandex.ru> (raw)
In-Reply-To: <jwvwmqzuba4.fsf-monnier+emacs@gnu.org>

On Mon, 2024-02-19 at 21:24 -0500, Stefan Monnier wrote:
> > > It would be easy enough to provide a kind of prefix command
> > > `smerge-apply-all-conflicts` which reads the next key and calls
> > > the
> > > corresponding command in every conflict in the file.
> > > It would generalize `smerge-resolve-all`.
> > 
> > Sorry, I'm not sure I understand… 😅 You want a function `smerge-
> > apply-
> > all-conflicts` that would accept a prefix command
> 
> No: `smerge-apply-all-conflicts` would *be* the prefix command.
> Instead of a prefix `C-u 8` which causes the next command to be
> executed
> 8 times, your use `M-x smerge-apply-all-conflicts` to cause the next
> command to be applied to every conflict in the buffer.
> 
> > If so, that would be almost the same as what I did,
> 
> I think so, yes.

I think I see, so you suggest a function that would apply resolution to
the next N conflicts. But unless I'm missing something, sounds like
this would be less useful. The "resolve all conflicts" function caters
to specific situation where you want all conflicts to be resolved in
preference of either side. Whereas making a function to do that to the
next N conflicts I don't see how it's better, given that:

1. I just don't see what usecase it solves. The case where you know
that exactly 2 next conflicts needs to be solved for "upper" but not
more? I don't remember stumbling upon such situation and there's a
reason for that: you either know beforehand that all conflicts are
solved "in preference of X", or they require manual intervention; in
the latter case having to solve them one by one means that you
typically don't look up next conflict before you figured out the
current one. 
   Also, it is rare to have even 3 full conflicts simultaneously in a
window, so even if you looked up next conflicts before solving them,
you're very unlikely to use the command with prefix more than 3.
2. I posted elsewhere in the thread a frequency list of types of
conflicts I usually see, and the case where there are simultaneously
conflicts of mixed type "manual intervention" + "preference to some
side" is just more rare than other two cases, in particular the one
where everything needs to be solved "in preference". So if we're
discussing whether to accept the new function based on the number of
people that are going to use it, then I think the "resolve all
conflicts" wins just because it's a more frequent situation.

> > > I have needed such a thing in the past, but there are several
> > > ways to
> > > do
> > > that already: beside telling Git beforehand how to resolve the
> > > conflicts, you can also use things like
> > > 
> > >     C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e
> > 
> > I fear to even try to decypher that combination.
> 
> `C-x (` starts a keyboard macro
> `C-x ^ n` is `smerge-next`
> `C-x ^ u` is `smerge-keep-upper`
> `C-x e` terminates the keyboard macro and repeats it immediately.
> Every `e` after that repeats the keyboard macro.
> 
> > For the record, I have lots of commands that I use situationally,
> > but
> > I do not care to remember their bindings because it's easier to
> > just
> > call `M-x` ...
> 
> I like `M-x` too :-)
> 
> 
>         Stefan
> 






  reply	other threads:[~2024-02-20  3:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-17 10:16 bug#69220: [PATCH] smerge-mode: add a function to resolve all conflicts in a file Konstantin Kharlamov
2024-02-19 12:03 ` Eli Zaretskii
2024-02-19 12:17   ` Konstantin Kharlamov
2024-02-19 12:25     ` Andreas Schwab
2024-02-19 12:28       ` Konstantin Kharlamov
2024-02-19 12:33         ` Andreas Schwab
2024-02-19 12:38           ` Konstantin Kharlamov
2024-02-19 12:44             ` Andreas Schwab
2024-02-19 12:53               ` Konstantin Kharlamov
2024-02-19 17:07     ` Konstantin Kharlamov
2024-02-20 15:34       ` Konstantin Kharlamov
2024-02-19 15:20   ` Dmitry Gutov
2024-02-19 15:35     ` Andreas Schwab
2024-02-19 15:31   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-19 17:25     ` Konstantin Kharlamov
2024-02-20  2:24       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-20  3:02         ` Konstantin Kharlamov [this message]
2024-02-20  3:15           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-20  3:24             ` Konstantin Kharlamov
2024-02-20  3:40               ` Konstantin Kharlamov
2024-02-20 13:53                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-20 13:59                   ` Konstantin Kharlamov
2024-02-20 14:03               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-20 14:10                 ` Konstantin Kharlamov

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=e7113d3e9afccc4d558df173c7d5da3c92590c28.camel@yandex.ru \
    --to=hi-angel@yandex.ru \
    --cc=69220@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).