From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <865xykr79f.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36939"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.50.3 Cc: Eli Zaretskii , 69220@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 20 04:04:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rcGQd-0009MK-Ja for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Feb 2024 04:04:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rcGQM-0001JM-Mj; Mon, 19 Feb 2024 22:04:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rcGQ1-0001Fj-1l for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 22:03:42 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rcGQ0-0001a8-Pr for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 22:03:40 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rcGQL-00067u-Oc for bug-gnu-emacs@gnu.org; Mon, 19 Feb 2024 22:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Feb 2024 03:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69220 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 69220-submit@debbugs.gnu.org id=B69220.170839820823504 (code B ref 69220); Tue, 20 Feb 2024 03:04:01 +0000 Original-Received: (at 69220) by debbugs.gnu.org; 20 Feb 2024 03:03:28 +0000 Original-Received: from localhost ([127.0.0.1]:43990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rcGPn-000671-SQ for submit@debbugs.gnu.org; Mon, 19 Feb 2024 22:03:28 -0500 Original-Received: from forward500c.mail.yandex.net ([178.154.239.208]:35696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rcGPk-00066s-Rz for 69220@debbugs.gnu.org; Mon, 19 Feb 2024 22:03:26 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net [IPv6:2a02:6b8:c12:5202:0:640:875:0]) by forward500c.mail.yandex.net (Yandex) with ESMTPS id 9EBDE60E83; Tue, 20 Feb 2024 06:02:31 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id U2HgjS3hA0U0-jdufj2jD; Tue, 20 Feb 2024 06:02:31 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1708398151; bh=UTGMBCPEPffvVBoZ8R1SajK75liMykX/jZcs0c5iPvM=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=HaKqQPl1VpX4e0mZ9DxyHk1/4RX1zlL0Nz0O3TWOl9V5uX6qZPUQIoXT448j0E07F u1sh+nWci9qBBHls7RdA1kmg887rRi2b9/TJfQI/cTjUwFSg7S3uBC2JuTYY+C0FjH SaFUtXNaM/cgsoFbYhj4QwX64jAkTr6RgZppB3vo= Authentication-Results: mail-nwsmtp-smtp-production-main-78.myt.yp-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:280304 Archived-At: 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`. > >=20 > > Sorry, I'm not sure I understand=E2=80=A6 =F0=9F=98=85 You want a funct= ion `smerge- > > apply- > > all-conflicts` that would accept a prefix command >=20 > 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. >=20 > > If so, that would be almost the same as what I did, >=20 > 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.=C2=A0 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 > > >=20 > > > =C2=A0=C2=A0=C2=A0 C-x ( C-c ^ n C-c ^ u C-x e e e e e e e e e > >=20 > > I fear to even try to decypher that combination. >=20 > `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. >=20 > > 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` ... >=20 > I like `M-x` too :-) >=20 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Stefan >=20