From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tino Calancha Newsgroups: gmane.emacs.bugs Subject: bug#25105: 26.0.50; diff navigation is broken Date: Sat, 7 Jan 2017 20:16:45 +0900 (JST) Message-ID: References: <87inpt6lce.fsf@gmail.com> <87tw9dc7bk.fsf@secretsauce.net> <87shoxc70l.fsf@secretsauce.net> <20170106030606.GB1101@holos.localdomain> <87lguovn5f.fsf@secretsauce.net> <83mvf4d3m9.fsf@gnu.org> <87pojzci4i.fsf@secretsauce.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Trace: blaine.gmane.org 1483787936 13998 195.159.176.226 (7 Jan 2017 11:18:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2017 11:18:56 +0000 (UTC) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Cc: Tino Calancha , npostavs@users.sourceforge.net, mvoteiza@udel.edu, Dmitry Gutov , 25105@debbugs.gnu.org To: Dima Kogan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 07 12:18:51 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPp1O-000310-Oe for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2017 12:18:50 +0100 Original-Received: from localhost ([::1]:57194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPp1T-0007qi-2V for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2017 06:18:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPozj-00074P-Ba for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 06:17:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPoze-0000Ku-CX for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 06:17:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58531) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cPoze-0000Ko-8t for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 06:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cPozd-00076G-Uh for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 06:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Tino Calancha Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2017 11:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25105 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25105-submit@debbugs.gnu.org id=B25105.148378781727278 (code B ref 25105); Sat, 07 Jan 2017 11:17:01 +0000 Original-Received: (at 25105) by debbugs.gnu.org; 7 Jan 2017 11:16:57 +0000 Original-Received: from localhost ([127.0.0.1]:45697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPozZ-00075u-JJ for submit@debbugs.gnu.org; Sat, 07 Jan 2017 06:16:57 -0500 Original-Received: from mail-pg0-f66.google.com ([74.125.83.66]:36469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPozX-00075f-Jp for 25105@debbugs.gnu.org; Sat, 07 Jan 2017 06:16:56 -0500 Original-Received: by mail-pg0-f66.google.com with SMTP id 75so8376062pgf.3 for <25105@debbugs.gnu.org>; Sat, 07 Jan 2017 03:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=bw+1/gU3EuKuFzv4k+JZWOr9VaWrqYult7b7TLNfeRc=; b=LOj5dyCSYxMbLHOWXPeFnBE77nBPb6xIPYJ3+TixC8X8PNIRfNUmjrneQOwfq2PmqU Oxu4m37XHjA8Uh+OGZx70saAyPN6Tb0x2vRHcZYvRgrWZtxo0+cljJDYgY+dq/SV27JM kapiobpO+y+s4OE6hL6K3JMo+KJU9tWCQeJoWwylu4j1tnhgCMAu3U2XTaWaF+6sIxKO KiOEXcVNQhwfz7Zvgm5zjeZaryO7b40PaYAsWRB+I0OTFxHuojZawkXUQAbS2yC4ieaQ OEpeHEt+dKEfcTCWVG3N8nFiz4P6eYlNYWtAspGmeGTLzzGSpMvodcLNPckJVJQJtrPW J69Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=bw+1/gU3EuKuFzv4k+JZWOr9VaWrqYult7b7TLNfeRc=; b=JnxhX3m+dbWOn+81S33hNWHNp1lAGiMOsgKqtSEV1FBIYNCC2mUOj3ChXT5qJES5Vy R4GppYOM4oV2DpfeMiQ1TI9zBg/2ea+XiUXsC3prPnYkk/7WlZYDOLAkzzxAwHMTCeqG Io36xb8/bp1IDFDbCCoZIgp0c+7AhQjszXY+AOuovcSQO/9jlATbHnxfA5Erei2Nfsod 8oIm9/thU1zYKaQ4C3AzZ64DPqhXR4AR9Ikg60WABNwvkyGm6Noe4H0taQJhR20pnmPG SEDjxoVt8KAcIdQCwjncI0kUIAdzlXw+DePYUKMrSzJyDfGRfb1ARD823Un9pwTU3B+G dqpg== X-Gm-Message-State: AIkVDXIc00I/4CidhgA9uN5+3hFCW+Tq/Gif54xm5HjbYEb8N4s9E7HQmx020Z6392QEIA== X-Received: by 10.84.129.131 with SMTP id b3mr173156378plb.54.1483787809759; Sat, 07 Jan 2017 03:16:49 -0800 (PST) Original-Received: from calancha-pc (217.225.128.101.dy.bbexcite.jp. [101.128.225.217]) by smtp.gmail.com with ESMTPSA id v73sm16795506pfa.45.2017.01.07.03.16.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Jan 2017 03:16:48 -0800 (PST) X-Google-Original-From: Tino Calancha X-X-Sender: calancha@calancha-pc In-Reply-To: <87pojzci4i.fsf@secretsauce.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127875 Archived-At: On Sat, 7 Jan 2017, Dima Kogan wrote: Dear Dima, i appreciate very much your efforts to improve diff-mode. In particular, i like 1. and 2. in your commit message. That are useful goals. I just disagree with the implementation. In summary, i believe a better approach is to get 1., 2. without affecting the behaviour of `n', `p'. > 1. It should be possible to place the point in the middle of a diff > buffer, and press M-k repeatedly to kill hunks in the order they appear > in the buffer. With the point on hunk1, M-k M-k would kill hunk1 then > hunk2. With the point on hunk3, it would kill hunk3 then hunk4; this is > fine. However, with the point on hunk2, it'd kill hunk2 then hunk1. > This is fixed by this patch. > > 2. Similarly, it should be possible to apply hunks in order. Previously > with the point at the start, C-c C-a would apply the hunk1, then move > the point to the first @@ header, and thus C-c C-a would try to apply > the same hunk again. Your patch is invasive: it should be possible to get 1) an 2) above without redefining a long standing behaviour for `diff-hunk-next' and `diff-hunk-prev'. In addition, that change in `n' and `p' would deserve a more prominent explanation in the commit message, f.i., a new dot 3., so people would be aware of this subtle change. >Let's look at the commands required to apply hunks 1 and 2 in a buffer >versus just hunk 2. Assuming we're at bob, and assuming we're using the >new code. > > Applying hunks 1 and 2: C-c C-a C-c C-a; i.e. apply 1, apply 2 > Applying hunk 2 only: M-n C-c C-a; i.e. skip 1, apply 2 > >If M-n works the way it did before, then you need to invoke M-n twice to >apply hunk 2 only. I claim this is weird, since it should require only >one command to "skip 1". This is what is meant by a "consistent" >behavior. Well, not everyone follow that logic. I like to read carefully the hunks of a patch _before_ decide to apply then. I can do that with easy using `n' and `p' keys. If the commit message is long, as in your commit 2c8a7e5, then an user need `n' to jump to the first hunk and read it; but after your patch the first hunk is skipped. Then the user need to be a believer and apply it without seeing it using `C-c C-a'; non believer users, might prefer to rewind and read the hunk as follows: M-! git show 2c8a7e5 RET C-o C-x C-q M-x diff-mode RET n ;; we are at 2nd hunk, i.e., at line: @@ -570,7 +570,102 @@ diff--auto-refine-data ;; Assuming no split window, so we can see clearly the first hunk; ;; after looking at it carefully, we decided is good, so let's apply it: p ; jump to 1st hunk: this is _extra_ compared with Emacs-25! C-c C-a So, it might be argued that this patch force users to gratuitously push _always_ an extra `p' to read/apply the first hunk of _every_ patch. That makes hunk navigation much less pleasant. >Furthermore, I'd like to get some feedback from more than just the few >people active on this thread. If there's a lopsided preference to the >old approach, we can simply revert and move on. As a rule of thumb, if i get N people here uncomfortable with one of my patches on master branch, i believe that can easily be translated to (* 100 N) people once the patch is in a stable release (at least). >I'm fine with a switch that lets you pick what you >want. As stated above, I don't think a hybrid approach makes sense, >since it takes one weird thing and converts it to another thing that's >weird in a different way. FWIW, I am working in an alternative patch: it would satisfy your 1. and 2. while respecting `n' and `p'. Stay tune! Best regards, Tino