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

[Eli Zaretskii]

> 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@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.