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#25410: 26.0.50; Refine an unified diff hunk only if adds lines Date: Wed, 11 Jan 2017 00:07:28 +0900 (JST) Message-ID: References: <8737grz0q3.fsf@gmail.com> <8737gr0zbn.fsf@users.sourceforge.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 1484061066 9848 195.159.176.226 (10 Jan 2017 15:11:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 10 Jan 2017 15:11:06 +0000 (UTC) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Cc: 25410@debbugs.gnu.org, Tino Calancha To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 10 16:10:56 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 1cQy4Y-00018F-0U for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Jan 2017 16:10:50 +0100 Original-Received: from localhost ([::1]:47929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQy4c-0005W9-Bv for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Jan 2017 10:10:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cQy1t-00044w-AQ for bug-gnu-emacs@gnu.org; Tue, 10 Jan 2017 10:08:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cQy1q-0005n7-4H for bug-gnu-emacs@gnu.org; Tue, 10 Jan 2017 10:08:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33645) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cQy1p-0005n3-UV for bug-gnu-emacs@gnu.org; Tue, 10 Jan 2017 10:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cQy1p-0003x0-QI for bug-gnu-emacs@gnu.org; Tue, 10 Jan 2017 10:08: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: Tue, 10 Jan 2017 15:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25410-submit@debbugs.gnu.org id=B25410.148406085915156 (code B ref 25410); Tue, 10 Jan 2017 15:08:01 +0000 Original-Received: (at 25410) by debbugs.gnu.org; 10 Jan 2017 15:07:39 +0000 Original-Received: from localhost ([127.0.0.1]:49044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQy1S-0003wN-4r for submit@debbugs.gnu.org; Tue, 10 Jan 2017 10:07:39 -0500 Original-Received: from mail-pf0-f194.google.com ([209.85.192.194]:34183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cQy1Q-0003w9-Rz for 25410@debbugs.gnu.org; Tue, 10 Jan 2017 10:07:37 -0500 Original-Received: by mail-pf0-f194.google.com with SMTP id y143so8284828pfb.1 for <25410@debbugs.gnu.org>; Tue, 10 Jan 2017 07:07:36 -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=TG5xc2b+9NhbDpg57tLpdYKPNIgAcbZeeou7Bh+A3v0=; b=iRcZmZojtpBzhIzeglSOL8L+1kyqJVcMV0eu2ERfoqHrbqz+UHtHnpQS5iPI1cBmm5 Y8KAschJddzSA9RrBkJXvayf4A8iYQtGYV3Ua3iaGg5Lq1VC7ZVV7bnztmtoTFUkcQA3 60wP6T/uyjEEAR8WTnGRKakLXoVRqnLYfDgNh3PYs+j6MmRWkfZvyoNs+NUTR9Uqf96F 5/6ejNFjW8fQ2X1laeW8hy2Y6QcVapbXvmA+0W5bwsdP4pMnBaXL6VF8eiKRE7lQycGb RUu89G76Z2Sq9nUhUCNtxTpkOerTORsIvDrj7cLvFoIiFpiDKtfUKmkojJqJN7WYkouC XZbw== 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=TG5xc2b+9NhbDpg57tLpdYKPNIgAcbZeeou7Bh+A3v0=; b=VOBVwpgqS1PjxFfC8FCcgc8CX00vsrRouqXZN+8gb9kXJWhnK60iwraQy7g27csKLF WiW0Bv6fcPbq1758MVhbO8sCQtyw+cnTipR1UNltF78GFOUmY57mpOMGGMzjtAETS/sZ KnAo+UguxAOJ0WrPRKcXg+C4FDDmH1iRMnV4f1T2A2DSaT9gG5JYfcMFe9v79Uj7Dkeq vsdRHPEbcX2YDNHOKNkcttz0NtABtE1oQUXRvh6BdHrv/vTET3Ig4VUqxeN9FjWnE3YO +SO9MRjoOl8gXoCbID3a5nejMgJZ/jtGOzlIoOUH8InGin2MJ9wJqv5KpK1RXNHcQ0yx VEGA== X-Gm-Message-State: AIkVDXLkl1izTrkH1Hbxmgy/0zuuFO2qNkWxGFebUDCcvBtpSp6CfU+hreSZdTqd/weoTA== X-Received: by 10.98.220.91 with SMTP id t88mr4378009pfg.78.1484060850908; Tue, 10 Jan 2017 07:07:30 -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 q190sm6533641pfb.51.2017.01.10.07.07.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 07:07:30 -0800 (PST) X-Google-Original-From: Tino Calancha X-X-Sender: calancha@calancha-pc In-Reply-To: <8737gr0zbn.fsf@users.sourceforge.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:127961 Archived-At: On Tue, 10 Jan 2017, npostavs@users.sourceforge.net wrote: > Tino Calancha writes: > >> After deletion of a large file from CVS, a diff shows >> a very large hunk with just deleted lines. Then, for unified diffs, a call >> to `diff-refine-hunk' on that hunk takes a huge time. >> Instead, it's better to first check if the hunk adds new lines: only when >> this is true, then proceed with the hunk refinement. > > What about a diff that adds a very large file? Perhaps we should only > refine if there added lines *and* deleted lines? On Tue, 10 Jan 2017, npostavs@users.sourceforge.net wrote: >What about a diff that adds a very large file? Perhaps we should only >refine if there added lines *and* deleted lines? That's logical; at the end neither a hunk just deleting nor one just adding lines need to be refined. We might do that if you like. It would be more symmetrical. >From a performance point of view, current code in the case where the hunk just adds lines is not as patological as the opposite one. For instance: emacs -Q M-! git diff ef8c9f8^ ef8c9f8 RET C-x o C-x C-q M-x diff-mode RET R ; Reverse the direction of the diffs. C-c C-b ; Refine hunk. ;; Perform reasonably fast.