Notepad-plus-plus: Jump to another lines when you switch tabs

[EgorAnatolievich]

Description of the Issue

Sorry, my English is not well, but I'll try.
If you switch between tabs, where a lot of lines, text jump to another lines.

Steps to Reproduce the Issue

1. Open two tabs with a lot of lines.
2. In tab_1 pagedown anywhere
3. In tab_2 pagedown anywhere
4. Switch between the tabs and focus lose in tab_1 or tab_2

Look the screenshots.

Expected Behavior

When you switch between the tabs, focus didn't lose. You always see lines what lines you saw before switch.

Actual Behavior

When you switch between the tabs, lines are jump.

Debug Information

Notepad++ v7.5.6 (64bit)
Build time: Mar 19 2018 - 00:23:17
Windows 10 Pro 64-bit Versions 1803 (OS Build 17134.48)

[sasumner]

What plugins do you have installed? Do ? menu, choose Debug Info. If I'm remembering correctly, this kind of issue always ends with a plugin causing it.

[EgorAnatolievich]

Debug info:

Notepad++ v7.5.6 (64-bit)
Build time : Mar 19 2018 - 00:23:17
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : ComparePlugin.dll DSpellCheck.dll mimeTools.dll NppConverter.dll PluginManager.dll PythonScript.dll XMLTools.dll

[sasumner]

I would try removing the plugins one at a time and see if behavior changes. Remove the plugins that do not come standard with Notepad++ first, as that is where you are likely to find the problem (if it is to be found that way).

[SinghRajenM]

This seems to be duplicate of #2078, #2576, #264, #3261, #3570, #3015, (bit similar to #3338).

[EgorAnatolievich]

Sorry for duplicate report. Very sad that this bug din't fix :(
Should I close my issue?

[sasumner]

@EgorAnatolievich At this point I would say leave the issue open. One would think that with all these issues open it would get some attention. :(

[cmeriaux]

I looked at the code, there are two issues : one in Notepad++ and one in scintilla.
When Npp saves the first visible line, it saves the document line number instead of the visual line

int32_t displayedLine = static_cast<int32_t>(execute(SCI_GETFIRSTVISIBLELINE));
int32_t docLine = static_cast<int32_t>(execute(SCI_DOCLINEFROMVISIBLE, displayedLine));
...
Position pos;
pos._firstVisibleLine = docLine;
...
buf->setPosition(pos, this);

Fixing this issue in NPP is not enough because there is still an issue on scintilla side. As we have an old verison of scinitlla, I don't think we'll have a fix for that.
For the record, scite have the same issue.

@EgorAnatolievich you seems to have another behavior. Can you share your text files ? So I'll check if there is another issue.

[EgorAnatolievich]

@cmeriaux sure.

Temp.zip

[EgorAnatolievich]

@cmeriaux, hello!
Any news?

[cmeriaux]

@EgorAnatolievich
I reproduce the issue with your files. The issue is reproductible only in release mode. Debug mode doesn't have the isue.
With some print (OutputDebugStringA), I found the line that does not work

int lineToShow = static_cast<int32_t>(execute(SCI_VISIBLEFROMDOCLINE, pos._firstVisibleLine));

It's a scintilla issue. I found a workaroud in the file FindReplaceDlg.cpp (which may have encout : send scintilla message SCI_ENSUREVISIBLE before SCI_VISIBLEFROMDOCLINE.

Now it seems to work. Can you please try on the nightly build ?
Thanks

See PR #4624

[EgorAnatolievich]

I didn't understand what should I do.
Where I can get the nightly build? Your PR is wait to merge into master, right?

[cmeriaux]

Here is the nightly build of the PR:
https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.2137/job/otit9y7f9oj8x8t0/artifacts

[cmeriaux]

@EgorAnatolievich any news on your side ?
I pushed another commit to fully fix the issue.
Here is the nighly build : https://ci.appveyor.com/project/donho/notepad-plus-plus/build/1.0.2139/job/cjjm8vbo05utuc9i/artifacts

[EgorAnatolievich]

Sorry, I have a lot of work.
I try to launch with this two files. And notepad++ didn't start.
What should I do with the nightly build?

[bersbersbers]

I have the same issue, and would like to verify that the nightly build fixes it. However, I get certificate/SCINTILLA errors on my (64 bit) system when running the nightly build. Is there another way?

[cmeriaux]

@bersbersbers keep the original scintilla dll and use only notepad++.exe artifacts

[bersbersbers]

I tried that:

:(

[cmeriaux]

@bersbersbers you are using a 32bits artifacts in a 64 bits install.
Try again with the 64 bits artifacts.

[bersbersbers]

@cmeriaux thanks, got it! This fixes the issue that I had, so you can certainly go ahead with this fix.

[Franz333]

Hi,
I have the same problem.
Could you please post the links to the 64 bits artifacts?
Thanks a lot

[cmeriaux]

@Franz333 it's now delivered in v7.5.9.
https://notepad-plus-plus.org/download/v7.5.9.html

[Franz333]

@cmeriaux Thanks Christophe, I'll check now..
All the best

[Franz333]

Well actually the problem still remains... :-(
So annoying
what a waste of time !

[bersbersbers]

Fixed for me, thanks. @Franz333, maybe you are seeing a different issue?

[Franz333]

Good that yours is fixed :-)

I dunno..

Here is my conf :

Notepad++ v7.5.9 (64-bit)
Build time : Oct 14 2018 - 15:19:55
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : DSpellCheck.dll mimeTools.dll NppConverter.dll AutoSave.dll ComparePlugin.dll PluginManager.dll

[bersbersbers]

@Franz333 if you do not know if you have a different issue than is described here, maybe you put together some reproduction steps, file a new issue and mention it here? They can always be merged if they turn out to be duplicates.

[Franz333]

Every post related to this problem are pointing to this one as a solution :

Jump to another lines when you switch tabs #4571

[bersbersbers]

@Franz333 I can only encourage you to post concrete reproduction steps. Ideally, upload a text document, tell us what to do (go to which line, switch to which tab/application, go back, note different line)? Without that, there is a good chance that no one can reproduce your issue, and thus no one can fix it.

[Franz333]

I can't describe it better than how it was described in this post.
I am now switching to another tool which is a shame cause I really liked notepad++
thanks @bersbersbers

[cmeriaux]

@Franz333 you may double check the test you've done. This issue is fixed and it's confirmed by several users. So they are two possibilities :

1. You didn't try the latest release
2. You have another issue with others conditions. In that case, please help de community and explain your bug

[Franz333]

@cmeriaux I will try to explain the situation more precisely eventually but for now I really need a steady tool to finish a job..

I will come back here soon..

Thanks

[yair-s]

Good fix for tab switching, however remembering tab screen layout on startup has the old bug.

A similar but separate issue is that startup does not remember the layout direction setting i.e. Menu|View|Text Direction RTL.

[GCWolle]

Hello,
I've the same Problem on a very fresh installing WIN10 with this scroll-up displacement when changing tabs, happens with .html files that have very long lines, and only if the option view > word wrap is enabled.

Notepad++ v7.6.3 (64-bit)
Build time : Jan 27 2019 - 17:16:47
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : DSpellCheck.dll mimeTools.dll NppConverter.dll XMLTools.dll _CustomizeToolbar.dll

Did I miss something?

Wolfgang

[amiga-500]

Problem stil persists for me too so u arent alone @GCWolle. Using the latest N++ (7.6.1). Been dealing with this problem since day 1. I disabled all plugins..same issue. I dont have XML Tools. But the problem, as described, is exactly as every other duplicate thread. And yes, when i turn off word wrapping the problem doesnt occur.

[cmeriaux]

This issue has been fixed but reverted due to a performance issue.
Sorry

[amiga-500]

This issue has been fixed but reverted due to a performance issue.
Sorry

Thanks very much for the reply and the info. Saves me from hunting more.

[Arczi008TV]

@cmeriaux

This issue has been fixed but reverted due to a performance issue.
Sorry

But temporary or forever?

[cmeriaux]

@Arczi008TV it's so hard to push a fix on this repository. it could take a while until a fix is accepted by the author.
you may not wait for it

[donho]

@cmeriaux

it's so hard to push a fix on this repository. it could take a while until a fix is accepted by the author.

It's not true.
If your PR is consist and efficient without regression, it will be accepted quickly. Otherwise no.
Just check all the bug-fixes merged into this repository.

[cmeriaux]

@donho
The bug-fixe I have done last year targeted old version of scintilla. It worth test it again with the latest version of scintilla you've recently integrated.
I'll test and I'll get back to you

[Arczi008TV]

For now Im gonna use N++ 7.5.9, is free from that bug :+1:

[cmeriaux]

@donho i'm requesting your help (or anyone else).

I'm fixing the PR I've done a year ago ( 40192bda0ccbd18077abb02fac30292dfe8e62f4 ) . I removed the line that introduce a performance issue ( L1792 execute(SCI_ENSUREVISIBLE); )
My fix doesn't works because I'm scrolling lines on a wrapped buffer that is not painted yet. That's clearly mentionned on scintilla Doc:
https://www.scintilla.org/ScintillaDoc.html#LineWrapping

Wrapping is not performed immediately there is a change but is delayed until the display is redrawn. This delay improves performance by allowing a set of changes to be performed and then wrapped and displayed once. Because of this, some operations may not occur as expected. If a file is read and the scroll position moved to a particular line in the text, such as occurs when a container tries to restore a previous editing session, then the scroll position will have been determined before wrapping so an unexpected range of text will be displayed.

To scroll to the position correctly, delay the scroll until the wrapping has been performed by waiting for an initial SCN_PAINTED notification.**

So here is my question:
Is there an easy solution to wait the SCN_PAINTED notification before scrolling ?? Or Do I have to implement a mechanism to store the number of extra lines to scroll (due to wrapping) and apply this extra scroll on SVN_PAINTED notification code handling (where could it be)?

cheers

[cmeriaux]

@donho @Arczi008TV I found a solution. The clue was to wait for Scintilla notification SCN_PAINTED before scrolling to a wrapped line. Line wrapping is a background activity that takes time, specially for huge file. That's why we have to wait before scrolling to a wrapped line

@Arczi008TV can you test please the nightly build ? See #7713

I've tested with a hughe file: 220 MB, 250000 lines