Finally available! The Notepad++ Plugin Interface Library.
What is it?
A library to help other plugin makers by providing some commonly repeated functions/methods and some not so common but helpful functions that allow the plugin writer to concentrate more on writing the logic they want rather than the functions required to get the plugin up and running in the first place. Which isn't actually difficult, but can be tedious.
The library currently provides the following:
* The basic interface enhancement provides plugin registration and handle controls, with
* multiple common ways to access view handles.
*
* The ExtLexer extension provides styler (lexer) registration helper functions for implementing
* external lexers.
*
* - Both of those also allow for function registration. The basic difference between the
* two function registrations is the base functions display under a separator in the order
* registered, and the ExtLexer registered functions get sorted and displayed above the
* separator.
*
* The CmdMap extension allows plugins to use an internal enum value for a cmdId when working
* with registered N++ funcItems. This allows the plugin writer to register the commands
* with N++ in one order yet use the command values from an enum in an order more useful to
* the code, as well as not needing to deal with the funcItem array, and instead can use a
* call ( getCmdId( CMD_HIGHLIGHT ) ) to get the assigned N++ menu command id.
*
* The DocTabMap provides plugins some common helper functions that allows plugins to get
* the Scintilla document id from a N++ bufferId, determine if a file is open and ready, and
* get the Scintilla document id for the actively focused document in either N++ view.
*
* The XmlConfig extension makes it easy for a plugin to read/write configuration data in
* the same way that N++ does. So, if the plugin provides styling, the plugins' styles
* xml can also be used for config params.
*
* The Markers extension provides plugins with functions to read and react to the basic
* Notepad++/Scintilla margin and marker settings. For instance if the plugin provides
* a marker the defineMarker function will check for a valid and free marker number to use,
* as well as set the mask information for the margins in both views.
*
* The ActionIndex extension provides an action counter for a given document synchronized
* with the users actions for inserte/delete/undo/redo actions.
*
* The ActionHistory extension provides a history container for a plugin to store actions
* that it wants to have tied to the users insert/delete/undo/redo actions. It uses the
* ActionIndex count for the 'major' index and allows multiple action item entries per index
* ( or 'minor index' ). An example of this is the NppPlugin_ChangeMarker plugin that shows
* lines that have changed since a document was opened and if those changes are saved or not.
*
* Lastly, the msgs extension provides a common place to store inter plugin msg definitions.
What's required?
The library NppPluginIface.lib to build your plugin against, or if you want to build the library yourself then boost headers need to be installed ( you don't need the boost binary install ).
If you are going to build against the library without installing the boost headers the NppPluginIface.lib is located in the vc_9_0_sln folder in both the Debug_Unicode and Release_Unicode folders, which is what made the download just over 5MB. If you use the provided solution it will find them there. Just be sure to make a backup of the .lib files somewhere on your system in case you 'clean' and accidently erase them.
Also included is the source code for several plugins.
NppPlugin_Template
NppPlugin_ChangeMarker
NppPlugin_SciMarkerSymbol
NppPlugin_PluginMargin
NppPlugin_ExtLexer ( an update to the previously released NppExternalLexers project )
If there is anyone out there that wants to make additions to the library I'll be setting up a repo in the near future and am considering either svn or git, so make your voice heard. :) Right now it is in a svn repo, but I'd like to see it be more available for one-off hacks as well as major additions.
I hope others find this to be a useful and helpful library!
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You wrote something about the headers to include for direct linking. How about to make also the CPP files available like in NppPlugins project. There exist a common folder for classes like Npp behave:
- Toolbar
- Docking Interface
- Scintilla Interface
- Static Dialog
...
I think this should be possible to implement this code seperate in each project you need. Hope you understand!
Best Regards
Jens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe I understand what you are stating, and for the NppPluginIface files it should work just fine although the may warrant a project of their own.
There is an unfortunate side effect to having used the boost headers, and that is extracting only the required files. While creating the ChangeMarkers plugin I had a go at doing just that and it seemed like such a waste of effort as there are many required boost headers to get the indexing working properly.
The multi_index_container isn't something I can see going away at this point either since it provides a functionality that neither N++ nor Scintilla can currently duplicate. Namely, the ability to store multiple custom actions that can be done as a group when Scintilla does an undo or redo. Which, just to re-state, means the ActionHistory isn't just for change markers and can be used for any actions a plugin wants synchronized with a change index in Scintilla.
Given that extracting the boost headers isn't really practical and hosting the Npp_ChangeMarkers source without the NppPluginIface isn't logical how would you like to proceed?
almostautomated
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I believe I understand what you are stating, and for the
> NppPluginIface files it should work just fine although the
> may warrant a project of their own.
> There is an unfortunate side effect to having used the
> boost headers, and that is extracting only the required
> files. While creating the ChangeMarkers plugin I had a go
> at doing just that and it seemed like such a waste of
> effort as there are many required boost headers to get
> the indexing working properly.
Hi,
Just in case you didn't know about it, there's a
utility to automatically extract header dependencies
that you might find useful for this:
Finally available! The Notepad++ Plugin Interface Library.
What is it?
A library to help other plugin makers by providing some commonly repeated functions/methods and some not so common but helpful functions that allow the plugin writer to concentrate more on writing the logic they want rather than the functions required to get the plugin up and running in the first place. Which isn't actually difficult, but can be tedious.
The library currently provides the following:
* The basic interface enhancement provides plugin registration and handle controls, with
* multiple common ways to access view handles.
*
* The ExtLexer extension provides styler (lexer) registration helper functions for implementing
* external lexers.
*
* - Both of those also allow for function registration. The basic difference between the
* two function registrations is the base functions display under a separator in the order
* registered, and the ExtLexer registered functions get sorted and displayed above the
* separator.
*
* The CmdMap extension allows plugins to use an internal enum value for a cmdId when working
* with registered N++ funcItems. This allows the plugin writer to register the commands
* with N++ in one order yet use the command values from an enum in an order more useful to
* the code, as well as not needing to deal with the funcItem array, and instead can use a
* call ( getCmdId( CMD_HIGHLIGHT ) ) to get the assigned N++ menu command id.
*
* The DocTabMap provides plugins some common helper functions that allows plugins to get
* the Scintilla document id from a N++ bufferId, determine if a file is open and ready, and
* get the Scintilla document id for the actively focused document in either N++ view.
*
* The XmlConfig extension makes it easy for a plugin to read/write configuration data in
* the same way that N++ does. So, if the plugin provides styling, the plugins' styles
* xml can also be used for config params.
*
* The Markers extension provides plugins with functions to read and react to the basic
* Notepad++/Scintilla margin and marker settings. For instance if the plugin provides
* a marker the defineMarker function will check for a valid and free marker number to use,
* as well as set the mask information for the margins in both views.
*
* The ActionIndex extension provides an action counter for a given document synchronized
* with the users actions for inserte/delete/undo/redo actions.
*
* The ActionHistory extension provides a history container for a plugin to store actions
* that it wants to have tied to the users insert/delete/undo/redo actions. It uses the
* ActionIndex count for the 'major' index and allows multiple action item entries per index
* ( or 'minor index' ). An example of this is the NppPlugin_ChangeMarker plugin that shows
* lines that have changed since a document was opened and if those changes are saved or not.
*
* Lastly, the msgs extension provides a common place to store inter plugin msg definitions.
What's required?
The library NppPluginIface.lib to build your plugin against, or if you want to build the library yourself then boost headers need to be installed ( you don't need the boost binary install ).
Either way you'll need the source code which is downloadable as a full VS 2008 solution zip from the Windows Skydrive located at:
http://cid-71a486ea08eb407c.skydrive.live.com/browse.aspx/.Public/NppPluginIface
( it includes everything except the N++ source and boost headers ).
If you are going to build against the library without installing the boost headers the NppPluginIface.lib is located in the vc_9_0_sln folder in both the Debug_Unicode and Release_Unicode folders, which is what made the download just over 5MB. If you use the provided solution it will find them there. Just be sure to make a backup of the .lib files somewhere on your system in case you 'clean' and accidently erase them.
Also included is the source code for several plugins.
NppPlugin_Template
NppPlugin_ChangeMarker
NppPlugin_SciMarkerSymbol
NppPlugin_PluginMargin
NppPlugin_ExtLexer ( an update to the previously released NppExternalLexers project )
If there is anyone out there that wants to make additions to the library I'll be setting up a repo in the near future and am considering either svn or git, so make your voice heard. :) Right now it is in a svn repo, but I'd like to see it be more available for one-off hacks as well as major additions.
I hope others find this to be a useful and helpful library!
almostautomated
Posted fixed version for build error in the Markers extension margin control.
almostautomated
You wrote something about the headers to include for direct linking. How about to make also the CPP files available like in NppPlugins project. There exist a common folder for classes like Npp behave:
- Toolbar
- Docking Interface
- Scintilla Interface
- Static Dialog
...
I think this should be possible to implement this code seperate in each project you need. Hope you understand!
Best Regards
Jens
Jens,
I believe I understand what you are stating, and for the NppPluginIface files it should work just fine although the may warrant a project of their own.
There is an unfortunate side effect to having used the boost headers, and that is extracting only the required files. While creating the ChangeMarkers plugin I had a go at doing just that and it seemed like such a waste of effort as there are many required boost headers to get the indexing working properly.
The multi_index_container isn't something I can see going away at this point either since it provides a functionality that neither N++ nor Scintilla can currently duplicate. Namely, the ability to store multiple custom actions that can be done as a group when Scintilla does an undo or redo. Which, just to re-state, means the ActionHistory isn't just for change markers and can be used for any actions a plugin wants synchronized with a change index in Scintilla.
Given that extracting the boost headers isn't really practical and hosting the Npp_ChangeMarkers source without the NppPluginIface isn't logical how would you like to proceed?
almostautomated
> I believe I understand what you are stating, and for the
> NppPluginIface files it should work just fine although the
> may warrant a project of their own.
> There is an unfortunate side effect to having used the
> boost headers, and that is extracting only the required
> files. While creating the ChangeMarkers plugin I had a go
> at doing just that and it seemed like such a waste of
> effort as there are many required boost headers to get
> the indexing working properly.
Hi,
Just in case you didn't know about it, there's a
utility to automatically extract header dependencies
that you might find useful for this:
http://www.boost.org/tools/bcp/bcp.html
You can ask for further assistance with bcp at the Boost
mailing lists.
HTH,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Joaquín,
Thank you for the information! The bcp application did indeed help isolate the files needed.