Re: [Nano-devel] Softwrap navigation overhaul

[David Ramsey]

On Wed, Feb 8, 2017 at 5:57 AM, Benno Schulenberg
<address@hidden> wrote:
> But the answer is yes.  There are three places where a chunks()
> routine is called with editwinrows - 1, one place where it's called
> with editwinrows - nrows, and once with editwinrows / 2.  They all
> risk being zero.  The question then becomes: does the case need
> special treatment?  It seems not: for nrows == zero, all the ifs and
> fors just fall through and become noops.  Good.

Indeed; I only removed returning on zero, and (editwinrows - 1)'s being
zero is handled by the earlier fix for having only one row onscreen.  As
for the noops, that's why I made the loop go backwards instead of
forwards; it's by design.

> This is horrible.  For every chunk++ you recompute the line span
> completely superfluously.  You have to duplicate the assignment to
> last_chunk: once before the loop, and once at the tail of the loop.
> For a small optimization, you could conditionalize the latter with an
> 'if (i > 0)', but for now just drive straight.

Fixed locally.

> (Later on we will probably, a la Mark Majeres, want to simply store
> the line span of each line in its linestruct (misnomed filestruct).
> That should speed things up a bit.)

Indeed.

> Also, I don't like the parenthesis around last_chunk computation.

Removed locally.

> Well... this is complicated.  It has to do with double-width
> characters sitting on the boundary between two chunks.  When this
> happens, this character should not be included in the lefthand chunk,
> and the righthand chunk should start a column earlier -- I think.  But
> that makes the calculation of the number of chunks wildly complicated.
> Don't know how to solve that.

Hmmm.  And having the lines wrap on whitespace long-term will still need
a solution to this: if the line in question is wider than the screen and
has no whitespace, there's no way to break it except the way we do so
now.

> Maybe a "solution" would be to not use the last column of the screen,
> so that a double-width character in the penultimate column can
> "overflow" into this column instead of disappearing?
>
> (Problem is related to https://savannah.gnu.org/bugs/?49440.)

I'll look into this.