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

From: Akib Azmain Turja <[email-masked]>
Date: Sun, 11 Dec 2022 21:21:13 +0600

Akib Azmain Turja <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> 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" <[email-masked]>
>>>
>>> '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'll dig into the 'window-max-chars-per-line' definition and report if I
> find something suspicious.

I just found the root cause.  I've used '(set-window-fringes nil 0 0)'
(from Doom as said by the original reporter) to hide fringe.  It doesn't
set 'left-fringe-width' and 'right-fringe-width', which are checked by
'window-max-chars-per-line'.  Setting these two variables to zero fixes
the bug.

Now I think this is a bug of _both_ Emacs and Doom.  Doom doesn't set
the variables, hence this bug report here; and Emacs doesn't check
'window-fringes'.

What do you think?

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: [email-masked]
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."