From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.bugs Subject: bug#25105: 26.0.50; diff navigation is broken Date: Sat, 07 Jan 2017 14:16:35 -0800 Message-ID: <87o9zicy7w.fsf@secretsauce.net> 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 X-Trace: blaine.gmane.org 1483827446 27140 195.159.176.226 (7 Jan 2017 22:17:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 7 Jan 2017 22:17:26 +0000 (UTC) User-Agent: mu4e 0.9.17; emacs 26.0.50.1 Cc: mvoteiza@udel.edu, Dmitry Gutov , 25105@debbugs.gnu.org, npostavs@users.sourceforge.net To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 07 23:17:20 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 1cPzIc-0005XT-4j for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2017 23:17:18 +0100 Original-Received: from localhost ([::1]:59359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPzIX-00083Z-QD for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Jan 2017 17:17:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPzIR-00082K-4P for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 17:17:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPzIM-0001Nf-5z for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 17:17:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59084) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cPzIM-0001NV-27 for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 17:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cPzIL-0005s8-TK for bug-gnu-emacs@gnu.org; Sat, 07 Jan 2017 17:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dima Kogan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2017 22: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.148382739922540 (code B ref 25105); Sat, 07 Jan 2017 22:17:01 +0000 Original-Received: (at 25105) by debbugs.gnu.org; 7 Jan 2017 22:16:39 +0000 Original-Received: from localhost ([127.0.0.1]:46250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPzHz-0005rU-FD for submit@debbugs.gnu.org; Sat, 07 Jan 2017 17:16:39 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:53690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cPzHy-0005rM-Br for 25105@debbugs.gnu.org; Sat, 07 Jan 2017 17:16:38 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D5E8F20922; Sat, 7 Jan 2017 17:16:37 -0500 (EST) Original-Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 07 Jan 2017 17:16:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=9wpiZufGqCdr6lThqibgEZZ3tAM=; b=dhA8Yo FmmHaESB7UPOnOcNX+BINX9McB8ZTrOXkxnUSlY26jLqx+s1plN9QG1Gsje86OU5 5y/FvvYOgeAdzVkKV3prtrHBsNZ2DBru/BIPCKblRkL2WjlxRHVlmigGfi/xj7u5 KBd4oy/A9YuZ7Q3/d3TWMYXwYiMWE7R7hvHP8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=9wpiZufGqCdr6l ThqibgEZZ3tAM=; b=ZZC7yTuwfDxFwktgqmzTEoILxAUy42zykMydfX30IG7noQ IC4hxdn99xO3gPvEo1BrTpccdhZO68JBN54BSK3b14xw/UrqOG3E+qXEgauqHg/8 Dd6uCN9yi4HxMsrtnhLtQ7X4dk5Vw5YhcJB8DUErg0nibzCGd4urIsAP7f8LM= X-ME-Sender: X-Sasl-enc: zodr/3mJvN97qVOa0Nh00ksZ0Y0aBohfceDab7t6gGgn 1483827397 Original-Received: from shorty.local (50-1-153-216.dsl.dynamic.fusionbroadband.com [50.1.153.216]) by mail.messagingengine.com (Postfix) with ESMTPA id 82D137E660; Sat, 7 Jan 2017 17:16:37 -0500 (EST) Original-Received: from dima by shorty.local with local (Exim 4.88) (envelope-from ) id 1cPzHv-0002Km-K8; Sat, 07 Jan 2017 14:16:35 -0800 In-reply-to: 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:127887 Archived-At: Tino Calancha writes: > On Sat, 7 Jan 2017, Dima Kogan wrote: > >>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. This clearly shows that it would be useful to have some binding that jumps to the beginning of the current hunk. But that's not the same as moving to the 'next' hunk, which is what 'n' ostensibly is supposed to do. >>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). Right. The choice is whether to revert the new behavior entirely, or to leave it in with a switch. Since we're looking at a small sample here, it's not clear which is the right move. >>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! Great! dima