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 (tracking 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 <address@hidden>
> 
> * * *
> 
> 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.