Subject: bug#76538: 31.0.50; 31.0.50; 31.0.50; feature/igc: using magit-section-cycle-global (S-TAB) and magit-section-toggle (TAB) in some random ways blocks GNU Emacs.

From: Eli Zaretskii <[email-masked]>
Date: Mon, 03 Mar 2025 17:33:23 +0200

> Date: Mon, 03 Mar 2025 14:46:55 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> 
> Should this combination ever be valid?
> 
> it->what = IT_CHARACTER
> it->c = 10
> it->len = 0
> 
> >> It seems to me like a bug in the xdisp.c code, but it's xdisp.c, so
> >> who knows?
> >
> > I suspect it->len is not used when the character is composed, because
> 
> The character isn't composed, is it? It's a plain newline.

AFAIR, the value of it->len for a newline is never used, because we
are at the end of a line, and will then jump to the next visible line
anyway (or stop iteration altogether).

Which is not to say I'm against the changes, I'm just trying to
explain why it never caused us any assertion violations till now.

> >> -	it->c = STRING_CHAR (s);
> >> +	{
> >> +	  it->c = STRING_CHAR (s);
> >> +	  it->len = CHAR_BYTES (it->c);
> >> +	}
> >
> > This is sub-optimal; please use string_char_and_length instead.
> 
> Will do, if we need to fix this at all.
> 
> >> @@ -6724,6 +6730,7 @@ handle_composition_prop (struct it *it)
> >>        pos_byte = IT_BYTEPOS (*it);
> >>        string = Qnil;
> >>        it->c = FETCH_CHAR (pos_byte);
> >> +      it->len = it->multibyte_p ? CHAR_BYTES (it->c) : 1;
> >
> > Likewise here.
> 
> I was looking for fetch_char_and_length, but I guess
> string_char_and_length (BYTE_POS_ADDR (pos_byte), &it->len) works, too?

Yes.