GNU bug report logs - #59963
29.0.50; 'window-max-chars-per-line' doesn't always work on GUI without fringe

Previous Next

Full log

View this message in rfc822 format

From: Akib Azmain Turja <akib <at> disroot.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59963 <at> debbugs.gnu.org
Subject: bug#59963: 29.0.50; 'window-max-chars-per-line' doesn't always work on GUI without fringe
Date: Sun, 11 Dec 2022 21:03:46 +0600

[Message part 1 (text/plain, inline)]

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

>> Date: Sun, 11 Dec 2022 17:13:41 +0600
>> From:  Akib Azmain Turja via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> 'window-max-chars-per-line' doesn't always work on GUI when fringe width
>> is set to zero.  Although it returns seemingly correct answer, actually
>> writing that characters results in the continuation/truncation glyph to
>> appear, decreasing the text area width.
>>
>> I don't know precisely what condition needs to be meet for trigger the
>> bug.  But I think this is triggered when the width of the text area of
>> window in character is a fraction.  For example, my window is 1366px
>> width, each character takes 8px; so my window is 170.75 characters
>> width, and this triggers the bug.
>>
>> This bug affects Term, Eat, Eat in Eshell, Coterm in Shell mode, Vterm,
>> and possibly any other Emacs terminal emulator.
>>
>> Reproduction steps:
>>
>> 1.  Run the command 'emacs -nw -Q' in any of the terminal emulators
>>     listed above.
>> 2.  Remove fringes with 'M-: (set-window-fringes nil 0 0)'.
>> 3.  To make the bug is even more clear, enable 'visual-line-mode'.
>> 4.  If everything seem to be OK, resize the window.
>
> I tried reproducing the problem, but couldn't:
> window-max-chars-per-line returns a value correctly truncated to the
> number of fully visible characters that can be shown on the line,
> minus the continuation/truncation glyph if there should be one.
>
> So please provide a complete recipe, and please show the numbers: what
> does window-max-chars-per-line report when you do what needs to be
> done to demonstrate the issue.  Bonus points for demonstrating the
> issue without running any terminal emulators, but just by typing
> characters (which should produce the same effect, since Emacs display
> doesn't really know what Lisp program produces the characters it needs
> to display).
>
> Thanks.

Here is a GIF demonstration of Eat affected by the bug, by
rahguzar <at> Codeberg.

[#14-eat-top.gif (image/gif, inline)]

[Message part 3 (text/plain, inline)]

Quoting from the first message:

> I don't know precisely what condition needs to be meet for trigger the
> bug.  But I think this is triggered when the width of the text area of
> window in character is a fraction.  For example, my window is 1366px
> width, each character takes 8px; so my window is 170.75 characters
> width, and this triggers the bug.

In the above circumstance, (window-max-chars-per-line) returns 170.  But
writing 170 characters (my font is monospace, of course) causes the last
characters to be obscured by the truncation glyph.

FYI, I used the '(insert (make-string (window-max-chars-per-line) ?\s))'
to insert spaces.

I'll dig into the 'window-max-chars-per-line' definition and report if I
find something suspicious.

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[signature.asc (application/pgp-signature, inline)]

Previous Next

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