Thu 11 May 2017 06:49:12 PM UTC, comment #4:
> Setting placewewant differently in softwrap mode was done in
> the earlier version of the variable-length chunks.
I only commented on the variable-width chunks when it formed a single patch set with the overhaul, but only in the sense that it was far too much code and that I didn't want to go there.
> resizing the window also makes Up and Down not put the cursor
> at the same place either, since the effective column has changed
> while the numeric value of placewewant hasn't
If that is so, then that is a bug too -- whenever <Up>+<Down> is not immobile, it is a bug. But I have a hard time reproducing this. I've seen it twice now, but most of the time <Up>+<Down> do the right thing. If you can find a sure-fire recipe, please report a separate bug.
|
Thu 11 May 2017 03:40:19 PM UTC, comment #3:
Okay; I was not sure what the quotes were.
Setting placewewant differently in softwrap mode was done in the earlier version of the variable-length chunks.
As for vertical placement, resizing the window also makes Up and Down not put the cursor at the same place either, since the effective column has changed while the numeric value of placewewant hasn't. I thought this was another indicator that this wasn't a problem. So I guess I don't understand; why is this bug a problem while the other instances of it (other than the one you already mentioned) aren't?
|
Thu 11 May 2017 09:07:15 AM UTC, comment #2:
Yes, I know the column isn't random. That's why I wrote "random".
> an alternate solution of setting placewewant by one method in
> softwrap mode and by another method in non-softwrap mode is
> something you already turned down in one of my previous patch sets
I did? Where was that?
> this issue doesn't seem to be a problem.
It is a problem, because after doing <Up><Down> (or <Down><Up>) the cursor is no longer at the same place. And that is a property the editor must have. The same for <PageUp><PageDown> and vice versa (in smooth mode, and as long as we don't hit top or bottom of file, of course). Attached patch achieves this.
(file #40662)
|
Wed 10 May 2017 08:13:37 PM UTC, comment #1:
The column here actually isn't random, and it's set by the same logic that's used for the README case you mention.
Specifically, in the faq.html case, nano goes to the closest reachable column: column 474, since the line is shorter than 501 columns. Press Up, and the cursor goes to the "n" of "gnu", which is on column 341 of the line. Press Down again from there, and the cursor goes to the "y" of "anonymous", which is on column 421 of the line. If the line were at least 501 columns, pressing Down again would make the cursor go to column 501. So the cursor is in the proper vertical position for column 501, which, given the way placewewant is constrained by the column width of the screen, is exactly as expected, and the best we can do.
Setting placewewant to the column it actually lands in, as you suggest, would also mean that, in the README case, placewewant would be set to column 0 instead of column 40, since the line in question has no column 40, but you say that the bahavior for README should be left as-is because it's been that way for ages.
So... given that you don't want to change the existing behavior for README, and an alternate solution of setting placewewant by one method in softwrap mode and by another method in non-softwrap mode is something you already turned down in one of my previous patch sets, this issue doesn't seem to be a problem.
|
Wed 10 May 2017 04:00:21 PM UTC, original submission:
To reproduce, in an 80-column terminal, run:
nano --ignore --softwrap +116,501 doc/faq.html
Then type <Up>. Instead of going to the character directly above it (the "c" of "document"), the cursor goes to the "n" of "gnu", half a row to the left. That is unexpected.
When running 'nano +8,40 README', and then typing <Up> or <Down>, the cursor going to the word "friendly" or "licence" is less surprising, because the user «ordered» the cursor to column 40. (Plus: it has been this way for a long time, so we shouldn't change that.)
But in the softwrap case, the user didn't order the cursor to screen column 21. So... when the desired column is not reachable, then nano should set placewant to the column that it actually lands in, so that moving from there won't be surprising.
"Bug" exists since nano-2.8.0, since the new softwrap paradigm.
|