GNU bug report logs - #71525
30.0.50; Spin in delete-region/interval_deletion_adjustment

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>, Steven Allen <steven <at> stebalien.com>
Cc: jporterbugs <at> gmail.com, 71525 <at> debbugs.gnu.org
Subject: bug#71525: 30.0.50; Spin in delete-region/interval_deletion_adjustment Spin in delete-region/interval_deletion_adjustment)
Date: Fri, 14 Jun 2024 00:47:40 +0300

On 13/06/2024 19:31, Eli Zaretskii wrote:
>> From: Steven Allen<steven <at> stebalien.com>
>> Cc:71525 <at> debbugs.gnu.org
>> Date: Thu, 13 Jun 2024 09:06:07 -0700
>>
>>
>> Steven Allen<steven <at> stebalien.com>  writes:
>>> Eli Zaretskii<eliz <at> gnu.org>  writes:
>>>> I see a couple of Eshell-related changes, but no obvious suspects.
>>>>
>>>> Can someone please reproduce this and post a detailed backtrace,
>>>> including Lisp backtrace?  Jim, are you looking into this?
>>> It's hanging in the C code, not lisp. I believe the issue is:
>>>
>>> https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00241.html
>>>
>>> So I'm trying that patch now.
>>>
>>> If that doesn't work, I'll produce a backtrace sometime later today.
>> I can confirm that the linked patch fixes the issue. Would you still
>> like me to produce a backtrace?
> No need, thanks.  That issue is already on someone's table.

I think I see it now.

The thing is, decode_coding_c_string already calls 
adjust_markers_for_insert through

  decode_coding_object->decode_coding->produce_chars->insert_from_gap

And the extra call moves the markers too far.

Unfortunately, it's called with BEFORE_MARKERS=nil, and the above call 
chain makes it difficult to pass through the extra argument.

Perhaps we should do this?

diff --git a/src/process.c b/src/process.c
index eb526311c53..3c6cbe9b188 100644
--- a/src/process.c
+++ b/src/process.c
@@ -6423,9 +6423,17 @@ read_and_insert_process_output (struct 
Lisp_Process *p, char *buf,
       specbind (Qinhibit_modification_hooks, Qt);
       decode_coding_c_string (process_coding,
 			      (unsigned char *) buf, nread, curbuf);
-      adjust_markers_for_insert (PT, PT_BYTE,
-				 PT + process_coding->produced_char,
-				 PT_BYTE + process_coding->produced, true);
+      /* The previous call adjusts the markers, except for those
+	exactly at PT (it inserts with BEFORE_MARKERS=nil). */
+      struct Lisp_Marker *m;
+      for (m = BUF_MARKERS (current_buffer); m; m = m->next)
+	{
+	  if (m->bytepos == PT_BYTE)
+	    {
+	      m->bytepos = PT_BYTE + process_coding->produced;
+	      m->charpos = PT + process_coding->produced_char;
+	    }
+	}
       unbind_to (count1, Qnil);

       read_process_output_set_last_coding_system (p, process_coding);


That doesn't adjust the overlays, however (the 
adjust_overlays_for_insert call inside adjust_markers_for_insert). And 
doing the same trick with them seems more difficult.

Previous Next

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