Is there an IT test for a tab-width spacer?

Is there an IT test for a tab-width spacer?

[Keith David Bershatsky]

I am working on implementing crosshairs (17684) and multiple fake cursors (22873).

it.c lets us know whether we are on the initial tab that has been assigned a character by the user with the buffer-display-table, e.g., 187/».

it.c also lets us know whether we have moved beyond that location to a tab without a character; i.e., 9, aka (char-to-string 9).

I am having trouble calculating the X and HPOS for each and every location between the initial tab and the next textual character.  A buffer-display-table for a tab that is assigned a leading 187 followed by a 9 has a minimum tab-width of 2.  Even though the buffer-local value for tab-width may be 2, that combination of 187/9 might be a total of 3 characters wide depending upon the circumstances.  And as the user increases the buffer-local tab-width value, it seemingly becomes more difficult to predict the X and HPOS.

Inching along with a test similar to line 22682 in xdisp.c seems insufficient for this particular project:  while (it.current_x + it.pixel_width <= target_x).

To analyze the width of the spacer and calculate the X and HPOS for each location within that space, is it necessary to go to the next character and then mathematically determine what the previous tab-width was?

Thanks,

Keith

Re: Is there an IT test for a tab-width spacer?

[Eli Zaretskii]

> Date: Tue, 24 Oct 2017 17:59:47 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> it.c lets us know whether we are on the initial tab that has been assigned a character by the user with the buffer-display-table, e.g., 187/».
> 
> it.c also lets us know whether we have moved beyond that location to a tab without a character; i.e., 9, aka (char-to-string 9).
> 
> I am having trouble calculating the X and HPOS for each and every location between the initial tab and the next textual character.  A buffer-display-table for a tab that is assigned a leading 187 followed by a 9 has a minimum tab-width of 2.  Even though the buffer-local value for tab-width may be 2, that combination of 187/9 might be a total of 3 characters wide depending upon the circumstances.  And as the user increases the buffer-local tab-width value, it seemingly becomes more difficult to predict the X and HPOS.

I'm sorry, but I don't understand your description: you use
terminology which I cannot decipher.  What is "the initial tab"?
"initial" in what sense?

Also, what do you mean by calculate position "for each and every
location between the initial tab and the next character"?  What are
those locations, and why do you need the coordinates of each one of
them?

Can you show an example of a buffer where this issue arises?

(I think you are making a mistake looking at it.c, you should look at
it.char_to_display instead.  The former is the character found in the
buffer or string, the latter is what actually needs to be displayed,
and it could be different, e.g., due to display-table in effect.)

> Inching along with a test similar to line 22682 in xdisp.c seems insufficient for this particular project:  while (it.current_x + it.pixel_width <= target_x).
> 
> To analyze the width of the spacer and calculate the X and HPOS for each location within that space, is it necessary to go to the next character and then mathematically determine what the previous tab-width was?

Sorry, I cannot answer these questions, because I don't understand
what you are trying to accomplish.

Re: Is there an IT test for a tab-width spacer?

[Keith David Bershatsky]

Thank you, Eli, for looking at this particular thread.

The following link contains a screen-shot of crosshairs at its present stage of development:

https://www.lawlist.com/images/tab_width_01.png

* The tab-width used in this example is 8.

* Tab is defined in the buffer-display-table as [?» ?\t].

My goal is to create solid horizontal and vertical lines spanning the window-body-width and window-body-height that tracks PT.

In the screen-shot, we can see that the spacer used for tabs is not always 8.  The tab to the immediate right of PT looks like it has a width of 4.

As we move IT, I would like to know if we can programmatically determine the width of that adjustable space [associated with a tab] and the corresponding X and HPOS of the next character.  [Once those values are known, I can place fake cursors along that adjustable space.]

Do we have to move forwards to the next character to know what the width of that adjustable space was, or can we obtain that width while IT is still at the tab.

Thanks,

Keith

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

DATE:  [10-25-2017 08:02:27] <25 Oct 2017 18:02:27 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Tue, 24 Oct 2017 17:59:47 -0700
> > From: Keith David Bershatsky <esq@lawlist.com>
> > 
> > it.c lets us know whether we are on the initial tab that has been assigned a character by the user with the buffer-display-table, e.g., 187/».
> > 
> > it.c also lets us know whether we have moved beyond that location to a tab without a character; i.e., 9, aka (char-to-string 9).
> > 
> > I am having trouble calculating the X and HPOS for each and every location between the initial tab and the next textual character.  A buffer-display-table for a tab that is assigned a leading 187 followed by a 9 has a minimum tab-width of 2.  Even though the buffer-local value for tab-width may be 2, that combination of 187/9 might be a total of 3 characters wide depending upon the circumstances.  And as the user increases the buffer-local tab-width value, it seemingly becomes more difficult to predict the X and HPOS.
> 
> I'm sorry, but I don't understand your description: you use
> terminology which I cannot decipher.  What is "the initial tab"?
> "initial" in what sense?
> 
> Also, what do you mean by calculate position "for each and every
> location between the initial tab and the next character"?  What are
> those locations, and why do you need the coordinates of each one of
> them?
> 
> Can you show an example of a buffer where this issue arises?
> 
> (I think you are making a mistake looking at it.c, you should look at
> it.char_to_display instead.  The former is the character found in the
> buffer or string, the latter is what actually needs to be displayed,
> and it could be different, e.g., due to display-table in effect.)
> 
> > Inching along with a test similar to line 22682 in xdisp.c seems insufficient for this particular project:  while (it.current_x + it.pixel_width <= target_x).
> > 
> > To analyze the width of the spacer and calculate the X and HPOS for each location within that space, is it necessary to go to the next character and then mathematically determine what the previous tab-width was?
> 
> Sorry, I cannot answer these questions, because I don't understand
> what you are trying to accomplish.

Re: Is there an IT test for a tab-width spacer?

[Eli Zaretskii]

> Date:  Sat, 28 Oct 2017 10:10:02 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  emacs-devel@gnu.org
> 
> As we move IT, I would like to know if we can programmatically determine the width of that adjustable space [associated with a tab] and the corresponding X and HPOS of the next character.  [Once those values are known, I can place fake cursors along that adjustable space.]

You have it.pixel_width.

As for HPOS, it always moves by 1 for each glyph, so there's no notion
of "width" for it.

HTH

Re: Is there an IT test for a tab-width spacer?

[Keith David Bershatsky]

Yes, that does indeed solve this issue.

Thank you very much -- greatly appreciated!  :)

Keith

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

DATE:  [10-28-2017 10:23:39] <28 Oct 2017 20:23:39 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Sat, 28 Oct 2017 10:10:02 -0700
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  emacs-devel@gnu.org
> > 
> > As we move IT, I would like to know if we can programmatically determine the width of that adjustable space [associated with a tab] and the corresponding X and HPOS of the next character.  [Once those values are known, I can place fake cursors along that adjustable space.]
> 
> You have it.pixel_width.
> 
> As for HPOS, it always moves by 1 for each glyph, so there's no notion
> of "width" for it.
> 
> HTH