From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dima Kogan Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation Date: Sat, 10 Dec 2016 09:27:44 -0800 Message-ID: References: <874m2q1oca.fsf@gmail.com> <4707af57-53ae-9b10-686a-1ca0864b9abb@yandex.ru> <87h96cr2su.fsf@secretsauce.net> <59e902d2-e8b4-63e3-f780-af24cdf50a74@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1481391013 2617 195.159.176.226 (10 Dec 2016 17:30:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Dec 2016 17:30:13 +0000 (UTC) User-Agent: K-9 Mail for Android Cc: emacs-devel@gnu.org, Tino Calancha To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 10 18:30:09 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 1cFlTL-0007XC-Cu for ged-emacs-devel@m.gmane.org; Sat, 10 Dec 2016 18:30:07 +0100 Original-Received: from localhost ([::1]:52564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFlTL-0003Rx-Rh for ged-emacs-devel@m.gmane.org; Sat, 10 Dec 2016 12:30:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFlRS-0002kK-2x for emacs-devel@gnu.org; Sat, 10 Dec 2016 12:28:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFlRO-0003ih-VV for emacs-devel@gnu.org; Sat, 10 Dec 2016 12:28:10 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42473) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cFlRO-0003iC-PM for emacs-devel@gnu.org; Sat, 10 Dec 2016 12:28:06 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DC79F20CC7; Sat, 10 Dec 2016 12:28:05 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 10 Dec 2016 12:28:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=secretsauce.net; h=cc:content-transfer-encoding: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=t36 6YT3d6Japk1bR+nVvl7jw2A8=; b=DoiMzQKGjgMgWzRosehOy3TwF5SMK3DQ5f4 aYFDlwUCFEkH/heCMLkHTh2OJxD8ljxCiTh4NV0PJtDZCnitffRTVZNmyqY0973j oPkj4VxZd5XT9edYtN23sUZ+h7TQX8L6eEHUflg2LVRQSVSOg2mBJMVDsggHRGcH DYbLQ+ZM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=t366YT3d6Japk1bR+nVvl7jw2A8=; b=Xgcj4N+M49AAT97Q2o8N q3lJHtd+5PT5VHmOsMv19fmvvnNcWVwRYfEeJUVSoBWz110NmxGcU8ZUHQbL6Krm en1IfCciPQf0AOLkhQD9/Z7+iyAg0+BFUhZBats7YW/M/NHtBObULRIP1MOhQBez poRoSZ7yKkud4iYdBZk6j40= X-ME-Sender: X-Sasl-enc: eZWyqunObTDU2ZCsqal5fqI/mmmrlzajq0/RbedmKwC3 1481390884 Original-Received: from [33.239.98.111] (unknown [172.56.6.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 471C024428; Sat, 10 Dec 2016 12:27:53 -0500 (EST) In-Reply-To: <59e902d2-e8b4-63e3-f780-af24cdf50a74@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.111.4.28 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:210240 Archived-At: On December 10, 2016 2:14:41 AM PST, Dmitry Gutov wrote: >On 10.12.2016 03:27, Dima Kogan wrote: > >> I'm unclear about what the complaint is. Both the old and new >behaviors >> made the auto-refinement do its thing. Is the complaint that the >point >> no longer moves to the end (and if so, why is that "right"?) or is >the >> "ding" the "problem? > >Sorry, let me clarify. > >The first complaint is that, yes, point doesn't move to the end >anymore. >Foremost, I'm simply used to the old behavior. Second, I'm not sure how > >to implement on-demand refining of the first hunk in a sane fashion >without it, see below. > >Third, it's simply handy if the first hunk is taller than the height of > >the window, I would navigate to its end to examine it. Fourth, I'd see >the end of the buffer myself before the next pressing of `n' invokes a >"ding". > >The second complaint is that the command does a "ding" (informing me >that I did something wrong), and then proceeds to do something useful: >refining the hunk. > >> OK. The logic in place is to auto-refine the hunk at point after a >> motion, which is why you're seeing this behavior. Are you seeing this >> issue only with the first hunk in a buffer and only when you first >load >> such a buffer? > >Yes. > >> If so, an auto-refinement call from a diff-mode-hook >> would solve this. Sounds reasonable, or are such things frowned-upon? > >What if the first hunk is big and refining takes a lot of time? > >As it is now, I can make the choice to refine or not myself. If >`diff-mode-hook' does that, I won't even see the diff before refining >is >done. It sounds like "auto" refinement isn't what you really want. You want to ask emacs to refine the hunk you are on by invoking diff-next even though diff-refine-hunk makes more sense. For the other concerns, I can special-case the last hunk, and move to eob for diff-next, and to ding only if we're already at eob to begin with. That will give you the legacy behavior if there's only a single hunk, I think. Seems reasonable?