From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation Date: Thu, 5 Jan 2017 21:58:11 -0500 Message-ID: <20170106025811.GA1101@holos.localdomain> References: <874m2q1oca.fsf@gmail.com> <878trtoluv.fsf@udel.edu> <874m2gfb9b.fsf@secretsauce.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1483671535 8477 195.159.176.226 (6 Jan 2017 02:58:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jan 2017 02:58:55 +0000 (UTC) User-Agent: Mutt/1.7.2+12 (2bc2ec9ac664) (2016-11-26) Cc: 25105@debbugs.gnu.org, emacs-devel@gnu.org, Tino Calancha To: Dima Kogan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 06 03:58:51 2017 Return-path: Envelope-to: ged-emacs-devel@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 1cPKjy-0001TK-4d for ged-emacs-devel@m.gmane.org; Fri, 06 Jan 2017 03:58:50 +0100 Original-Received: from localhost ([::1]:49790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPKk2-0000uV-08 for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2017 21:58:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPKjT-0000uQ-5c for emacs-devel@gnu.org; Thu, 05 Jan 2017 21:58:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPKjQ-0003Wl-4y for emacs-devel@gnu.org; Thu, 05 Jan 2017 21:58:19 -0500 Original-Received: from mail-qk0-x244.google.com ([2607:f8b0:400d:c09::244]:33738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cPKjP-0003VK-Vo for emacs-devel@gnu.org; Thu, 05 Jan 2017 21:58:16 -0500 Original-Received: by mail-qk0-x244.google.com with SMTP id n21so61034035qka.0 for ; Thu, 05 Jan 2017 18:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ewKOQLgjpNd1WsgXsv/QdHwvpPQsMQh9V9KbUj7EZaY=; b=rVoOVDvkYjr3R5IN/+Dfj8cHY9j0WLWR8QITnAvPrd3bE7itNrMUzy2tv3uh55CUF2 Ni3ZotBL9VbtyWJmfkunejIwCSrryBu7peAkOlCDW2OdSbEb9uzEnSGKuN07Jmm/5p2/ AsJ2Q32y0oTjkJLZXuJlufYZ1mPEpNqOcjg84RbS1nvZhfw1SBaT+B8j2T+/2l6GTt/w Bm08v1HKuvc5V7r/9MRx5vqCc0UuSfLMrHtXc9dXUseKFluoPs0Q7HIU8nyb/wB5Qq5j 7g2eujlcx9QJonFWEKnIVfQuPl+/pWUPC4Pcvqnb4PzudxM6nvTONpyDuOzJqGNaN9sV YyBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ewKOQLgjpNd1WsgXsv/QdHwvpPQsMQh9V9KbUj7EZaY=; b=mgKE7UUjJSWFhJU2tj6kYu967tjR6DnBQ7CJZouQ44EJ5xOph1bRO5IhvFdACoHc0c bLEd2z3YP5BEcod/Ks6rKpe5L9D8ut/RxC/sUyxa8MfhGmimvgizZbE513HEzmS5rYYi L9qRgjp9FpshUB1tJqDlq20zeV2iO+kW7ujGA88z3O4QMIUVjIDfD6s5v1QU5XgTlVV6 EV+UznK+03pFzgElT21I0YJU6RdI9H43G1yT/RKg6GTXjTAhnd9xYlTbb5ZdCBgaVodQ AQgMXWoHxWAa2QMqDksmVKlKdlX96N63RtvRE5o0l5iPu2OM+Skj/HpHbgczb0yTi9wm y4Zw== X-Gm-Message-State: AIkVDXIT/KB5GLhQHs+OGhbbQ2z4S4NZN05uX4RVji/55cIcP0yhU1D32ACnn6nSqqaODqEy X-Received: by 10.55.122.134 with SMTP id v128mr68610399qkc.111.1483671493745; Thu, 05 Jan 2017 18:58:13 -0800 (PST) Original-Received: from holos.localdomain (pool-173-67-40-97.bltmmd.fios.verizon.net. [173.67.40.97]) by smtp.gmail.com with ESMTPSA id e63sm49542474qkc.29.2017.01.05.18.58.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 18:58:12 -0800 (PST) Original-Received: by holos.localdomain (Postfix, from userid 1000) id 231A560D63; Thu, 5 Jan 2017 21:58:11 -0500 (EST) Content-Disposition: inline In-Reply-To: <874m2gfb9b.fsf@secretsauce.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c09::244 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:211140 Archived-At: On 06/12/16 at 11:29pm, Dima Kogan wrote: > Mark Oteiza writes: > > > Fixing C-c C-a to DTRT is great, thanks, but I don't think the > > off-by-one navigation changes to "n" and "p" (diff-hunk-next, > > diff-hunk-prev) make sense. While it may have made fixing the issues > > mentioned in the commit message easier, the changes to what "n" and "p" > > do at the beginning and end of a diff are not documented, and I didn't > > see any discussion of it in the associated bug. > > > > I contend that the new behavior is inconsistent with the behavior of > > other outline/thing-with-headers type things in Emacs. outline-mode, > > org-mode, and rst-mode are the first ones that come to mind. > > Can you give a specific example of interaction in any of these modes > that is analogous to the off-by-one behavior you're referring to? I wrote about how your changes are make diff-mode _not_ analogous. > The > fundamental question is what hunk diff-mode should think the point is > looking at, when it is in some non-diff message above the first hunk. > The answer I chose for the new navigation logic is "first hunk". You > could also choose "invalid hunk, not a hunk at all", which would imply > that C-c C-a and M-ret and such shouldn't work there. Better suggestions > welcome. One might argue that C-c C-a and friends in a file header should apply all hunks in a file, or perhaps that there should actually be diff-apply-file commands, etc. The way n and p worked was not a bug, yet you gratuitously changed them, and broke auto-refinement. Why do I have to now hit two keys to refine the first hunk, and one key to refine the second? > > It's also not clear how the introduced oddity with auto-refine is going > > to be resolved, unless a way is found to autorefine the first hunk > > without there being any user interaction. Then opening a diff has > > inconsistent auto-refining from the start. > > I don't use auto-refinement, so didn't notice the breakage. Will look at > it in a bit. It's on by default, so this statement perplexes me.