Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I am using NPPExec for a whole variety of functions now, and it works very nice.
But I have one issue left when using %FILE%.
What I am doing, is creating a function list with an external command, and the output is like this:
main.xx: 1317: GetItem() : function declaration
main.xx: 1317: GetLength() : function declaration
However the double click to go to file, works fine, but not if the filenames are similar.
Then it gets confused between for example mainpanel.xx and applmainpanel.xx
The filter is like this:
Also, I cannot use %ABSFILE% as then the output needs to have the absolute path, and it does not. Neither do I want it to have that, as I have the output docked to the left (as a function list should), and it would become much to wide.
Do you think this is a bug, and could it be adressed?
It's because NppExec takes the very first file name which _partially_ matches the file name given. I.e. if you open "applmainpanel.xx" _before_ "mainpanel.xx", it finds "mainpanel.xx" in "applmainpanel.xx" and uses it. Neat, isn't it? :)
Such ugly implementation can be found in NppExec.cpp, function CNppExec::nppConvertToFullPathName. Additionally, the same partially file name matching can be found in function CNppExec::nppSwitchToDocument.
Here's the corresponding code:
S1 = npp_bufFileNames[i];
if (S1.length() > 0) ::CharUpper(S1.c_str());
if ((S == S1) || (S1.Find(S) >= 0))
Seems there should be two cycles to fix the issue: the first cycle should look for the complete matching (S == S1) and, in case of no comlete matching, the second cycle should look for the partial matching (S1.Find(S) >= 0).
Well, I'll re-write these two functions and provide the update.
Wow, I can't wait :o) I imagined the problem might be something like that indeed.
I have another question, just out of curiosity. I am very low on time, so no promises. But what environment is needed to compile the plugin? And what is the quickest way to set it up?
OK, 3 hours of coding & debugging + one cup of tea + one small cake + one Snickers = support of partial file path name even in a form of "partial\path/to\file" where the file depth (count of '\' and '/') is taken into account.
To build the sources:
1. Download and install Visual C++ 2008 Express (either stand-alone or inside Visual Studio 2008 Express). It's a free version. I assume you can also use newer version.
2. Double-click the file NppExec\NppExec_VC9_no_Win9x.sln and press Build.
Please try the version uploaded here: http://www.sendspace.com/file/76zhfv and let me know the results.
I'm facing same problem. Is it fixed?
Please upload again the new version, the file is not any more on the specified link.
Or maybe some tips to solve this I'm currently struggling to solve this on my self.
This is the version that I have and the issue is still present i.e. if two (multiple) files with the same name are opened in editor , when double click on the link in the console (%FILE% filter) wrong file is chosen (the most left one). I tried also an workaround - to use the replace filter and to build the absolute path and for this I wanted to use a variable i.e. %$(CWD)% but is treated as a string.
Well, in case of two files with the very same name (let's say "C:\A\1.txt" and "C:\B\1.txt") how do you propose to differ them by the name only ("1.txt")? Let's assume I'm telling you: there's an error inside a file "1.txt". Do you have any hint which file exactly is being implied: "C:\A\1.txt" or "C:\B\1.txt"? Or probably "C:\some\other\path\1.txt"?
And, anyway, it's hard to advice something without any example. Probably the file path or the current directory is mentioned somewhere in the output or in your NppExec's script - I can just guess of this.
My idea of implementing is: store $(CWD) in a variable and output console link = Current Working Directory i.e. variable $(CWD) + the relative path for the link or replace filter to be aware of nppexec variables (just as suggestion). Also if error/warnings are in different paths \include and \src if I double click on the first error (from include) than the second link for the error from \src is corrupted because current directory is changed.
Actually this are just observations, for me it is easier to somehow create the absolute path. I also have the nppexec source and I will try to figure out what happens maybe to come with a proposal.
I think any customization of find/replace filters should be done in the scope of implementation of concept of run-time filters:
Once we will have run-time filters, we'll be able to use any environment variables there. As for the moment, the concept of run-time filters is still at the stage of design - you can find the original ideas at the link specified above.
Hey, thinking about this gave me another idea:
- if NppExec will support macro-variables everywhere in its Output Filters, this will solve the question of run-time filter automatically!
I mean, if you specify $(hl1) as the HighLight mask 1, $(hl2) as the HighLight mask 2 and so on, you'll be able to apply any run-time HighLight mask just by specifying the values of $(hl1), $(hl2) and so on.
In such case, the only action that the new command CON_FILTER will need to do, is just to add an ability to turn different filters on and off.
From my point of view implementation of this new feature is a significant improvement for the output filters.
Implemented in developed version of NppExec:
Thanks for the update. It looks fine!