Long time struggle with opening search results

Jean Noble

Hi there,
I now work very happily with Notepad++ for an odd three years to edit html-files, but the bummer is that when I want to edit a file that comes up as a search result in “Find in Files” (I hope that is a correct description as I work with a Dutch language edition) sometimes I can go straight away to the file and find myself focused on the spot, but most of the time, about 90% of the files do not open after double click, but have to be opened manually. Sometimes, really sometimes, a searched file opens when I double click on it continuously in a frenzy. Then tadaa! it suddenly opens. I have searched several times for an answer but I believe most people do not recognize this behaviour and when I remember well, it did work alright at the start of my working with Notepad, but sometime after that the function disappeared.

All my html-files are in one directory, so I cannot imagine it has something to do with the path.

I opened Notepad with administrator rights. Using v. 7.7.1 on a Lenovo with W10.

It would really make my day if I could open a search result with a simpel double click.

Many, many thanks for any help.

PeterJones

@Jean-Noble said in Long time struggle with opening search results:

I opened Notepad with administrator rights. Using v. 7.7.1 on a Lenovo with W10.

Could you provide the full ? > Debug Info > Copy debug info into clipboard and paste it here?

most people do not recognize this behaviour

Yeah, I’ve never heard of that happening (and it hasn’t happened to me). When I Find in Files, double-clicking the result has always 100% of the time opened the file.

All my html-files are in one directory, so I cannot imagine it has something to do with the path.

Since it fails 90% of the time for you, having them all in one location is actually (to me) more indicative that it is the path, rather than it isn’t. A few questions regarding that:

Is it a few files, or a hundred files, or a thousand files in that one path? (approximate)
By “all in the same path”, do you mean “all in c:\some\directory\” or “all in c:\some\directory\ or one of it’s subdirectories”?
Is that path on your hard drive / SSD? Or is it on a networked / mounted drive? If it’s on HD/SSD, is it a “shared” folder that other people have access to?
You mentioned you are in Admin mode. Do you need to be in order to edit those files? Because if those files are in an admin-protected folder, maybe something else strange is going on. If you don’t need to be Admin, does the behavior get fixed if you aren’t Admin?

It also might be some plugin interfering with the normal behavior of the find-in-files results. You can try without plugins by using the -noPlugin command-line-option. Or you can go into your C:\program Files\Notepad++\plugins directory and rename all the subfolders (or just rename C:\program Files\Notepad++\plugins itself) so that Notepad++ cannot see the plugins, and thus doesn’t load them. (After each of these renames, you’ll have to reload Notepad++.) If the behavior goes away, then it’s probably one of your plugins, and you’ll have to try re-enabling you plugins one-by-one until the problem comes back; and then try with just the one plugin that you think might be the culprit.

Jean Noble

Many thanks for your speedy reply. But where do I find “debug info”? I cannot find that menu-item.

All files are in the same directory, about 50 files or so, but usually only some 5-10 appear in a Search-result.

After changing the name of folder plugins in “pluginsss” and a reboot of Notepad++, about half of the files in Searchresults openend after double click. But curiously most of the results in one file, so a search resulted in about 30 items in one file, they focussed better after double click, when the file itself was already open, than the other files.
Now I suppose changing the name of the folder plugins should have been enough to offset all of them, or not?
I have a feeling we are getting closer to a solution. Many thanks again!

Alan Kilborn

@Jean-Noble

You are not answering very well the questions Peter has put to you.

PeterJones

@Jean-Noble said in Long time struggle with opening search results:

Many thanks for your speedy reply. But where do I find “debug info”? I cannot find that menu-item.

Did you see the question mark (?) I included before Debug Info ? That was there for a reason. On the menu bar of Notepad++, there’s a ? menu (just to the right of the Window menu). (Sorry, I don’t know what they look like in the Dutch language version – oh, if I switch to Settings > Preferences > General > Localization = Nederlands, the ? menu is to the right of the Documenten menu). Click that ?. Click Debug Info (Foutenopsporingsgegevens, which google translate tells me means literally “debugging data”). Then click Copy debug info into clipboard (which apparently doesn’t get translated in the Localization = Nederlands).

about 50 files or so

That’s not a lot. I was thinking if it was in the thousands, maybe it was overwhelming some allocated array somewhere.

There were 3 other question-items in my list which you didn’t answer.

Now I suppose changing the name of the folder plugins should have been enough to offset all of them, or not?

I’m not sure what you mean by that. Renaming the plugin folders was a method of turning off the plugins, so we could make sure that it wasn’t a plugin that was causing your find-in-files results to not work properly. Based on your response, I cannot really tell if it helped or not.

they focussed better after double click, when the file itself was already open

Again, if the search-results double-click works when the file was already open, but doesn’t work reliably when the file isn’t yet open, that sounds like an issue with trying to open the file, like maybe the file is timing out. (This timeout is likely to happen on mounted network drives (like Z:-drive), or even network drives accessed through the \\UNC\style\paths). But since you’re not answering 2-4, we don’t actually have enough information to help you.

Jean Noble

Sorry, sorry, I overlooked the other items. Was a kind of stressed with other issues also.
Here is my debug info:

Notepad++ v7.7.1 (64-bit)
Build time : Jun 16 2019 - 21:24:47
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : none
3. All files are in a folder on my harddrive, not an extra mounted drive. It is not a shared folder.
4. As I remembered seeing some issues in this respect appear some years back and the suggestions then done, I once tried working with Notepad in admin mode. But it didn’t make any difference.

Again apologies for my sloppy answering.

I owe you one.

PeterJones

Thank you for the final answers.

Unfortunately, if the problem is persisting, then there is something unique about your setup – where the files are located, or the contents of those files or something – that we cannot guess at. As of now, we cannot replicate your problem, and if we cannot replicate it, it’s much harder for us to remote debug.

Try creating five or so files, about the same size as your real files, with dummy content. (Maybe even just create two files, then copy them each multiple times to unique names. Maybe copy the first 5x and the second 10x, so the number of found files will be different). Put them in a known location, like c:\temp\dummyFolder\. Does the find-in-files behave the same manner, or does it work correctly? If it behaves in the same manner, maybe share those two dummy files with us: if they aren’t huge, you can embed them here with the syntax

~~~
file contents
~~~

which will render as

file contents

and make it easy for us to copy/paste your data.

If they are large, put them in bitbucket or similar, and some of us may be able to grab the files. Some of us (like me) may be blocked because of work-net-restrictions, depending on where you put them, so it would be much better if you can replicate the circumstances with files small enough to embed in your post. This will give us something to try to replicate the behavior you describe.

If the dummy files do not show the problem, then it’s either your location, or your files. You can try bringing some of your real files to the dummy location, and see if the real files still show the same behavior or not: if not, then it’s something about your location, and if you can change the location, that should solve it. Otherwise, you can try bringing your dummy files into your real-file-location, and see if the dummy-files have the double-click problem: again, if you do have problems in that direction, it’s something unique about the location, and you’ll need to try to find a place to edit the files that does work; if you don’t have problems with the dummy files in real-location, then it’s something unique about your real files, so then you could try to make your dummy files more like the real files, until they show the same problems.

At this point, the remote debug will be difficult, but if you can share files that give an example, we might be able to do more; and if you can tell results of these experiments, then someone might be able to help you along your way. (I’m running out of ideas, so unless one of the results of your experiments sparks some memory in me, it may have to be someone else to jump in with new ideas.)

Good luck.

Jean Noble

@PeterJones Again many thanks for your effort and patience. I will try to work out your line of thought, but that will not be today, perhaps not even tomorrow. Busy as hell and in the mean time I work as I have done two years or so, which is rather a nuisance.
But again I appreciate your helpful thinking.
I will be back as soon as I can.
Cheers.