bug#71525: 30.0.50; Spin in delete-region/interval_deletion_adjustment Spin in delete-region/interval_deletion_adjustment)

[Dmitry Gutov]

On 13/06/2024 19:31, Eli Zaretskii wrote:
> > From: Steven Allen<steven@stebalien.com>
> > Cc:71525@debbugs.gnu.org
> > Date: Thu, 13 Jun 2024 09:06:07 -0700
> >
> >
> > Steven Allen<steven@stebalien.com>  writes:
> > > Eli Zaretskii<eliz@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.