Re: [Nano-devel] Port of variable-length chunks to 2.8.2

[Benno Schulenberg]

On Thu, May 11, 2017, at 00:15, David Ramsey wrote:
> On Wed, May 10, 2017 at 3:28 PM, Benno Schulenberg
> <address@hidden> wrote:
> > It badly needs to be improved performance-wise.
> 
> I know that.  However, Mark Majeres' code was the only thing that did
> so, and it didn't even work correctly in all cases, so if you have some
> ideas to to how, please speak up, because I'm short on inspiration as to
> where to cache these things.

I don't know, as I have avoided looking at this code.  But now
that I have used 'set atblanks' for a few minutes, I think nano
really needs to have this feature and that performance issues
can be solved later.

>  (For example, the main() loop won't work
> if we're in something like the replace loop.)  And considering that my
> ability to guess the variable and/or function names you want is limited,
> if you wouldn't mind giving me a hint as to what to call them so I don't
> have to rewrite the code quite as often?

Renaming something shouldn't require any rewriting.  Assuming
you regularly do a 'git rebase master' of your branch, you could:

rm 00*
git format-patch master
sed -i 's/name/othername/' 00*
git checkout master
git checkout -b newone
git am 00*

> > I would simply set this variable to FALSE whenever it is declared,
> > saving an 'if' on every call.
> 
> Even in the cases where end_of_line isn't used, which would mean
> declaring a dummy boolean?

As in this case there is just one call that uses NULL, I would probably
have chosen to pass a dummy instead.  It is done elsewhere in the code.

> > I'm not sure I want clicking after the breakpoint to shift the cursor
> > back to the last column of the line.  If the user clicks beyond the
> > last column, it means they want the cusor /there/, and that means
> > that the cursor will in effect appear at the start of the next row.
> 
> If the terminal is 80 columns wide, the line is softwrapped at column
> 74, and you click on column 78, your proposed solution will put the
> cursor at column 4 of the next line, which is nowhere near where you
> clicked the mouse, because of how actual_x() works.  Even if I change
> that to move it to column 0 of the next row, neither approach seems
> intuitive to me, and neither approach matches the behavior of any other
> editor I've seen that does softwrapping; all other editors I've seen
> shift back to the last column of the line.

Okay; let the cursor stay always on the row that was clicked on.

> > Why does spotlighting need to redraw the '>' marker?
> 
> If the text you're replacing is spread across more than one softwrapped
> line (as it can be if you're dealing with an unbroken line that takes up
> more than one row, and the match just so happens to straddle between
> rows), the ">" needs to be drawn as part of the highlighted text, just
> as it is on the screen originally.  Just drawing the word in the same
> place, as the current code does, is no longer enough.

This part:
> the ">" needs to be drawn as part of the highlighted text
seems to contradict what you say a bit later:

> The wattron is used to highlight matches, the wattroff is used to *not*
> highlight the ">" parts of the match, since the ">"'s are not actually
> part of the word,

And if I remove that redrawing of ">", I can't see things getting
mishighlighted.

The non-softwrap routine has a special case for zero-length matches,
the softwrap routine doesn't.  When trying to replace the regex "^"
in the new softwrap mode, nothing gets highlighted.

Benno

-- 
http://www.fastmail.com - Accessible with your email software
                          or over the web