I hacked together a useful plugin to execute NppExec scripts automatically on Notepad++ events some time ago for my personal automation needs and decided to release it to the public, perhaps it might grow into something powerful. The source is on GitHub, binaries are available there as well. NppEventExec is just an extension to NppExec that allows you to define rules consisting of an Notepad++ event (like NPPN_FILEBEFORESAVE), regular expression which the active document is checked against and the name of an NppExec command. I use this for a lot of tasks, including formatting source code (for which btw I use this script and compilation after saving for error checking. Anyhow, the rules still have to be defined by hand in the CSV config file, but I'm actively working on an editor. Rules can also be executed in the foreground, meaning all input to Notepad++ will be blocked and you'll see a waiting dialog. Oh, and I coded it in C, because I love C. Anyway, I just wanted to hear if somebody else would find the plugin useful to know if it's worth the time to implement the missing features. Perhaps also some ideas, wishes etc. would be great :) NppExec is an amazing plugin, no matter what I need I always find it there and it would make me quite happy if this simple extension provides an added value :)
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, it is cool!
I'd recommend to add more details about how to set up this plugin properly, because:
1. It took me some time to realize that the example rule was initially disabled (and it was the cause why nothing happened);
2. I had no idea where and in which form to put the "Format C/C++ source" script - I've figured out only after debugging.
And immediately I've found a logical problem in the plugin's workflow (but it's only because I already was thinking about that and was trying that in NppExec itself :)).
Please enable your rule and then execute the following command for a modified C/C++ file in Notepad++:
NPP_SAVE
The execution of NPP_SAVE triggers NPPN_FILEBEFORESAVE, which, in its turn, triggers the execution of the "Format C/C++ source". And everything hangs, waiting for the command to be executed. This needs to be solved :)
Also, why boost::wregex instead of std::wregex? We are already in the world of C++11, aren't we?
As for C-style memory allocations... What a pain is this manual memory freeing with permanent potential memory leaks...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey DV, thanks for taking the time to try it out and respond with good suggestions and critique. This is very important for me!!! You are right, the documentation needs some additional work and I have to finish some features like a rule editor and the ability to cancel scheduled commands.
About the hanging problem... NppExec doesn't communicate whether the command exists when I call NPEM_NPPEXEC. Perhaps this needs to be adressed in the future. I can solve it for the time being by setting some maximum number of retries, 3 for instance. This makes sense for a lot of scenarios even. I will do this right away. This will solve the hanging.
I used boost::wregex, because I wanted to stay consistent to Notepad++. I read somewhere that it's used internally, but I haven't checked it out in detail to be honest. I have no personal preference towards Boost and could replace it, my only wish being consistency in Notepad++.
Hehe, C allocations, I don't mind for they exercise your ability to stay vigilant and are quite fun :)) Nothing better than a bit of hacking... I really love that.
Still I'd ask for your honest opinion whether the existence of the plugin is justified in some way. All of the functionality can be implemented in NppExec at some point of time, but currently I can expand NppEventExec rapidly as it's a simple codebase. For me it makes sense, for I find the plugin quite usable, but it could be just me, I am aware of that :)
There are a couple of things I also wanted to talk with you about, such as implementing a mechanism for showing message dialog boxes from NppExec for info / warning / errors, but let me code that maximum retries thing first :)
Regards!!!
P.S.
Hm, I appears I have misunderstood something, can you elaborate on how to cause the hanging? I think I have seen it myself once, but cannot seem to reproduce it any more.
P.S.S.
OK, I managed to reproduce it, I have been aware of issues of this kind for some time now, but I have no idea how to fix it actually. Perhaps you'll have an idea :) Something that would definetely work is to abort the rule execution, but it would imply Notepad++ events triggered from NppExec are troublesome.
Last edit: BilderVonFrüher 2016-12-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There can be even more interesting situation.
Just try to add the NPP_SAVEALL into a script that is triggered by NPPN_FILEBEFORESAVE :)
Potentially this may lead to recursion - because each NPPN_FILEBEFORESAVE will lead to NPP_SAVEALL that may trigger another NPPN_FILEBEFORESAVE, and so on.
Looks like we both need to think about proper design and handling of such situation - either by your plugin or by NppExec itself, or maybe by both of them...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just uploaded the code allowing the user to abort scheduled rules. This solves the blocking issue only partially, i.e. the user will still be angry for having to do it, but at atleast no ctrl+alt+del would be required :) I haven't released a new version yet, because I wanted to test it for at least 2 days, but you can compile it manually if you want to. I am now beginning to write an editor for rules so no manual file editing would be necessary.
As for the problem with the mutual blocking... I spent some time thinking about what is happening and possible solutions. I haven't yet thought about it much, but one obvious hack would be to make the plugin use a second NppExec instance for its work, since this would allow the main instance to continue the script execution. Perhaps in the futue NppEventExec could use the core logic of NppExec through a special DLL which does not expose a Notepad++ plugin interface. Or NppExec could provide a special 2nd executor accessible through some Notepad++ message or an exported DLL function. Or the instance NppEventExec uses could be configurable through an options dialog (also in the making). I will test what happens when using 2 instances shortly.
Aside from this strategy, I'm currently out of ideas concerning the issue. I also have an interesting sense of "naturalness" to the situation, i.e. it's exactly what I as a developer expect would happen in this scenario. I recall now that I experienced this when I first hacked together the basic functionality some time ago. Of course, the problem definetely needs a solution since it's not what the user will be expecting :) That is, major changes in the plugins might not be required, for they already do what they are supposed to do on their own and the situation is not a bug. We probably need extra code on both sides to allow them to work better together, you are fully correct!!!
On a side note, I've spent some time this weekend to study the source code of NppExec in detail after more than 1,5 years and I have to say it really looks very tight :) Congratulations on a very clear concept and architecture coupled with solid craftmanship.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, cool. I'll try to invest more time in development of NppExec that is still not finished after several months of mostly doing nothing. The change is described in brief here: https://sourceforge.net/p/npp-plugins/discussion/672146/thread/da49de3c/?page=1
As it is a fundamental, core change, I don't want to do anything else until this change is done. And since it's complicated, I postpone it again and again. I'll try to surmount my laziness and develop this at last! :)
Returning to the callback scripts (this is how I called the functionality provided by your plugin when I was thinking about supporting it in NppExec some time ago), we can try another approach I was experimenting with in the latest 0.5.9.9 versions of NppExec. I'm talking about CNppExec::ExecuteChildProcessCommand that creates a new instance of CScriptEngine and runs it in a new thread. Probably callback scripts can be based on something similar.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just released version 0.9.0 of NppEventExec and it's available on the development list of the plugin manager. The plugin now also supports 64-bit Notepad++. It would be great if some of you NppExec users could give it a test. I've added a lot of new features: a number of dialogs to ease the management of rules, numerous bug fixes, the ability to abort rules and improvements to the execution code. I hope it could be useful for someone. Please be on your guard for potential issues.
@DV: A multi-threaded version of NppExec might be dangerous for NppEventExec currently, because NppEventExec depends on sequential execution and waits for the "Ready" state, before executing the next rule in the queue. It would be great if NPEM_NPPEXEC provides a way to check for the completion of a script, for example using an ID. This seems to be easy and could be done by adding another parameter to NpeNppExecParam :) What do you think?
Regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello DV & all NppExec users,
I hacked together a useful plugin to execute NppExec scripts automatically on Notepad++ events some time ago for my personal automation needs and decided to release it to the public, perhaps it might grow into something powerful. The source is on GitHub, binaries are available there as well. NppEventExec is just an extension to NppExec that allows you to define rules consisting of an Notepad++ event (like NPPN_FILEBEFORESAVE), regular expression which the active document is checked against and the name of an NppExec command. I use this for a lot of tasks, including formatting source code (for which btw I use this script and compilation after saving for error checking. Anyhow, the rules still have to be defined by hand in the CSV config file, but I'm actively working on an editor. Rules can also be executed in the foreground, meaning all input to Notepad++ will be blocked and you'll see a waiting dialog. Oh, and I coded it in C, because I love C. Anyway, I just wanted to hear if somebody else would find the plugin useful to know if it's worth the time to implement the missing features. Perhaps also some ideas, wishes etc. would be great :) NppExec is an amazing plugin, no matter what I need I always find it there and it would make me quite happy if this simple extension provides an added value :)
Regards
Wow, it is cool!
I'd recommend to add more details about how to set up this plugin properly, because:
1. It took me some time to realize that the example rule was initially disabled (and it was the cause why nothing happened);
2. I had no idea where and in which form to put the "Format C/C++ source" script - I've figured out only after debugging.
And immediately I've found a logical problem in the plugin's workflow (but it's only because I already was thinking about that and was trying that in NppExec itself :)).
Please enable your rule and then execute the following command for a modified C/C++ file in Notepad++:
The execution of NPP_SAVE triggers NPPN_FILEBEFORESAVE, which, in its turn, triggers the execution of the "Format C/C++ source". And everything hangs, waiting for the command to be executed. This needs to be solved :)
Also, why boost::wregex instead of std::wregex? We are already in the world of C++11, aren't we?
As for C-style memory allocations... What a pain is this manual memory freeing with permanent potential memory leaks...
Hey DV, thanks for taking the time to try it out and respond with good suggestions and critique. This is very important for me!!! You are right, the documentation needs some additional work and I have to finish some features like a rule editor and the ability to cancel scheduled commands.
About the hanging problem... NppExec doesn't communicate whether the command exists when I call NPEM_NPPEXEC. Perhaps this needs to be adressed in the future. I can solve it for the time being by setting some maximum number of retries, 3 for instance. This makes sense for a lot of scenarios even. I will do this right away. This will solve the hanging.
I used boost::wregex, because I wanted to stay consistent to Notepad++. I read somewhere that it's used internally, but I haven't checked it out in detail to be honest. I have no personal preference towards Boost and could replace it, my only wish being consistency in Notepad++.
Hehe, C allocations, I don't mind for they exercise your ability to stay vigilant and are quite fun :)) Nothing better than a bit of hacking... I really love that.
Still I'd ask for your honest opinion whether the existence of the plugin is justified in some way. All of the functionality can be implemented in NppExec at some point of time, but currently I can expand NppEventExec rapidly as it's a simple codebase. For me it makes sense, for I find the plugin quite usable, but it could be just me, I am aware of that :)
There are a couple of things I also wanted to talk with you about, such as implementing a mechanism for showing message dialog boxes from NppExec for info / warning / errors, but let me code that maximum retries thing first :)
Regards!!!
P.S.
Hm, I appears I have misunderstood something, can you elaborate on how to cause the hanging? I think I have seen it myself once, but cannot seem to reproduce it any more.
P.S.S.
OK, I managed to reproduce it, I have been aware of issues of this kind for some time now, but I have no idea how to fix it actually. Perhaps you'll have an idea :) Something that would definetely work is to abort the rule execution, but it would imply Notepad++ events triggered from NppExec are troublesome.
Last edit: BilderVonFrüher 2016-12-30
There can be even more interesting situation.
Just try to add the NPP_SAVEALL into a script that is triggered by NPPN_FILEBEFORESAVE :)
Potentially this may lead to recursion - because each NPPN_FILEBEFORESAVE will lead to NPP_SAVEALL that may trigger another NPPN_FILEBEFORESAVE, and so on.
Looks like we both need to think about proper design and handling of such situation - either by your plugin or by NppExec itself, or maybe by both of them...
Hey DV,
I just uploaded the code allowing the user to abort scheduled rules. This solves the blocking issue only partially, i.e. the user will still be angry for having to do it, but at atleast no ctrl+alt+del would be required :) I haven't released a new version yet, because I wanted to test it for at least 2 days, but you can compile it manually if you want to. I am now beginning to write an editor for rules so no manual file editing would be necessary.
As for the problem with the mutual blocking... I spent some time thinking about what is happening and possible solutions. I haven't yet thought about it much, but one obvious hack would be to make the plugin use a second NppExec instance for its work, since this would allow the main instance to continue the script execution. Perhaps in the futue NppEventExec could use the core logic of NppExec through a special DLL which does not expose a Notepad++ plugin interface. Or NppExec could provide a special 2nd executor accessible through some Notepad++ message or an exported DLL function. Or the instance NppEventExec uses could be configurable through an options dialog (also in the making). I will test what happens when using 2 instances shortly.
Aside from this strategy, I'm currently out of ideas concerning the issue. I also have an interesting sense of "naturalness" to the situation, i.e. it's exactly what I as a developer expect would happen in this scenario. I recall now that I experienced this when I first hacked together the basic functionality some time ago. Of course, the problem definetely needs a solution since it's not what the user will be expecting :) That is, major changes in the plugins might not be required, for they already do what they are supposed to do on their own and the situation is not a bug. We probably need extra code on both sides to allow them to work better together, you are fully correct!!!
On a side note, I've spent some time this weekend to study the source code of NppExec in detail after more than 1,5 years and I have to say it really looks very tight :) Congratulations on a very clear concept and architecture coupled with solid craftmanship.
OK, cool. I'll try to invest more time in development of NppExec that is still not finished after several months of mostly doing nothing. The change is described in brief here:
https://sourceforge.net/p/npp-plugins/discussion/672146/thread/da49de3c/?page=1
As it is a fundamental, core change, I don't want to do anything else until this change is done. And since it's complicated, I postpone it again and again. I'll try to surmount my laziness and develop this at last! :)
Returning to the callback scripts (this is how I called the functionality provided by your plugin when I was thinking about supporting it in NppExec some time ago), we can try another approach I was experimenting with in the latest 0.5.9.9 versions of NppExec. I'm talking about CNppExec::ExecuteChildProcessCommand that creates a new instance of CScriptEngine and runs it in a new thread. Probably callback scripts can be based on something similar.
Hello everyone!
I've just released version 0.9.0 of NppEventExec and it's available on the development list of the plugin manager. The plugin now also supports 64-bit Notepad++. It would be great if some of you NppExec users could give it a test. I've added a lot of new features: a number of dialogs to ease the management of rules, numerous bug fixes, the ability to abort rules and improvements to the execution code. I hope it could be useful for someone. Please be on your guard for potential issues.
@DV: A multi-threaded version of NppExec might be dangerous for NppEventExec currently, because NppEventExec depends on sequential execution and waits for the "Ready" state, before executing the next rule in the queue. It would be great if NPEM_NPPEXEC provides a way to check for the completion of a script, for example using an ID. This seems to be easy and could be done by adding another parameter to NpeNppExecParam :) What do you think?
Regards
Thank you for the update!
Yes, assigning an id to the external script/command is a good idea. Added to the ToDo list.