SetFirstVisibleLine not working?

[peter-wall]

My plugin extracts a string from the current line of the active document, identifies a file containing the string, opens that and positions the caret at the line/column.
That part works but the location is not necessarily visible so I am using SetFirstVisibleLine() to bring the it in to view.
But it doesn’t.
If I use SetFirstVisibleLine() in the original document it works but not in an opened file - or a new file for that matter.
It’s as if the editor doesn’t know which document is active.
I’ve tried LineScroll() but that behaves in the same way.

[PeterJones]

@peter-wall ,

Using PythonScript (which allows me to do the equivalent calls to a plugin, without all that pesky compiling and overhead), I can use the sequence

notepad.new()
editor.setText("Hello,\nworld\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")
editor.addText("Second,\ngroup\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")
editor.setFirstVisibleLine(35)

And that correctly sets the first visible line to the second group.
So it correctly scrolls in a new file just fine.

It may be that you have two views open, and you are sending the commands to editor2 even though editor1 is where the new file is (or vice versa).

Or if you only have one editor view, you may have accidentally gotten yourself into the state that you have closed/hidden editor1, so that editor2 is the active editor; thus, when you created the new file, it was in editor2, but you are sending commands to editor1, so things don’t update.

[peter-wall]

@PeterJones said in SetFirstVisibleLine not working?:

editor.setFirstVisibleLine(35)

Thanks Peter.

I’d be interested to see what happens for you if you do another couple of addTextCalls and then setFirstVisibleLine(105).
The issue I’m seeing seems to be where the target line is not within visible range - i.e. my window has space for 64 lines.

Also, I seem to get different behaviour with your snippet depending on whether I use AddText() or AppendText(). With the former the caret gets positioned on line 106, using the latter it remains on line 1.

[PeterJones]

@peter-wall ,

The issue I’m seeing seems to be where the target line is not within visible range - i.e. my window has space for 64 lines.

For me, the 35 was beyond the current visible screen. Regardless, I added another couple groups of text, and went to line 105, and it still scrolled properly, putting 0-based line#105 (ie, Notepad++ calls it 106) as the first line in my editor view, with no difficulty or unexpected behavior.

I seem to get different behaviour with your snippet depending on whether I use AddText() or AppendText()

Regarding addText vs appendText: yes; addText adds the argument wherever the cursor currently is; appendText puts the text at the end of the file, no matter where the cursor is. That’s well-documented in the PythonScript documentation for those two methods, and in the Scintilla documentation that they link to for those two different SCI_… message calls

[PeterJones]

@peter-wall .

You may also want to study editor.visibleFromDocLine() * and editor.docLineFromVisible() *, because if you have hidden text or folded sections of code in your actual data (as opposed to my dummy data), then the actual line number might not match what you expect it to.

[pnedev]

@peter-wall ,

I have also seen such behavior in my NppGTags plugin.
If I want to open a file and scroll the view to a line that is several pages down (I use NPPM_DOOPEN + Scintilla SCI_SETFIRSTVISIBLELINE) it doesn’t always work.
Sometimes it works as expected but sometimes the view scroll doesn’t happen. Because I also position the caret on that line it is always successfully positioned.
That started happening after Notepad++ v8.4.2. In previous versions the problem didn’t exist.
I thought that the reason on my side might be connected to me running under Wine on Linux.
It seems like when NPPM_DOOPEN does its job and returns the control to the plugin there is still something going on that re-positions the view at the start of the file (maybe the document lexer, I don’t know).

[peter-wall]

Thanks Peter.

The document does have foldable sections but they are all fully expanded.
I’ll try perhaps with a plain text file and see whether there’s any difference.
As you can probably tell this is a background task and I can only dedicate the odd moment to it hence the delay in responding.

Thanks again for your thoughts.

@PeterJones

[peter-wall]

Ah, good to know it’s not just me!

I’ve also tried using the SCI_SETFIRSTVISIBLELINE but that doesn’t work for me either.

I have seen this working and I have updated Notepad++ recently - I’m on v8.4.4.

Perhaps I’ll reinstall an earlier version and see whether that behaves any better.

Cheers, Peter.

@pnedev

[peter-wall]

This behaviour stopped for quite a while and then mysteriously came back. It was working on one install of Notepad++ but not in another - both the same version.

Turns out, it was related to word wrap. It works if that setting is off.

My solution is to get the current word wrap setting, set w-w off, set my visible line and reinstate the original w-w setting.

[PeterJones]

@peter-wall said:

It works if that setting is off.

It works, full stop. You just need to understand the documentation. As ScintillaDoc says for SCI_SETFIRSTVISIBLELINE, “These messages retrieve and set the line number of the first visible line in the Scintilla view. The first line in the document is numbered 0. The value is a visible line rather than a document line.” (emhasis added).

The “document line” in Scintilla is the same thing that Notepad++ numbers in the line number column: it’s the real line, no wrapping. The “visible line” is affected by hiding lines and/or wrapped lines: if you have lines hidden in the document, that can decrease the visible line index relative to the document line number; if you have lines wrapped, that can increase the visible line index relative to the document line number.

Scintilla has commands like SCI_VISIBLEFROMDOCLINE and SCI_DOCLINEFROMVISIBLE to help transform between the two concepts, and SCI_WRAPCOUNT will help you determine how many visible lines a single document line will become.

If you want to turn word wrapping off, set your visible line, then reinstate word-wrapping, that’s fine; but the Scintilla messages provide other ways to allow you to correctly handle visible-line vs display-line.