Page down key does not work if there are too many removed lines

[M393]

With the cursor in line 4040 on the right side, pressing page down does nothing.

Looks like the page up/down behavior in Notepad++ is implemented by moving the cursor and then scrolling the cursor into view, so this poses a problem when there is no line to place the cursor on, but maybe it's possible to use the next available line instead of not moving the cursor.

Not sure if this is a plugin problem or would need a fix in Notepad++ itself.

[pnedev]

@M393 ,

I'll look into it, thanks 👍

[pnedev]

@M393 ,
Hi again,
This issue is coming directly from Notepad++ - the plugin does not handle document navigation on its own.
I can try manually processing navigation to circumvent this shortcoming but I prefer not to do it.
I'll leave the issue open as a reminder if I decide to look at it in the future. Thanks.

[M393]

Thank you, @pnedev, I reported it to Notepad++, maybe it can be resolved there.

[xomx]

This issue is coming directly from Notepad++ - the plugin does not handle document navigation on its own.

Hello @pnedev ,
this looks to me as the ComparePlus issue as I did a quick replacement by the old Compare v2.0.2 and it works with the PageDown as the OP expected even in my latest N++ v8.6.9. I know absolutely nothing about how your plugin works, but Scintilla probably does not see the ComparePlus enlarged view size for the smaller doc (enlarged to match the bigger doc one, I mean that inserted grey-area visible in the OP's pic above). But OTOH it is interesting that the scroll-bar behavior seems to be ok at the same time.

[pnedev]

Hi @xomx ,

The old Compare plugin (2.0.2) uses real custom-inserted empty lines to achieve the synchronization between both views.
ComparePlus uses Scintilla annotations to do that which has many advantages (the main one is not messing up the undo/redo functionality) but also has several shortcomings like slower views refresh and this issue as well.

So the problem is maybe Scintilla itself as it directly handles annotations. You could make a simple test to verify this:

1. Create a new file in Notepad++ containing at least 2 lines.
2. Open PythonScript plugin console.
3. Execute there editor.annotationSetVisible(1)
4. Execute editor.annotationSetText(0, "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"). If annotation does not fill the whole screen please add more \n's in the above command.
5. Go to the first line in the document (after which the annotation starts) and try using PageDown key. You should observe that it does nothing - the page is not scrolled. You need to use the ArrowDown key to move the view to the next line.

BR,
Pavel

[xomx]

You could make a simple test to verify this:

Ok, I am able to reproduce your STR.

But there should not be any reason for a reached range difference in between the PageDown and the scroll-bar use...

So now I think this is a potential bug in the Scintilla PageDown handler (direction == +1 ... PageDown, -1 ... PageUp):
https://github.com/notepad-plus-plus/notepad-plus-plus/blob/8e26e08c1cf799c632c3cdc067804ed128f6e743/scintilla/src/Editor.cxx#L3013
the problem there seems to be somewhere inside the SPositionFromLocation.

[pnedev]

I am posting here a link to a comment of mine in the corresponding Notepad++ issue thread which describes a problem with last line views synchronization of ComparePlus : notepad-plus-plus/notepad-plus-plus#15579 (comment)

It is just a reminder for me to look at this (has nothing to do with PageDown behavior which is another issue unrelated to ComparePlus).

[pnedev]

The last line scroll issue caused by ComparePlus 1.2 views sync function is fixed and will be available in the next plugin version.
The PageDown key issue is caused by Scintilla so it is still present and currently I am not planning to do a work-around fix in the plugin.