[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with move_it_in_display_line_to X when tabs exist.
From: |
Keith David Bershatsky |
Subject: |
Re: Problems with move_it_in_display_line_to X when tabs exist. |
Date: |
Mon, 04 Dec 2017 00:03:10 -0800 |
I could use a little help, please, to perform the same test that you did. I
built Emacs 26 tonight _without_ any modifications for both OSX and Windows. I
launched Emacs 26 on both platforms with no user configuration using gdb. From
gdb, I set a breakpoint as follows:
break xdisp.c:22746
I created a long word-wrapped line with a single space at the right window
edge, followed by a continued line with three (3) xxx, followed by a tab,
followed by hello-world. I evaluated the following code (using setq instead of
set for the tab-width):
(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)
(setq tab-width 2)
(setq visual-order-cursor-movement t)
I placed by my cursor on the 00BB character (aka »), and I typed M-x right-char.
On both platforms, IT is on the second "x" from the far left of the window
edge. In other words, I appear to be moving in the wrong direction and when I
go to print the it.*** info in gdb, I am clearly on the second "x" -- i.e., I
am one character to the _left_ of ».
Thanks,
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [12-03-2017 06:29:57] <03 Dec 2017 16:29:57 +0200>
FROM: Eli Zaretskii <address@hidden>
>
> * * *
>
> 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.
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/02
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/02
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/02
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/03
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/03
- Re: Problems with move_it_in_display_line_to X when tabs exist.,
Keith David Bershatsky <=
- Re: Problems with move_it_in_display_line_to X when tabs exist., Keith David Bershatsky, 2017/12/06