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

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

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

...when a certain popular font is used. Visual line breaks are inserted,
and it can break the visuals quite badly. For some reason, it happens
not every time I try it in practice, but the test example below shows
this result quite reliably.

Enlarge Emacs so that its width is big enough for pop-to-buffer to
prefer horizontal splits, evaluate the code below and then `M-x test-1'
or `M-x test-2'. The propertizing with `face' below only serves to show
better how the string gets distorted.


;; https://github.com/mozilla/Fira/blob/master/ttf/FiraMono-Regular.ttf?raw=true
(set-face-attribute 'default nil :height 105 :family "Fira Mono")

(defun test-propertize-strings (strings)
  (concat "\n"
          (mapconcat (lambda (str) (propertize str 'face 'highlight))
                     strings
                     "\n")
          "\n"))

(defvar test-string-1 (test-propertize-strings
		       '(" ad-Advice-call-interactively     "
			 " ad-Advice-compilation-find-file  "
			 " ad-Advice-copy-region-as-kill    ")))

(defvar test-string-2 (test-propertize-strings
		       '(" ad-Advice-Info-read-node-name  "
			 " ad-Advice-add-to-history <f>   "
			 " ad-Advice-apropos <f>          "
			 " ad-Advice-beginning-of-buffer  "
			 " ad-Advice-delete-file <f>      "
			 " ad-Advice-delete-window <f>    ")))

(defun test-1 ()
  (interactive)
  (pop-to-buffer "test-1")
  (visual-line-mode 1)
  (enlarge-window-horizontally (- 34 (window-width)))
  (let ((ov (make-overlay (1+ (point)) (1+ (point)) nil t t)))
    (overlay-put ov 'invisible t)
    (overlay-put ov 'after-string test-string-1)
    (overlay-put ov 'window (selected-window))))

(defun test-2 ()
  (interactive)
  (pop-to-buffer "test-2")
  (visual-line-mode 1)
  (enlarge-window-horizontally (- 32 (window-width)))
  (let ((ov (make-overlay (1+ (point)) (1+ (point)) nil t t))
        (str test-string-2))
    (overlay-put ov 'invisible t)
    (overlay-put ov 'after-string str)
    (overlay-put ov 'window (selected-window))))


See attached screenshots for how the results look.

In GNU Emacs 24.4.51.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-11-28 on axl
Repository revision: 6b765b8facbdbb03f28028007885236601652515
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04.1 LTS

(Also reproducible in 25.0.50.1).

Inspired by https://github.com/company-mode/company-mode/issues/249.


[-- Attachment #2: test-1.png --]
[-- Type: image/png, Size: 13739 bytes --]

[-- Attachment #3: test-2.png --]
[-- Type: image/png, Size: 17405 bytes --]

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 08 Dec 2014 01:50:34 +0200
> 
> ...when a certain popular font is used. Visual line breaks are inserted,
> and it can break the visuals quite badly. For some reason, it happens
> not every time I try it in practice, but the test example below shows
> this result quite reliably.

Please explain what exactly is not right about the results.
visual-line-mode doesn't understand the text it renders, it just
breaks lines at whitespace.  What would you expect it to do instead in
this use case?

Thanks.

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

[Dmitry Gutov]

On 12/08/2014 05:46 AM, Eli Zaretskii wrote:

> Please explain what exactly is not right about the results.
> visual-line-mode doesn't understand the text it renders, it just
> breaks lines at whitespace.  What would you expect it to do instead in
> this use case?

I'd expect the text not to be broken, because the `after-string' text 
already includes newlines, and the length of each line there equals to 
the value reported by (window-width).

Without overlays, even when visual-line-mode is enabled, I can make a 
window body 34 chars wide and type 34 characters (maybe including 
spaces) on a line without seeing them break up.

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

[Eli Zaretskii]

> Date: Mon, 08 Dec 2014 12:14:35 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> On 12/08/2014 05:46 AM, Eli Zaretskii wrote:
> 
> > Please explain what exactly is not right about the results.
> > visual-line-mode doesn't understand the text it renders, it just
> > breaks lines at whitespace.  What would you expect it to do instead in
> > this use case?
> 
> I'd expect the text not to be broken, because the `after-string' text 
> already includes newlines

visual-line-mode doesn't care about newlines, when the stuff before
the newline overflows the window width.

> and the length of each line there equals to the value reported by
> (window-width).

Not here: I need to resize a bit the windows showing the overlays, in
order to see something similar to your images.

> Without overlays, even when visual-line-mode is enabled, I can make a 
> window body 34 chars wide and type 34 characters (maybe including 
> spaces) on a line without seeing them break up.

Are you saying that if you insert your test-string-1 and test-string-2
into the respective windows as buffer text, you see them displayed
differently than the overlay in the same window?  If so, I cannot
reproduce this: I see both the overlay and the buffer text wrap
exactly identically.

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

[Dmitry Gutov]

On 12/08/2014 06:04 PM, Eli Zaretskii wrote:

> visual-line-mode doesn't care about newlines, when the stuff before
> the newline overflows the window width.

Right. That's why I made sure the stuff before and after each newline 
fits the window.

>> and the length of each line there equals to the value reported by
>> (window-width).
>
> Not here:

I'm sure it does. It depends on the test data only: 34 columns in the 
first example, 32 columns in the second.

> I need to resize a bit the windows showing the overlays, in
> order to see something similar to your images.

The scenarios intentionally resize the newly popped window to make sure 
it's the right size.

>> Without overlays, even when visual-line-mode is enabled, I can make a
>> window body 34 chars wide and type 34 characters (maybe including
>> spaces) on a line without seeing them break up.
>
> Are you saying that if you insert your test-string-1 and test-string-2
> into the respective windows as buffer text, you see them displayed
> differently than the overlay in the same window?

Hmm, actually no. Sorry about that. So the examples could be simplified 
to just insert the respective test string, without overlays.

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.

Could this be a bug in `enlarge-window-horizontally' and/or `window-width'?

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

Have you installed Fira Mono and set it up, like the first code line in 
the example does? This doesn't happen with the default Ubuntu font in 
the Emacs master, although in emacs-24 it did when I tried.

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

[Eli Zaretskii]

> Date: Mon, 08 Dec 2014 18:40:36 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> >> and the length of each line there equals to the value reported by
> >> (window-width).
> >
> > Not here:
> 
> I'm sure it does. It depends on the test data only: 34 columns in the 
> first example, 32 columns in the second.
> 
> > I need to resize a bit the windows showing the overlays, in
> > order to see something similar to your images.
> 
> 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.

> >> Without overlays, even when visual-line-mode is enabled, I can make a
> >> window body 34 chars wide and type 34 characters (maybe including
> >> spaces) on a line without seeing them break up.
> >
> > Are you saying that if you insert your test-string-1 and test-string-2
> > into the respective windows as buffer text, you see them displayed
> > differently than the overlay in the same window?
> 
> Hmm, actually no. Sorry about that. So the examples could be simplified 
> to just insert the respective test string, without overlays.
> 
> 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.

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

> > If so, I cannot
> > reproduce this: I see both the overlay and the buffer text wrap
> > exactly identically.
> 
> Have you installed Fira Mono and set it up, like the first code line in 
> the example does?

Yes, of course.

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

[Dmitry Gutov]

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.

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

[Eli Zaretskii]

> Date: Mon, 08 Dec 2014 20:47:02 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> >> 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.

I meant a recipe to show one window with the problem and another
without, in the same session.  If you achieve that with the same
resizing of a window, it'd be interesting to see.

> 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?

The pixel size of the canonical character of that font, as you get in
your session, would be a good start.  E.g., put a breakpoint in
set_cursor_from_row, then step a few lines, and type "pgrow".

Here's the full recipe:

  gdb ./emacs
  break Fredraw_display
  r -Q

Now arrange for the problematic display, and then

  M-x redraw-display RET
  (gdb) break set_cursor_from_row
  (gdb) continue
  (gdb) continue
  (gdb) next
  (gdb) next
  (gdb) next
  (gdb) pgrow

The first "continue" is because the first time set_cursor_from_row is
entered Emacs is displaying the echo area, whereas I need to see the
window of a normal buffer.

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

The fact that pixel size changes, but the size in characters doesn't
is expected, of course.

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

[Dmitry Gutov]

On 12/08/2014 10:39 PM, Eli Zaretskii wrote:
> I meant a recipe to show one window with the problem and another
> without, in the same session.  If you achieve that with the same
> resizing of a window, it'd be interesting to see.

The recipe won't work on your system anyway, right? Since you can't 
reproduce the situation of just "one window with a problem", and the 
above would be a (tiny bit) more complicated version of it.

I can make a video, if you like.

> The pixel size of the canonical character of that font, as you get in
> your session, would be a good start.  E.g., put a breakpoint in
> set_cursor_from_row, then step a few lines, and type "pgrow".
>
> Here's the full recipe:
> ...
>    (gdb) pgrow

Thanks, here's the full output:

Breakpoint 3, Fredraw_display () at dispnew.c:3026
3026	  FOR_EACH_FRAME (tail, frame)
(gdb) break set_cursor_from_row
Breakpoint 4 at 0x42ee50: file xdisp.c, line 14350.
(gdb) continue
Continuing.

Breakpoint 4, set_cursor_from_row (w=0x1170530, row=row@entry=0x159d3c0, 
delta=delta@entry=0, delta_bytes=delta_bytes@entry=0, dy=dy@entry=0, 
dvpos=dvpos@entry=0, matrix=<optimized out>) at xdisp.c:14350
14350	set_cursor_from_row (struct window *w, struct glyph_row *row,
(gdb) continue
Continuing.

Breakpoint 4, set_cursor_from_row (w=0x116f520, row=row@entry=0x18b5230, 
delta=delta@entry=0, delta_bytes=delta_bytes@entry=0, dy=dy@entry=0, 
dvpos=dvpos@entry=0, matrix=<optimized out>) at xdisp.c:14350
14350	set_cursor_from_row (struct window *w, struct glyph_row *row,
(gdb) next
14389	  if (row->mode_line_p)
(gdb) next
14361	  ptrdiff_t pt_old = PT - delta;
(gdb) next
14350	set_cursor_from_row (struct window *w, struct glyph_row *row,
(gdb) pgrow
TEXT: 39 glyphs
   0    0: STRETCH[20+15] pos=740 w=64 a+d=15+5 MB
   1   64: STRETCH[20+15] pos=741 w=64 a+d=15+5 MB
   2  128: STRETCH[20+15] pos=742 w=64 a+d=15+5 MB
   3  192: CHAR[ ] pos=743 blev=0,btyp=L w=8 a+d=15+5 MB
   4  200: CHAR["] pos=744 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
   5  208: CHAR[ ] pos=745 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
   6  216: CHAR[a] pos=746 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
   7  224: CHAR[d] pos=747 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
   8  232: CHAR[-] pos=748 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
   9  240: CHAR[A] pos=749 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  10  248: CHAR[d] pos=750 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  11  256: CHAR[v] pos=751 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  12  264: CHAR[i] pos=752 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  13  272: CHAR[c] pos=753 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  14  280: CHAR[e] pos=754 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  15  288: CHAR[-] pos=755 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  16  296: CHAR[d] pos=756 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  17  304: CHAR[e] pos=757 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  18  312: CHAR[l] pos=758 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  19  320: CHAR[e] pos=759 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  20  328: CHAR[t] pos=760 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  21  336: CHAR[e] pos=761 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  22  344: CHAR[-] pos=762 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  23  352: CHAR[f] pos=763 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  24  360: CHAR[i] pos=764 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  25  368: CHAR[l] pos=765 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  26  376: CHAR[e] pos=766 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  27  384: CHAR[ ] pos=767 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  28  392: CHAR[<] pos=768 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  29  400: CHAR[f] pos=769 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  30  408: CHAR[>] pos=770 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  31  416: CHAR[ ] pos=771 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  32  424: CHAR[ ] pos=772 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  33  432: CHAR[ ] pos=773 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  34  440: CHAR[ ] pos=774 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  35  448: CHAR[ ] pos=775 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  36  456: CHAR[ ] pos=776 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  37  464: CHAR["] pos=777 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
  38  472: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=15+5 MB

>> 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.
>
> The fact that pixel size changes, but the size in characters doesn't
> is expected, of course.

I wrote down specific numbers, for you to maybe try resizing the window 
to these dimensions. Like mentioned, I see the problem at 288px, and 
there's no problem at 291px, while the reported width in columns stays 
the same.

It's fairly hard to reach 288px though, because dragging with the mouse 
still moves the window border in jumps (even though not by columns).

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

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 02:51:32 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> On 12/08/2014 10:39 PM, Eli Zaretskii wrote:
> > I meant a recipe to show one window with the problem and another
> > without, in the same session.  If you achieve that with the same
> > resizing of a window, it'd be interesting to see.
> 
> The recipe won't work on your system anyway, right? Since you can't 
> reproduce the situation of just "one window with a problem", and the 
> above would be a (tiny bit) more complicated version of it.
> 
> I can make a video, if you like.
> 
> > The pixel size of the canonical character of that font, as you get in
> > your session, would be a good start.  E.g., put a breakpoint in
> > set_cursor_from_row, then step a few lines, and type "pgrow".
> >
> > Here's the full recipe:
> > ...
> >    (gdb) pgrow
> 
> 14350	set_cursor_from_row (struct window *w, struct glyph_row *row,
> (gdb) pgrow
> TEXT: 39 glyphs
>    0    0: STRETCH[20+15] pos=740 w=64 a+d=15+5 MB
>    1   64: STRETCH[20+15] pos=741 w=64 a+d=15+5 MB
>    2  128: STRETCH[20+15] pos=742 w=64 a+d=15+5 MB
>    3  192: CHAR[ ] pos=743 blev=0,btyp=L w=8 a+d=15+5 MB
>    4  200: CHAR["] pos=744 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>    5  208: CHAR[ ] pos=745 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>    6  216: CHAR[a] pos=746 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>    7  224: CHAR[d] pos=747 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>    8  232: CHAR[-] pos=748 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>    9  240: CHAR[A] pos=749 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   10  248: CHAR[d] pos=750 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   11  256: CHAR[v] pos=751 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   12  264: CHAR[i] pos=752 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   13  272: CHAR[c] pos=753 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   14  280: CHAR[e] pos=754 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   15  288: CHAR[-] pos=755 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   16  296: CHAR[d] pos=756 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   17  304: CHAR[e] pos=757 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   18  312: CHAR[l] pos=758 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   19  320: CHAR[e] pos=759 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   20  328: CHAR[t] pos=760 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   21  336: CHAR[e] pos=761 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   22  344: CHAR[-] pos=762 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   23  352: CHAR[f] pos=763 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   24  360: CHAR[i] pos=764 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   25  368: CHAR[l] pos=765 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   26  376: CHAR[e] pos=766 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   27  384: CHAR[ ] pos=767 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   28  392: CHAR[<] pos=768 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   29  400: CHAR[f] pos=769 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   30  408: CHAR[>] pos=770 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   31  416: CHAR[ ] pos=771 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   32  424: CHAR[ ] pos=772 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   33  432: CHAR[ ] pos=773 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   34  440: CHAR[ ] pos=774 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   35  448: CHAR[ ] pos=775 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   36  456: CHAR[ ] pos=776 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   37  464: CHAR["] pos=777 blev=0,btyp=L w=8 a+d=15+5 face=17 MB
>   38  472: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=15+5 MB

This means every character is 8 pixels wide, so I'd expect the
wrapping to occur around 256-pixel wide window.

> >> 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.
> >
> > The fact that pixel size changes, but the size in characters doesn't
> > is expected, of course.
> 
> I wrote down specific numbers, for you to maybe try resizing the window 
> to these dimensions. Like mentioned, I see the problem at 288px, and 
> there's no problem at 291px, while the reported width in columns stays 
> the same.

These are not the numbers we need, we need what this returns:

  M-: (window-width nil t) RET

> It's fairly hard to reach 288px though, because dragging with the mouse 
> still moves the window border in jumps (even though not by columns).

Perhaps set window-resize-pixelwise non-nil.

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

[Dmitry Gutov]

On 12/09/2014 06:11 PM, Eli Zaretskii wrote:

 > This means every character is 8 pixels wide, so I'd expect the
 > wrapping to occur around 256-pixel wide window.

Or 272 (34 columns), if we're talking the first example. Right?

 > These are not the numbers we need, we need what this returns:
 >
 >    M-: (window-width nil t) RET

All right, thanks. So, this time I ended up increasing the window width 
by 1 pixel, and wrapping disappeared. The widths in pixels:

288 total, 272 body: text is wrapped.

289 total, 273 body: no wrapping.

>> It's fairly hard to reach 288px though, because dragging with the mouse
>> still moves the window border in jumps (even though not by columns).
>
> Perhaps set window-resize-pixelwise non-nil.

Ok, but that doesn't seems to make much of a difference: I have the 
frame maximized when experimenting with this (although that's not 
required to reproduce the problem), and there are only two windows.

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

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 19:30:46 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> On 12/09/2014 06:11 PM, Eli Zaretskii wrote:
> 
>  > This means every character is 8 pixels wide, so I'd expect the
>  > wrapping to occur around 256-pixel wide window.
> 
> Or 272 (34 columns), if we're talking the first example. Right?
> 
>  > These are not the numbers we need, we need what this returns:
>  >
>  >    M-: (window-width nil t) RET
> 
> All right, thanks. So, this time I ended up increasing the window width 
> by 1 pixel, and wrapping disappeared. The widths in pixels:
> 
> 288 total, 272 body: text is wrapped.
> 
> 289 total, 273 body: no wrapping.

So I guess this bug report now boils down to the question why one
extra pixel, is that correct?  Or are there additional issues with
this?

> >> It's fairly hard to reach 288px though, because dragging with the mouse
> >> still moves the window border in jumps (even though not by columns).
> >
> > Perhaps set window-resize-pixelwise non-nil.
> 
> Ok, but that doesn't seems to make much of a difference: I have the 
> frame maximized when experimenting with this (although that's not 
> required to reproduce the problem), and there are only two windows.

When you move the divider between windows, window-resize-pixelwise
does take effect, but I think only in Emacs 25.0.50, not on the
release branch.

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

[Dmitry Gutov]

On 12/09/2014 07:51 PM, Eli Zaretskii wrote:

> So I guess this bug report now boils down to the question why one
> extra pixel, is that correct?

Apparently so, yes.

> When you move the divider between windows, window-resize-pixelwise
> does take effect, but I think only in Emacs 25.0.50, not on the
> release branch.

On emacs-24, too.

Sorry, I've been confused by its nil behavior. The doc says "when a 
frame's pixel size is not a multiple of the
frame's character size, at least one window may get resized
pixelwise even if this option is nil", and it behaves very similarly to 
pixelwise (certainly not column-wise), but still jerky.

Enabling this option indeed makes the behavior better.

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

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 20:38:15 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> On 12/09/2014 07:51 PM, Eli Zaretskii wrote:
> 
> > So I guess this bug report now boils down to the question why one
> > extra pixel, is that correct?
> 
> Apparently so, yes.

OK, I will look into that.

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

[Eli Zaretskii]

> Date: Tue, 09 Dec 2014 20:38:15 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300@debbugs.gnu.org
> 
> On 12/09/2014 07:51 PM, Eli Zaretskii wrote:
> 
> > So I guess this bug report now boils down to the question why one
> > extra pixel, is that correct?
> 
> Apparently so, yes.

Turned out it was a remnant of a distant past.  Originally,
overflow-newline-into-fringe was not supported when word-wrap was in
effect.  That was fixed more than 5 years ago (see bug#2749), except
in one corner case: when the last character before the newline is a
whitespace character.

I fixed that now on the emacs-24 branch (commit 0c2f254), please
test.  Please be sure to test cursor motion, as this affects that as
well.

Thanks.

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

[Dmitry Gutov]

On 12/10/2014 07:58 PM, Eli Zaretskii wrote:

> Turned out it was a remnant of a distant past.  Originally,
> overflow-newline-into-fringe was not supported when word-wrap was in
> effect.  That was fixed more than 5 years ago (see bug#2749), except
> in one corner case: when the last character before the newline is a
> whitespace character.
>
> I fixed that now on the emacs-24 branch (commit 0c2f254), please
> test.  Please be sure to test cursor motion, as this affects that as
> well.

Thanks! Wrapping seems to work as expected now.

The cursor movement also looks fine, except that now that I know about 
the newline-in-fringe indicator, seems a bit weird that it's only 
displayed when the window body width is a multiple of a column width.

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

[Eli Zaretskii]

> Date: Thu, 11 Dec 2014 00:50:48 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19300-done@debbugs.gnu.org
> 
> The cursor movement also looks fine, except that now that I know about 
> the newline-in-fringe indicator, seems a bit weird that it's only 
> displayed when the window body width is a multiple of a column width.

When we have even 1 pixel after the text, we display the (thin) cursor
there.  I don't see it as weird, but perhaps I'm just used to it.