From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation Date: Fri, 16 Dec 2016 03:05:28 +0200 Message-ID: <450ce252-418d-ccdc-7310-092146a13c90@yandex.ru> References: <874m2q1oca.fsf@gmail.com> <4707af57-53ae-9b10-686a-1ca0864b9abb@yandex.ru> <87h96cr2su.fsf@secretsauce.net> <59e902d2-e8b4-63e3-f780-af24cdf50a74@yandex.ru> <9fe241fa-d4ee-6e44-bfdd-99cb6b4ab4e4@yandex.ru> <87fultr4he.fsf@secretsauce.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1481850386 30080 195.159.176.226 (16 Dec 2016 01:06:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 01:06:26 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 Cc: emacs-devel@gnu.org, Tino Calancha To: Dima Kogan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 02:06:19 2016 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 1cHgyV-0006Lb-MJ for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 02:06:15 +0100 Original-Received: from localhost ([::1]:57704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHgyZ-0001ed-Rm for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2016 20:06:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46241) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHgxt-0001Zt-R2 for emacs-devel@gnu.org; Thu, 15 Dec 2016 20:05:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHgxo-0001Rv-Py for emacs-devel@gnu.org; Thu, 15 Dec 2016 20:05:37 -0500 Original-Received: from mail-wj0-x244.google.com ([2a00:1450:400c:c01::244]:34089) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cHgxo-0001RE-Kg for emacs-devel@gnu.org; Thu, 15 Dec 2016 20:05:32 -0500 Original-Received: by mail-wj0-x244.google.com with SMTP id xy5so12261494wjc.1 for ; Thu, 15 Dec 2016 17:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7HRI9/Gz3LNsnbFsuKBgaxHylAQ/FPID8dItj6KNEVU=; b=TYSrxjfBcDlZQiFq3fiPAX0tfIj0bx9YhuI0qDXhG33CqClXOoWPmIfaQV6hucHXqJ A8cgWHTbTf2yoo/4JLIYYJruvJH01cPAxXS6daQDg1ZKKyZ6k24STTsf1xCYv2F4KePw XbwI5DqGLBykLl+FM4m3/WysQRLdJdffwt4UBkbuT1mbeRFwBHdvEDVSXhill4VO/NrB tHUaQgPRRGMsEzPGx9QTquLOW83GD48QTH6yvwrC9PLlljGv4uksCjQ6weAr6RdcKQ2o D0VYFnhizqETY3n6+3xFkTbBtW4LeL/aFUwtJdx+zDlce0sNMdAl5AV6fUXGiY+zDdaz ShsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7HRI9/Gz3LNsnbFsuKBgaxHylAQ/FPID8dItj6KNEVU=; b=qCksQh2QLIV3fwqa6G4lDmERXFDiAGC9aKXWEgPexCVO4yzfwR9XIrDRpP7GHJ9xEz E/biSJ3KoM8Rhk8n2urVzBVqmujmyHjggTVymg0rtDMolpXWGuAZcaWAFB8MzfF9wDSI iIioTnDWGtwBQ4doQIpF1IoTEInYLTqH+F3NGfqCzlDCMrAx4+Wc7S2ttEbNhqG31YgT bN93EB5PJfAjKCMgYFn32S/yq3NO/2fyDpGWS4tN9mYnj3mZIqZUw4RhK8NgD1KLwr97 pJM6K/slkdZnGHlC6CWiqpVp5LbD90yFbc/Ewo2EvBdd+d6mewraN/kCqExROvDuFVLq YYyQ== X-Gm-Message-State: AIkVDXLpEEzXCwhBCEvC409L71HPu3k+x2gACHcJFvcFVJjAOWNZwnJHVUddIZDq3dC6gg== X-Received: by 10.194.66.37 with SMTP id c5mr237922wjt.138.1481850331156; Thu, 15 Dec 2016 17:05:31 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id n17sm4442253wjq.6.2016.12.15.17.05.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Dec 2016 17:05:30 -0800 (PST) In-Reply-To: <87fultr4he.fsf@secretsauce.net> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c01::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:210492 Archived-At: On 12.12.2016 09:28, Dima Kogan wrote: > Hi. I played around with this, and I now really don't like this idea > because it would mean that diff-hunk-next no longer always moves to the > next hunk. We have other commands that behave this way. beginning-of-defun and end-of-defun, for instance. You could say they're named differently, but I think the uniformity of behavior is more important. > At the last hunk, diff-hunk-next would stay on the SAME hunk > if this was implemented. It would go beyond the last hunk, wouldn't it? > Furthermore, I think invoking auto-refinement in diff-mode-hook makes > sense. From a strict and logical point of view, maybe. But not from the user convenience point of view. I don't think we should exchange the latter for the former. > And I think that this should happen even if the first hunk is large. > This would indeed be slow, but this is AUTO refinement. Again, words are important, but it's up to us as developers to choose how to interpret them for maximum user benefit. > If you want to > decide when refinement should or should not happen, auto-refinement is > not what you want. It's worked quite well before. > We can add a variable to block auto-refinement for > hunks larger than some size, which probably would be a good idea anyway. That sounds finicky. It would be hard to find the value that's good for all kinds of diffs, users and differently performing computers. > I fixed the incorrect behavior where auto-refinement was kicking in even > when the navigation failed and we signalled an error. That's something, I guess. > Not attaching any patches yet. Let's agree on an approach, and then talk > implementation. I'm sorry for not proposing a particular course of action. If nobody has a good suggestion aside from a revert (which we obviously want to avoid), I'll try to dig in sometime later (January at the earliest).