GNU bug report logs - #43297
27.1; corrupts patch when diff-update-on-the-fly is set to nil

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mark H Weaver <mhw <at> netris.org>
Subject: bug#43297: closed (Re: bug#43297: 27.1; corrupts patch when
 diff-update-on-the-fly is set to nil)
Date: Thu, 06 Mar 2025 03:42:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#43297: 27.1; corrupts patch when diff-update-on-the-fly is set to nil

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 43297 <at> debbugs.gnu.org.

-- 
43297: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43297
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Mark H Weaver <mhw <at> netris.org>, 43297-done <at> debbugs.gnu.org
Subject: Re: bug#43297: 27.1; corrupts patch when diff-update-on-the-fly is
 set to nil
Date: Wed, 5 Mar 2025 19:41:08 -0800

Daniel Martín <mardani29 <at> yahoo.es> writes:

> Mark H Weaver <mhw <at> netris.org> writes:
>
>> I don't know if this behavior is new in 27.1, but that's the only
>> version I've tried this on.
>>
>> When I set 'diff-update-on-the-fly' to nil, I find that some patches are
>> consistently corrupted when I save them while in diff-mode.  See below
>> for an example patch that demonstrates this behavior.
>>
>> To reproduce:
>>
>> * Save the example patch below to "test.patch", and make another copy
>>   in "test2.patch".
>>
>> * Launch "emacs -nw -q"  (I used Emacs 27.1)
>>
>> * Evaluate (setq diff-update-on-the-fly nil)
>>
>> * Find file "test2.patch".
>>
>> * Add a character anywhere in the buffer and then delete it, such that
>>   the buffer is now in a "modified" state.
>>
>> * Save the file.
>>
>> * Run "diff -u test.patch test2.patch" in the shell.
>>
>> * Here's the result that I see:
>>
>> --- test.patch
>> +++ test2.patch
>> @@ -39,7 +39,7 @@
>>
>>   	var elements = document.getElementsByTagName("style");
>>   	for(var i = 0; i < elements.length; i++){
>> -@@ -41,16 +48,20 @@ function reveal_css(){
>> +@@ -41,17 +48,20 @@ function reveal_css(){
>>
>>   		}
>>   	}
>>
>>
>> Emacs corrupts the line count of the final hunk, making it one larger
>> than it should be (17 instead of 16).  This breaks the patch, such that
>> attempts to apply it will fail.
>
> I've tried to reproduce this bug in an Emacs build from the current
> master branch and I couldn't.  Could you try a recent build of Emacs and
> confirm if it's also fixed for you?  Thanks.

I can't reproduce this either, so let's assume this is fixed.

I'm therefore closing this bug report.

[Message part 3 (message/rfc822, inline)]

From: Mark H Weaver <mhw <at> netris.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; corrupts patch when diff-update-on-the-fly is set to nil
Date: Wed, 09 Sep 2020 15:50:36 -0400

I don't know if this behavior is new in 27.1, but that's the only
version I've tried this on.

When I set 'diff-update-on-the-fly' to nil, I find that some patches are
consistently corrupted when I save them while in diff-mode.  See below
for an example patch that demonstrates this behavior.

To reproduce:

* Save the example patch below to "test.patch", and make another copy
  in "test2.patch".

* Launch "emacs -nw -q"  (I used Emacs 27.1)

* Evaluate (setq diff-update-on-the-fly nil)

* Find file "test2.patch".

* Add a character anywhere in the buffer and then delete it, such that
  the buffer is now in a "modified" state.

* Save the file.

* Run "diff -u test.patch test2.patch" in the shell.

* Here's the result that I see:

--8<---------------cut here---------------start------------->8---
--- test.patch
+++ test2.patch
@@ -39,7 +39,7 @@
  
  	var elements = document.getElementsByTagName("style");
  	for(var i = 0; i < elements.length; i++){
-@@ -41,16 +48,20 @@ function reveal_css(){
+@@ -41,17 +48,20 @@ function reveal_css(){
  
  		}
  	}
--8<---------------cut here---------------end--------------->8---

Emacs corrupts the line count of the final hunk, making it one larger
than it should be (17 instead of 16).  This breaks the patch, such that
attempts to apply it will fail.

Note that the example patch includes the following footer immediately
after the last hunk, added by "git format-patch":

--8<---------------cut here---------------start------------->8---
-- 
2.26.2
--8<---------------cut here---------------end--------------->8---

My guess is that the line with "--" is being interpreted as a deleted
line, part of the hunk.  This bug only seems to happen when
'diff-update-on-the-fly' is set to nil.

The example patch that demonstrates this problem follows.

     Thanks,
       Mark


--8<---------------cut here---------------start------------->8---
From 2e8618d22568b6e00892a17303d437dd700eca98 Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw <at> netris.org>
Date: Tue, 5 May 2020 21:27:41 -0400
Subject: [PATCH] Revert "Update Reveal hidden HTML."

I prefer the user interface of the old version.

This reverts commit f6e3adb6b2344ee2c7bb453a305fd2d6fb4c194c.
---
 .../passive_improve_css.js                    | 23 ++++++++++++++-----
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/data/extensions/SubmitMe <at> 0xbeef.coffee/passive_improve_css.js b/data/extensions/SubmitMe <at> 0xbeef.coffee/passive_improve_css.js
index 7692990..ca57982 100644
--- a/data/extensions/SubmitMe <at> 0xbeef.coffee/passive_improve_css.js
+++ b/data/extensions/SubmitMe <at> 0xbeef.coffee/passive_improve_css.js
@@ -10,6 +10,8 @@ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLI
 */
 
 
+var bad = [];
+
 function escapeHTML (unsafe_str) {
     return unsafe_str
       .replace(/&/g, '&amp;')
@@ -20,9 +22,14 @@ function escapeHTML (unsafe_str) {
       .replace(/\//g, '&#x2F;')
 }
 
+function dounhide(){
+        for(var i = 0; i < bad.length; i++){
+                        bad[i].remove();
+                }
+}
+
 console.log("passive_improve_css.js");
 function reveal_css(){
-	var bad = [];
 
 	var elements = document.getElementsByTagName("style");
 	for(var i = 0; i < elements.length; i++){
@@ -41,16 +48,20 @@ function reveal_css(){
 
 		}
 	}
-	if(bad.length > 0 && window.confirm("Hidden HTML detected, would you like to reveal it?")){
-		for(var i = 0; i < bad.length; i++){
-			bad[i].remove();
-		}
+	if(bad.length > 0){
+		const insertedDiv = document.createElement('div');
+		insertedDiv.innerHTML= '<p id="unhide" class="button white" style="text-decoration:none!important; color:#000!important;  font-size:1em !important; font-family:\'sans-serif\'!important; font-weight:normal !important; background-color:transparent!important; margin:0!important; padding:0!important; font-size:10px!important; line-height:1!important"' +
+			'alt="Click to reveal hidden elements in this page">' +
+	                '<span>Reveal hidden elements</span>' +
+			'</a>';
+		insertedDiv.style="position:fixed; bottom:1em; right:1em; opacity:0.8; z-index: 2147483647 !important; border-radius: 3px !important; background-color: #fff !important; padding: 0.5em !important;   box-shadow: 0 0 3px grey !important; font-color:#bbb!important; cursor: pointer!important;";
+		insertedDiv.addEventListener("click", dounhide, false);
+		document.body.insertBefore(insertedDiv, document.body.firstChild);
 	}
 }
 
 reveal_css();
 
-
 /*
 var a = document.getElementsByTagName("style")[2];
 var btn = document.createElement("style");        // Create a <button> element
-- 
2.26.2

--8<---------------cut here---------------end--------------->8---

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.