unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
       [not found] <87zjowpn2s.fsf@fencepost.gnu.org>
@ 2013-11-23  1:42 ` Stefan Monnier
  2013-11-23  6:23   ` David Kastrup
  2013-11-23 14:07   ` David Kastrup
  0 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2013-11-23  1:42 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-23  1:42 ` smerge-ediff "MINE" and "OTHER" monikers unhelpful Stefan Monnier
@ 2013-11-23  6:23   ` David Kastrup
  2013-11-23 14:33     ` Stefan Monnier
  2013-11-23 14:07   ` David Kastrup
  1 sibling, 1 reply; 14+ messages in thread
From: David Kastrup @ 2013-11-23  6:23 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-23  1:42 ` smerge-ediff "MINE" and "OTHER" monikers unhelpful Stefan Monnier
  2013-11-23  6:23   ` David Kastrup
@ 2013-11-23 14:07   ` David Kastrup
  2013-11-25 15:40     ` Stefan Monnier
  1 sibling, 1 reply; 14+ messages in thread
From: David Kastrup @ 2013-11-23 14:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- 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

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-23  6:23   ` David Kastrup
@ 2013-11-23 14:33     ` Stefan Monnier
  2013-11-23 15:03       ` David Kastrup
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2013-11-23 14:33 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-23 14:33     ` Stefan Monnier
@ 2013-11-23 15:03       ` David Kastrup
  0 siblings, 0 replies; 14+ messages in thread
From: David Kastrup @ 2013-11-23 15:03 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-23 14:07   ` David Kastrup
@ 2013-11-25 15:40     ` Stefan Monnier
  2013-11-27 10:45       ` David Kastrup
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2013-11-25 15:40 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-25 15:40     ` Stefan Monnier
@ 2013-11-27 10:45       ` David Kastrup
  2013-11-27 17:37         ` Stefan Monnier
  0 siblings, 1 reply; 14+ messages in thread
From: David Kastrup @ 2013-11-27 10:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 10:45       ` David Kastrup
@ 2013-11-27 17:37         ` Stefan Monnier
  2013-11-27 18:07           ` David Kastrup
  2013-11-27 18:45           ` David Kastrup
  0 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2013-11-27 17:37 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 17:37         ` Stefan Monnier
@ 2013-11-27 18:07           ` David Kastrup
  2013-11-27 18:45           ` David Kastrup
  1 sibling, 0 replies; 14+ messages in thread
From: David Kastrup @ 2013-11-27 18:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 17:37         ` Stefan Monnier
  2013-11-27 18:07           ` David Kastrup
@ 2013-11-27 18:45           ` David Kastrup
  2013-11-27 20:46             ` Stefan Monnier
  1 sibling, 1 reply; 14+ messages in thread
From: David Kastrup @ 2013-11-27 18:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 18:45           ` David Kastrup
@ 2013-11-27 20:46             ` Stefan Monnier
  2013-11-27 20:54               ` David Kastrup
  2013-11-28  8:44               ` Thien-Thi Nguyen
  0 siblings, 2 replies; 14+ messages in thread
From: Stefan Monnier @ 2013-11-27 20:46 UTC (permalink / raw)
  To: David Kastrup; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 20:46             ` Stefan Monnier
@ 2013-11-27 20:54               ` David Kastrup
  2013-11-28  8:44               ` Thien-Thi Nguyen
  1 sibling, 0 replies; 14+ messages in thread
From: David Kastrup @ 2013-11-27 20:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-27 20:46             ` Stefan Monnier
  2013-11-27 20:54               ` David Kastrup
@ 2013-11-28  8:44               ` Thien-Thi Nguyen
  2013-11-28 18:31                 ` Stefan Monnier
  1 sibling, 1 reply; 14+ messages in thread
From: Thien-Thi Nguyen @ 2013-11-28  8:44 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
  2013-11-28  8:44               ` Thien-Thi Nguyen
@ 2013-11-28 18:31                 ` Stefan Monnier
  0 siblings, 0 replies; 14+ messages in thread
From: Stefan Monnier @ 2013-11-28 18:31 UTC (permalink / raw)
  To: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-11-28 18:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <87zjowpn2s.fsf@fencepost.gnu.org>
2013-11-23  1:42 ` smerge-ediff "MINE" and "OTHER" monikers unhelpful Stefan Monnier
2013-11-23  6:23   ` David Kastrup
2013-11-23 14:33     ` Stefan Monnier
2013-11-23 15:03       ` David Kastrup
2013-11-23 14:07   ` David Kastrup
2013-11-25 15:40     ` Stefan Monnier
2013-11-27 10:45       ` David Kastrup
2013-11-27 17:37         ` Stefan Monnier
2013-11-27 18:07           ` David Kastrup
2013-11-27 18:45           ` David Kastrup
2013-11-27 20:46             ` Stefan Monnier
2013-11-27 20:54               ` David Kastrup
2013-11-28  8:44               ` Thien-Thi Nguyen
2013-11-28 18:31                 ` Stefan Monnier

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).