Re: Problems with move_it_in_display_line_to X when tabs exist.

[Keith David Bershatsky <esq@lawlist.com>]

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

Thank you, Eli, for trying to reproduce the current issue.  The good news is that I was able to reproduce the issue with Emacs 26, dated today (12/03/2017), bearing last commit 1fdac2d65c7134a2e1261bf7ad32d275f37da0dc.  The bad news is that my recipe is cumbersome.  In the coming days, I will work on developing a less cumbersome recipe.

For the issue to be present, the tab STRETCH must _visibly_ be 2 columns wide _and_ the tab CHARACTER must be 1 column wide, for a grand total of 3 columns.  The variable tab-width is exactly 2.  The preceding long line must have a space at the window edge; and, the following line contains a second word with just "xxx", a tab, followed by some letters like "hello-world".

This evening (after work), I will experiment using your recipe in the most recent email (below).  I can also build Emacs 26 on Windows and compare the results to Emacs 26 on OSX 10.6.8 (which is what I currently use).

Here is my complete recipe for Emacs 26:

0.  Screen-shot taken today:

https://lawlist.com/images/pgrowx_b.png

1.  Apply the attached patch.diff, and build a modified Emacs 26.  I am using the following settings:

CFLAGS='-O0 -g3' ./configure \
--with-ns \
--enable-checking='yes,glyphs' \
--enable-check-lisp-object-type \
--without-compress-install \
--without-makeinfo \
--with-gnutls=no \
--with-mailutils \
--without-makeinfo

2.  Launch the newly built modified Emacs 26 in gdb.

3.  Open the attached Lisp library named +-mode.el and evaluate the entire buffer.

4.  Open the attached .scratch file; place the cursor at the end of the buffer; and type M-x +-mode

[If the default font is different than Emacs 26 on OSX 10.6.8, then the long line will need to be adjusted such that the last character at the right window edge is a space.]

5.  In the gdb debugger select the frame that threw the hard-code emacs_abort and run the tests that we have been using:

Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40)
    at emacs.c:364
364	  signal (sig, SIG_DFL);

(gdb) frame 2
#2  0x000000010002d244 in mc_draw_crosshairs (w=0x103be7038) at xdisp.c:1918
1918	emacs_abort ();

(gdb) pgrowx glyph_row
[New Thread 0x1d0b of process 25723]
TEXT: 17 glyphs
  0    0: CHAR[x] pos=1099 blev=0,btyp=L w=7 a+d=12+4 MB
  1    7: CHAR[x] pos=1100 blev=0,btyp=L w=7 a+d=12+4 MB
  2   14: CHAR[x] pos=1101 blev=0,btyp=L w=7 a+d=12+4 MB
  3   21: CHAR[0xbb] pos=1102 blev=0,btyp=L w=7 a+d=12+4 face=36 MB
  4   28: STRETCH[16+12] pos=1102 w=14 a+d=12+4 face=35 MB
  5   42: CHAR[h] pos=1103 blev=0,btyp=L w=7 a+d=12+4 MB
  6   49: CHAR[e] pos=1104 blev=0,btyp=L w=7 a+d=12+4 MB
  7   56: CHAR[l] pos=1105 blev=0,btyp=L w=7 a+d=12+4 MB
  8   63: CHAR[l] pos=1106 blev=0,btyp=L w=7 a+d=12+4 MB
  9   70: CHAR[o] pos=1107 blev=0,btyp=L w=7 a+d=12+4 MB
 10   77: CHAR[-] pos=1108 blev=0,btyp=L w=7 a+d=12+4 MB
 11   84: CHAR[w] pos=1109 blev=0,btyp=L w=7 a+d=12+4 MB
 12   91: CHAR[o] pos=1110 blev=0,btyp=L w=7 a+d=12+4 MB
 13   98: CHAR[r] pos=1111 blev=0,btyp=L w=7 a+d=12+4 MB
 14  105: CHAR[l] pos=1112 blev=0,btyp=L w=7 a+d=12+4 MB
 15  112: CHAR[d] pos=1113 blev=0,btyp=L w=7 a+d=12+4 MB
 16  119: CHAR[ ] pos=0 blev=0,btyp=B w=7 a+d=12+4 MB

(gdb) print it.c
$1 = 9

(gdb) print it.pixel_width
$2 = 7

(gdb) print it.what
$3 = IT_CHARACTER

(gdb) print it.method
$4 = GET_FROM_DISPLAY_VECTOR

(gdb) print it.current_x
$5 = 28

(gdb) print it.char_to_display
$6 = 9

(gdb) print it.method


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [12-03-2017 06:29:57] <03 Dec 2017 16:29:57 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Sat, 02 Dec 2017 19:38:51 -0800
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  emacs-devel@gnu.org
> > 
> > The five faces were set up with the built-in defface macro.  I set the buffer-display-table with setq and the following variable:
> > 
> > (defvar +-buffer-display-table
> >   (let* (
> >       (display-table (make-display-table))
> >       (ff-char
> >         (cond
> >           ((eq system-type 'darwin)
> >             ?\U0001D4D5)
> >           ((eq system-type 'windows-nt)
> >             ?\u0046)))
> >       (glyph-form-feed (make-glyph-code ff-char '+-form-feed-face))
> >       (glyph-pilcrow (make-glyph-code ?\u00B6 '+-newline-face))
> >       (glyph-space (make-glyph-code ?\u00B7 '+-space-face))
> >       (glyph-tab (make-glyph-code ?\u00BB '+-tab-face))
> >       (glyph-tab-spacer (make-glyph-code ?\t '+-tab-spacer-face)))
> >     (aset display-table ?\n `[,glyph-pilcrow ?\n])
> >     (aset display-table ?\f `[,glyph-form-feed])
> >     (aset display-table ?\t `[,glyph-tab ,glyph-tab-spacer])
> >     (aset display-table ?\s `[,glyph-space])
> >     display-table)
> >   "The `buffer-display-table' that is used when `+-mode' is active.")
> 
> I cannot reproduce your problem with the latest emacs-26 branch.
> 
> The above snippet leaves a lot undefined, so I simulated that as
> follows:
> 
>   (setq buffer-display-table (make-display-table))
>   (aset buffer-display-table
>         ?\t
>         (vector (make-glyph-code ?\u00BB 'font-lock-warning-face)
>                 (make-glyph-code ?\t 'fringe)))
>   (setq word-wrap t)
>   (set tab-width 2)
> 
> Then I inserted a long line as you described, arranging for its second
> screen line to start with "xxx" followed by a TAB.
> 
> Then I emulated your calls to move_it_in_display_line_to by setting
> visual-order-cursor-movement to t, putting the cursor on the 0xBB
> character which depicts the TAB, and typing "M-x right-char RET".
> If I set a breakpoint in xdisp.c:22746, which is here:
> 
>       else if (it.current_x != target_x)
>  move_it_in_display_line_to (&it, ZV, target_x, MOVE_TO_POS | MOVE_TO_X);
> 
> I see that this call returns with it.current on the stretch glyph
> following the 0xBB character, and with it.pixel_width set correctly to
> the width of the stretch glyph.
> 
> So I think either you call move_it_in_display_line_to in some way that
> is different from the above, or there's something else you didn't tell
> in your recipe.


[-- Attachment #2: patch.diff --]
[-- Type: application/diff, Size: 121088 bytes --]

[-- Attachment #3: .scratch --]
[-- Type: application/javascript, Size: 1113 bytes --]

[-- Attachment #4: +-mode.el --]
[-- Type: application/el, Size: 30548 bytes --]