GNU bug report logs - #77233
31.0.50; crash if message starts with a space and then without it

Previous Next

Package: emacs;

Reported by: Daniel Clemente <n142857 <at> gmail.com>

Date: Mon, 24 Mar 2025 09:44:02 UTC

Severity: normal

Found in version 31.0.50

Fixed in version 31.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: n142857 <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 77233 <at> debbugs.gnu.org
Subject: Re: bug#77233: 31.0.50; crash if message starts with a space and
 then without it
Date: Mon, 24 Mar 2025 21:00:22 +0100
Pip Cet <pipcet <at> protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> > Can anyone else reproduce this?
>>>>
>>>> I can, on GNU/Linux with no special options and in an xterm.
>>>
>>> And you can explain how come curX(tty) got such a large value?
>>>
>>>> Reverting 6fb68f4310d808827b83da053fbc112b316b7757 avoids the crash.
>>>
>>> Adding Gerd.
>>
>> I think I can reproduce this, but I can't take a closer look
>> for a couple of days or so.
>>
>> If it's urgent, maybe try to comment out the emacs_abort in cmcheckmagic
>> and see if that suffices.
>
> That avoids the crash here, and things work fine in an xterm, but it
> means we printed a character with the cursor at (cols-1,rows-1), which
> allegedly would have caused some (old, I assume?) terminals to scroll by
> a line, destroying the entire Emacs layout...

Well, it's complicated as usual.

xterm implements AutoWrap. AutoWrap means that when outputting a
character the cursor automatically moves forwawrd. In the last column of
a row, the cursor automatically moves to column 0 of the next line.
Doing this in the last line of a display scrolls the display.

And then there is insert and overwrite mode. AFAIU what you wrote in
another mail len == 1 which means we wrote nothing in overwrite mode,
and then 1 glyph in insert mode. tty_insert_glyphs probably (I don't
know), just turns on insert mode, calls tty_write_glyphs, and switches
insert mode off again. The cursor doesn't move. The terminal shifts
glyphs right that came after the cursor.

So the questing is what does inserting a glyph in the last column of the
last row do in various terminals. Does this scroll in some case even
when there are no glyphs to shift right?

> However, xterm and M-x term both handle this situation sensibly, not
> scrolling the frame.  Is anyone aware of a terminal emulator that
> scrolls in this situation?

I simply don't know. I can't remember having seen that defined anywhere.
But don't forget, this is insert mode, I'm pretty sure it scrolls if not
in insert mode.






This bug report was last modified 51 days ago.

Previous Next


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