All Instances Aren't Highlighted (In Green Highlighting Of Selected Text) When "Clone To Other View" Is Used

[sshivsh]

Description of the Issue

#4486

The bug that I noticed seems similar to the issue described in the above link. but I'm not sure if it's identical. Also, unlike in the above link, I see the bug in both saved files & unsaved files.

Steps to Reproduce the Issue

1. Download the attached file named "NotepadPlusPlusSelectionHighlightBug.txt". Rename it as NotepadPlusPlusSelectionHighlightBug.c & open it in Notepad++. From the "Language" menu in Notepad++, select C (to enable syntax highlighting).
2. Right click on the file's tab & choose "Clone to Other View".
3. In the original view: Select "v1" on line 17 (The C statement is "foo(v1);"). This will automatically highlight other instances of v1 in both views.
4. In the cloned view: Scroll down with the mouse wheel until lines 35 & 36 are visible (The C statements are "foo(v1-65);" & "bar(v1-65);"). Now it is clearly visible that "v1" isn't highlighted in these lines.

Expected Behavior

I expected that all instances of "v1" would be highlighted.

Actual Behavior

Some instances of "v1" were not highlighted.

Debug Information

Notepad++ v7.7.1 (32-bit)
Build time : Jun 16 2019 - 21:14:50
Path : E:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 8.1 (64-bit)
Plugins : mimeTools.dll NppConverter.dll NppExport.dll

NotepadPlusPlusSelectionHighlightBug.txt

Hope you can remove this bug. Thank you.

[ArkadiuszMichalski]

This was fixed by #8905.

[sshivsh]

Hi. It doesn't look fixed to me. I followed "Steps to Reproduce the Issue" & I could still see the bug.
I've pasted my Debug information below & I've attached screenshots. Thanks.

Notepad++ v7.9 (32-bit)
Build time : Sep 22 2020 - 03:24:22
Path : E:\Program Files (x86)\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS Name : Windows 8.1 Pro (64-bit)
OS Build : 9600.0
Current ANSI codepage : 1252
Plugins : mimeTools.dll NppConverter.dll NppExport.dll

[ArkadiuszMichalski]

@sshivsh Because PR #8905 will be included in Notepad 7.9.1. If you want you can manually download .exe and test it:
https://ci.appveyor.com/project/donho/notepad-plus-plus/builds/35421267/job/vnm4ylmg1qomatd9/artifacts
https://ci.appveyor.com/project/donho/notepad-plus-plus/builds/35421267

[sshivsh]

Ok Arkadiusz. I prefer to wait till 7.9.1 is ready. Thank you.

[sasumner]

I prefer to wait till 7.9.1 is ready.

Well, what if it isn't truly fixed there?
Answer: More back and forth discussion, rework, delays...wait for NEXT release...

Really, we need more people, especially the issue creators themselves, to test potential fixes and provide feedback.
It isn't hard to set up:

• Download the most recent N++ release, portable version
• Unzip into a test folder
• Replace the release .exe with the "artifact" .exe
• Run and test

[sshivsh]

Hi sasumner.

I don't wish to place my computers & my data under undue risk.

I have faith in the normal release process - it's one reason why I choose
Notepad++.

Hope you don't mind. Thanks !

[alankilborn]

Tested in N++ 8.4.4 (current version as of this writing) and could not repro.
Recommend CLOSURE of this item.

[sshivsh]

Hi Alan & Arkadiusz !

Sorry, in Notepad++ v8.4.4, I followed "Steps to Reproduce the Issue" !
As the screenshot below shows, the bug is still present !

Debug Info:
Notepad++ v8.4.4 (32-bit)
Build time : Jul 15 2022 - 17:56:38
Path : E:\Program Files (x86)\Notepad++\notepad++.exe
Command Line : "C:\Users\cornetUser\Desktop\NotepadPlusPlusSelectionHighlightBug\NotepadPlusPlusSelectionHighlightBug.c" -multiInst -nosession -lc -n1 -c1
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 8.1 Pro (64-bit)
OS Build : 9600.0
Current ANSI codepage : 1252
Plugins :
mimeTools (2.8)
NppConverter (4.4)
NppExport (0.4)

[ArkadiuszMichalski]

This happens if the selected fragment in the first view is not visible in the second view (and even when we scroll in the second view to see this fragment). For me it looks like a bug because all occurrences in the first view are selected (regardless of their visibility/scrolled window).

Str:

1. Open https://github.com/notepad-plus-plus/notepad-plus-plus/files/3656190/NotepadPlusPlusSelectionHighlightBug.txt on first view.
2. Clone opened file to second view.
3. Resize NPP window that line 35 foo(v1-65); and 36 bar(v1-65); will not be visible.
4. Select v1 on first view.

We see that v1 in 35/36 in line in the second view are not highlighted. Same happend if we scroll down second view (and see all v1 occurences) before select v1.

When we scroll first view then missing highlighted on the second view suddenly appears. The same is happening in the opposite direction. Maybe this behavior is intentional? It seems that highlighting is only applied to visible things, so scrolling the bar affects how it works.
It's worth noting that min/max a window does not update the highlight, so after maximize window we also have not highlighted items.

[jofon]

@ArkadiuszMichalski and @sshivsh
Do you have Settings->Preferences->Highlighting->Smart Hightlighting->Highlight another view checked? This needs to be checked for the hightlight to work "correctly" on the cloned view. If it's not checked, then the clone only clones the highlights of the other view, and doesn't do it's own highlighting.

[sshivsh]

@jofon
Hi. Thanks. It seems you've correctly described the behavior of Notepad++ in both cases below:
1. Settings->Preferences->Highlighting->Smart Hightlighting->Highlight another view is not checked.
2. Settings->Preferences->Highlighting->Smart Hightlighting->Highlight another view is checked.

Couple of points to consider:
a. Should Setting 2 above be the default setting ?
b. Should Setting 1 above exist ? (Under Setting 1 above, the user may fail to spot text which isn't highlighted.)
(In the attached image, lines 35 & 36 may be missed by the user since v1 isn't highlighted.)

Thanks.

[RFImages]

@jofon Thank you this seems to resolve the issue. However it should be checked as the default rather than something people have to start multiple posts in here for. Why would anyone not want this checked and tolerate unacceptable behavior? Why don't they calrify the checkbox to make it simpler?
It should be: Do you want a bug in your editor, yes/no?

[jofon]

@RFImages
There are two things conflicting here: "Highlight another view" and a view's Clone.

"Highlight another view" will highlight things on the other view no matter what that other view has: might be a clone, or might be another file entirely. Do people always want to highlight the other view when it might have a completely unrelated file that has nothing to do with the one I'm actually interested in (primary view), but that just happens to have the word, letter, or number that I'm highlighting? Maybe not, so "Hightlight another view" is provided for people to toggle the highlighting according to what they want.

A view's Clone is just another pair of eyes looking at the file that's in the primary view. It doesn't actually, as far as I know, create another file. The cloned view does not control the file, it just looks at it (unless you focus on the cloned view, at which point it "becomes" the primary view, and the other "becomes" the cloned view), so, for example, when you edit the file on the primary view, the clone sees the changes, but it didn't actually perform them. If you've highlighted something on the primary view, the second pair of eyes (cloned view) will only see that highlight if it's looking at it ("looking at it" in this case being "is at the same part of the file").

The highlights are done only on what's visible for the primary view (main eyes), because that all that matters for the primary view (and also for performance reasons... you probably don't want N++ to hang when you decide to highlight the space character on a giant file, when you're just looking at 30 lines of that file).

Here comes the conflict: "Highlight another view" is disabled, so you don't get hightlights on the other view. But you've cloned the view and you're looking at the highlighted part of the primary view and you see that things are highlighted. So you assume that everything else on the clone should be highlighted. Nope, you didn't enable "Highlight another view".

Is this misleading? Yes. But it's correct. If you want to highlight the other view, enable the option.

Now you might say that for cloned views, the option should always be enabled... Maybe. But then we go back to the performance issues that this could cause: you zoom out on the cloned view or scroll to a part of the file that's full of the highlight target, and boom. And maybe you want the highlight on the cloned view, but maybe other users don't. With this, we go back to the feature: If you want to highlight the other view, enable the option.

[RFImages]

@jofon "Highlight another view" will highlight things on the other view no matter what that other view has: might be a clone, or might be another file entirely. Do people always want to highlight the other view when it might have a completely unrelated file that has nothing to do with the one I'm actually interested in (primary view), but that just happens to have the word, letter, or number that I'm highlighting? Maybe not, so "Highlight another view" is provided for people to toggle the highlighting according to what they want.

I would say that even if it is another file, the highlight could only be useful and never detrimental. It might trigger a developer to pay attention, since this is the word currently of interest. Perhaps it is in the other file by mistake, perhaps he/she forgot it was in the other file - what harm is there in highlighting it? And as you say it can be disabled, but should be ENABLED by default. You point out performance issues, if that is a problem (typically in coding you should keep your files short and modular) I have never noticed any performance problems, but if it is a problem it can be turned off. Prompt the user about it. "to improve performance turn off this switch" orwhatever with a warning that it will introduce a bug and you will not see all occurences when highlighting, but you will see SOME occurences very quickly.. I still strongly believe it should be enabled by default. Optimization can come when the user understands the functionality and feature/performance tradeoff.

The highlights are done only on what's visible for the primary view (main eyes), because that all that matters for the primary view

I strongly disagree with this statement. What matters is that NO occurence of this highlight is MISSED accidentally, anywhere, (including other files, although not necessary) which is exactly what happened that prompted me to make a post about it. What happens to be visible in the other view is not the only area of the file of interest obviously because you want to see all occurences, and they are rarely in the viewable portion.. That is the entire purpose of this feature. Occurences of interest are almost never contained in the visible portion. You are assuming someone has scrolled in the cloned view only to the area of interest and all occurences of interest are only there. Rarely is this true. The purpose of cloning and highlighting is so that you KNOW where to scroll the cloned view. The area of interest is in the primary view.

So you assume that everything else on the clone should be highlighted. Nope, you didn't enable "Highlight another view".Is this misleading? Yes. But it's correct. If you want to highlight the other view, enable the option.

Of course not, as I had no idea this was an option and not a bug because the default is "apparent bug" mode. . What reasonable person would not make the assumption that when you highlight someting, ALL occurences are also ohighlight. Why would anyone want to only see SOME occurences? You're blaming the (beginning) user for not knowing about this? Again the default should be "do not add apparent bugs to improve performance" . You're putting the onus on the ignorant user who should have known better but had no way of knowing other than posting it here and communicating with the developer. It should never have gotten to that point and would not have were the feature turned on by default.

And maybe you want the highlight on the cloned view, but maybe other users don't.

I see no use case where hiding occurences, whether they be on or off screen, or in another file is an advantage other than for performance if that is even a problem. Typically long files are a no-no in any development. It is the exception and not the rule. Default behaviour should service the rule. Options are for advanced users who even know there is some hidden switch to make things work as any reasonable newbie would expect them to, or this thread would not even exist. I am not the only one that mentioned a preference for the opposite default.

If you want to highlight the other view, enable the option.

You casually put the onus on the user as if it is obvious that this switch even exists and it's functionality understood. Stupid users, why did you not flip this hidden switch? Reasonably expected and most useful behaviour should always be default. Optimization and performance should be an option for advanced users to tune things up. Missing an occurence after assuming they are all highlighted is far more catastrophic and time consuming than seeing one that may not be useful. I have already experienced this almost every time I highlight something.

[sshivsh]

@RFImages @jofon

@RFImages

It should be: Do you want a bug in your editor, yes/no?

Ha ha, this is funny.

@jofon

you probably don't want N++ to hang when you decide to highlight the space character

From what I saw just now, Notepad++ doesn't highlight all spaces if 1 space is selected.

Now you might say that for cloned views, the option should always be enabled

Probably, it should be the default setting for cloned views.
GUI experts can determine the best places to make this setting visible to users (Right-click menu ? Toolbar ?).

Thanks.

[RFImages]

@sshivsh @jofon I have no idea why anyone would intentionally highlight a space character, and if it does hang this is a problem that should be addressed by the developer, not by handicapping the user. and apparently it has, because I find it inpossible to highlight a space character.

[sshivsh]

@RFImages @jofon

@RFImages
Yeah, maybe @jofon typed it for the sake of discussion. (But it did make me open Notepad++ & check ! )

Thanks.

[RFImages]

@sshivsh @jofon Perhaps he meant a frequently used occurence. Well isn't that the point anyway, to find all occurences regardless of frequency? If it takes a while so be it - put up some kind of indication that it may take a while with option to cancel. It isn't a problem as far as I can tell. Again, an issue that should be addressed by the developer and not by handicapping the user and expecting him to find the "turn off bug" switch that is off by default.

[jofon]

@sshivsh @RFImages Yes, I only realized that after I posted the comment. The idea was to present an extreme example, so any other single-char should work in place of the space character. Although this did make me try some random characters, and there are some that aren't highlighted if "Match whole word only" is enabled. May be another bug...

@RFImages
Like I said, it is misleading, and the (at least) 2 issues about this are proof of that. Last week I tried to see if the highlight could be removed from the clone if the option wasn't enabled, but I didn't find any way to do it. Now, obviously I'm not an expert on N++ or Scintilla, so there might be a way.

I hope you understand that there are multiple ways to use Notepad++, and not everyone is a developer using it for ideal-length code files. There's an open issue (unrelated to highlighting) about a 1-million-line, 49MB .csv file, and another one with some users that have 500k-line files. There's one I saw today about a 1 liner that has 170 thousand characters. Why, you ask? I don't know, it's weird. But people use this for a huge number of things.

You could create a feature request to make this option be enabled by default, and start a discussion with more knowledgeable members of the community (and the big man himself). I just presented my opinion on whether this was a bug or not (which, if anything, then having the clone view show the highlights, when the option is disabled, is the actual bug).

[RFImages]

@jofon Fair enough. I thought you were one of the developers. Regardless thank you for making us aware of the bug switch!