bug#19300: 24.4.51; visual-line-mode messes up after-string rendering when it spans all window columns

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/08/2014 07:03 PM, Eli Zaretskii wrote:

>> The scenarios intentionally resize the newly popped window to make sure
>> it's the right size.
>
> I know.  But facts are stubborn things: I still need to resize.

Please don't, it invalidates the point of this bug report.

>> But I can open a different window, enable visual-line-mode, take its
>> (window-width), insert that numbers of characters on one line and not
>> see them wrapped.
>
> Then please show a recipe for that.

Do I need to? The fact that you don't see the problem when executing my 
scenario means that the above must always work well for you.

>> Could this be a bug in `enlarge-window-horizontally' and/or `window-width'?
>
> Maybe, there's no way of guessing in advance.  It could also be that
> this particular font has some weird metrics in it.

Could you suggest how to proceed debugging it? If you can't reproduce 
the problem with my scenario, can I send you some data from my session?

I reproduce it with 100% probability, in GUI mode, without any 
customization (emacs -Q).

>>> If so, I cannot
>>> reproduce this: I see both the overlay and the buffer text wrap
>>> exactly identically.

Right, same here, albeit (in the first case) when (window-width) returns 
34, and (window-pixel-width) returns 288.

I can also drag the left window border a bit, so that (window-width) 
still returns 34, but (window-pixel-width) is 291, then the lines in the 
test buffer become not wrapped.