bug#29594: Emacs 26 -- xdisp.c:21657 OR xdisp.c:21671?

bug#29594: Emacs 26 -- xdisp.c:21657 OR xdisp.c:21671?

[Keith David Bershatsky]

In the Emacs 26 branch downloaded this morning, I see:

xdisp.c:21657
it->continuation_lines_width += wrap_x;

and, I see:

xdisp.c:21671
it->continuation_lines_width += x;

If only one of these is needed, then it may be appropriate to remove whichever one is not needed.  I understand that the second occurrence supersedes the first occurrence in this section of code, but it would be cleaner if there were only one setting.  If both occurrences are needed, then perhaps a comment in the code at that particular location would be helpful.

There is an ongoing thread on Emacs Devel relating to this section of code (among one other location) affecting the calculation of it->pixel_width at xdisp.c:28212; however, that discussion may or may not yet be ripe for a bug report:

https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00209.html

Thanks,

Keith

bug#29594: Emacs 26 -- xdisp.c:21657 OR xdisp.c:21671?

[Eli Zaretskii]

> Date: Wed, 06 Dec 2017 13:49:24 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> In the Emacs 26 branch downloaded this morning, I see:
> 
> xdisp.c:21657
> it->continuation_lines_width += wrap_x;
> 
> and, I see:
> 
> xdisp.c:21671
> it->continuation_lines_width += x;
> 
> If only one of these is needed, then it may be appropriate to remove whichever one is not needed.  I understand that the second occurrence supersedes the first occurrence in this section of code, but it would be cleaner if there were only one setting.  If both occurrences are needed, then perhaps a comment in the code at that particular location would be helpful.

This is a bug, and a very old one: the second increment should not be
done.  This bug was introduced when the word-wrap feature was added to
Emacs, 9 years ago.  It could only remain undetected for such a long
time because the numerical value of continuation_lines_width is almost
never used, most of the code only cares whether the value is zero or
positive.

Thanks for pointing this out, I've now fixed this on the release
branch.