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

Previous Next

Package: emacs;

Reported by: Steven Allen <steven <at> stebalien.com>

Date: Wed, 12 Jun 2024 19:22:01 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #38 received at 71525 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.




This bug report was last modified 344 days ago.

Previous Next


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