From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Branislav =?UTF-8?Q?Zahradn=C3=ADk?= Newsgroups: gmane.emacs.bugs Subject: bug#74509: Feature request - smerge-mode Date: Tue, 3 Dec 2024 07:39:30 +0100 Message-ID: References: <86bjxx817w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000010f58b062857ee9c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1296"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74509@debbugs.gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 03 07:41:17 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 1tIMaz-0000BF-DZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Dec 2024 07:41:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIMam-0007tL-Em; Tue, 03 Dec 2024 01:41:04 -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 1tIMak-0007t9-R4 for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 01:41:03 -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 1tIMak-0001OG-Ab for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 01:41:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=5UbqjQ1m+2cRM+wNXy2s9ho9yu/S2OZazQ6cvuaBgWM=; b=LzQYimWpfXrWf59KYSeJYSs/wG7nLxMt1oD98n+RMplLbNixN2hUOo5DNnO5et0a8y4rDcbvPHkw5uO/B1vdxElZqOu0UY9g1l+xkBSxbkIyTEsUYYTG5/XWfEP6LppumFxst/mRIrz3y6tRD8Rtmzt7Z8txsofjM7ujBnqJzz6gt87uJA/BDDv8430TUU2DWn1C6M1Pzpb9NpmgdeJFPmCaWkjzrooYr96toUK8s+oyUfUKZ+SAB0f5G7bI8elA28vaNu3XAR78NEaLuKmXMYTkJzIsRNf6wOZLF4npFMei93ZurRVemjkl0BYp6pbs+dKMs9Sc0z+C/fBw1PAKSw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tIMak-0003JK-5e for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2024 01:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Branislav =?UTF-8?Q?Zahradn=C3=ADk?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2024 06:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74509 X-GNU-PR-Package: emacs Original-Received: via spool by 74509-submit@debbugs.gnu.org id=B74509.173320804512694 (code B ref 74509); Tue, 03 Dec 2024 06:41:02 +0000 Original-Received: (at 74509) by debbugs.gnu.org; 3 Dec 2024 06:40:45 +0000 Original-Received: from localhost ([127.0.0.1]:57929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIMaT-0003If-0y for submit@debbugs.gnu.org; Tue, 03 Dec 2024 01:40:45 -0500 Original-Received: from mail-wr1-f50.google.com ([209.85.221.50]:50304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tIMaQ-0003IW-Pm for 74509@debbugs.gnu.org; Tue, 03 Dec 2024 01:40:43 -0500 Original-Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-382610c7116so3392822f8f.0 for <74509@debbugs.gnu.org>; Mon, 02 Dec 2024 22:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733207982; x=1733812782; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5UbqjQ1m+2cRM+wNXy2s9ho9yu/S2OZazQ6cvuaBgWM=; b=hfRHtvwL+Qv0ZJJgtR+n4Na9fMggcEFKrEEIBYoocw32KqqJ1WpAlgMOOVKyWwWsoi ylhyCX20Er1BV+7l6POOp1ZcnxVsOjTSRGGdYJcYv8nxA/aYjg3VPujXe6VnwsJH5EXH PtAc0whk6+yeKkHQeDVgpZBpjeu6dWX1q3254J38WCpuIoqiyCKt89XB8njIyqRDoQXG OU+7DVFwcDw4cJi6qkrmuBIndlmet0ewB2EncKPVD4is1eowyNuNlnoqvVVcOfpuKwgK tZxEBKbkUVIG5hq8MUXJLIRTDg6By7P1MaV1O6n/fKI7PIM1PTHN/Et0VIt+NTe6VPj3 rJUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733207982; x=1733812782; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5UbqjQ1m+2cRM+wNXy2s9ho9yu/S2OZazQ6cvuaBgWM=; b=iM32UzlTV8DUfxvMjdwqN9auS7zudrArvnyPuAzAMm1GGMGolCdiZpQCCK6fzWUv5Y KElVXaN+5cQth86B57NKkh+4eWxDuE28n7oadLyLJ2z6PKygDIBrfbQlO0acAeblOqFG 1itczgwcmChOA79QLiyGTmo5ey9M+7/NzG3sExvZct24SbOzpco7K6QLMSgVqtm5k91H EcN2NvObWDXX4rWYz5pc1tvAO1JYgHurlUJ6eOUwW1aSB44N4eEHIQ6duz9agw+BHcXF ry6psJ1+W47Fvk/Bu59+OTuAALgjeGMNVOt4kjhT77qq8s85nH7fQJCzCFAJ3PA6zI/u hreg== X-Forwarded-Encrypted: i=1; AJvYcCUZy/eKDRKwuKXdoUvu3kHQK0lj1Vj3rno1JeED5aMF8TRD+XXJKfoC9mL4EOTQin0v33x/aA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyukbB32oa/RKwU72yFzz0N5C4G0yWX7fyg0D6/Aql7kelCIwnW j8TH2YvYQgX/D17YAJ1klYa9mBevPwyq4uB3KB3+2Uq5ISFHRD6n7rWz1EofIHu+pCIm30fqqix EKdJXXuZPP7ttkCtRiLS/0+l7B5U= X-Gm-Gg: ASbGncvAgMiyMxX9IODtTBJUhzh3gjxOadE68pDRbYHjn3Q1VlaXKWymwD/UvxKiC3p Zyuk4bh70hDsfFixu0stOnbDUpXF7mFk= X-Google-Smtp-Source: AGHT+IEEBWBJ6Ce9xJVCnYGgaa61YJmlWuP2s8Xf8d/J5lWYNpb81FoGPu/7m99E/XXwOXIYKjylNHGWJU1ggL7JiSc= X-Received: by 2002:a05:6000:4025:b0:382:31a2:17fd with SMTP id ffacd0b85a97d-385fd532b93mr1103552f8f.55.1733207981616; Mon, 02 Dec 2024 22:39:41 -0800 (PST) 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:296354 Archived-At: --00000000000010f58b062857ee9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 3 Dec 2024 at 04:26, Stefan Monnier wrote: > >> >> # keybinding > >> >> would be nice to provide default keybinding for smerge-swap: C-c ^ = s > >> Interesting. I've never found a use for that command, personally. > >> Could you give some hint for the situations where you found it handy? > > Example: > > I keep my functions alphabetically ordered. > > When I merge two changes which added function in same alphabetical plac= e, > > I often need to change their order. > > I see; makes sense! > > >> >> # smerge-extend > >> >> Helpful when user intent to keep both. > >> Sorry: to keep both what? > > > > Both =3D lower + upper. > > > > Using above example: > > when I intent to keep both functions, end of block (eg: C, Java, Perl, > ...) > > will currently not appear twice, > > Really? Here, when I merge two changes which both add a function at the > same place I get a conflict with the complete functions (with their > respective closing brace and trailing space if applicable). > > >> Hmm... Why just one line and why only from the end? > > One line - one can use it multiple times to add more. > > And yes, you are right, it should accept numeric argument (negative for > > preceding line). > > Though I still believe common use case will be to extend with following= . > > I guess a numeric argument could be handy (e.g. to handle the case of > extending from the front rather than from the end). > I had in mind a different UI where you move point to the "end" of the > extension (i.e. to right after the one-or-two lines you want to add to > the ends), but I guess that would be more clunky than what you have. > > >> [ Unless you specifically chose 2-way conflicts, I recommend you > >> investigate how to get 3-way conflicts, because they give a lot more > >> information and allow for example `smerge-resolve` to "just work" in > >> more cases. YMMV, but personally whenever I'm faced with a 2-way > >> conflict, I'm frustrated. ] > > Different experiences - I for example run mostly into 2-way conflicts > > Maybe it's because of > > % grep -B1 diff3 ~/.gitconfig > [merge] > conflictstyle =3D diff3 > % > > =F0=9F=99=82 > As I said, everyone has different preferences and experiences. I'm trying to organize my code (diff-friendly programming) that way so only minimum number of lines / informations is changed so conflicts are usually easier to solve, including punctuation characters used by given programming language. That leads to small diffs, easy to solve, but with necessity of having this extend functionality. > > > Stefan > > --00000000000010f58b062857ee9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 3 Dec 2= 024 at 04:26, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> >> # keybinding
>> >> would be nice to provide default keybinding for smerge-sw= ap: C-c ^ s
>> Interesting.=C2=A0 I've never found a use for that command, pe= rsonally.
>> Could you give some hint for the situations where you found it han= dy?
> Example:
> I keep my functions alphabetically ordered.
> When I merge two changes which added function in same alphabetical pla= ce,
> I often need to change their order.

I see; makes sense!

>> >> # smerge-extend
>> >> Helpful when user intent to keep both.
>> Sorry: to keep both what?
>
> Both =3D lower + upper.
>
> Using above example:
> when I intent to keep both functions, end of block (eg: C, Java, Perl,= ...)
> will currently not appear twice,

Really?=C2=A0 Here, when I merge two changes which both add a function at t= he
same place I get a conflict with the complete functions (with their
respective closing brace and trailing space if applicable).

>> Hmm... Why just one line and why only from the end?
> One line - one can use it multiple times to add more.
> And yes, you are right, it should accept numeric argument (negative fo= r
> preceding line).
> Though I still believe common use case will be to extend with followin= g.

I guess a numeric argument could be handy (e.g. to handle the case of
extending from the front rather than from the end).
I had in mind a different UI where you move point to the "end" of= the
extension (i.e. to right after the one-or-two lines you want to add to
the ends), but I guess that would be more clunky than what you have.

>> [ Unless you specifically chose 2-way conflicts, I recommend you >>=C2=A0 =C2=A0investigate how to get 3-way conflicts, because they g= ive a lot more
>>=C2=A0 =C2=A0information and allow for example `smerge-resolve` to = "just work" in
>>=C2=A0 =C2=A0more cases.=C2=A0 YMMV, but personally whenever I'= m faced with a 2-way
>>=C2=A0 =C2=A0conflict, I'm frustrated.=C2=A0 ]
> Different experiences - I for example run mostly into 2-way conflicts<= br>
Maybe it's because of

=C2=A0 =C2=A0 % grep -B1 diff3=C2=A0 ~/.gitconfig
=C2=A0 =C2=A0 [merge]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conflictstyle =3D diff3
=C2=A0 =C2=A0 %

=F0=9F=99=82

As I said, everyone has di= fferent preferences and experiences.
I'm trying to organize m= y code (diff-friendly programming) that way
so only minimum numbe= r of lines / informations is changed so conflicts
are usually eas= ier to solve, including punctuation characters used by
given prog= ramming language. That leads to small diffs, easy to solve,
but w= ith necessity of having this extend functionality.
=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--00000000000010f58b062857ee9c--