Eli Zaretskii 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" >> >> '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. I forgot to mention, probably you need to set 'window-resize-pixelwise' to t to get the correct width of reproducing the bug. -- Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5 Fediverse: akib@hostux.social Codeberg: akib emailselfdefense.fsf.org | "Nothing can be secure without encryption."