Re: Efficiently using MOVE_IT_... to gather a plethora of information.

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Keith David Bershatsky]

Thank you, Eli, for reading this thread and also for confirming that the connect-the-dots diagram 1 to 9 is the most efficient order for moving IT to gather data.

On my wish list of things to do is to extract your new built-in line numbers and incorporate them into an older version of the master branch that I am still using because certain unrelated bugs prevent me from using the current master branch in my preferred daily workflow.  For the past few years, I have been generating line numbers on just the visible window and that is why I need the beginning of the lines.

Your suggestion about being smarter in the data gathering is well taken, and I will give it some serious thought as I move forward in the development of the vertical line feature.  I have been gathering data for each screen line at all three (3) locations and storing that data in a list -- I'll call this "the whopper/everything".  Once all of the data is gathered, I iterate over each element of the list and see whether certain criteria is met -- e.g., this element is for the beginning of a line, so put line numbers; this element is for the end of a line, so put pilcrows and maybe part of a floating vertical line (tracking the cursor position); this element is aligned with the real cursor and we are in the middle of a line of text, so draw a portion of thin vertical line through the text (t
 racking the cursor position).  Until just a few days ago, I had no solution for the conflict between buffer-display-table pilcrows and the overlay after-string -- however, the invention of glyphless
  bar fake cursors should resolve that problem by eliminating the need for overlay after-strings.

Based upon your comments about there being no magical way of moving IT more efficiently, I will work on coming up with a set of criteria to move IT sparingly to just the essential locations instead of "the whopper/everything".

I have been using mono-spaced fonts since day one and have never thought about how these feature requests might be affected by variable fonts.  I'll give that some thought in the coming days/weeks/months/...  My initial impression would be that a vertical line indicating the fill-column would not be helpful to a user with variable fonts; however, the vertical line that tracks the cursor position might be a useful feature for certain situations depending upon a user's preference and what may be happening in the visible window.

Keith

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

DATE:  [08-22-2017 12:16:41] <22 Aug 2017 22:16:41 +0300>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> * * *
> 
> You need to do this for _every_ screen line in the window?  If so,
> this will be terribly slow, so slow as to be impractical in some
> situations.
> 
> Why do you need all those coordinates of all the screen lines?
> 
> Btw, if variable fonts are used, the cursor positions on two adjacent
> lines might not be aligned, so I'm not sure I understand how your
> feature is supposed to work in that case.
> 
> > This project utilizes the MOVE_IT family within xdisp.c.  We would probably all agree that we start the IT at w->start, but where do we go from there is the question.  Is the following connect-the-dot the most efficient approach to move the IT to each location from window-start to window-end?
> > 
> > 1  2  3
> > 
> > 4  5  6
> > 
> > 7  8  9
> 
> The move_it_* functions all proceed in the buffer logical order, so
> you are traversing all these places anyway.  IOW, yes, this is the
> most efficient order.  But it will be very slow, if you need to do
> this for all screen lines in a window.

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Stefan Monnier]

> Your suggestion about being smarter in the data gathering is well
> taken, and I will give it some serious thought as I move forward in
> the development of the vertical line feature.

BTW, regarding that vertical-line feature: wouldn't it make sense to
implement it not by sprinkling various little chunks of vertical bars in
the glyph matrices (with the difficulty of making sure they are
correctly connected, with the right color and what not), but by drawing
it on top of the text?

Having a "second layer" that can used to draw on top of the text would
also be useful, e.g. to draw little arrows connecting various parts of
the text.


        Stefan

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[martin rudalics]

 > BTW, regarding that vertical-line feature: wouldn't it make sense to
 > implement it not by sprinkling various little chunks of vertical bars in
 > the glyph matrices (with the difficulty of making sure they are
 > correctly connected, with the right color and what not), but by drawing
 > it on top of the text?
 >
 > Having a "second layer" that can used to draw on top of the text would
 > also be useful, e.g. to draw little arrows connecting various parts of
 > the text.

We could try using "always on top" child frames.  Anything else would
probably clase with redisplay optimizations

martin

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[martin rudalics]

> We could try using "always on top" child frames.  Anything else would
> probably clase with redisplay optimizations
              ^sh

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Stefan Monnier]

> Anything else would probably clase with redisplay optimizations

I don't think so.  Changing every frame so it uses a composition of a Gtk
canvas (completely transparent by default) layered on top of our usual
text area should make it possible to keep the new feature
largely separate.  Of course, you'll probably want to update the canvas
in response to changes to the underlying text, so reality is
more complicated.

And in case you wonder, no, I have no time nor intention to work on this
in the coming decade.


        Stefan

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 22 Aug 2017 23:58:21 -0400
> 
> BTW, regarding that vertical-line feature: wouldn't it make sense to
> implement it not by sprinkling various little chunks of vertical bars in
> the glyph matrices (with the difficulty of making sure they are
> correctly connected, with the right color and what not), but by drawing
> it on top of the text?

This requires infrastructure that waits a motivated volunteer to
implement it.

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Eli Zaretskii]

> Date:  Tue, 22 Aug 2017 13:17:38 -0700
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  emacs-devel@gnu.org
> 
> I have been gathering data for each screen line at all three (3) locations and storing that data in a list -- I'll call this "the whopper/everything".  Once all of the data is gathered, I iterate over each element of the list and see whether certain criteria is met -- e.g., this element is for the beginning of a line, so put line numbers; this element is for the end of a line, so put pilcrows and maybe part of a floating vertical line (tracking the cursor position); this element is aligned with the real cursor and we are in the middle of a line of text, so draw a portion of thin vertical line through the text (tracking the cursor position).

IMO, this design is sub-optimal, and will necessarily cause slowdown,
sometimes a very serious one.  What you should do instead is generate
your numbers, pilcrows, and thin lines as part of the basic layout
code in display_line.  That is, do that on the fly, whenever
display_line gets to the point where you need to produce something
special.  Doing that as an after-thought, in a separate cycle that
follows redisplay is bound to be slow.  The native line numbers are
much faster than linum.el and similar packages precisely because it
produces line numbers on the fly, whenever the lines are laid out.

Efficiently using MOVE_IT_... to gather a plethora of information.

[Keith David Bershatsky]

I am working on two of my related feature requests:  #17684 (vertical line spanning window body height); and, #22873 (multiple fake cursors).

draw_window_cursor is used to create fake cursors with/without glyphs on top -- the creation of glyphs is optional by permitting/suppressing the call to draw_phys_cursor_glyph.  On OSX, a glyphless fake cursor (i.e., no character on top) can be erased by redrawing it with the window background color.  Fake cursors with glyphs on top (i.e., a character) are erased with erase_phys_cursor.  [I have not yet experimented with erasing a glyphless fake cursor on a Windows or X11 platform, but am hoping the concept is similar to the approach I use for OSX.]

The combination of glyph/glyphless fake cursors can be used to create a thin vertical line spanning the window body height, which has a variety of applications; e.g., a vertical line indicating the fill-column, a vertical line that tracks the cursor position, etc.

Creating a horizontal line spanning the window body width is easier, and can be done with hbar fake cursors and/or overlays (using a combination of 'display and 'after-string properties with an :underline).  This application is similar to hl-line-mode, except that the :underline can be extended beyond the end of the text.

`word-wrap` set to a non-nil value and truncate-lines set to a nil value makes the coordinate calculations costly if they are run each command loop.  At the present time, I am using an idle timer to calculate/display the vertical line.

The method that I am presently using to calculate coordinates is inefficient and relies upon a unique set of circumstances that must exist for everything to work.  I am looking for the most efficient approach to calculate certain values at three locations of each visible screen line -- `point` and coordinates (x/y/hpos/vpos):

1.  Beginning of each visible screen line.

2.  Ending of each visible screen line.

3.  The current X axis aligned with the cursor on each visible screen line.

This project utilizes the MOVE_IT family within xdisp.c.  We would probably all agree that we start the IT at w->start, but where do we go from there is the question.  Is the following connect-the-dot the most efficient approach to move the IT to each location from window-start to window-end?

1  2  3

4  5  6

7  8  9

Thanks,

Keith

Re: Efficiently using MOVE_IT_... to gather a plethora of information.

[Eli Zaretskii]

> Date: Tue, 22 Aug 2017 11:26:25 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> 
> The method that I am presently using to calculate coordinates is inefficient and relies upon a unique set of circumstances that must exist for everything to work.  I am looking for the most efficient approach to calculate certain values at three locations of each visible screen line -- `point` and coordinates (x/y/hpos/vpos):
> 
> 1.  Beginning of each visible screen line.
> 
> 2.  Ending of each visible screen line.
> 
> 3.  The current X axis aligned with the cursor on each visible screen line.

You need to do this for _every_ screen line in the window?  If so,
this will be terribly slow, so slow as to be impractical in some
situations.

Why do you need all those coordinates of all the screen lines?

Btw, if variable fonts are used, the cursor positions on two adjacent
lines might not be aligned, so I'm not sure I understand how your
feature is supposed to work in that case.

> This project utilizes the MOVE_IT family within xdisp.c.  We would probably all agree that we start the IT at w->start, but where do we go from there is the question.  Is the following connect-the-dot the most efficient approach to move the IT to each location from window-start to window-end?
> 
> 1  2  3
> 
> 4  5  6
> 
> 7  8  9

The move_it_* functions all proceed in the buffer logical order, so
you are traversing all these places anyway.  IOW, yes, this is the
most efficient order.  But it will be very slow, if you need to do
this for all screen lines in a window.