bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#69220: [PATCH] smerge-mode: add a function to resolve all conflicts


From: Konstantin Kharlamov
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
User-agent: Evolution 3.50.3

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 via email to

[Prev in Thread] Current Thread [Next in Thread]