nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] a problem with tabs after the overhaul


From: David Ramsey
Subject: Re: [Nano-devel] a problem with tabs after the overhaul
Date: Fri, 17 Mar 2017 11:55:10 -0500

On Fri, Mar 17, 2017 at 11:14 AM, Benno Schulenberg
<address@hidden> wrote:
> To reproduce, run:
>
>     stty cols 75 && src/nano --ignore --soft --nowrap --smart +233 
> doc/faq.html
>
> Now type tabs until the cursor has moved well into the next row.
> Then type <Home>.  The cursor goes home to the beginning of the
> entire line, as expected.  Now type <Down>.  The cursor goes to
> somewhere near the end of the row.  (This is weird, but emacs
> does the same, so... let it pass.)  Now press <Down> again, and
> again, and again...  The cursor doesn't move.  It is stuck.  :|
>
> Expected behavior: upon the second <Down> the cursor goes to the
> beginning of the third chunk, and so on.

Unfortunately, this is another manifestation of nano's problems
with a character at the edge of the screen taking up multiple
columns, which is unfixable until variable-length chunk support is
added.  If it was a control character at the edge of the screen, it
would cause similar problems.  This is why I figured that
variable-length chunk support (as opposed to using it to break
lines at whitespace) wasn't a new feature, but a bugfix.  (Unless
you have another way to do it, because even your other fix for
two-column Unicode won't fix this.)

As for what's causing the bug, somewhere near the end of the row is
column 72, and the tab right after it is column 80.  Since the edge
of the screen is column 74, it can't put the cursor directly at the
end of the line, because it's in the middle of a tab, so it puts it
at the beginning of the tab due to how actual_x() calculates
things.  As for why the cursor jams, it's because placewewant is
column 72, and the formula to convert placewewant into a value
relative to the current chunk is (placewewant % editwincols), which
ends up being zero since editwincols is 75.

As for fixing it, since that involves the variable-length chunk
support, I know you objected to moving placewewant calculation into
its own function in the variable-length chunk support, but that was
only to allow easily changing placewewant to be relative to the
current chunk in softwrap mode.

With variable-length chunks, it's impossible to figure out the
relative placewewant using the non-relative placewewant unless nano
knows what screen column the non-relative placewewant is on.  That
screen column can only be determined when placewewant is set, and
it's only set by horizontal movement, so trying to calculate it on
the fly during vertical movement is too late.  It was the only way
I could think of to do it.  (I didn't move it into a function
arbitrarily; it was for a good reason.)

So, in short, if you want this fixed... either variable-length
chunk support gets in earlier, everyone lives with problems like
this until variable-length chunk support gets in, or you come up
with something else in the meantime.  Again, no offense.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]