unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful
Date: Wed, 27 Nov 2013 19:07:13 +0100	[thread overview]
Message-ID: <87vbzdd8ha.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <jwvppplhhrf.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 27 Nov 2013 12:37:58 -0500")

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



  reply	other threads:[~2013-11-27 18:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 [this message]
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

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=87vbzdd8ha.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --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).