young-developer / nppnavigateto Goto Github PK

Link to the comment: https://community.notepad-plus-plus.org/post/82574

A general remark : In the last versions, from v2.0.0, you changed your mind and don’t take in account some of the previous features used till the v1.12.7 version. For instance :

No view column, in the list

No complementary search, with the leading | character, in the Search Input zone. I suppose that it would be rather useless with the new options of the Search behaviour

Hitting the Shift key when you click on a file of the list does not switch to this file but simply select it for a future paste operation

The colors of the row text does not changed anymore with the file status ( saved, unsaved or read-only )

Conversely, there are a lot of improvements with numerous new settings in your last v2.4.1 version ! For instance :

The ability to close or keep the plugin opened after moving to a file

The ability to clear or not the search input

If the Search in current folder option is ticked in Plugins > NavigateTo > Settings , any further search will look in all the listed tabs AND in all the files contained in the folder of the current file. Very useful feature !

The new Fuzzy search feature

The possibility of sorting the search results AFTER the search

Many custom colors can be applied on various regions

Now, I noticed some small bugs which you’ll probably fix very soon :

Right after starting Notepad++ , if you run the NavigateTo plugin with the Ctrl + , shortcut or with the Plugins > NavigateTo > NavigateTo option, the plugin window is initially empty. So, you must type in, for instance, a Space char followed by a hit on the Backspace key, in the Search Input zone, to get the list of all your opened tabs !

Although, I set the Min Char Search to the 1 value, in the Plugins > NavigateTo > Settings option, it seems that the search is really effective after you type in, at least, 2 characters in the Search Input zone. For any value greater than 1, the result is correct

Sometimes, the search shows default orange results in the Source column, in a random way. Is this behaviour normal ? I would expect that this column should never be highlighted !

In the Plugins > NavigateTo > Settings window, I suppose that the option Search in sub directories too should be greyed out when the Search in current file folder ( Top directory only ) is not ticked !

It would be nice to have a new option Plugins > NavigateTo > About to know some details on the current version !

Now, regarding some possible enhancements :

Could it be possible that the search feature acts on :

Filenames only

Directories paths only

Both filenames AND Directories

Thus, the Search behaviour zone, in the Settings window, would be reorganized as :

•--- Search behaviour -----------------------------------------•
| |
| [ ] Search in 'Name' column only |
| [ ] Search in 'Path' Column only |
| |
| [ ] Prefer filename over path |
| |
| [ ] Search in current file folder ( Top directory only ) |
| [ ] Search in sub directories too |
| |
| [ ] Fuzzy search (Tabs only) - Tolerance list |
| |
| [ ] Search menu commands (experimental) |
•--------------------------------------------------------------•
Note that :

If none of these new options Search in 'Name' column only and Search in 'Path' column only is ticked by the user, it would automatically tick the Search in 'Name' column only option

Of course, the Prefer filename over path option would be functional ONLY IF, both, the two new options are checked. If NOT, the Prefer filename over path option would be greyed out !

Nevertheless, I don’t know if this enhancement could perturb the Fuzzy search feature ?

To end with, the new Fuzzy search seems very powerful. However, after reading the Wikipedia article on that topic, I did not understand all the process. In some cases, I could get the same number of results with regexes but not in all the cases ;-))

So, could you provide us with some more hints on this surprising search method and its logic ?

Best Regards,

guy038

I immediately hit an issue whereby the plugin doesn't even see all the tabs I have open to search through?

v8.4.6 32bit

Extracting this from issue #8 as it appears to still be happening with release 1.12.4.

When you create a new file in Notepad++ using Ctrl+N, it does not get listed by the plugin no matter what filter you enter. Saving the new file makes no difference.

The new file (even though it has not been explicitly saved to disk) does get picked up on Notepad++ restart.

Files opened from disk on the other hand are picked up and get displayed in the plugin's dialog correctly.

Notepad++ debug information:

Notepad++ v7.5.8   (64-bit)
Build time : Jul 23 2018 - 02:06:36
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : NavigateTo.dll PluginManager.dll DSpellCheck.dll mimeTools.dll NppConverter.dll 

When you're entering the plugin's input filter, you can not use Home or End keys to navigate in that text, including things like Shift-End to select all the text to the end of the current input field value.

You do seem to be able to use the arrow keys, backspace, del and shift.

I see the new experimental menu search feature. Is the intent to make is something like:

https://github.com/peter-frentrup/NppMenuSearch

If so, I think this plugin could be the closest to "universal search" for Notepad++ - current tabs, files in directories and menu items. Much like the command palette in VS Code.

Cheers.

See my posts in the community forum for a description of the issue, and also my proposed solution.

I can also submit a PR, although I can't get to it yet.

Currently the list of files in the current directory is regenerated every time the file list is regenerated. This is unnecessary. You should instead keep the files in the current directory as an instance variable of the form and keep track of whether it has been regenerated since the user last activated the current buffer. This way, the file list is regenerated the first time the user makes a query when a given buffer is open, and then is simply reused for all subsequent queries in that buffer.

I tried this myself and it affords a significant performance improvement. I can submit a PR, but since I'm using .NET Framework in my fork, you'd have to go up to .NET 4.8 to accept it.

Using CTRL+Backspace in the search bar results in a unicode, when it should result in deleting the word. Is there any way to fix this? It's quite frustrating... otherwise, the new version is much better.

Also, have you considered adding in the ability to change the font size and table padding? The current font size is fairly small, especially for people who have a hard time reading small text.

Also also, I don't think the row color does anything? It stays the same color for me.

All that needs to be done is change line 13 of the csproj to <TargetFrameworkVersion>v4.8</TargetFrameworkVersion>

Reasons to go to .NET Framework 4.8:

• Visual Studio 2022 (you need to install a targeting pack for 4.0, which is a hassle)
• you can use the MSBuild GitHub action, which is really nice because it means that your compiled x86 and x64 binaries are stored as artifacts that anyone can download without having to build your project from source

I do recognize that .NET Framework 4.8 is not installed by default on Windows versions before Windows 10 May 2019 update, and that was indeed my rationale for dragging my feet in moving to 4.8 for JsonTools. But since moving to 4.8, I've been really happy with the change. My general impression is that very few people are likely to not have .NET 4.8 installed on their computers anyway.

I'm mostly submitting this issue for selfish reasons because I want to submit a PR and I can't work on NavigateTo in Visual Studio without changing the TargetFramework to 4.8.

Is it possible to add an option so that the menu stays always open.

I have Dell XPS 17, 4k screen. When I try to use this plugin, line spacing is too small, lines overlap and it is impossible to use it. Is it possible to fix this?

I propose to add the following syntax to NavigateTo. This would be backwards-compatible with the default search method where every search result must contain all of the space-separated search terms.

Logical OR

Searches can find either or both of the search terms separated by the | (pipe) character. Thus foo | bar would match foo.txt and bar.txt, where the present syntax does not have a good way to restrict searches to both of those.

Since the | character is not a legal character in Windows paths, this does not conflict with the matching of paths in any way.

Logical negation

Use the ! character before a search term to NOT match things matching that search term. Thus foo !bar would match foo.txt but not foobar.txt

The ! character is legal in Windows paths, so this is not free. However, my proposed glob syntax below would allow the matching of ! in character classes or by using the unicode escape \x21.

Grouping of character classes

With the added capacity for logical OR and negation, it becomes advantageous to group search terms (e.g., match (foo AND bar) OR baz). This would be achieved using the < and > characters to open and close groups. Thus baz | <foo bar would match foobar.txt and baz.txt, but not foo.txt or bar.txt.

Note that < could be used without a matching >. Forcing the matching of parentheses is an unnecessary formality, and error handling could slow down parsing and make the app less responsive.

I could use ( and ) for this purpose, but those are legal characters in Windows paths, and < and > are not, so it is free to use them for that purpose.

glob syntax

As described in this Wikipedia article. The portions of this syntax that I propose to incorporate are all the standard components, the "Unix-like" components, and "globstar" (**), and alternation (e.g., *.{cpp,h} matches foo.cpp and foo.h)

full example foo**[!c-p]uack*.{tx?,cpp} !fgh | <bar baz

Matches

1. foo\boo\quacked.txt
2. foo\boo\quacked.cpp
3. foozuack.txb
4. bar.baz
5. baz.bar
6. fgh\bar.baz (fgh is forbidden if the glob is being matched, but not if bar baz is being matched)

Non-matches

1. foo\boo\duacked.txt (the d in duacked is in the character class c-p, which was negated)
2. foozuack.xml (the xml extension does not match tx?)
3. foo.baz (does not match the fancy glob, and it doesn't contain both bar and baz)
4. foo\boo\quacked.txto (txto does not match tx? because globs are always anchored at the end and txto has an o after the matching portion)
5. foo\fgh\quacked.txt (contains the forbidden search term fgh)
6. foo\boo\quacked\bad.txt (uack* matches any characters after uack other than \)

Steps to replicate:

1. Use the navigation form with the current file being at the top of a very large directory tree (say, 20k files or more)
2. Enter a search term that is present in the name of every file in that tree (say, part of a common directory name)
3. Watch the form and Notepad++ become unresponsive for a very long time

Proposed solutions/mitigations:

1. The only complete solution to this problem would be to have the main form be on a background worker. I may try to implement this, but it may not be the best solution owing to the added complexity and possibility of concurrency bugs.
2. Disable highlighting of matches if the number of results is over a certain threshold (say, 5000). This is very easy to implement, and will be part of a PR that I will submit shortly
3. Add a timeout between keypresses and updates to the main form, to allow the user to type several characters before blocking input. After each keypress, wait a short time (say, 0.2 seconds). If any other keypresses happened during the timeout, do nothing. This does not completely eliminate the problems, but it helps address the potential frustration when, for example, a user wishes to enter the word "foobar" but they have to wait for each individual character to be processed. This may be rather difficult to implement, but I intend to work on it after addressing #55 .

Hello, @young-developer,

I noticed two issues, with NavigateTo v1.12.4 : a tiny one and a bigger one !

• First, when you right-click on the NatigateTo.dll file ( 158,720 bytes ), and select the Properties, at bottom, then select the Version tab it still shows 1.12.3, instead of 1.12.4. Luckily, from within N++, if you choose the Plugins > Navigate To > About option, it correctly displays the 1.12.4 version

• Secondly, I noticed that, if you have two views, in your current N++ session, with some files in view 0 and some others in view 1, the Navigate To list shows :

• All files of the view 0 ( the main view )

• Only the very first file of the view 1 ( the secondary view )

Now, anki-code said :

For example this feature can be activated when user type the name but filtering result is empty. In this case NavigateTo start to search files around. And the start folder will be the folder of current opened file.

Indeed, when the characters typed in, by the user, cannot be found, in names of all the opened documents, it could be interesting to search, automatically, in the folder of the current opened file, for any other file, whose name matches the typed characters, and outputs them in a new list. Then, double-clicking, on one, or several of them, would, simply, open them, in N++ and close the Navigate To window

Best Regards

guy038

Let me know if you need further information. Good luck on this one.

Hi,

It seems that NavigateTo cannot search files in the Right View, it only search files in the Left View. Can you please update this function.

Thanks!

Hey there,

First off, I just wanted to say that I absolutely love this plugin, it's saved my life since I always have a lot of tabs open. The fact that you can search by path is just amazing.

I originally docked it, but then I decided I liked it better as a popup in the middle of the screen instead, but realized that after I hit enter to switch to the file I still needed to then hit CTRL+, to close the popup window.

I got around this by making a little AutoHotKey script that just sends Enter followed by CTRL+, so that the window closes automatically when you open the file:

#IfWinActive, ahk_exe notepad++.exe
#IfWinActive, NavigateTo
Enter::
SendInput, {Enter}
SendInput, ^,
#IfWinActive
return

(Apologies for my super basic AutoHotKey code, it could probably be done better)

This totally works, and I'm happy with it, but I thought I would mention it here for two reasons. The first is in case anybody else is looking for a similar solution, maybe they might find this script useful. The second is that I actually think this would be a good option in the main plugin settings instead of working around it with something like AutoHotKey.

So I guess consider this a feature request. Thanks!

Hi! Thank you for your great work!

I've tried the version v.1.12.4 (64) and when I press Enter key the file isn't open.

Details:

1. Windows 10, Notepad++ 7.5.5 (64), NavigateTo v.1.12.4 (64)
2. Press Ctrl+, and choose any file (press Enter or click)
3. Nothing happens

I really like the new version, especially the ability to quickly select files in the same project as the current file.

That said, one of the things I really liked about the old NavigateTo was the ability to quickly tell at a glance how many tabs I had open. Probably what would make the most sense would be to show it in a little text box at the bottom of the grid.

I have a lot of files open in my Notepad++ at the moment - cca 200., with multi-line tabs enabled. Some of those tabs contain files that have been saved on disk and some that have not (named New 1, New 42 and alike)>

Plugin correctly lists all of those files, but selecting them from the plugin's main dialog does not always select the correct tab. Some of the files it selects correctly, but on many of the files it actually selects the first tab following the desired tab.

At first I thought this only happened when selecting files that have not been saved on disk yet, but it seems to be unrelated. I have found such both saved & unsaved files that it selects correctly and those that it does not.

Related problems encountered when trying to provide more info for this issue

Repositioning the tabs in Notepad++ might have something to do with this, as when I repositioned a tab just now, it messed up the plugin even more. When searching for the file in the moved tab, it now selects the tab that's in the position where this file's tab used to be positioned.

Also, opening a new tab and not saving it yet (named New 27 in my case) does not seems to get that file detected by the plugin. No matter what filter I enter, the file is not listed. Saving the file afterwards does not get it listed either.

Restarted Notepad++ afterwards, which reopened all the tabs correctly, and the plugin seems to have been left in a completely unusable state. Opening the main plugin dialog just shows the old Found 179 matching results title and does not change it or list any files no matter what filter text I enter into it.

I also noticed that now, unlike in issue #7, the plugin's main dialog closes every time on <Alt-Tab> out of Notepad++.

I'll leave my Notepad++ in this state for as long as I can. Hopefully you can contact me before I have to change it, in case you want to look into the issue more closely. If needed you can contact me via Skype (profile: jurkog) or e-mail (mail server: pke.hr, name: jurko.gospodnetic).

Notepad++ debug info

Notepad++ v7.5.4   (64-bit)
Build time : Jan  1 2018 - 01:50:29
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : DSpellCheck.dll mimeTools.dll NavigateTo.dll NppConverter.dll PluginManager.dll 

At some times the list of matching files is completely empty, even though in the title it says "Found x matching results" (where x > 0). As far as I know, it only happens when starting NP++. I haven't completely narrowed down the cause, but I could only "fix" it by closing all opened documents until I got to a new file.

Hi,

It seems that the first tab is not included in the search box.

Info:

• Notepad++ 7.5.4 (32-bit)
• Navigate To 1.12.3

Thanks,

Test on Windows 10 64 bit, npp v7.6.3 32-bit and npp v8.4.2 32-bit, NavigateTo v1.12.7.

The dialog can called by menu bar, but cant react with hot key Ctrl+,. Do I need to do any other settings before?

And suggestions:

Navigate filter cant react with Ctrl+C and Ctrl+V. Sometimes I copy a filename in a source code, and I want to search it in navigate bar, so I use Ctrl+V to paste text into navigate filter.

And, can the search bar support multiple keywords separated by spaces? If difficult to support regEx, space-separated keywords will be easier?

I've noticed a bunch of people on the community forum complaining about not having a way to efficiently close/open large numbers of files. I think it's absurd that people would open 500 files in Notepad++ at the same time, but it seems like NavigateTo could easily support functionality to make this easier.
Basic idea is that you could right-click on the files display grid and a context menu would pop up with two options, Open all files displayed and Close all files displayed.

Could you add some shortcuts to manipulate faster the dialog :

ctrl+a : select all the text already written in the dialog
ctrl+arrow left/rigth: move previous/next word
ctrl + shift + arrow left/right: slect the previous/next word
....

thanks

"new 1" doesn't exist in ANY tab?

Very helpfull tool!

When working with lengthy file paths, the current display often hides useful content in the "Path" column.
I'd suggest to add another option to the settings (infact two of them)

New Options

[#]  "Last char of path always displayed" 
[x]  "Suppress filename in path"

How it's meant to work:

Option [#] "Last char of path always displayed"

set to: [0] "Last char of path always displayed"
... is equivalent to the actual behaviour.

| Path                                  |
| D:\HN\dev\Smart\Superclue\v1\pipe\imp |
| D:\HN\dev\Smart\Superclue\v1\pipe\imp |
| D:\HN\dev\Smart\Superclue\v1\pipe\imp |

set to: [20] "Last char of path always displayed"
... would look something like this:

| Path                                  |
| D:\HN\dev\Sma...d\Klett.V3.2\execute\ |
| D:\HN\dev\Sma...d\Klett.V3.2\execute\ |
| D:\HN\dev\Sma...quid\Klett.V3.2\test\ |
| D:\HN\dev\Sma...tt.V3.2\execute\.arc\ |

Option [x] "Suppress filename in path"

set to: [ ] "Suppress filename in path"
... is equivalent to the actual behaviour.

| Name           | Path                                  |
| MySettings.cfg | D:\HN\dev\MySeetings.cfg              |

set to: [x] "Suppress filename in path"
... would look like this:

| Name           | Path                                  |
| MySettings.cfg | D:\HN\dev\                            |

The "Supress filename in path" setting follows somewhat naturally out of the "Last char of path always displayed" option, I guess.

Thanks in advance for considering.

when you open NavigateTo dialog it should has empty input field instead of showing previous entry. Or at least give the option to this behavior.

Hi,

This version always crashes my NPP (only tested the 32 bit version). I had to go back to1.8.2 and it works nicely.

Thank you for such good plugin!!

PS: Windows 64bits 10.0.15063

When the plugin's main dialog is open, pressing Ctrl-A to select the currently entered text in the filter input box behaves strangely for me.

Don't know if it occurs in other cases, but I can reproduce it somewhat reliably when I have have many tabs open, enter only a single letter as a filter and the list control below it ends up containing more files then can fit on the screen (so the scroll-bar appears).

Effects are:

1. pressing Ctrl-A often seems to cause the entire list control content to flicker
2. pressing Ctrl-A causes the current list control selection to change back to the first displayed row
3. pressing Ctrl-A occasionally does not select the filter text, but instead clears the current selection and just moves the caret to the end of the currently entered input text
4. several times when clearing the current filter and then closing the dialog, reopening it and pressing Ctrl-A, I've see the previous filter text be restored

The effects do not occur if the whole currently entered filter text is already selected, so the code might be short-circuiting its regular behavior and just doing nothing on Ctrl-A in that case.

The effects are also sometimes affected by:

• whether you last typed in the filter input text box or moved around on the list control
• whether you changed focus to a different application and back or whether you just opened the dialog

When the filter text selection problem does occur, then it occurs most of the time if not always, but then after a while it starts working ok again and can't be reproduced for a while.

Reproducible use-case

One strange use-case that seems to reproduce some of these issues in all the cases I've tried it:

1. open the plugin's main dialog
2. enter some filter text so the input box is populated with at least some data
3. select the entered filter text
4. Alt-Tab to a different application
5. Alt-Tab back to Notepad++
6. you should be back the the plugin's main dialog, but the current selection has been lost
7. pressing Ctrl-A will now not select the entered filter text
8. Alt-Tab to a different application
9. Alt-Tab back to Notepad++
10. you will now be back in Notepad++, but the plugin's main dialog will have been closed (if you look more closely, you notice the dialog diapears on Alt-Tab out and not the one coming back to Notepad++)

This also illustrates a separate issue with Alt-Tab out of Notepad++ affecting the plugin's main dialog, which I believe it should not do in any way.

Notepad++ debug info

Notepad++ v7.5.4   (64-bit)
Build time : Jan  1 2018 - 01:50:29
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : DSpellCheck.dll mimeTools.dll NavigateTo.dll NppConverter.dll PluginManager.dll 

Random thoughts on what might be behind these problems

There might be a race condition between the list control refreshing its content (which it should not have to do in the first place, just for a selection change) and setting the current selection in the filter input box. In that case, possibly some internal focus change that occurs due to the list control refresh makes Notepad++ forget/reset the current filter input box selection.

You might have two different system vying for control over those keyboard shortcuts, e.g. some system inherent to the input box control used and some higher level one built in the plugin application itself.

You might have tried to do some special handling for Alt-Tab out of Notepad++, possibly to have it disappear then, which I believe should not be done and Notepad++ losing focus should leave the plugin's main dialog as is for use when Notepad++ application receives back the focus.

Steps to reproduce:

1. Have 2 or more monitors
2. Move Notepad++ off the primary monitor
3. Hit the shortcut for NavigateTo to open (using version 1.12.6)
4. NavigateTo dialog opens in the center of the primary monitor, instead of relative to the npp window that spawned it.

Half of search line is not visible and below is a mess. I noticed that N++ and some other programs have problems with dialogs if your resolution is 4k. Can you fix it please?

Screenshot:
https://ibb.co/drWJvDz

Version: NavigateTo v2.7

Options in the plugin settings to enable/disable or add/remove individual columns

To replicate the issue:

1. Install NavigateTo 2.7.0 on Notepad++ 8.6.1 (32bit or 64bit, shouldn't matter).
2. Copy some text to the clipboard (call this Original selection)
3. Open the NavigateTo window in any document.
4. Select some text in the NavigateTo textbox (call this NavigateTo selection)
5. Copy the NavigateTo textbox selection using Ctrl+C.
6. Observe that Original selection is still in the clipboard.
7. Cut the NavigateTo textbox selection using Ctrl+X.
8. Observe that Original selection is still in the clipboard.
9. If desired, try doing similar things on the settings form. You should find that Ctrl+C and Ctrl+X are broken everywhere.

My proposed solution

You can fix this issue by following the process I describe in my NppCSharpPluginPack.

If you like, I can submit a PR. While this issue isn't hard to fix, it is annoying and finicky to fix because you have to visually compare the order of Controls.Add calls to the desired tab order for every form in your plugin.

Extracting this from issues #7 & #8 as this appears to still be happening with release 1.12.4.

When the plugin's dialog is open, pressing Alt-Tab to leave the application and then pressing it again to come back to it, sometimes closes the dialog and sometimes not.

Dialog seems to remain if I enter some text into the dialog first, and it has not already remained open through a previous Alt-Tab operation.

I have never seen the dialog remain twice in a row.

After the dialog remains open:

• you can see that the caret in the text entry input field, as well as any previous text selection there, is gone
• if you press Ctrl-A to select the complete text in the input field, it will actually replace any existing text there with just a and select that

When the dialog goes away due to an Alt-Tab operation we do get some strange behaviour like the dialog has actually still remained open but only went hidden and is still intercepting some keyboard shortcuts.

Reproducible scenario with my current setup:

• I have Ctrl-F4 mapped to closing the current document
• I have some entries listed in the plugin dialog's input history
• I have many files open, including many unsaved ones called New ##
• open a new document using Ctrl-N
• load a document from disk using Ctrl-O
• open a new document using Ctrl-N
• open the plugin dialog (mapped to Ctrl-Shift-O)
• enter filter text new
• Alt-Tab twice to exit and reenter the editor - the dialog will remain
• Alt-Tab twice to exit and reenter the editor again - the dialog will disappear
• Ctrl-F4 to close the current document (the second newly created one) - it closes and focus moves back to to the open one
• Ctrl-F4 to attempt to close the current document (the one opened from disk) - but this does not close it and instead opens the hidden plugin dialog's input filed history dropdown, same as if I pressed F4 on that dialog
• at this point this can be repeated indefinitely by pressing ESC and then Ctrl-F4 again
• kinda funny how the dropdown appears out of nowhere :-) and especially funny if the input field's history is actually empty at the time :-)

You can then continue to get an additional bad scenario like this:

• continue after the drop-down history list appeared
• Alt-Tab twice to exit and reenter the editor - the drop-down history list will disappear
• Ctrl-F4 to close the current document - it closes and focus moves back to the first newly created one
• Ctrl-F4 to close the current document - it closes and focus moves to the previous document (whatever was already open at the start of the scenario)
• Ctrl-O to attempt to open a new document - it will fail and just cause a beep, as if something intercepted that shortcut before Notepad++ got to handle it
• this continues to occur with this and other shortcuts until you click your mouse somewhere on Notepad++, after which the shortcuts start working correctly

Notepad++ debug information:

Notepad++ v7.5.8   (64-bit)
Build time : Jul 23 2018 - 02:06:36
Path : C:\Program Files\Notepad++\notepad++.exe
Admin mode : OFF
Local Conf mode : OFF
OS : Windows 10 (64-bit)
Plugins : NavigateTo.dll PluginManager.dll DSpellCheck.dll mimeTools.dll NppConverter.dll 

Version: NavigateTo v2.7

It would be great if the plugin remembered the set column widths.

Steps to reproduce problem;

I expand the width of the Name-column to see the full file name

I switch to another pane like Document list

...or the project panel

...and I go back to NavigateTo the columns are reset and the Name column is truncated again

Just wanted to thank you for all the fixes as I can now use your plugin as the "quick swapping" plugin of my dreams!!

Hello, @young-developer,

I'm quite sorry for this very late reply, but I noticed some problems, with both versions 1.12.3.0 and 1.12.4.0

First of all, these problems could be, simply, related to my Win XP configuration. Here is, below, the Debug Info :

Notepad++ v7.5.6   (32-bit)
Build time : Mar 19 2018 - 00:26:59
Path : D:\@@\756\notepad++.exe
Admin mode : OFF
Local Conf mode : ON
OS : Windows XP (32-bit)
Plugins : ComparePlugin_2.0.dll DSpellCheck.dll HTMLTag_unicode.dll LuaScript_0.71.17.dll mimeTools.dll NavigateTo_1.12.2.0.dll NppConverter.dll nppcrypt_1.0.1.3.dll NppExport.dll NppTextFX.dll PreviewHTML.dll PythonScript.dll VIsimulator.dll 

So, briefly :

v12.4 : Wrong version number ( still v1.12.3.0 instead of v1.12.4.0 )

• v12.3 : Column VIEW NOT visible in "NavigateTo" dialog

• v12.4 : Same problem

• v12.3 : The first file, of VIEW 1, is absent of the list

=> Necessity to close this file ( Ctrl + W ) and re-open it ( Ctrl + Shift + T ) or re-start N++ to get it visible, in the list

• v12.4 : OK, no problem

• v12.3 : All the files, in VIEW 2, are invisible, in the list

• v12.4 : Only the first file, in VIEW 2, is visible in the list

• v12.3 : Double-click, selection or Enter on a file, of VIEW 1 => OK

• v12.4 : Double-click, selection or Enter on a file, of VIEW 1 => OK

• v12.4 : Double-click, selection or Enter on the UNIQUE file, of VIEW 2, visible in the list

=> The last file, of VIEW 2, although invisible in the list, is WRONGLY selected !

• v12.3 : If move of files, from VIEW 2 to VIEW 1, they are absent, in the list

=> Necessity to close this file ( Ctrl + W ) and re-open it ( Ctrl + Shift + T ) or re-start N++ to get it visible, in the list

• v12.4 : Same problem

• v12.3 : If move of files, from VIEW 1 to VIEW 2, they are absent, in the list

=> Necessity to close this file ( Ctrl + W ) and re-open it ( Ctrl + Shift + T ) or re-start N++ to get it visible, in the list

• v12.4 : If move of files, from VIEW 1 to VIEW 2``, they are ABSENT, in the list

After closing this file ( Ctrl + W ) and re-opening it ( Ctrl + Shift + T ) or after re-starting N++

=> Only the first file, of VIEW 2, is visible, in the list

So, I'm still using the 1.12.2.0 version, on my XP laptop, which works fine, without any bug :-))

Again, @young-developer, all these bugs could appear because of Win XP !

Many thanks for your future investigation :-))

Best Regards,

guy038

I have two PCs, an Intel Haswell 4790K one, an an AMD 5900x one. On both of them I have around 180 text files permanently open in Notepad++, and I use NavigateTo to easily switch between them.

One thing I noticed after installing this extension, is that the time Notepad++ takes when I close it has greatly increased. On the Intel Haswell system, it's ~10 seconds, while on the AMD one is ~4 seconds. If I remove the "NavigateTo" folder from the Notepad++ plugins extension folder, then Notepad++ goes back to closing very quickly.

There must be something the extension does when Notepad++ is closed that increases the time it takes to close itself. Maybe it reacts to every file being removed form the list of open files? Please have a look and see if this can be improved.

Is it possible to enhance the plugin's functionality by automatically opening a new tab with the file when an absolute file path is pasted? For instance:

C:\Users\DummyUser\Documents\Coding\CPP\ProjectName\example.cpp
/home/DummyUser/Documents/Coding/CPP/ProjectName/example.cpp
We can easily determine if the path is absolute and then search for it among the currently open tabs. If it's not found, we can promptly open it in a new tab. This feature will save time when there's a need to quickly edit a file with a known path (which, in my case, is quite frequent).

Currently, the user needs to press CTRL+O, paste the file path, manually remove the file name from the path, search for the file in the list (which could be lengthy), and then open it by pressing Enter or clicking "Open".

It would be great to add an option so that the main search window could be dockable (usable as a tab among the others in the Notepad++ main window).

Steps to reproduce the bug:

• enable "Clear search input" in the plugin settings
• open the plugin dialog window (Ctrl+,)
• start typing something like: 4090
• the first typed character is ignored, the search line edit shows "090" and only the "090" entries are listed and highlighted in the search results

Hi,

I think this plugin is really, really good. But there's a huge problem that I don't understand. When you first open Notepad++ and press the hotkey to open the menu, there's no data in it. No files, nothing at all.

To solve this, you can click on a tab then the menu is populated. But being this is going to replace the top tabs, it's really frustrating to have to click one of them to get data in the NavigateTo plugin!

Note 1: This only happens in v2.0+. I went back and tested an old version (v1.12.7) and the menu is populated fine when Notepad++ is opened.

Note 2: The menu has to be open when you click a tab for it to populate.

Also, it would be really nice to have an "only search filenames" option, because I really don't see a difference when using "Prefer filename over path." But the main issue is the menu not populating.

You can see what I mean here:
https://i.imgur.com/tfY7Tc4.jpg

Version 2.6.

I'm editing text in a Notepad++ tab, and now I want to run NavigateTo's functionality. If I press the shortcut keycombo, the NavigateTo window that I had open from the last time closes, when what it should do is stay open and take input focus here:

Worse, when the NavigateTo window closes, input focus is left in some strange and unknown place, because a second press of the keycombo does nothing.

Hi! Thank you for your great idea and plugin!

Many IDEs have a feature to search by all files in project. For example all JetBrains IDEs open the menu like NavigateTo after triple Shift.

It will be great if NavigateTo can be search files around already opened ones. For simplest way the files can be found in the folders of opened files without recursion diving in subfolders.

For example this feature can be activated when user type the name but filtering result is empty. In this case NavigateTo start to search files around. And the start folder will be the folder of current opened file.

Thank you!

⬇️ Please click "+1" icon instead of "+1" comment

Could you possible add the ability to autosize the columns of the search results? Or at the very least save the dimensions from session to session after I close down NPP? Bonus feature would be ability to close multiple results tabs at once, but the fact I can close 1 at a time is still GREAT!!

Hello,

This plugin is a must have, even I am asking myself why isn't it included by default with Notepad++.

One problem in consequence, is that there is no option to open it when opening Notepad++. I must always click on Plugins >> NavigateTo.

Or am I wrong ?

Thank you very much

When you have some filter entered in the plugin's input field that shows you no results, and you start deleting characters from that filter, at the point when some the remaining filter text matches some open file's name, the currently entered filter text will get selected and the caret will get moved to the end of the entered filter text.

This is problematic for instance if you were deleting the text at the start by pressing the del key.

The caret should not be moved automatically in any case during user's filter text editing except as a result of an explicit user operation for moving that caret, e.g. like pressing the arrow keys, home or end (see issue #17).

So maybe this is just me not understanding how to use fuzzy search but this is NOT what I would have expected:

I would have thought it would look for the && of each sequence typed not the ||