unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: monnier@iro.umontreal.ca, "Branislav Zahradník" <happy.barney@gmail.com>
Cc: 74509@debbugs.gnu.org
Subject: bug#74509: Feature request - smerge-mode
Date: Sat, 21 Dec 2024 10:47:23 +0200	[thread overview]
Message-ID: <86plll8lt0.fsf@gnu.org> (raw)
In-Reply-To: <CAB=rbOnUw57rBdsDCNhoeZrwmCJdKEnn8uu0vpptRDUOOYxbSw@mail.gmail.com> (message from Branislav Zahradník on Tue, 3 Dec 2024 07:39:30 +0100)

> From: Branislav Zahradník <happy.barney@gmail.com>
> Date: Tue, 3 Dec 2024 07:39:30 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, 74509@debbugs.gnu.org
> 
> On Tue, 3 Dec 2024 at 04:26, Stefan Monnier <monnier@iro.umontreal.ca> 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 place,
>  > 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 = 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 = diff3
>      %
> 
>  🙂
> 
> 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.

How should we go about this bug report?  Can we make some progress
here?  Or should we close it as wontfix?





  reply	other threads:[~2024-12-21  8:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-24  8:17 bug#74509: Feature request - smerge-mode Branislav Zahradník
2024-11-30 10:28 ` Eli Zaretskii
2024-12-01 23:51   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-02  7:59     ` Branislav Zahradník
2024-12-03  3:26       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-03  6:39         ` Branislav Zahradník
2024-12-21  8:47           ` Eli Zaretskii [this message]
2024-12-21 15:11             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-22  2:54               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-22  9:46                 ` Branislav Zahradník

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=86plll8lt0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=74509@debbugs.gnu.org \
    --cc=happy.barney@gmail.com \
    --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).