Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

Sounds OK (i.e. patch welcome).  Just be careful that diff3 markers
don't always come with useful "names".  Also mine/other is used as
mnemonic for key-bindings, so the terminology is "deeply" embedded in
smerge-mode, so maybe we should use "MINE - HEAD" and "OTHER -
2c633c8... Issue 3656/2: disambiguate our own ::to_string from
std::to_string" for the names.

In any case, please make it a bug-report, so we have a number to
track it.


        Stefan

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Sounds OK (i.e. patch welcome).  Just be careful that diff3 markers
> don't always come with useful "names".

Sure.

> Also mine/other is used as mnemonic for key-bindings, so the
> terminology is "deeply" embedded in smerge-mode,

Uh what?  The keybindings use a, b, and c.  The only connection to the
buffers is via visual arrangement, not via "MINE" and "OTHER.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Sounds OK (i.e. patch welcome).  Just be careful that diff3 markers
> don't always come with useful "names".  Also mine/other is used as
> mnemonic for key-bindings, so the terminology is "deeply" embedded in
> smerge-mode, so maybe we should use "MINE - HEAD" and "OTHER -
> 2c633c8... Issue 3656/2: disambiguate our own ::to_string from
> std::to_string" for the names.
>
> In any case, please make it a bug-report, so we have a number to
> track it.

At any rate, this is what I went with.  Feel free to take it; I have a
copyright assignment for Emacs on file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Let-smerge-mode-choose-default-buffer-names-based-on.patch --]
[-- Type: text/x-diff, Size: 3074 bytes --]

From 05ca072a856d0121422228ec3688a240194d8784 Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@gnu.org>
Date: Sat, 23 Nov 2013 14:53:05 +0100
Subject: [PATCH] Let smerge-mode choose default buffer names based on conflict
 markers

* vc/smerge-mode.el (smerge-ediff): Let smerge-mode choose
default buffer names based on the conflict markers when
available.
(smerge-get-marker): New function.
---
 lisp/ChangeLog         |  7 +++++++
 lisp/vc/smerge-mode.el | 24 +++++++++++++++++++-----
 2 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 8d2a754..c791fe2 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,10 @@
+2013-11-23  David Kastrup  <dak@gnu.org>
+
+	* vc/smerge-mode.el (smerge-ediff): Let smerge-mode choose
+	default buffer names based on the conflict markers when
+	available.
+	(smerge-get-marker): New function.
+
 2013-11-23  Ivan Shmakov  <ivan@siamics.net>  (tiny change)
 
 	* vc/diff-mode.el (diff-mode): Only allow diff-default-read-only
diff --git a/lisp/vc/smerge-mode.el b/lisp/vc/smerge-mode.el
index 87336b6..63ddd13 100644
--- a/lisp/vc/smerge-mode.el
+++ b/lisp/vc/smerge-mode.el
@@ -243,8 +243,8 @@ Used in `smerge-diff-base-mine' and related functions."
   "Font lock patterns for `smerge-mode'.")
 
 (defconst smerge-begin-re "^<<<<<<< \\(.*\\)\n")
-(defconst smerge-end-re "^>>>>>>> .*\n")
-(defconst smerge-base-re "^||||||| .*\n")
+(defconst smerge-end-re "^>>>>>>> \\(.*\\)\n")
+(defconst smerge-base-re "^||||||| \\(.*\\)\n")
 (defconst smerge-other-re "^=======\n")
 
 (defvar smerge-conflict-style nil
@@ -1182,6 +1182,14 @@ repeating the command will highlight other two parts."
 (defvar ediff-quit-hook)
 (declare-function ediff-cleanup-mess "ediff-util" nil)
 
+(defun smerge-get-marker (regexp default)
+  (save-excursion
+    (goto-char (point-min))
+    (if (and (search-forward-regexp regexp nil t)
+	     (> (match-end 1) (match-beginning 1)))
+	(match-string-no-properties 1)
+      default)))
+
 ;;;###autoload
 (defun smerge-ediff (&optional name-mine name-other name-base)
   "Invoke ediff to resolve the conflicts.
@@ -1194,9 +1202,13 @@ buffer names."
 	 (config (current-window-configuration))
 	 (filename (file-name-nondirectory buffer-file-name))
 	 (mine (generate-new-buffer
-		(or name-mine (concat "*" filename " MINE*"))))
+		(or name-mine (concat "*" filename " "
+				      (smerge-get-marker smerge-begin-re "MINE")
+				      "*"))))
 	 (other (generate-new-buffer
-		 (or name-other (concat "*" filename " OTHER*"))))
+		 (or name-other (concat "*" filename " "
+					(smerge-get-marker smerge-end-re "OTHER")
+					"*"))))
 	 base)
     (with-current-buffer mine
       (buffer-disable-undo)
@@ -1221,7 +1233,9 @@ buffer names."
 
     (when base
       (setq base (generate-new-buffer
-		  (or name-base (concat "*" filename " BASE*"))))
+		  (or name-base (concat "*" filename " "
+					(smerge-get-marker smerge-base-re "BASE")
+					"*"))))
       (with-current-buffer base
 	(buffer-disable-undo)
 	(insert-buffer-substring buf)
-- 
1.8.3.2


[-- Attachment #3: Type: text/plain, Size: 20 bytes --]



-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

> Uh what?  The keybindings use a, b, and c.  The only connection to the
> buffers is via visual arrangement, not via "MINE" and "OTHER.

The ediff bindings, yes, but not the smerge-mode bindings.


        Stefan

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Uh what?  The keybindings use a, b, and c.  The only connection to the
>> buffers is via visual arrangement, not via "MINE" and "OTHER.
>
> The ediff bindings, yes, but not the smerge-mode bindings.

Well, it's smerge-ediff that my patch changed, and it's smerge-ediff
that's the subject of this thread, and I checked the whole thread to
make absolutely sure that I have not mentioned anything else (such as
smerge-mode) anywhere.  Indeed, I didn't.

If you feel you should draw smerge-mode into it and solve the basic lack
of information in a different manner, that's commendable.  If not, the
provided patch helps those people who use smerge-ediff for conflict
resolution.  Which may be fewer than the users of smerge-mode.el as a
whole, but more than nobody.

If you feel you want to improve on this, but not now: it's extremely
unlikely that anybody will make programmatic use of the buffer names, so
it's not like this code might create physical dependencies.

It takes up buffer name length (but those are usually truncated anyway
because of their side by side placement), and it takes startup time, but
not likely much.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

> At any rate, this is what I went with.  Feel free to take it; I have a
> copyright assignment for Emacs on file.

Installed with minor tweaks, thank you,


        Stefan

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> At any rate, this is what I went with.  Feel free to take it; I have a
>> copyright assignment for Emacs on file.
>
> Installed with minor tweaks, thank you,

I've finally taken the time to take a look at it.  The only user-visible
tweak in my opinion, while unquestionably deliberate, is a mistake: you
decided to shove MINE = ... and OTHER = ... strings into the buffer
names before the identifying strings.

For one thing, smerge-ediff (purportedly as opposed to the smerge-mode
not visibly involved in the user interaction) does not expose _any_ of
the MINE/OTHER terminology to the user, so this is a distraction not
reflecting anything in the ediff-help.  For the usual case of a rebase
along the lines of

git pull -r

it labels the upstream changes as "MINE" and my own changes as "OTHER".

Not helpful.  If there was _any_ point in labelling, one should use A
and B, the actual names used for the ediff keybindings that are active
here.  But it's not usually a puzzler to figure out whether A or B comes
first, so that seems unnecessary.

But worse is that we are talking about the buffer names of buffers in a
horizontally split window.  For the normal terminal line length of 80,
and for a somewhat normal mode line with a non-minimal file name, this
means that the misleading and useless information does not leave _any_
room for the helpful information on the split mode line.

So we are back to where we started from, just in a more complex manner.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

> For one thing, smerge-ediff (purportedly as opposed to the smerge-mode
> not visibly involved in the user interaction) does not expose _any_ of

We can't assume that the user of smerge-ediff does not also use smerge.
So it's important to keep a connection between the names used in smerge
and the names used in ediff.  Maybe in your case it's not helpful, but
I think the added text should clarify the problem (and the 5/6 extra
chars may occasionally push the extra info past the truncation, but
this truncation problem exists even without those extra 5/6 chars).

> git pull -r
> it labels the upstream changes as "MINE" and my own changes as "OTHER".

Of course, any tool is free top put the 2 in whichever order they
prefer.  Maybe we should revisit the MINE/OTHER names used so far.
But whichever name we use there will need to also be present in
smerge-ediff.


        Stefan

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> For one thing, smerge-ediff (purportedly as opposed to the smerge-mode
>> not visibly involved in the user interaction) does not expose _any_ of
>
> We can't assume that the user of smerge-ediff does not also use
> smerge.

smerge-ediff is a utility of its own with its own user interface.  If
you call smerge-ediff from inside of smerge-mode, you can easily enough
pass "MINE", "OTHER" and "BASE" as function arguments in order to
maintain terminology across calls.

> So it's important to keep a connection between the names used in
> smerge and the names used in ediff.

Only if smerge-ediff is called from smerge-mode, and then it's easy to
pass the strings for getting the old behavior.

> Maybe in your case it's not helpful, but I think the added text should
> clarify the problem (and the 5/6 extra chars may occasionally push the
> extra info past the truncation, but this truncation problem exists
> even without those extra 5/6 chars).

The truncation problem is vastly acerbated with the 7 characters
"OTHERS=".  Not "occasionally", but pretty much always when we are
talking about an 80 column terminal which is pretty much a standard
working width since punchcard time (you don't want to edit most Fortran
code without it).

>> git pull -r
>> it labels the upstream changes as "MINE" and my own changes as "OTHER".
>
> Of course, any tool is free top put the 2 in whichever order they
> prefer.  Maybe we should revisit the MINE/OTHER names used so far.
> But whichever name we use there will need to also be present in
> smerge-ediff.

Only if you call smerge-ediff from within smerge-mode (using its
keybinding).  But then you _can_ pass it the names.  Possibly any passed
strings can be _added_ to the marker texts in the buffer names rather
than replacing them: there's probably nothing wrong putting the marker
texts out additionally anyway even if most of them is going to get cut
off.

But when called interactively standalone, "MINE", "OTHER", "BASE" are
pointless and confusing.  They have _no_ relation to ediff-mode and/or
to the keybindings and helps.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Of course, any tool is free top put the 2 in whichever order they
> prefer.  Maybe we should revisit the MINE/OTHER names used so far.
> But whichever name we use there will need to also be present in
> smerge-ediff.

Whenever you use _meaning_-carrying names, they'll be wrong half of the
time.  Ediff got that right with A, B, and, uh, C?  No idea (rarely use
three-way conflicts).  It's arbitrary what the first and the second
_mean_, so you just put them first and second on screen and give them A
and B as monikers.

And since nobody would suspect that you have first B, then A, even
omitting them from the mode lines works fine.

The only reliable _meaning_ is, if at all, in the conflict markers.

For a straightforward diff (rather than a conflict merge), again it's
natural to have the original before the diff left, and the patched file
right.

If the user has to puzzle out how additional, differently named and
actually _unrelated_ information relates to the buffer names, stuff
becomes hard.

I don't actually care all that much whether you want to make smerge-mode
an intellectual challenge, but I'm using smerge-ediff alone all the
time, and there "MINE" and "OTHER" are a clearly entirely unhelpful
distraction.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

> Whenever you use _meaning_-carrying names, they'll be wrong half of the
> time.  Ediff got that right with A, B, and, uh, C?  No idea (rarely use
> three-way conflicts).  It's arbitrary what the first and the second
> _mean_, so you just put them first and second on screen and give them A
> and B as monikers.

For three-way merges, the 3rd is called "BASE" in smerge, which makes
sense, no matter how you get that result.  Using A/B/Base is not great
because of the conflicting first letter of B and Base.
Maybe we could go with X/Y/Base?

> I don't actually care all that much whether you want to make smerge-mode
> an intellectual challenge,

Now that was a constructive side remark,


        Stefan

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Whenever you use _meaning_-carrying names, they'll be wrong half of the
>> time.  Ediff got that right with A, B, and, uh, C?  No idea (rarely use
>> three-way conflicts).  It's arbitrary what the first and the second
>> _mean_, so you just put them first and second on screen and give them A
>> and B as monikers.
>
> For three-way merges, the 3rd is called "BASE" in smerge, which makes
> sense, no matter how you get that result.  Using A/B/Base is not great
> because of the conflicting first letter of B and Base.
> Maybe we could go with X/Y/Base?

Well, I don't see why "BASE" needs to have a meaning-carrying name while
the others don't, but it could be "C" for "Common ancestor".  Or "R" for
"Root".  But the latter is probably a really bad idea in connection with
ediff bindings.

-- 
David Kastrup

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

() Stefan Monnier <monnier@iro.umontreal.ca>
() Wed, 27 Nov 2013 15:46:59 -0500

   For three-way merges, the 3rd is called "BASE" in smerge, which makes
   sense, no matter how you get that result.  Using A/B/Base is not great
   because of the conflicting first letter of B and Base.
   Maybe we could go with X/Y/Base?

You can also think of A/B/Common, in which case C is fine.
That's what i do.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful

[Stefan Monnier]

> You can also think of A/B/Common, in which case C is fine.
> That's what i do.

That migth work.  The down side is that visually they are presented as
A/Common/B, which makes the lettering less intuitive.  We could go for
A/Base/C, but then for the 2-way situation (which, BTW, I despise) we'd
have A/C which will probably feel odd to the user, or use A/B but then
the "B" doesn't really corresponds to the "B" of the 3-way case.


        Stefan