FileSwitcher 0.6 is now available. This plugin lets you switch files without leaving the keyboard, by typing part of the filename, path or even the tab position.
Lots of improvements in this release, almost all suggestions from people who looked at the last release, so thank you all for those.
- Now uses a list view instead of a list box, so you can sort by the column you want
- Shows file status
- Supports Ctrl-Tab emulation, but will allow typing whilst ctrl-tabbing (thanks to almostautomated for his discussion on this, I hope this solution meets with his expectation!)
- Supports multiple views (options to show files from just the current view, or both views)
- Automatic resizing of columns (optional)
- Allows selection of default sort orders, or remembering your previous
- Added options button to the switcher dialog
- Options for what to include in search (filename, path, tab order)
Wow Dave! You did a good job. I just had a quick look and I think this might have been called version 1.0 without any doubt.
A few suggestions I have for you:
1. In my imagination I thought the Order column would be the first, instead of the last. Perhaps you could make the order of the columns also customizable.
I just had an incident which reduced the width of the Order column to, I guess, the widht of the longest entry, leaving no more space for the name of the column itself. The header just showed the arrow down for descending sort order.
2. When leaving the Options dialog, called from the File Switcher, I would expect to return to the File Switcher. However, it disappears.
Focus is not returned to Notepad++ main window, but I guess I just found out why: the File Switcher is still active. I typed some characters, pressed Enter, and got to the intended document. What happened to the Switcher dialog?
3. Having the Home and End keys, (also) in combination with the Ctrl keys, working to move up and down the list, would also be very welcome.
The color of the currently selected document/line could be somewhat brighter, like the normal selection color.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Either way, I really like the interface. It has replaced my ctrl-tab; but how do I quick switch last viewed in View1 to last viewed in View2? Also, is there anyway to have it do the same thing but with what-ever shortcut the user decides on? I tried it with tilda instead of tab and the tab switching worked but the fileswitcher dialog did not popup.
Regarding getting it on the Plugins project.... If you find out let me know :P I had posted to their forum, asked in here, and emailed regarding 'submitting' plugins with not 1 reply to those messages.
Cheers, and thanks!
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just put up 0.6.0.1, to the same locations. This fixes the issue with the options dialog, and has the about box updated :) Also the home and end keys work.
The options dialog issue was due to me naughtily testing on the debug build, which excludes a small piece of code that hides the switch dialog if it loses focus (so you can "click off" to hide it). I hadn't tested everything on the release build - I shall stand in the corner and hang my head for 10 minutes :)
I've also enabled column re-ordering, although it doesn't save your order yet. I'll release 0.6.0.2 with this in later.
Thanks again,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. The Order column's header wasn't visible when Notepad++ had started. Perhaps you could also consider the width of the column's header text to determine the necessary width of the column, possibly including the width for the ascending or descending order symbol. In my opinion this symbol uses quite some space relative to the short word Order.
2. The name Order is not consistent with the name File Index in the Options dialog.
3. The documents in the second view get a [2] prefix. This prefix is not searchable: if I type 2 (or [ or ]), these documents won't be listed. Perhaps it is a good idea to add another column just indicating the view: 1 or 2, perhaps even (with the addition) primary or secondary.
4. The selection color of the currently selected line. I think the standard "blue" (or the corresponding Windows enumarted color) would be better than the current grey.
5. Perhaps you could also add an About button to the File Switcher dialog itself. There is also room for Previous and Next buttons, to capture even all menu items as well.
6. Not necessary, but the (nice!) file status icons won't show if a file is read-only etc. You might also want to create a separate column for these, also possibly extended with a textual description of the status.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. This will kinda be fixed in the next version, as it will save your choice of size for the order (index) column. This column is never autosized - didn't see the point as the maximum size is pretty static, unless you've got over 999 files open in 2 views! My own preference would be to have this as small as possible, as I don't want to use up space for a header, but, by allowing you to change the size, and remembering your choice, that should be fixed. And yes, it's a pity that symbol uses up so much space, I can't understand why they made it take up so much space (if I'm doing something wrong to make it take so much, by all means shout!)
2. Good point. Consider it done.
3. Yes, in fact, I tried it with two columns, but it's a useless column if you normally have only one view open, and I guess that's how most people use N++ for most of the time - this is a guess, however! I could put an option to use an extra column, to suit both camps? Otherwise, I'll make the view searchable.
4. Agreed. The only reason it's grey is it's the standard "selected" but not "focused" colour. I'll see what I can do to change it.
5. Can do - not sure how useful the previous and next buttons would be though - same as up and down cursor keys, or clicking on the file itself?
6. That's the one, that's the raw nerve! :) I spent a depressing amount of time figuring out how the daddy-of-doc-switchers (window manager) works out when a doc goes read only, and it's on a timer. As far as I can tell, it polls every second (or even more often) to check if the current document has gone read-only, or gone read-write. I thought that overhead was a bit much for something that is only shown for a few seconds to switch docs, and might not be used at all. My hope was that I could submit a small patch at some point to fire a NPPN_READONLYCHANGED(int bufferID, BOOL readonly) when it changes then it would take advantage of it (the image resources are actually there, ready :) )
Thanks again - nice to hear someone finds it useful.
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. If the Order column isn't autosized, then it must have been my manual autosizing that made the word Order disappear. Please consider also taking into account the space of the header in that case, but preferably, always.
I don't know if you do anything wrong concerning the symbol. Haven't got a clue or any knowledge about that.
3. I normally don't ever use the second view, but I just tried to examine the behavior. I would like the ability of "fast" access to second view documents.
4. Perhaps the correct description would be "highlighted".
5. I didn't mean buttons to act like the up and down cursor arrows, but just a quick access to directly showing the previous or next document, like I thought Ctrl+(Shift+)Tab would do. I just checked and noticed that those key combo's only do select in the list unless you release them. I had in mind that pressing a button would immediately switch to the according document in the background, leaving the File Switcher dialog open, on top and focused. I meant to copy the behavior of the menu items, so all would be covered in the dialog as well.
6. I was thinking about just getting the actual status, not considering any changes being done while the File Switcher dialog is open (how would that be possible?). So you would only have to get the status once, when filling the list. Don't spend time on things that do not really matter, I would say. There shouldn't be too much logic in the dialog, I guess.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's funny... Now that I have set the Ctrl+(Shift+)Tab key combo's to activate the File Switcher dialog, those menu items suddenly also act like those keys. I can see in the menu that is what they are "linked" to.
Before I had done that, those menu items would directly show the previous or next document as I intended those buttons in the dialog to do as well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, that's intended. Granted, it's not self explanatory! If you set the shortcut to be Ctrl-Tab/Ctrl-Shift-Tab, then it will behave similar to the built-in Ctrl-Tab switcher, just with the advantage that you can start typing to reduce the size of the list, otherwise, I thought the only sensible "default" behaviour for the switch-next and switch-previous options is to switch directly to next and previous doc. The extra options are really only there so that you can replace the Ctrl-Tab functionality, and still use the file switcher normally.
On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance.
Hope that helps explain it.
Cheers,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance. "
No patch to N++ is needed, the performance hit is virtually null. You can use BUFFERACTIVATED notification; then SCI_GETREADONLY to populate a map; and then remove the entry on FILECLOSED.
almostautomated
Actually, now that I think about it, it might not be a bad idea to add a read-only flag to the DocMap in the NppPluginIface Library.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I thought about that, but (I think) the following scenario will break that
Doc A opened (r/w)
Doc B opened (r/w)
Doc C opened (r/w)
File-switcher switch to Doc B (SCI_GETREADONLY, returns r/w)
Change read-only flag, so Doc B now read only
Click tab C (BUFFERACTIVATED notification, SCI_GETREADONLY, returns r/w, as it's on C)
Unless there's some other notification I don't know about? Or is buffer activated sent before the actual change has occurred?
Thanks,
Dave.
p.s. fool4uanyway: you're right about this thread!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did you get a chance to take a look at what was discussed in #notepad++ the other day regarding using the SCI_GET/SET DOC for creating a map between bufferID and DocumentID to be able to acquire a buffer's ReadOnly status?
If so, how did it work out?
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not apart from reading up on Scintilla and poc pointers, sorry. I'm hoping to get some time this week to put this to bed - I'm trying to get some time on the plugin manager!
Thanks again for your help - I'll let you know how it goes.
Cheers,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> "
Yes, that's intended. Granted, it's not self explanatory! If you set the shortcut to be Ctrl-Tab/Ctrl-Shift-Tab, then it will behave similar to the built-in Ctrl-Tab switcher, just with the advantage that you can start typing to reduce the size of the list, otherwise, I thought the only sensible "default" behaviour for the switch-next and switch-previous options is to switch directly to next and previous doc.
<< "
In my opinion, the _only_ sensible behavior for the menu items is to always directly switch to the previous or next document. I do not see much advantage to those functions _also_ opening the File Switcher (as the first menu item does) with the only difference being already only selecting the previous or next document in the list.
>> "
The extra options are really only there so that you can replace the Ctrl-Tab functionality, and still use the file switcher normally.
" <<
Yeah, I thought so. But perhaps you could create separate options for those that state that the File Switcher will be opened instead of directly switching...
>> "
On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance.
" <<
Oh, forget about it, then. This seems way to complicated. I can't even take the time now to think about what goes on from your description.
STILL
I would still like those previous and next buttons in the dialog that do a direct switch in the background as opposed to moving the selection in(side) the list.
SUGGESTION
You might also create a checkbox that will enable or disable this direct switching whenever another document is selected in the list. A user could quickly check if he got the right document then.
BUG
I just noticed that the File Switcher is mistaken when I pressed the menu items to switch to the next and previous document after Notepad++ having just started. The selected document was the second in the "Order"ed list, while the active document was the one before the last. So it seems the current selection isn't initialised correctly.
By the way, when doing this the color of the selection (background bar) _is_ the highlighted (focus) color (blue).
NEW
You might also add a drop down combo box listing the last typed search string and/or complete names of documents activated from the File Switcher.
Perhaps you could even create yet another column allowing the list to be ordered as MRU list, showing the most recent (activated) documents on top to allow yet even faster access.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When (only) opening the File Switcher dialog from the menu, the selection color is not focused (grey).
When selecting the "previous" item from the menu, also the _next_ document is selected, instead of the previous.
I would prefer to have this item above the "next" item in the menu.
Also, when calling the File Switcher from the Ctrl+(Shift+)Tab key combo's the selection initialization is wrong: it does not start from the currently active document, but from some seemingly remembered number or previous selection. (Ctrl+Shift+Tab _does_ work in the intended order: previous, as opposed to the menu item.)
So if I "key" or "menu" to the previous or next document, I can't tell beforehand which document I will go to. (I did not notice this behavior yesterday, which I find strange.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, sounds like you've been playing with this more than I have!
Just to pick up on some of your points
>>
In my opinion, the _only_ sensible behavior for the menu items [Switch to next/ switch to previous]
is to always
directly switch to the previous or next document. I do not see much advantage
to those functions _also_ opening the File Switcher (as the first menu item
does) with the only difference being already only selecting the previous or
next document in the list.
<<
That's not the only difference. When launched from those menu options, with the Ctrl-Tab / Ctrl-Shift-Tab keys, the selection will change on a "tab" press, and select the document when Ctrl is released. When launched "normally" (from the first menu item), it will only select the document when return (or OK) is pressed.
This is why the bar is blue when launched from ctrl-tab, and grey when launched from Ctrl-Sh-O, because when ctrl-tabbing, the listview is in focus, and when using it normally, it's out of focus. I am looking into whether the colour can be remain the same all the time however.
Where you will get strange behaviour, and something that is on my list to see if a neat solution can be found, is if you use the menu to access the switch-next or switch-previous, but with the ctrl-tab shortcuts assigned. Then you're ctrl-tabbing without holding ctrl, which is just plain weird :), and then the only real difference is that the next document is highlighted, which as you say is not very useful. (The text box is also disabled, but will be enabled as soon as you press a key)
>> BUG
I just noticed that the File Switcher is mistaken when I pressed the menu items
to switch to the next and previous document after Notepad++ having just started.
<<
Good spot on the bug - actually I think it's a single bug that the Ctrl-(shift)-Tab launch doesn't properly set the currently selected document.
Your suggestion for a checkbox to show the currently selected document is already on my "to do before 1.0" list, which seems to be getting longer rather than shorter! Personally, I'd like the option of showing the documents live-switch whether I'm typing, tabbing or whatever.
I'll get these things fixed as soon as I can, and a very genuine thank-you for the time you've put into reviewing this.
Cheers,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> "
I'll get these things fixed as soon as I can, and a very genuine thank-you for the time you've put into reviewing this.
" <<
You're welcome. Thank you for the very useful plugin. I guess the best test is just using it, noticing strange this that happen (what you don't expect) and noticing under what circumstances and perhaps doing a little digging to find consistency or differences.
Did you notice the "reverse-order" effect for the "previous" menu item (with key combo's set)?
Yet one other suggestion could be a column "(number of times) accessed", as an alternative to normal MRU behavior. The column could just count the number of times a document is accessed (probably only from the File Switcher itself), allowing the ability to order the documents by this number.
I'm looking forward for the next release.
I propose starting another thread for that one. This one is getting long.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
almostautomated,
At the moment, only Ctrl-Tab/Ctrl-shift-tab works. I will look at allowing any shortcuts here, but it's not a small piece of work (e.g. if the shortcut is Ctrl-Alt-1, what happens if you let go of just alt, etc), and I'm not sure how many people would want a non-standard switch shortcut. However, if there's a few people that are interested in it, then I'll certainly have a go.
Not sure what you mean by the last viewed in View 1 to last viewed in View 2 - doesn't F8 do this now? Or do you mean something else?
I've fixed the about box in the new version.
Cheers,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems this plugin will make notepad++ crash when opening session. I tested it with notepad++ 5.3 and 5.4 RC2. But the order version (before 0.6) work fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The crash issue happened in version 0.6.
I tested 0.6.0.1 now, and works fine. (with Windows XP)
I got a "NppDump.dmp" file during the crash made by 0.6 when using Notepad++ 4.5 RC2. If you want it for further examination, I can send it to you. It may useful for avoiding crash again for newer version (after 0.6.0.1).
And thanks for your great plugin, I like it...:)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's ok - 0.6 did have a small issue (well, small in terms of the number of lines of code that were broken, large in terms of potential effects!) with deleting some potentially unallocated memory. This was fixed in 0.6.0.1. I hadn't actually seen it until testing the 0.6.0.1 release.
Glad you like it :)
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
FileSwitcher 0.6 is now available. This plugin lets you switch files without leaving the keyboard, by typing part of the filename, path or even the tab position.
Lots of improvements in this release, almost all suggestions from people who looked at the last release, so thank you all for those.
- Now uses a list view instead of a list box, so you can sort by the column you want
- Shows file status
- Supports Ctrl-Tab emulation, but will allow typing whilst ctrl-tabbing (thanks to almostautomated for his discussion on this, I hope this solution meets with his expectation!)
- Supports multiple views (options to show files from just the current view, or both views)
- Automatic resizing of columns (optional)
- Allows selection of default sort orders, or remembering your previous
- Added options button to the switcher dialog
- Options for what to include in search (filename, path, tab order)
Unicode is
http://www.brotherstone.co.uk/npp/FileSwitcher_UNI.zip
ANSI is
http://www.brotherstone.co.uk/npp/FileSwitcher_ANSI.zip
Source is
http://www.brotherstone.co.uk/npp/FileSwitcher_src.zip
What's the process if I wanted to get this included in the "notepad++ plugins" project - do a certain number of people need to approve it?
Any comments always welcome.
Many thanks,
Dave.
Wow Dave! You did a good job. I just had a quick look and I think this might have been called version 1.0 without any doubt.
A few suggestions I have for you:
1. In my imagination I thought the Order column would be the first, instead of the last. Perhaps you could make the order of the columns also customizable.
I just had an incident which reduced the width of the Order column to, I guess, the widht of the longest entry, leaving no more space for the name of the column itself. The header just showed the arrow down for descending sort order.
2. When leaving the Options dialog, called from the File Switcher, I would expect to return to the File Switcher. However, it disappears.
Focus is not returned to Notepad++ main window, but I guess I just found out why: the File Switcher is still active. I typed some characters, pressed Enter, and got to the intended document. What happened to the Switcher dialog?
3. Having the Home and End keys, (also) in combination with the Ctrl keys, working to move up and down the list, would also be very welcome.
The color of the currently selected document/line could be somewhat brighter, like the normal selection color.
release - .6 or .5 ? 'About' states .5.
Either way, I really like the interface. It has replaced my ctrl-tab; but how do I quick switch last viewed in View1 to last viewed in View2? Also, is there anyway to have it do the same thing but with what-ever shortcut the user decides on? I tried it with tilda instead of tab and the tab switching worked but the fileswitcher dialog did not popup.
Regarding getting it on the Plugins project.... If you find out let me know :P I had posted to their forum, asked in here, and emailed regarding 'submitting' plugins with not 1 reply to those messages.
Cheers, and thanks!
almostautomated
"... how do I quick switch last viewed in View1 to last viewed in View2? ... "
Thanks for reminding me about [F8] (on irc ) Dave. Doh! Consider the question retracted.
Works great, thanks! cocinerox
Thanks for the feedback.
I've just put up 0.6.0.1, to the same locations. This fixes the issue with the options dialog, and has the about box updated :) Also the home and end keys work.
The options dialog issue was due to me naughtily testing on the debug build, which excludes a small piece of code that hides the switch dialog if it loses focus (so you can "click off" to hide it). I hadn't tested everything on the release build - I shall stand in the corner and hang my head for 10 minutes :)
I've also enabled column re-ordering, although it doesn't save your order yet. I'll release 0.6.0.2 with this in later.
Thanks again,
Dave.
Again, quite some improvement, Dave.
Here's just another short wish list.
1. The Order column's header wasn't visible when Notepad++ had started. Perhaps you could also consider the width of the column's header text to determine the necessary width of the column, possibly including the width for the ascending or descending order symbol. In my opinion this symbol uses quite some space relative to the short word Order.
2. The name Order is not consistent with the name File Index in the Options dialog.
3. The documents in the second view get a [2] prefix. This prefix is not searchable: if I type 2 (or [ or ]), these documents won't be listed. Perhaps it is a good idea to add another column just indicating the view: 1 or 2, perhaps even (with the addition) primary or secondary.
4. The selection color of the currently selected line. I think the standard "blue" (or the corresponding Windows enumarted color) would be better than the current grey.
5. Perhaps you could also add an About button to the File Switcher dialog itself. There is also room for Previous and Next buttons, to capture even all menu items as well.
6. Not necessary, but the (nice!) file status icons won't show if a file is read-only etc. You might also want to create a separate column for these, also possibly extended with a textual description of the status.
1. This will kinda be fixed in the next version, as it will save your choice of size for the order (index) column. This column is never autosized - didn't see the point as the maximum size is pretty static, unless you've got over 999 files open in 2 views! My own preference would be to have this as small as possible, as I don't want to use up space for a header, but, by allowing you to change the size, and remembering your choice, that should be fixed. And yes, it's a pity that symbol uses up so much space, I can't understand why they made it take up so much space (if I'm doing something wrong to make it take so much, by all means shout!)
2. Good point. Consider it done.
3. Yes, in fact, I tried it with two columns, but it's a useless column if you normally have only one view open, and I guess that's how most people use N++ for most of the time - this is a guess, however! I could put an option to use an extra column, to suit both camps? Otherwise, I'll make the view searchable.
4. Agreed. The only reason it's grey is it's the standard "selected" but not "focused" colour. I'll see what I can do to change it.
5. Can do - not sure how useful the previous and next buttons would be though - same as up and down cursor keys, or clicking on the file itself?
6. That's the one, that's the raw nerve! :) I spent a depressing amount of time figuring out how the daddy-of-doc-switchers (window manager) works out when a doc goes read only, and it's on a timer. As far as I can tell, it polls every second (or even more often) to check if the current document has gone read-only, or gone read-write. I thought that overhead was a bit much for something that is only shown for a few seconds to switch docs, and might not be used at all. My hope was that I could submit a small patch at some point to fire a NPPN_READONLYCHANGED(int bufferID, BOOL readonly) when it changes then it would take advantage of it (the image resources are actually there, ready :) )
Thanks again - nice to hear someone finds it useful.
Dave.
Thanks for the fast reply.
A short reply:
1. If the Order column isn't autosized, then it must have been my manual autosizing that made the word Order disappear. Please consider also taking into account the space of the header in that case, but preferably, always.
I don't know if you do anything wrong concerning the symbol. Haven't got a clue or any knowledge about that.
3. I normally don't ever use the second view, but I just tried to examine the behavior. I would like the ability of "fast" access to second view documents.
4. Perhaps the correct description would be "highlighted".
5. I didn't mean buttons to act like the up and down cursor arrows, but just a quick access to directly showing the previous or next document, like I thought Ctrl+(Shift+)Tab would do. I just checked and noticed that those key combo's only do select in the list unless you release them. I had in mind that pressing a button would immediately switch to the according document in the background, leaving the File Switcher dialog open, on top and focused. I meant to copy the behavior of the menu items, so all would be covered in the dialog as well.
6. I was thinking about just getting the actual status, not considering any changes being done while the File Switcher dialog is open (how would that be possible?). So you would only have to get the status once, when filling the list. Don't spend time on things that do not really matter, I would say. There shouldn't be too much logic in the dialog, I guess.
That's funny... Now that I have set the Ctrl+(Shift+)Tab key combo's to activate the File Switcher dialog, those menu items suddenly also act like those keys. I can see in the menu that is what they are "linked" to.
Before I had done that, those menu items would directly show the previous or next document as I intended those buttons in the dialog to do as well.
Yes, that's intended. Granted, it's not self explanatory! If you set the shortcut to be Ctrl-Tab/Ctrl-Shift-Tab, then it will behave similar to the built-in Ctrl-Tab switcher, just with the advantage that you can start typing to reduce the size of the list, otherwise, I thought the only sensible "default" behaviour for the switch-next and switch-previous options is to switch directly to next and previous doc. The extra options are really only there so that you can replace the Ctrl-Tab functionality, and still use the file switcher normally.
On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance.
Hope that helps explain it.
Cheers,
Dave.
"On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance. "
No patch to N++ is needed, the performance hit is virtually null. You can use BUFFERACTIVATED notification; then SCI_GETREADONLY to populate a map; and then remove the entry on FILECLOSED.
almostautomated
Actually, now that I think about it, it might not be a bad idea to add a read-only flag to the DocMap in the NppPluginIface Library.
Yes, I thought about that, but (I think) the following scenario will break that
Doc A opened (r/w)
Doc B opened (r/w)
Doc C opened (r/w)
File-switcher switch to Doc B (SCI_GETREADONLY, returns r/w)
Change read-only flag, so Doc B now read only
Click tab C (BUFFERACTIVATED notification, SCI_GETREADONLY, returns r/w, as it's on C)
Unless there's some other notification I don't know about? Or is buffer activated sent before the actual change has occurred?
Thanks,
Dave.
p.s. fool4uanyway: you're right about this thread!
Dave,
Did you get a chance to take a look at what was discussed in #notepad++ the other day regarding using the SCI_GET/SET DOC for creating a map between bufferID and DocumentID to be able to acquire a buffer's ReadOnly status?
If so, how did it work out?
almostautomated
Not apart from reading up on Scintilla and poc pointers, sorry. I'm hoping to get some time this week to put this to bed - I'm trying to get some time on the plugin manager!
Thanks again for your help - I'll let you know how it goes.
Cheers,
Dave.
>> "
Yes, that's intended. Granted, it's not self explanatory! If you set the shortcut to be Ctrl-Tab/Ctrl-Shift-Tab, then it will behave similar to the built-in Ctrl-Tab switcher, just with the advantage that you can start typing to reduce the size of the list, otherwise, I thought the only sensible "default" behaviour for the switch-next and switch-previous options is to switch directly to next and previous doc.
<< "
In my opinion, the _only_ sensible behavior for the menu items is to always directly switch to the previous or next document. I do not see much advantage to those functions _also_ opening the File Switcher (as the first menu item does) with the only difference being already only selecting the previous or next document in the list.
>> "
The extra options are really only there so that you can replace the Ctrl-Tab functionality, and still use the file switcher normally.
" <<
Yeah, I thought so. But perhaps you could create separate options for those that state that the File Switcher will be opened instead of directly switching...
>> "
On the read-only thing, if only it were that easy! I can only get the read only status of the current document, but if you change to a doc (with or without the switcher), set the readonly flag, then change without the switcher to another doc, I get no notification that the readonly has changed for that document. It's certainly on my to-do list, but it needs a small patch to N++ before it is sensible to do it, without causing a hit on performance.
" <<
Oh, forget about it, then. This seems way to complicated. I can't even take the time now to think about what goes on from your description.
STILL
I would still like those previous and next buttons in the dialog that do a direct switch in the background as opposed to moving the selection in(side) the list.
SUGGESTION
You might also create a checkbox that will enable or disable this direct switching whenever another document is selected in the list. A user could quickly check if he got the right document then.
BUG
I just noticed that the File Switcher is mistaken when I pressed the menu items to switch to the next and previous document after Notepad++ having just started. The selected document was the second in the "Order"ed list, while the active document was the one before the last. So it seems the current selection isn't initialised correctly.
By the way, when doing this the color of the selection (background bar) _is_ the highlighted (focus) color (blue).
NEW
You might also add a drop down combo box listing the last typed search string and/or complete names of documents activated from the File Switcher.
Perhaps you could even create yet another column allowing the list to be ordered as MRU list, showing the most recent (activated) documents on top to allow yet even faster access.
MORE ABOUT THE SELECTION INITIALIZATION BUG
When (only) opening the File Switcher dialog from the menu, the selection color is not focused (grey).
When selecting the "previous" item from the menu, also the _next_ document is selected, instead of the previous.
I would prefer to have this item above the "next" item in the menu.
Also, when calling the File Switcher from the Ctrl+(Shift+)Tab key combo's the selection initialization is wrong: it does not start from the currently active document, but from some seemingly remembered number or previous selection. (Ctrl+Shift+Tab _does_ work in the intended order: previous, as opposed to the menu item.)
So if I "key" or "menu" to the previous or next document, I can't tell beforehand which document I will go to. (I did not notice this behavior yesterday, which I find strange.)
Wow, sounds like you've been playing with this more than I have!
Just to pick up on some of your points
>>
In my opinion, the _only_ sensible behavior for the menu items [Switch to next/ switch to previous]
is to always
directly switch to the previous or next document. I do not see much advantage
to those functions _also_ opening the File Switcher (as the first menu item
does) with the only difference being already only selecting the previous or
next document in the list.
<<
That's not the only difference. When launched from those menu options, with the Ctrl-Tab / Ctrl-Shift-Tab keys, the selection will change on a "tab" press, and select the document when Ctrl is released. When launched "normally" (from the first menu item), it will only select the document when return (or OK) is pressed.
This is why the bar is blue when launched from ctrl-tab, and grey when launched from Ctrl-Sh-O, because when ctrl-tabbing, the listview is in focus, and when using it normally, it's out of focus. I am looking into whether the colour can be remain the same all the time however.
Where you will get strange behaviour, and something that is on my list to see if a neat solution can be found, is if you use the menu to access the switch-next or switch-previous, but with the ctrl-tab shortcuts assigned. Then you're ctrl-tabbing without holding ctrl, which is just plain weird :), and then the only real difference is that the next document is highlighted, which as you say is not very useful. (The text box is also disabled, but will be enabled as soon as you press a key)
>> BUG
I just noticed that the File Switcher is mistaken when I pressed the menu items
to switch to the next and previous document after Notepad++ having just started.
<<
Good spot on the bug - actually I think it's a single bug that the Ctrl-(shift)-Tab launch doesn't properly set the currently selected document.
Your suggestion for a checkbox to show the currently selected document is already on my "to do before 1.0" list, which seems to be getting longer rather than shorter! Personally, I'd like the option of showing the documents live-switch whether I'm typing, tabbing or whatever.
I'll get these things fixed as soon as I can, and a very genuine thank-you for the time you've put into reviewing this.
Cheers,
Dave.
>> "
I'll get these things fixed as soon as I can, and a very genuine thank-you for the time you've put into reviewing this.
" <<
You're welcome. Thank you for the very useful plugin. I guess the best test is just using it, noticing strange this that happen (what you don't expect) and noticing under what circumstances and perhaps doing a little digging to find consistency or differences.
Did you notice the "reverse-order" effect for the "previous" menu item (with key combo's set)?
Yet one other suggestion could be a column "(number of times) accessed", as an alternative to normal MRU behavior. The column could just count the number of times a document is accessed (probably only from the File Switcher itself), allowing the ability to order the documents by this number.
I'm looking forward for the next release.
I propose starting another thread for that one. This one is getting long.
almostautomated,
At the moment, only Ctrl-Tab/Ctrl-shift-tab works. I will look at allowing any shortcuts here, but it's not a small piece of work (e.g. if the shortcut is Ctrl-Alt-1, what happens if you let go of just alt, etc), and I'm not sure how many people would want a non-standard switch shortcut. However, if there's a few people that are interested in it, then I'll certainly have a go.
Not sure what you mean by the last viewed in View 1 to last viewed in View 2 - doesn't F8 do this now? Or do you mean something else?
I've fixed the about box in the new version.
Cheers,
Dave.
Seems this plugin will make notepad++ crash when opening session. I tested it with notepad++ 5.3 and 5.4 RC2. But the order version (before 0.6) work fine.
Can I check - are you using 0.6 or 0.6.0.1?
Opening a session works for me on 0.6.0.1. If you are, can you tell me what OS you're running, and I'll look into it.
Thanks,
Dave.
The crash issue happened in version 0.6.
I tested 0.6.0.1 now, and works fine. (with Windows XP)
I got a "NppDump.dmp" file during the crash made by 0.6 when using Notepad++ 4.5 RC2. If you want it for further examination, I can send it to you. It may useful for avoiding crash again for newer version (after 0.6.0.1).
And thanks for your great plugin, I like it...:)
It's ok - 0.6 did have a small issue (well, small in terms of the number of lines of code that were broken, large in terms of potential effects!) with deleting some potentially unallocated memory. This was fixed in 0.6.0.1. I hadn't actually seen it until testing the 0.6.0.1 release.
Glad you like it :)
Dave.
Just a quick note that I really like this plugin, especially when setting the Ctrl+Tab shortcut. This works just as I would expect.