Received: (at 81375) by debbugs.gnu.org; 9 Jul 2026 11:16:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 09 07:16:26 2026 Received: from localhost ([127.0.0.1]:51321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whmjy-0000PC-00 for submit <at> debbugs.gnu.org; Thu, 09 Jul 2026 07:16:26 -0400 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:46459) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1whmjv-0000Ow-6X for 81375 <at> debbugs.gnu.org; Thu, 09 Jul 2026 07:16:23 -0400 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id 0FEC51400082; Thu, 9 Jul 2026 07:16:18 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Thu, 09 Jul 2026 07:16:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1783595778; x= 1783682178; bh=ryozLuUWpFLI72lJMfK8q7Mjki5LWCz943NZephX/0Q=; b=L +KIlM+PUCpdiSNcl/pAcX/DRw2VmM6WQj1Ch/x4JOt1gGPzriAA0nqA9XhpFiAYB R4Jpt2o3sExU+XH7zAIChnHsuCqOOZ8eKSg+hmmvSt3QXspOI6rXtAuEWJ4Ckek3 8/7ErtWsaBPyA1ojs6pnPRqUaZrql4FxJjCRqgGcV1UDbhZrLEwJp+MTWIAR4UfX 3SN5YFwxrtpJttlPoNFu0k4mjZBnAaMCA+hbkVcw9XpMu6vYxDWLXHJtS0ukMIO6 XrZJUB+B1P9iCfqPbkd1JYvEPps7f2u2/wO7yOLmwZjOZ0VJOQ7Kxn0cAZzf3R4s 0PMI+mSw2ZvaMi7rG8zBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783595778; x=1783682178; bh=ryozLuUWpFLI72lJMfK8q7Mjki5LWCz943N ZephX/0Q=; b=p7mWhO5aopd0rDLsjkft0ZXeChbpdbJxdrhWjJPEP1XSUO4ucq3 NWuLxJ1clscZOKsoksimcYfAEiCO72iEXEvdIR6qPov3v9CauD4u3mVpKUEs++35 vwetWhELmFYOiWbeE/8ERxV0sUmfmfZkjCK1V8pAEj6x4ADI68fMKUyhBhVe0wqr 3+dSGhiFDhR+8ST4QpeDh42SU8WxCgOEArDdz3H0BPOAVN4+y2eIDWqwhoGLWAEq KyUcjr6oJ49EidKutDg1DNRPEQqXhrpX+NUaQcz8XcV3dFJdMVHfP2LgYp2VuLPB jmYyZ+FJZ8LgF9z4/QjESW2zbJu3xhObw8w== X-ME-Sender: <xms:AYNPalFn82PJO_ZQI-Vlz0bfz6RihdeiNzs20mDV4tW09G2_Kt_vRg> <xme:AYNPahy782vr_zvHU8uSuZxUEcG06FI5G6n1CuW1ePdFJUfbcqZJZPrBBg-qoOxtD xQiqhS_TGUkCrXyzna7PLnMj7aDbkT4rWBIzgkTYtGijMa_jvLLOPM> X-ME-Received: <xmr:AYNPakjbL-swUdHmcwxvuRWE4b5rpLE2BNHsz8aWKxeZVAbteJVq2ROeGE6L4QrxbjbTzut0cug5> X-ME-Proxy-Cause: dmFkZTGQZSTIGqcFkz+tt6R9uQW3KJ/sx2ixSERqyr2m1x7ydq6hlN6/n0jm3sBxrmFFM/ z6tZ8gcJu0IlgZgmWqiVSME5aCqnPFncc5Wpw5HmxvBlpU6Dp+I8FPzG35TltVetMb+jtb 6SOGzuXFKpX19VsiYB2wVrf0GepaaJ9Z06fPGJ/BEwPCI+x9tZ37iH9AJesDJOe2erJc4Y cDtH/taHkO1u78xciOTsWSLlKZyF/v8lgNmMBqlz2Eg87Ph4sGCxyO5wmy/PflkHNOsYu5 9UymmQgW1kAWHtgQW/WH644L2tTMLtMIfo7yc/C5iLOIN59WCGwkBRtd6IPnjffI2ZDODz X0ZydgFNAlwAs4Un59fMbCvT7eXDRUc8ezz8iYPqeTuDCK9SS7ckce80/qJxtR9PqDI8NN x7DWuaBmBUruFIcsBHmaGbN7iqQDvT7qoPJ1360EQAhnjPAaymWg9oYx89HV/1k72umngM vp+d0JNOo0Czju9rIeYFzAReWxgovgHVCSzGWxkmBto465mzI5yo6Nu7UOarfGNq/2THdO wQyu9xfij6KMWcDaihoPz2aliq8cWEqxUTAu9FK6Q+gbqAEyM29ALXXiYkuOQmHVpC5/+A +Q6t18oWrjg3U5ie72L0twp5TbbJHL7AwpRlIwbzG96o8VaRT5BYJnVioqrg X-ME-Proxy: <xmx:AYNPakyRjaE7REQwVaNPtt2ELiHuf-UEev53FfCmCcCB_xm6gELbmg> <xmx:AYNPavKgQj6Y941p1dDvLbcQdJ9EZ_H89ByX9_BU2vQnLva9wWTshA> <xmx:AYNPajR0oaSpE8e7lxUhFHw8r4cfSWOhXdXqylSz6Cn1o6bIdf5ddQ> <xmx:AYNPavo76MyMYp-K39LnW0E-__PYu9a2G_4LRDdh0wBilLmd0SOlGQ> <xmx:AoNPajejCtU681tgVrAWKvyPyIUctnELLz3Uk9cvsL0jrYE6Lh3BN5DO> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Jul 2026 07:16:17 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id ACEFA7E746D; Thu, 09 Jul 2026 12:16:16 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Umar Ahmad <ahmad.umar2009@HIDDEN> Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks In-Reply-To: <86ldbk68hu.fsf@HIDDEN> References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> <86ldbk68hu.fsf@HIDDEN> Date: Thu, 09 Jul 2026 12:16:16 +0100 Message-ID: <875x2oifb3.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81375 Cc: 81375 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii [09/Jul 8:24am +03] wrote: > More generally, I'm not sure I understand why "useless" refinement is > at all a problem. It's easy to ignore it if it makes no sense. And > maybe we should have a command to remove the refinement from a hunk, > which should make ignoring such useless refinement even easier. I find it easy to ignore, too, but I can understand how some people might find it harder -- it also might depend on how bright it looks under their theme. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 9 Jul 2026 11:15:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 09 07:15:51 2026 Received: from localhost ([127.0.0.1]:51313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whmjP-0008Cv-G8 for submit <at> debbugs.gnu.org; Thu, 09 Jul 2026 07:15:51 -0400 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:34081) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1whmjL-0007t0-Q0 for 81375 <at> debbugs.gnu.org; Thu, 09 Jul 2026 07:15:49 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id 96CF7140006E; Thu, 9 Jul 2026 07:15:42 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 09 Jul 2026 07:15:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1783595742; x= 1783682142; bh=Wd7bc9JBCZ6IBPdS9NizdOmGY66oMpIwXgVgLzAgcww=; b=t QoMkcCV6rAmvSpIS3J6byNSdUO1qebQTimA13xk1oplE83zvMBNHjZHSS+SA1CYV TQ3G740zf3ZffFK3tmpsoPV6pa7bCyEO/UfD4WyCU7iSCRHLWBmbS16HSpZ4skTB rcU93VW0NnQyyj+pQcCysqskqSf39RxnkBVZtWTrKgbiR/vfYdoPeBHLYYjFLJ0T llIoWXsVRR3NEv6Vz2O87XTmrCcxudjgZlqOffUIGrrvTN36ZB/kd7OiyDyRfDTg BwkuamRiHc6V7iPpbG4N6YSLhiZQtNtuTfPnjpdiV7tBxgPgvOxMjkNSdkFCu2MT tcidqbsZflm1iuCFnA0WQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783595742; x=1783682142; bh=Wd7bc9JBCZ6IBPdS9NizdOmGY66oMpIwXgV gLzAgcww=; b=l/eKmbCk30FwfFiVUmKtC90ftRk4Af7vbN7UOv1TR+fOvEPo8cg DC4nQ1BzNscx/wEAnKuxFIuWBZ2Pjuppyt9FDyc3hceNyGTDtsb+I1l2txsjlmiY 2Z1ka01QIPrbZvlyEuQvp3VMASc4gceTx5OlKvT3EjcoVEmB2oTU8V78nbRTPFjI A5NkejBWP4BkSW14hnyE1UHaOhr88KbYZl0bi+m1FeY3agXBBLMWK+XIkqwUmTnC kn38Up8sAvfcPS143MHNTQdxGK/kATt/9rzMiuvW6EumEn1TyIYG57jEYK2hp/Zg hTCdTKu7LC9pODPe2kLDbTHwOKZqbsgRjCw== X-ME-Sender: <xms:3oJPancUS669GoWQ_zqieuwdaqZ1TxQbXfaO6gcTSdDZrYfJnZXCOw> <xme:3oJPajNAopIGOVEFVEO8f81ihHIBCxJWoL4GQjRnVZbo5AHvlwHmnizr1VoDeXD2i K2hfGubywep1wVOWFw6xlgNdxNOlnksczIb_At7qaJzSsAb4zX_MZY> X-ME-Received: <xmr:3oJPauIdENKAlGjWraUJKJghMu2a8P2A8EZXGPGl-LQTZsP9yJMk5KPmYtxtavJtoI965xUw44G8> X-ME-Proxy-Cause: dmFkZTEDrev9QePeba59t7r8uAfILepbfC6irFXYV5C5cp4rWAHEOvJlLKmS5wPnpa1vKE MhzMOm5VRNjAwHaKP9OlmE++a0S7wn3AbNVxV2etZKhPUpvFFHfCwl3qEMnrusxXUL10tp L4Mg0uKW2xjSp8zXpwxPI4UgQZpnWKj8OjfG4KDs8ScQKBCpKynxHYFwxU+BD1bm1MvYpu GjxOZddB3hR+3Z4thNbZzlmQ7L71jkT4pFseKnf+wjDjuvCPXTPJB77LGbh8uVd4lUDtbi leGUlsW99GlbHIo9b5pqo7Ep89etxKslWmBRF6i6GnOMstTBAqN/DGynzp2GXytrqOdvnF 8JMz+Vt4kZAJQRl0ztLBSxHgUzw8lTRnWl+rlzG6b3Rxiy/fZaoj7IvfukxvJlDaj42BbP XPd+THcEWjkFLF+3yesDO63JCks9WtTcosHSjnDiOU9on5eL1BUyM1GnxizbWmfALcHG6W YhheX1UXzA7U1n+nH7yksCHwLBpBk54KqXxLFz3dqMvtTDmw6CuvZFr+1bQaANuIZOBS/+ 2KJPIk7AbnT8mE+A3ebwijoe0zxq7n7s/o0tfZVr114GlT7ClQo3pLORPfiWZllckdA7hT iWMtBAKKekrAPDGE6ulQj/rzzqNSBNBwMk1hqJfyE65BoWI78n6rEc1IKHIQ X-ME-Proxy: <xmx:3oJPakEO6JsAcaFzVf0UEVJq1P4BC8bJzp5z6bJ4xB_Zo1zTQCcmng> <xmx:3oJPamT1Tkr77Zr3XFdJhk8FPeRhtxHC9VdnfgS_HBqhQTsEE0H36g> <xmx:3oJPagE_3iEMkajlE4R53T-uhUMrG2mb376bvbTYzMcsFQQHGitAgw> <xmx:3oJPai9svOYw8lMUHNPCarHuWHUJdI9OtiWoRnv4tsvtT9SrirzEJw> <xmx:3oJPava2wGnM1W5t70S584vbZBukaxU8QSvuDZq0p9MzVLORi2rbeapf> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Jul 2026 07:15:42 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id 6AD187E746D; Thu, 09 Jul 2026 12:15:41 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Umar Ahmad <ahmad.umar2009@HIDDEN> Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks In-Reply-To: <CAFHo54etG5R26UZjwAu-fm-wmUBBmmYCwpjpXnfo6enxd1-ydQ@HIDDEN> References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> <8733xtk3ni.fsf@HIDDEN> <CAFHo54etG5R26UZjwAu-fm-wmUBBmmYCwpjpXnfo6enxd1-ydQ@HIDDEN> Date: Thu, 09 Jul 2026 12:15:41 +0100 Message-ID: <878q7kifc2.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81375 Cc: 81375 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Umar Ahmad [08/Jul 8:38pm +0530] wrote: > Do you mean a flag to the external diff command that can control this > behavior? > > If so, I am not sure which existing option would solve this particular > issue. My point is that diff needs to learn a new option for this purpose. > I think there are two different splitting steps here. > > The original hunk boundaries are indeed decided by the external diff that > produced the patch. I agree that deciding those boundaries is diff's > territory. > > But the problematic step here happens later. `diff-mode' has already > received a hunk, and `smerge-refine-regions' then chops the selected > removed/added regions into token-per-line temporary files and invokes > external diff again to compute intra-hunk refinement. > > So I don't think this is about changing where file-level hunks are split. > It is about the second token-level refinement pass, and whether there is > a way to tell external diff not to align low-value/incidental matches in > that pass. I still think the external tool should be making this determination. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 9 Jul 2026 05:24:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 09 01:24:25 2026 Received: from localhost ([127.0.0.1]:49554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whhFJ-0002vh-Fy for submit <at> debbugs.gnu.org; Thu, 09 Jul 2026 01:24:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33584) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1whhFG-0002vG-PR for 81375 <at> debbugs.gnu.org; Thu, 09 Jul 2026 01:24:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1whhFB-00009h-As; Thu, 09 Jul 2026 01:24:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pRFJJUQdXj4nlonX3VYxYVWG/7AyrC4CiFbE042hAe0=; b=GEZ1+CeCu+B3 wTqRrAmemnkZf4itld2w0/WrxpA1ZTqd6OMY5jVTKzWqROsWgozZZjcD6IktLH5kbjWTmWHMGQFEc Q4MQAWNJABKYxqILV15SfyRMI0LwjYLmwoHNJksx/8MCdOZWw85V2lk1eEm/rvz9pRVXYogor394A n8VybIVa9pSTPk3cQBvqWsSvnvNtwDOjPw0jApf5RTVDOdYgApvYHHa+9+IKwoVq6jOatutRLClNd 3RntNxuEwj2KSlCLy1ceK+cZaQcaTOOatlOX3rtn0PIBJYVpqD7UD/Z7oDyBdq1tUdPe+mPfOHU3z +37P/4A1iExj+vBzZgA1wQ==; Date: Thu, 09 Jul 2026 08:24:13 +0300 Message-Id: <86ldbk68hu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Umar Ahmad <ahmad.umar2009@HIDDEN> In-Reply-To: <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> (message from Umar Ahmad on Wed, 8 Jul 2026 18:14:32 +0530) Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 81375 Cc: 81375 <at> debbugs.gnu.org, spwhitton@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 81375 <at> debbugs.gnu.org > From: Umar Ahmad <ahmad.umar2009@HIDDEN> > Date: Wed, 8 Jul 2026 18:14:32 +0530 > > The issue I am trying to address is more about when Emacs should ask for > fine refinement at all. For large or shape-mismatched replacement blocks, > the external diff result may be technically reasonable but not useful as > UI highlighting. In those cases line-level highlighting is clearer. > > That is why I suggested a guard before calling `smerge-refine-regions` > (or inside it before invoking external diff), based on region size or > line-count delta. We already have diff-refine-threshold, is that not enough? However, I'm not sure the size of the hunk is a reliable indicator of problematic refinement. Consider a large chunk of a program where almost every line has a variable or several variables renamed, something that frequently happens in refactoring. In this case, I believe refinement will show perfectly sensible results, or am I mistaken? More generally, I'm not sure I understand why "useless" refinement is at all a problem. It's easy to ignore it if it makes no sense. And maybe we should have a command to remove the refinement from a hunk, which should make ignoring such useless refinement even easier.
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 8 Jul 2026 23:24:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 19:24:16 2026 Received: from localhost ([127.0.0.1]:47910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whbci-0004QB-92 for submit <at> debbugs.gnu.org; Wed, 08 Jul 2026 19:24:16 -0400 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]:43385) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ahmad.umar2009@HIDDEN>) id 1whUot-0001Y7-Hn for 81375 <at> debbugs.gnu.org; Wed, 08 Jul 2026 12:08:21 -0400 Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-6a1840edbabso1668eaf.1 for <81375 <at> debbugs.gnu.org>; Wed, 08 Jul 2026 09:08:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783526893; cv=none; d=google.com; s=arc-20260327; b=FPIYTCrDC3EJvCw83M0RofWozipDj0LnFAqpEF2eeZZ8KZ5fWzQQBB+vtgJmEA1QwH cTUptLvT2fmlXL2e8ML6fz6wZ4+zM62sdZKlicyGexKFcGiuFPTWqld4eV+kHB4F+s1+ F0K+f19DydFdzelxC3yrou55nRXMCUFX00rD/LnI41MwmQ0X50+Ibi5nKlL80JDot4o5 khwmUDVMmsI9j0eTrmxxcVede8Bz+7bMXO6Lzdnz0Z8xHYJHF98RWji7fjgtUs1YeTkh nlqZKr8g27BLZ3kXDsdhi8jYSwdYi3ERZspJ3L5XK/TQZca2p7ghQs0He7U16wtrGI1Z IpVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RZ4o4J+JV0zjOuMVtrcPFDcl5Q/Hrqc+yRwp81nPRro=; fh=7PMUV/4VICWWS9LIJEJiFqTy1VDjVx0w3A97qZl6WhM=; b=n393BDvAwhUPvsT1zRRSEpJrutyl7ogHQqmvvLiW+ctsa2LjdEcqS8/pucjuHWH5B9 l5mAS6BRjb4CdVm7xdy2LSE9tUipcauSiVql3uFazc5LmT0SB4t+Fkr57MkEVaovxBnU H2BU3BppxWyycqhFLj/o7lrUY405NTqd6LsH8NrvJoAAJfcUQL3sA0HoYbkLRULp0jPO i5+o7Ebz950uR2MRzNxTm029wYYursxatWk+4ORZNgT4XwZNZOvrXEZ9rLRclZ/ti8YH i8ElSCJ1j98Rmc5kbmLDlgurUmCiw7bHa7U0JfSGcqOCDzUZaRUxeYuTNXnpRgGyeXFi dpPg==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783526893; x=1784131693; darn=debbugs.gnu.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=RZ4o4J+JV0zjOuMVtrcPFDcl5Q/Hrqc+yRwp81nPRro=; b=mws/suLQR0/xJEJLLMLXdowaUu/Et0tMnVCx3OcfN9+FrOKGAkzRGPvjJ3xkjsFfGL tVUf1+KWk07+oWHRpONgSzd8GuN0yeQYK8slQK5AAlrLX3UyyjBj5OmcKsieJmbIECYd V2gADt/qFo8L5JElSmW48q2OTJUpKMxsFYhBDl0gUtMTiQhGkWZx03ggrCpVK4xJsdIo /9tcjaxgdT1ISyVX85fXMj0ek+YvxTnpdIDYPVJaJIGsjxDBKQsvCavk4dV6y3PPTanm T/x0PIPNTfOj1Lj/Hq6yC4DOilpGdbZdk7zXbRhvZeRy0faDJLXqP6pM66hUQFKhJHvE Ad3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783526893; x=1784131693; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=RZ4o4J+JV0zjOuMVtrcPFDcl5Q/Hrqc+yRwp81nPRro=; b=iknkbL+Bm2ozBXWXvgF0WMaLTnd9wDdrlwfs3wI9TpvTkMnYpb7LauyAag/gn5vPJH gu6jIeDmZwzA8E9vxeLm6WAaBjrIPb8PIvks+0qrFMJ9Yc2XYJuIX3bM0YBi+kD2ohVU /PJYJnbiu6RKA5a0fg1KIQ8FJh5P0TV/rO0nSD7d4UcSc2A65CY1KtnGjnqLSVV6rmKU 4QEitW3b9rVlfWYyw+SKRTKGsM3/kApkxxeQle0HwwYKGaocTEHAhO0R0Khnw7QzYTi+ brdJvNIdygh/2zX8B9Gl1xUfUxkG8ShfTOScc6956uD5Gbr5TCues6Znnmm6uUP0q6Di gmRg== X-Gm-Message-State: AOJu0YzuII6ec+kcZ/JFWk3B0HtNAZs7K2LjuY4cdkozsjZSNV8JUoXx 1FBK40KlPf2MUBOJ62UYR//wgmBCmUbCK/BhB8Oz2TiW3CxCOmvDkwcvouVR+oXbjvV741rfzX6 2p6wd8PcPEfpOTSoZpjBbkwOxsqatxQihqDJWE0Y= X-Gm-Gg: AfdE7clKUxglpdsWLX2PUwd2Z31D2DuXSOFjw64S9PjW5uoxKqm45BtxL4ANO3y8sC/ ahuSZ2TcXoAqzt8Xy61y0Ga3gENpmrjO3OBP0rKOcY8DXyUyAs5Be2npSpodvlkG7qoaRHzZxjW kOdzLPyiInLd6QNqf9hFfLUfTSUFGp6B0mcleVXAzG8duYPbxM4HPwHzTkFNRBTKeZsyfYpdBjv pS3uMGjNVQWgcqEi4LTCvpMG8Crho+bjedhcy0sYogNi6Yjy0ynNuOJps/FyuKmddOL6eeQ2f58 NStmHtAaOi8YhT6Zk7aDjiU2OftIegBxy/zIiJM= X-Received: by 2002:a67:cd16:0:b0:736:e29f:168d with SMTP id ada2fe7eead31-744c241d352mr3180386137.16.1783523337768; Wed, 08 Jul 2026 08:08:57 -0700 (PDT) MIME-Version: 1.0 References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> <8733xtk3ni.fsf@HIDDEN> In-Reply-To: <8733xtk3ni.fsf@HIDDEN> From: Umar Ahmad <ahmad.umar2009@HIDDEN> Date: Wed, 8 Jul 2026 20:38:46 +0530 X-Gm-Features: AUfX_mzgOWppS2xzKFuP_E-WkMHmVCeekdDJ2K60rRcCoW4fGQvvXH-vNdsJ8cY Message-ID: <CAFHo54etG5R26UZjwAu-fm-wmUBBmmYCwpjpXnfo6enxd1-ydQ@HIDDEN> Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks To: Sean Whitton <spwhitton@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Do you mean a flag to the external diff command that can control this behavior? If so, I am not sure which existing option would solve this particular issue. The options that seem closest are: - --minimal / -d: try harder to find the smallest diff - --speed-large-files: trade quality for speed on large files - algorithm selection in some implementations - whitespace/case ignore flags Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ahmad.umar2009[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (ahmad.umar2009[at]gmail.com) 1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received' headers -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:c2e listed in] [list.dnswl.org] X-Debbugs-Envelope-To: 81375 Cc: 81375 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.3 (/) Do you mean a flag to the external diff command that can control this behavior? If so, I am not sure which existing option would solve this particular issue. The options that seem closest are: - --minimal / -d: try harder to find the smallest diff - --speed-large-files: trade quality for speed on large files - algorithm selection in some implementations - whitespace/case ignore flags But none of those seem to mean =E2=80=9Cdo not match small incidental token= runs across a large replacement block". In this case `smerge-refine-regions' has already tokenized the regions into temporary files, and external diff is finding matches between those token streams. The matches are not necessarily wrong from diff's point of view; they are just not useful as UI refinement for this kind of replacement. So I am not sure what we can pass to diff here. If there is an existing option I am missing, I would be happy to try that. I think there are two different splitting steps here. The original hunk boundaries are indeed decided by the external diff that produced the patch. I agree that deciding those boundaries is diff's territory. But the problematic step here happens later. `diff-mode' has already received a hunk, and `smerge-refine-regions' then chops the selected removed/added regions into token-per-line temporary files and invokes external diff again to compute intra-hunk refinement. So I don't think this is about changing where file-level hunks are split. It is about the second token-level refinement pass, and whether there is a way to tell external diff not to align low-value/incidental matches in that pass. On Wed, Jul 8, 2026 at 7:02=E2=80=AFPM Sean Whitton <spwhitton@HIDDEN= me> wrote: > > Umar Ahmad [08/Jul 6:14pm +0530] wrote: > > Thanks. > > My understanding is that the path is `diff-refine-hunk` -> > > `diff--refine-hunk` -> `smerge-refine-regions`, > > and then `smerge-refine-regions` invokes the external `diff` command on= the > > tokenized temporary files. > > > > So I agree the fine-grained matches ultimately come from external diff. > > But I am not sure external diff is doing anything wrong here: it is bei= ng > > asked to align two token streams from a large replacement block, and it > > finds incidental matches. > > > > The issue I am trying to address is more about when Emacs should ask fo= r > > fine refinement at all. For large or shape-mismatched replacement block= s, > > the external diff result may be technically reasonable but not useful a= s > > UI highlighting. In those cases line-level highlighting is clearer. > > > > That is why I suggested a guard before calling `smerge-refine-regions` > > (or inside it before invoking external diff), based on region size or > > line-count delta. > > > > From what I understand, trying to fix it in the diff command would mean= either: > > 1. Changing Emacs' tokenization/preprocessing so the external diff > > produces fewer incidental matches. But that would likely hurt the good > > small examples too. > > 2. Passing different options to diff, which is unlikely to solve the > > structural problem reliably. (diff -d asks for a smaller diff, but > > Emacs already uses -ad or -awd.) > > > > Does that distinction make sense, or do you think this > > policy should still live in the tokenization/diff invocation instead? > > To me, it doesn't make sense (at least not yet). > > Applying heuristics to make judgements about when to do refinement seems > just the same kind of thing as deciding where to split hunks, which is > squarely in diff's territory. > > It seems like we should be able to pass to diff some tolerance or limit > for how aggressively we want refinement to be done. That value, at > least, could be an Emacs defcustom. > > -- > Sean Whitton --=20 Regards, Umar Ahmad
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 8 Jul 2026 22:54:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 18:54:36 2026 Received: from localhost ([127.0.0.1]:47740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whbA3-0000W9-LJ for submit <at> debbugs.gnu.org; Wed, 08 Jul 2026 18:54:36 -0400 Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:50528) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ahmad.umar2009@HIDDEN>) id 1whRdx-0004Nl-Fk for 81375 <at> debbugs.gnu.org; Wed, 08 Jul 2026 08:44:51 -0400 Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-73791ee3612so414727137.1 for <81375 <at> debbugs.gnu.org>; Wed, 08 Jul 2026 05:44:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783514683; cv=none; d=google.com; s=arc-20260327; b=jpO/0hfBR83a0jxG+1Aecclx0Jw9RRzPzOAZkMwsD9O2dipoQ38Fyjeb0YzPR9vLhb SHbQdBM3tq6ZP4Bpl9PRGI12iDtJ97Aj7FDGumEwtKzW0Mw6K+gZA0Uqt1NIufFzrWqV oTYjh7vSw7bJH8h7lWTHj9eexmpQNuEQhV6LCSybNnwXrjM78toXD+rK1LGZDOXHJLQ7 NSuUn3rCEHR2UuE8YkscLCjTHs0jQ1O22mBTooFirR+Gr3JVJ5a4DMlaDzwaoAaeuCqL Hk8T6opcE+XiJscoZiaiy5HqU6LlYFKAl4VlUhcC3UBbj4aLZhYE1lhagnjv2gNgem+v 6gIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=isCdO/xkSgAFM1omWX/qWUUcd2OptPjBuEhvVSLaQN8=; fh=7PMUV/4VICWWS9LIJEJiFqTy1VDjVx0w3A97qZl6WhM=; b=G4OelIj0HzjqB2WiM1HFQ2wDZNpRLFKN+bk4weTcovi91tfEJfV3dI5ogfBj4IndUr yEXf1MtT0a0XieXS0PfVp+Imtr4m7yLjDLQG5DaAuZ6ysQDy4JDMolGJOnnMma1EmJiK pm15TQTEx4KaiT1qT9vrPWgLYH+Sius3K+EwU1fwYhGnpvG5uu+i9ba6PoDpUqQBqHLp GPAg0WtrGrh7G2G1hJ8777Zj6PsbumdLMtVv9X98T28a+GfL22HX30LcWaLbDKZZ/owQ mV6oP/hFAit8ooqEwjjxPTx7jNGbHfq2POfOQQeC3va/504Hc98F6MhyRa3OI3PGEDoM P2fA==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783514683; x=1784119483; darn=debbugs.gnu.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=isCdO/xkSgAFM1omWX/qWUUcd2OptPjBuEhvVSLaQN8=; b=A4cMl5CYa1PQ7Qt7OJ1Ao82az88eJgICNR91fjxNBoqbu2SvxX6VeNnxK3TLAdajbx LOXWBpKWRSkbZ2taodnNPlLeJnJ+DHrlcdWP9TiiBlmSLL/CRoHB/FMTD4znirVai8ii APNIXxJ03HKP5K1huTmW38JDHbHLOlrvVbsx26fcXxj7pIVYuMD0BGc15TExD/NO0HYu 9fLir5MQDl/347JBrqASBRWenm1GT0lzREzYK0XdOIDoJpMHegl6ZgQgN0oQNZDn28J1 uq4XrnGenWEvLcB60ZGWa14mL1opiUbLKz+XGGXOlXlsaQtiM8gVqGIUq3rQvV6DY2/q I8JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783514683; x=1784119483; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=isCdO/xkSgAFM1omWX/qWUUcd2OptPjBuEhvVSLaQN8=; b=nLtZgbRkTpuxRlQ0CNq0WUW9+KLAzf5rvl44DfXSDWMGAwO2b9vzFDs5KUgfl6dTZy wWJoUD51PNa+IiH1NkIoZPK59ZIXNBg6Y8/xbgL/hHP4vC+DdX10KHczmOquoGRK3h26 auFLFwjSs38qCoWtH34LVkEyz8UKLL6tpykqcwuZzZZO4JRApbTg6UIL8Okea64q9srn SEHaC4yOdHmPzcBhu4wFWW0IHtWvMJ3BAkoEjTOY1D1hjSGnLOFcpbWiEh9bCYcHa3yA Fwsv79Q4nTXEww2lVUMPH3eHru8V3SjDNtKw3MLE4BfqB0fQ1gxa7ZlJiD2YyTQ23kRm GGfw== X-Gm-Message-State: AOJu0YzJd1UH821RTjS3XazHsYk2bx8+mBzKWxSJTeWRduhR7TiTalvl 78hPfWxnUPuSBD6ck+6G3/1v7M7+exCBvKfPQkw7qqqb7aSK9nv3fq+qe0XVQUYcOxGQ3pTxPx3 mu4IB4DAmWdO7yAJcFap7JQn3gJfU6vs= X-Gm-Gg: AfdE7clTLXvVfNm4gJKtNMnq/drIAF38cH+yFIzbfhAOq4UsfcQuZgB5E/4zFl5P7IM cjHy08duJH6abC9dSIs0nrv2FNyOGfbB4D+HhhshSdfxCGiqH8i8Se0BO2dBYI2+F3jvZoU/uMG a86YwWTAR2sUFp5ddn1SUHcy0vRiGcmkx6cW6B72HWc5BPTVCt0kvCimJAUwp9zaoZb88X/BHxh HoNzWm687ZJPWBfhO8Z1CiydW2suyTEhPxQCTT2Q1cndM03/LBwrPJ+VyTzEwfOZFaF4H5jm+NK wTou7DCjTMqMs3jiRBZ2VNYDJyme X-Received: by 2002:a05:6102:8099:b0:726:cd42:d039 with SMTP id ada2fe7eead31-744dff98663mr1165608137.24.1783514683438; Wed, 08 Jul 2026 05:44:43 -0700 (PDT) MIME-Version: 1.0 References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> In-Reply-To: <87ik6pn735.fsf@HIDDEN> From: Umar Ahmad <ahmad.umar2009@HIDDEN> Date: Wed, 8 Jul 2026 18:14:32 +0530 X-Gm-Features: AUfX_mx7kFPeRSvWVjPFDCPQpSwVNhgglQVizGKpFqtJt5P1-nlSV5nn1kqMhsU Message-ID: <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks To: Sean Whitton <spwhitton@HIDDEN> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Thanks. My understanding is that the path is `diff-refine-hunk` -> `diff--refine-hunk` -> `smerge-refine-regions`, and then `smerge-refine-regions` invokes the external `diff` command on the tokenized [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (ahmad.umar2009[at]gmail.com) 1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received' headers 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (ahmad.umar2009[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2607:f8b0:4864:20:0:0:0:e2c listed in] [list.dnswl.org] X-Debbugs-Envelope-To: 81375 X-Mailman-Approved-At: Wed, 08 Jul 2026 18:54:34 -0400 Cc: 81375 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.3 (/) Thanks. My understanding is that the path is `diff-refine-hunk` -> `diff--refine-hunk` -> `smerge-refine-regions`, and then `smerge-refine-regions` invokes the external `diff` command on the tokenized temporary files. So I agree the fine-grained matches ultimately come from external diff. But I am not sure external diff is doing anything wrong here: it is being asked to align two token streams from a large replacement block, and it finds incidental matches. The issue I am trying to address is more about when Emacs should ask for fine refinement at all. For large or shape-mismatched replacement blocks, the external diff result may be technically reasonable but not useful as UI highlighting. In those cases line-level highlighting is clearer. That is why I suggested a guard before calling `smerge-refine-regions` (or inside it before invoking external diff), based on region size or line-count delta. From what I understand, trying to fix it in the diff command would mean eit= her: 1. Changing Emacs' tokenization/preprocessing so the external diff produces fewer incidental matches. But that would likely hurt the good small examples too. 2. Passing different options to diff, which is unlikely to solve the structural problem reliably. (diff -d asks for a smaller diff, but Emacs already uses -ad or -awd.) Does that distinction make sense, or do you think this policy should still live in the tokenization/diff invocation instead? On Wed, Jul 8, 2026 at 3:20=E2=80=AFPM Sean Whitton <spwhitton@HIDDEN= me> wrote: > > Umar Ahmad [08/Jul 7:47am +0530] wrote: > > Would it make sense to add user-tunable limits for refinement, either > > in diff-mode before calling smerge-refine-regions, or in smerge-mode > > itself? > > > > The idea would be to refine only when the paired removed/added regions > > look like a small local edit. If either side is too large, or if the > > line-count delta is too large, refinement would be skipped for that > > pair. > > > > I've something like this in my mind: > > > > > > ```elisp > > > > (defcustom diff-refine-max-region-lines 3 ...) > > (defcustom diff-refine-max-region-chars 800 ...) > > (defcustom diff-refine-max-line-delta 1 ...) > > > > (defun diff-refine--region-too-large-p (beg1 end1 beg2 end2) > > (let ((lines1 (count-lines beg1 end1)) > > (lines2 (count-lines beg2 end2)) > > (chars1 (- end1 beg1)) > > (chars2 (- end2 beg2))) > > (or (and diff-refine-max-region-lines > > (> (max lines1 lines2) diff-refine-max-region-lines)) > > (and diff-refine-max-region-chars > > (> (+ chars1 chars2) diff-refine-max-region-chars)) > > (and diff-refine-max-line-delta > > (> (abs (- lines1 lines2)) diff-refine-max-line-delta))))) > > > > ;; Then in `diff--refine-hunk', around calls to `smerge-refine-regions'= : > > (unless (diff-refine--region-too-large-p beg-del beg-add beg-add end-ad= d) > > (smerge-refine-regions beg-del beg-add beg-add end-add > > nil #'diff-refine-preproc props-r props-a)) > > ``` > > Thanks, this is interesting. > > We invoke the diff command to generate the information about refinement. > Have you thought about working on a change there instead? > It feels to me that your proposed change would be working around a > problem with the diff command in Emacs? > > -- > Sean Whitton --=20 Regards, Umar Ahmad
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 8 Jul 2026 13:33:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 09:33:00 2026 Received: from localhost ([127.0.0.1]:39397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whSOa-0002Cl-Cu for submit <at> debbugs.gnu.org; Wed, 08 Jul 2026 09:33:00 -0400 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]:38527) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1whSOW-0002C0-TQ for 81375 <at> debbugs.gnu.org; Wed, 08 Jul 2026 09:32:59 -0400 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 3AE301D00056; Wed, 8 Jul 2026 09:32:51 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Wed, 08 Jul 2026 09:32:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1783517571; x= 1783603971; bh=JibLN1k5S6BKipy+QtyiC8lAr5t5lSTFxUnktRLzheE=; b=a XUQSH1Kh2aFvKoz8aQ+ffnf5maLX4AZE4hdvV82JaYDuMSYhtkZFY59alcBWhDXG VDKldUlxRILIjA1EJnsLTlGBSsVuCjWE/qZF47WPv21nC2LrC4K1MLXToYQXGj5a TbiKY4smbc+XrJ+PHwKFtws8KGSVtZXd17fZn5i3dmn6H0FO6EiOWcQ7ui4gd6tj VsMm7W254byx3AEVuFe8XlmgHhdKLJ+XfIMWSMjQYvtfePsdSdPsCokd9Cu1wvnF RM80fOQz5oZJ7YWwqh8RkcSr69c/uW5+84RUHgcjSKZe9tcGt2r+ransHeI+BLs4 zG30L9CKawXBHy4LuWWAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783517571; x=1783603971; bh=JibLN1k5S6BKipy+QtyiC8lAr5t5lSTFxUn ktRLzheE=; b=Zbojyys6ZKuflQ/Q2dZrw1spOuAY4veFgc39NLWtFDVlTnOdGX3 x0x2TJk4RL4Z9SxP77e3ZnvGjwOyjok2VpiPaAE8Suj+k4N4izU7BKn9Zhl96HGJ B8lwaFXBykNki72zJdz9eF4DItJCG8SXGBaLyjIMlZrv63GlCsVfDlAF2nPQzycN I3wyDAAR1xI/U2InxnyKXpdiyV+/L0q7Me0b520TimB2elHn3mGJBZZNGKiWboxU TKSMp4REnhSY3KhKKXnaU4huW1fpunNwLv7XwrKGT2J0+itTLC6c75pZ+E/kRah5 XNpJuTD6kukIKWFR0WU7kI4Q6JREU7hFZRA== X-ME-Sender: <xms:glFOalT51yRJ2GW1b2c51RU9qdXSFrYiZH3G_UaoD4skaCD9T1ZS4g> <xme:glFOakxA-kPpRpj43Rl5qJn1THmlURfUuCahRHd3pAx0ZBxqRcixgrSQ74QKmya1A TqZsNM9AQzWlkS3Di6OeQnGQM6mymz3yrWlBX6ANzrxeSLiFkGYftU> X-ME-Received: <xmr:glFOaoeeqimy48NjmV1wGWOdgBOAZGdT9uo_lWN1ybtA_2KubrAqu9fl_bkrNBzuqiWBEn54mZB2> X-ME-Proxy-Cause: dmFkZTELUakpFBFEdBsPHuK/O2idL8lQr7KgILo5pkpi6uhMz21446MeRBy41ZsfXPtkBG 3za66WN6as0+NRCLZ0R4tgW9Nd8aQqhNxWxIZYnZaLwoX1qxzk+68rZdPtfUrqIJMqhSXs eF9zqdNSrQxu24Ui+OWIixvLLz+JDLDNurpW7mjmZ+ZgBsSswcqesOHgE6aktyCvhyuRE+ nPGmZRns1VOsuyvRDUIC6MLTCvvlo1qUmSSpzI5AdAh2BK8ZCf9y4iKJV/VyxP7tP3rdvv CwiTWluL0YHxQvvrBTAVFZD6cS0AGIUrfGfrSkcv2WzDSRsCH8EN247TkmHEwg+f2uvetx Zl3yNPdJzCzgW/lHoBUenPwZtPLLgCJIQ+Zs85lmyIlVvdbIRX2rRSMfbXR+14pclIYYmF yYULXL3mFqKc+Bkhfh/4l728IuZsbsSWnXRhmtlHq0P5ZBKzENrWijN6g4H5YyS6emKhn1 h1It6dtvQkg+O0CiOvBrUHvdqkAEjVuc1psBtM4jlGQRvbgQYbuU39v7Ys18LjfcRBqPd3 C5dIiY1kjq7oQ8AlKShvNz7ORaF4f3SluSswU6hjOzk6pV77gFCvMPeEwOUJSdLXu1J/fU B4YJKvJt+y5ijaX5M+3U/vyhwI0+8QXT7rA7fj26CqVGCLQS39JMQKN6dWFQ X-ME-Proxy: <xmx:glFOaoISYWabtpZkGmZhy5S1H8YSWpjVzAT-vuluhfrwqf0u5IQU6Q> <xmx:glFOahErlIMgHlI08UZJVq4ZUh_3Z7xcqMEgJz9x1pfJn5hL0k-rqg> <xmx:glFOaqqHCzTq4JFlgzrgA9AEt2XIF8k5WDJt9fopycGDTjtneiUUag> <xmx:glFOaiQyGN3dx_vYGNFwWLmKxWXOfJg_tV8j3tZjPLz-IhuN3FlVEA> <xmx:g1FOao0W14388ahhPw6m6VF_Iuo9K9WYHOGcU9ecXRdLlNJxrFd3TDVa> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Jul 2026 09:32:50 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id E3B497E6800; Wed, 08 Jul 2026 14:32:49 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Umar Ahmad <ahmad.umar2009@HIDDEN> Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks In-Reply-To: <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> <87ik6pn735.fsf@HIDDEN> <CAFHo54ei6hcY6LijF8EGxJ7YkTEoew7qfPVu16d3mz3NfC-33Q@HIDDEN> Date: Wed, 08 Jul 2026 14:32:49 +0100 Message-ID: <8733xtk3ni.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81375 Cc: 81375 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Umar Ahmad [08/Jul 6:14pm +0530] wrote: > Thanks. > My understanding is that the path is `diff-refine-hunk` -> > `diff--refine-hunk` -> `smerge-refine-regions`, > and then `smerge-refine-regions` invokes the external `diff` command on the > tokenized temporary files. > > So I agree the fine-grained matches ultimately come from external diff. > But I am not sure external diff is doing anything wrong here: it is being > asked to align two token streams from a large replacement block, and it > finds incidental matches. > > The issue I am trying to address is more about when Emacs should ask for > fine refinement at all. For large or shape-mismatched replacement blocks, > the external diff result may be technically reasonable but not useful as > UI highlighting. In those cases line-level highlighting is clearer. > > That is why I suggested a guard before calling `smerge-refine-regions` > (or inside it before invoking external diff), based on region size or > line-count delta. > > From what I understand, trying to fix it in the diff command would mean either: > 1. Changing Emacs' tokenization/preprocessing so the external diff > produces fewer incidental matches. But that would likely hurt the good > small examples too. > 2. Passing different options to diff, which is unlikely to solve the > structural problem reliably. (diff -d asks for a smaller diff, but > Emacs already uses -ad or -awd.) > > Does that distinction make sense, or do you think this > policy should still live in the tokenization/diff invocation instead? To me, it doesn't make sense (at least not yet). Applying heuristics to make judgements about when to do refinement seems just the same kind of thing as deciding where to split hunks, which is squarely in diff's territory. It seems like we should be able to pass to diff some tolerance or limit for how aggressively we want refinement to be done. That value, at least, could be an Emacs defcustom. -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.Received: (at 81375) by debbugs.gnu.org; 8 Jul 2026 09:50:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 05:50:37 2026 Received: from localhost ([127.0.0.1]:38048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1whOvK-0002na-W5 for submit <at> debbugs.gnu.org; Wed, 08 Jul 2026 05:50:37 -0400 Received: from fout-a4-smtp.messagingengine.com ([103.168.172.147]:60203) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <spwhitton@HIDDEN>) id 1whOvG-0002ko-6m for 81375 <at> debbugs.gnu.org; Wed, 08 Jul 2026 05:50:32 -0400 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id E81B2EC0098; Wed, 8 Jul 2026 05:50:24 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 08 Jul 2026 05:50:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1783504224; x=1783590624; bh=KUrC8XSn2g ji7Kb1uUiCZSvECo4N621ARqoTCFWLNiA=; b=cEHbcbuNA4wHnQPAkZU4ydx14n oQUpJ1xSQREQMihpiLZSZ8Ut1YldoHYdQsw3EdKn0ehaw4zlCR9XPAcPLi5gQcy/ 7+UrUZic4ALhfmDZ21I8ADNJnb0G3ezIoXNpq15j0niw5f4E69H0l+c+DM7DxyZe xC/Nbznmpi8j5Wbrb+nnxIInvmppA7xxpIRyc8wDUCdu2yhDlancggb1VHHGLadY fljtTNIy7oQQXAPVAzK1sAqx+OP+G7GWHFtCchOw83XCoP0u8le0DThZJwQGA5jY zXqnjBoRUP2zSqg5copVc2k2+jLExPMT6kdjdEnY+t4HhDCq+02n6uph/rsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1783504224; x=1783590624; bh=KUrC8XSn2gji7Kb1uUiCZSvECo4N621ARqo TCFWLNiA=; b=JQ8C6NSs+6VcjAtpzn43fnfT7cjNxhooaDHAEKw0gAcPq1l6I8M aKHnHN/7gTfg1ht2bd6OW/Ht0ExHq5aJD84esOCz80tlSfkMZvf2Q8CvEeiO6r9m nuIG9e4DsfVYYiHjPvxzcHjYxfEH2DM82346lFB5hI7wdSXoYkSbzUnR3TIQORT5 NhWicUx/T5fRLtuaBS2QDxKyUDEGmENSzsZgW6OSTbzCDpXFBoJvYIgZ62nngLfR S1BThaEtx+ZuUBH49az8rrrEelJDdYejkOUI0on+u3RVTEtlIDsm09nLGtbqzYIb /d6U43Of9n2nLQWn1fDWvy3Xm7Y55K73FQw== X-ME-Sender: <xms:Xx1OanITOXyDvhuVtMFAo79fChm_O56hU-tcruPrLud-h_X7q6wG_w> <xme:Xx1OahJTcc2xBwY3FiGh6Lb7taPQ7eZiW62yLq68Yvg5gwZ3Few4dwlMlR1Aensf5 3xAqbOk8UckaZaKMnv2VAekYEZW6lS2cDo3RPohrto4A6sevBr5O7M> X-ME-Received: <xmr:Xx1OatWAw65E0wNeNfGz1GmbHkjdoRUAgiZ7UueDHvZJS8IFG3HtNdWvrNfEi1qcYAICT-0KqWcw> X-ME-Proxy-Cause: dmFkZTExprd0w+8FXHpl1zxQYyuJQarshSZ4yf70GqY/zHgMT1YT+cH1g/8D3C2q46DsLv wrDbPltMVUd3UylP+D40izmgq8zuohsBZGWFxDH2j/hJDhcHEKCFLbHtWPyieQIXOuyRhS LwXRr/LfT/OxBkugRecsqkjI7tYZ1auWW4qrTz7HX9QBeS/VCe7cqtYazGIYk+Rl71FE1k mmH75Vcz+qEIsgvAZZb9iXbguFx/g3XGrPeF9bk52FBgKuGlvhHsVQx2N367qHgKwRBEfY E0THv+P0Bso80ETwMU4pCeqxQ2aRliE4ZiZDyZotQrcGq6KFXjsdcru83LlpWfEjIaQDk9 bOoFUjVe8hoy9TPLQw1RcjG5MS/pyTGBylrCSyYPM9CjrIsJMo8UMO3GV5ylbeYxYlL3i8 gibJAOh8pfckbzL2PKi9d+oNbvnpjoCX8rH1Z9dwbwsYgj8lKyBs/tup5ScyJaFFH+Oe/9 gXWA6PKLQoGh12WmfPtYvzqUkLdVHU7NVqE/OcnINUG69fYNEzskRXloW9bRJjOI1CeUSe UF8vZDsmjitjvROIIM7576eAUFQD6GNkSK6ZsijXacDzrMn8Hr9M6+OkZuNCNEiy7vcb9J FrcOriNLMFPdmnVa4UmvzBjALa9+aMcHaaWkPIA07ydUP/na3SX0JZJwYmwg X-ME-Proxy: <xmx:Xx1OariBM7Fmgj70o89X-ubSZSvXy7oYm3ocgru0rbhji1SeXL18Xg> <xmx:Xx1Oag8J4MigjkHeTylNag2bNYrwTytVACx2WvzN0mFQkahtvFItJQ> <xmx:Xx1OatBA88hFkXbCPTDBPkAiZBUX2pIR3uCB8XcpNsGkBdD3JInA0A> <xmx:Xx1OalIrIheaIyLHxP2bQUUjixeha2D3T-rXRtEXTe_16aCEzDC0gA> <xmx:YB1OaunEo3FpsGeTCImFV23xdtyD3bkvGgw66qBYg2LZDtqbXzWho6TX> Feedback-ID: i62564b17:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Jul 2026 05:50:23 -0400 (EDT) Received: by melete.silentflame.com (Postfix, from userid 1000) id EA2977E6BED; Wed, 08 Jul 2026 10:50:22 +0100 (BST) From: Sean Whitton <spwhitton@HIDDEN> To: Umar Ahmad <ahmad.umar2009@HIDDEN>, 81375 <at> debbugs.gnu.org Subject: Re: bug#81375: diff-refine-hunk over-refines large unrelated replacement blocks In-Reply-To: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> References: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN> Date: Wed, 08 Jul 2026 10:50:22 +0100 Message-ID: <87ik6pn735.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 81375 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Umar Ahmad [08/Jul 7:47am +0530] wrote: > Would it make sense to add user-tunable limits for refinement, either > in diff-mode before calling smerge-refine-regions, or in smerge-mode > itself? > > The idea would be to refine only when the paired removed/added regions > look like a small local edit. If either side is too large, or if the > line-count delta is too large, refinement would be skipped for that > pair. > > I've something like this in my mind: > > > ```elisp > > (defcustom diff-refine-max-region-lines 3 ...) > (defcustom diff-refine-max-region-chars 800 ...) > (defcustom diff-refine-max-line-delta 1 ...) > > (defun diff-refine--region-too-large-p (beg1 end1 beg2 end2) > (let ((lines1 (count-lines beg1 end1)) > (lines2 (count-lines beg2 end2)) > (chars1 (- end1 beg1)) > (chars2 (- end2 beg2))) > (or (and diff-refine-max-region-lines > (> (max lines1 lines2) diff-refine-max-region-lines)) > (and diff-refine-max-region-chars > (> (+ chars1 chars2) diff-refine-max-region-chars)) > (and diff-refine-max-line-delta > (> (abs (- lines1 lines2)) diff-refine-max-line-delta))))) > > ;; Then in `diff--refine-hunk', around calls to `smerge-refine-regions': > (unless (diff-refine--region-too-large-p beg-del beg-add beg-add end-add) > (smerge-refine-regions beg-del beg-add beg-add end-add > nil #'diff-refine-preproc props-r props-a)) > ``` Thanks, this is interesting. We invoke the diff command to generate the information about refinement. Have you thought about working on a change there instead? It feels to me that your proposed change would be working around a problem with the diff command in Emacs? -- Sean Whitton
bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 8 Jul 2026 09:11:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 08 05:10:59 2026
Received: from localhost ([127.0.0.1]:37942 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1whOIy-0004vH-Rk
for submit <at> debbugs.gnu.org; Wed, 08 Jul 2026 05:10:59 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:35310)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <ahmad.umar2009@HIDDEN>)
id 1whHqt-0002ru-4w
for submit <at> debbugs.gnu.org; Tue, 07 Jul 2026 22:17:33 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <ahmad.umar2009@HIDDEN>)
id 1whHqn-0005Mk-Bq
for bug-gnu-emacs@HIDDEN; Tue, 07 Jul 2026 22:17:25 -0400
Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <ahmad.umar2009@HIDDEN>)
id 1whHql-0000fW-Pi
for bug-gnu-emacs@HIDDEN; Tue, 07 Jul 2026 22:17:25 -0400
Received: by mail-vk1-xa2f.google.com with SMTP id
71dfb90a1353d-5bf7485e4ddso33463e0c.0
for <bug-gnu-emacs@HIDDEN>; Tue, 07 Jul 2026 19:17:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783477042; cv=none;
d=google.com; s=arc-20260327;
b=o8c0gMOZdPpXPuE1JAXuoyDTCAxeargunu8OfpoC908wD3ZKRTiKlL17HtarSIFoSE
tT5KXTqIXF7S39Zia/AwTNnRLZMIrl0PaIBogr0B4YkcQHPjeMgAag3Cp2DHD91xLzd+
l7vJid4iVTriJeHme0kr5IjS+ArWRnIOdzU8QtZvab++z+aslrMLG89PRZWjmlT9N+u3
6Bovs88BYLwVMWIeNMCNNagKTGSdy1o+3iHEWXv+SHN2XHtaDykrVi2iNVuiif/jgmFT
zYxk9noYTxtxl+/f1X6T8LRTVX8KCxSQqMJdiKmPPjGKPmKqSH/80RMidhaGrIV9G0Tc
gCfw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20260327;
h=to:subject:message-id:date:from:mime-version:dkim-signature;
bh=8xIGX1sIWw8v0lr4L6czTfx1YqU3z1LQWYL7g/HHuXE=;
fh=+R8aXOFVnuBbN1nRXJJI02Ia//JUQJmLW/Uk/VaA0ag=;
b=jQqpxws66gAs8FmVGccDzrbjioz89ZlF5TIGRNlK1poOkUaMTSaCcRyCnyNuMU6pMM
gJnlH9YdsM+EdStu5P4KE16QZ0FBObUwWWIugeSEkivVLmfzRxxq2JW0S9sSOwK/AkX+
0nV6TTiXho/A7dK7AUjvxnEybNVxdqrjvCQi6ekSlzxrlq+CRrqhj3o+5QsP4yBkviFa
gJPgy1GMx2ob2kj0/nzqLzM4I+baDTAthnRxAbYIZfeE5yKIJwUXLYFvPz1LDZn9DJBu
U65y0R8fwK7lwfSpW06JyaWEPbA55jGowSGH3s3CF6TkU01gJogD3P6w8Bfg6EVlGLyO
KWWA==; darn=gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1783477042; x=1784081842; darn=gnu.org;
h=content-type:to:subject:message-id:date:from:mime-version:from:to
:cc:subject:date:message-id:reply-to:content-type;
bh=8xIGX1sIWw8v0lr4L6czTfx1YqU3z1LQWYL7g/HHuXE=;
b=sw+R1id727pHo4LhhawvehSEBYwHLBuSQjL/D45vA4r4nJvywuCp7lFzyF0IA3alaT
apkzR1t4h1m0Ja11bRwQL9ydk7qgT1/HPCr7hmMDlr0NlwKgllhhFTBi0dnD3bubuPl0
njRERfPRVtV5NT6TKCu0U4Q8i9yuqNbmnYKk8lflvLIsjNPwqSd8JC1eOsmZaLgsIZBN
cWn7NQ3kgyjJYrWUvzTzIYfy9TIUoFiWwXq1rXwSBLdhGHTfUn9+JdtFfwx/nJp7akyL
z4J2AExM2T3jM10MhdSWfExZs94TKj8hSGEoNwpwM7kViEyPJlOzyY1gi3KIHoK0mbBE
2rfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1783477042; x=1784081842;
h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
:content-type;
bh=8xIGX1sIWw8v0lr4L6czTfx1YqU3z1LQWYL7g/HHuXE=;
b=FZLX0gbhgq3VjaAHWLZquPak/67QGfrxMiPuztn9G17erBRJCA7RNEmzq6xE+yyMNn
SInyMOpqk4vKtP9cBF1/Obiim5YcIFIRE8XOQ/iS1H+973TrzOKl1ev1dcHyop/0QAZh
1nvCe6KaTeiwmGq2FVAwI9w8wATAqFpA3q2NUGH5jUXYQlOAgSAktsfOBqfYh8qyxYAZ
IXboC9xL8ESnFYToQ5LN8v/pELLfo+eYIrO6h3U9ZT/DLDNoufKtMIlqjJTrX9w311tw
2zybYMPFNSM0ik7rIS/I7sjUDZoQ6hXGuXh9uiM33SN8sDOWPE5PqGeWdznwZWp4r0/8
N9uQ==
X-Gm-Message-State: AOJu0Yz1iPeOmV0Yb1DXcDuFDwboKFwWwKPbkLiTcww1rRyZoNoP1D0Q
Bb6CnrXyhjJGqAOzBc2ZNYR2xb2fFCpVsBooiSqb/rVpegyNHhRD6iZwUlJld7msK0IPM3lQlXl
avYR//dpOhilQGB21mskVc6TvnsC7oEoUMul5n0Q=
X-Gm-Gg: AfdE7ck8fTiNRNirCeB9GF/91mKyWzuIZaKAGjOASwgI9YGzt4DRZ3XbtPDX0Q8PwbQ
RRG7Lsb4QlxH0yf8NigvZRwc6pxT7cOCVkuqTwFuNilbztn0IMryP2w6GM9L3ZBfffHXgn+LOzv
Wweo3Ic5A7thJ8ph1HgnmnThDux3sIE7Im5+vpTTzCosMyJ6chJpO/B0lq5hW5Y9UoCZ1HhQxgb
XGEAk2uETmDqerYOVQusBMhF0k8t8ghPtaRQRMmqSlG+t5PIg7vT/Xc8c9Q7JBcsU3kTrKVGY+i
9ZxdJOWApirs0T8RSz9d4V4WEEccqsY5Gwu1QdiQsljOOzT4azD3niIOYsePh89LK3qE6UzR
X-Received: by 2002:a05:6122:3a06:b0:5a2:5669:d6d7 with SMTP id
71dfb90a1353d-5bf75eab6demr173014e0c.9.1783477041782; Tue, 07 Jul 2026
19:17:21 -0700 (PDT)
MIME-Version: 1.0
From: Umar Ahmad <ahmad.umar2009@HIDDEN>
Date: Wed, 8 Jul 2026 07:47:09 +0530
X-Gm-Features: AVVi8CdpSw8Ku9p-Kb1ARcSDMoZwX0CDtvi3X2WgKomWjk6rBhed9t6aHzB0z14
Message-ID: <CAFHo54cdv+FS8BbZ9=z2yjY0obK86KhTOi=v=GGn4O4rU34DpA@HIDDEN>
Subject: diff-refine-hunk over-refines large unrelated replacement blocks
To: bug-gnu-emacs@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::a2f;
envelope-from=ahmad.umar2009@HIDDEN; helo=mail-vk1-xa2f.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hello, `diff-mode` hunk refinement can become misleading when
a large removed block is paired with a smaller unrelated added block. Opening
this patch
(https://github.com/emacs-mirror/emacs/commit/66bd2ce8e69d31c04fb2f71c651d34a435f607eb.diff)
in emacs diff-mode gives the idea
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (ahmad.umar2009[at]gmail.com)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (ahmad.umar2009[at]gmail.com)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 08 Jul 2026 05:10:56 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Hello, `diff-mode` hunk refinement can become misleading when
a large removed block is paired with a smaller unrelated added block. Opening
this patch (https://github.com/emacs-mirror/emacs/commit/66bd2ce8e69d31c04fb2f71c651d34a435f607eb.diff)
in emacs diff-mode gives the idea
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (ahmad.umar2009[at]gmail.com)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (ahmad.umar2009[at]gmail.com)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
Hello,
`diff-mode` hunk refinement can become misleading when a large removed
block is paired with a smaller unrelated added block.
Opening this patch
(https://github.com/emacs-mirror/emacs/commit/66bd2ce8e69d31c04fb2f71c651d34a435f607eb.diff)
in emacs diff-mode gives the idea
A small hunk like this is refined well:
```
-(defun smerge--refine-chopup-region (beg end file &optional preproc)
- "Chopup the region from BEG to END into small elements, one per line.
+(defun smerge--refine-chopup-region (overlay file &optional preproc)
+ "Chopup the region covered by OVERLAY into small elements, one per line.
```
The fine highlights make sense there: beg end is replaced by overlay,
and `from BEG to END` by `covered by OVERLAY`.
But later in the same diff, around:
@@ -1149,53 +1179,20 @@
a large removed implementation block is paired with a smaller
replacement that calls the new helper. diff-refine-hunk /
smerge-refine-regions tries to refine this as though the two blocks
are local edits of each other. The result highlights small incidental
token matches across mostly unrelated code, which is visually noisy
and misleading. In that case plain line-level add/remove highlighting
is better.
Would it make sense to add user-tunable limits for refinement, either
in diff-mode before calling smerge-refine-regions, or in smerge-mode
itself?
The idea would be to refine only when the paired removed/added regions
look like a small local edit. If either side is too large, or if the
line-count delta is too large, refinement would be skipped for that
pair.
I've something like this in my mind:
```elisp
(defcustom diff-refine-max-region-lines 3 ...)
(defcustom diff-refine-max-region-chars 800 ...)
(defcustom diff-refine-max-line-delta 1 ...)
(defun diff-refine--region-too-large-p (beg1 end1 beg2 end2)
(let ((lines1 (count-lines beg1 end1))
(lines2 (count-lines beg2 end2))
(chars1 (- end1 beg1))
(chars2 (- end2 beg2)))
(or (and diff-refine-max-region-lines
(> (max lines1 lines2) diff-refine-max-region-lines))
(and diff-refine-max-region-chars
(> (+ chars1 chars2) diff-refine-max-region-chars))
(and diff-refine-max-line-delta
(> (abs (- lines1 lines2)) diff-refine-max-line-delta)))))
;; Then in `diff--refine-hunk', around calls to `smerge-refine-regions':
(unless (diff-refine--region-too-large-p beg-del beg-add beg-add end-add)
(smerge-refine-regions beg-del beg-add beg-add end-add
nil #'diff-refine-preproc props-r props-a))
```
--
Regards,
Umar Ahmad
Umar Ahmad <ahmad.umar2009@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#81375; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.