From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: smerge-ediff "MINE" and "OTHER" monikers unhelpful Date: Wed, 27 Nov 2013 19:07:13 +0100 Message-ID: <87vbzdd8ha.fsf@fencepost.gnu.org> References: <87zjowpn2s.fsf@fencepost.gnu.org> <87a9gvnreg.fsf@fencepost.gnu.org> <8761ref7hy.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385575647 621 80.91.229.3 (27 Nov 2013 18:07:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Nov 2013 18:07:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 27 19:07:33 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VljWN-0003jc-Sb for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2013 19:07:31 +0100 Original-Received: from localhost ([::1]:37163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljWN-0000lu-DQ for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2013 13:07:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljWJ-0000lm-HO for emacs-devel@gnu.org; Wed, 27 Nov 2013 13:07:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VljWI-00041E-4P for emacs-devel@gnu.org; Wed, 27 Nov 2013 13:07:27 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljWI-00041A-12 for emacs-devel@gnu.org; Wed, 27 Nov 2013 13:07:26 -0500 Original-Received: from localhost ([127.0.0.1]:51500 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VljWH-0005QR-3M; Wed, 27 Nov 2013 13:07:25 -0500 Original-Received: by lola (Postfix, from userid 1000) id D175FE0498; Wed, 27 Nov 2013 19:07:13 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Wed, 27 Nov 2013 12:37:58 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165809 Archived-At: Stefan Monnier 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