Plugin Margin, Marker, and Indicator Numbers
Notepad++ project is moving to GitHub:
Brought to you by:
donho
Menu
▾
▴
Hola once again,
I'm looking at working on another plugin that does line change makers and was looking at the margin and marker setups that N++ is using when an inconsistency appeared between markers and indicators. My actual questions are denoted **.
According to the Scintilla doc page indicators are divided:
"To prevent interference the set of indicators is divided up into a range for use by lexers (0..7) and a range for use by containers (8=INDIC_CONTAINER .. 31=INDIC_MAX)."
No such guideline is given for margins and markers. I assume this is because margins and markers would typically be targeted to the container by the container app and not a lexer. Yet, because N++ allows plugins at the container level I'm wondering if you have any such guideline.
It looks like N++ uses margins 0 to 2 as the default Scintilla doc recommends:
"The margins are numbered 0 to 4... ...By default, margin 0 is set to display line numbers, but is given a width of 0, so it is hidden. Margin 1 is set to display non-folding symbols and is given a width of 16 pixels, so it is visible. Margin 2 is set to display the folding symbols, but is given a width of 0, so it is hidden."
** So should plugins use Margin 1 and let N++ determine visibility; or should they use 3/4?
Personally I think it would be good to have margin 4 set aside for plugins and have its' visibility set within the Preferences->Edit Components along with the line number, and bookmark margins.
Last point of concern; according to the Scintilla doc:
"Any markers not associated with a visible margin will be displayed as changes in background colour in the text."
"Marker numbers 25 to 31 are used by Scintilla in folding margins, and have symbolic names of the form SC_MARKNUM_*, for example SC_MARKNUM_FOLDEROPEN."
"Marker numbers 0 to 24 have no pre-defined function; you can use them to mark syntax errors or the current point of execution, break points, or whatever you need marking."
"The markers are drawn in the order of their numbers, so higher numbered markers appear on top of lower numbered ones."
From looking at N++ I see that the markers constants are assigned low numbers. If plugins use the current margin 1 then bookmarks would be the one behind the rest. ( Not that it looks like it has been an issue.)
** At what marker number are plugins 'safe'; which could be set aside for plugin usage?
Thanks,
almostautomated
Here you go:
Screenshot of a comparison: http://i249.photobucket.com/albums/gg229/CountDown_0/Compare.png
Clear results: http://i249.photobucket.com/albums/gg229/CountDown_0/ClearResults.png
Version: http://i249.photobucket.com/albums/gg229/CountDown_0/Version.png
I would also like to send you the files that I am comparing, but I don't know how to do it. Email? Or should I open a new item in the bug tracker? In case you don't want to publish your email address, my name is Fabio Turati, and my email is
name dot surname at infinito.it
(I hope spambots can't recognize this format ;-) ); send me an email and I'll reply attaching them (they're very small, don't worry).
And no, I didn't tell the maintainer of Compare plugin because when I clear the results, N++ correctly considers the file as unmodified, that's why I think the problem is related with Change markers. But after all you are right, I'd better tell Jean-Sébastien as well. I'll do it in a minute.
Thanks for the screenshots, what you are seeing is not really a bug so much as a missing feature. That feature would be the ability of an external plugin being able to call for the clearing of change indicator markers. The reason this was not included is because while developing the plugin I didn't take the time to figure out when an external plugin should be able to clear results, and to which point it should be able to go back to.
Instead, I opted for user control of this. Simply select the tab for the document in question, and in the Change Markers menu select disable for this document. Which will clear the markers; then if you want it back simply re-enable it.
Perhaps a user selectable 'Allow external control' would be the answer for clearing all markers for the doc...
Heya Dev Team! Any input on this? Is there anywhere there may have been some doc put together spelling out some guidelines for this kind of stuff?
For the plugin I'm working on right now, I decided to check for previous use of margins 3 and 4 by another plugin, if one is free for both views then I use it, if not a message is posted to the user saying the plugin won't work because it doesn't want to cause unexpected behavior. As for the markers themselves I decided that since there are 32 markers available, the last 8 being used for folding that I'd shoot for using 16-23; (:shrugs:) just an ambiguous shot in the dark. :P
???
almostautomated
Currently, there are no guidelines, so its free for all (with all the bad things that may happen because of it :'] ). Or like with the shortcuts. Some docs on it would be a really good idea. The check oyu make is a good idea too, though a bit cumbersome to implement.
Maybe plugin atuhors can add what they make use of in the wiki in some constants table (feel free to do so :P)
> ** So should plugins use Margin 1 and let N++ determine visibility;
> or should they use 3/4?
It depends. If plugin does the same kind (the same number or not) of marker and it can make its markers stay harmonically with Notepad++'s ones, then just use 1. Otherwise use 4 (Number 3 is reserved for Notepad++ internal use), and it'll be the responsibility of plugin to display it (or not), but not Notepad++.
> From looking at N++ I see that the markers constants are assigned low numbers.
> If plugins use the current margin 1 then bookmarks would be the one behind the rest.
Thank you for the alert. Therefore here are the new definitions :
const int MARK_BOOKMARK = 24;
const int MARK_HIDELINESBEGIN = 23;
const int MARK_HIDELINESEND = 22;
// 24 - 16 reserved for Notepad++ internal used
// 15 - 0 are free to use for plugins
The modifications are committed, please check svn for the newest change.
Don
Don,
Excellent, just the type of information I was looking for. With the internal markers now having higher numbers it should be much easier to coincide with them, thank you.
It would be nice to have a user control for margin 4 in the same place as the Line/Bookmarks margin options instead of disparate plugins trying to decide if they should show it or not, instead of disparate plugins competing for control over it.
That's neither here nor there for now, as there aren't many ( that I know of ) plugins using the margins, and with the internal ones having a higher number now the default symbols margin should work good.
Thanks again,
almostautomated
> It would be nice to have a user control for margin 4 in the same place
> as the Line/Bookmarks margin options instead of disparate plugins trying
> to decide if they should show it or not,
It makes no sense to me to make a no used margin available for users.
> instead of disparate plugins competing for control over it.
Let plugins communicates this info among them :
#define NPPM_MSGTOPLUGIN (NPPMSG + 47)
//BOOL NPPM_MSGTOPLUGIN(TCHAR *destModuleName, CommunicationInfo *info)
// This message allows the conversation between 2 plugins.
// Notepad++ relays this message to found plugin and it does nothing more
// CommunicationInfo::info and CommunicationInfo::internalMsg are the protocol between (or among) plugins
// return value is TRUE when the message arrive to the destination plugins.
// if srcModuleName or info is NULL, then return value is FALSE
struct CommunicationInfo {
long internalMsg;
const TCHAR * srcModuleName;
void * info; // defined by plugin
}
Don
Hey Don and plugin developers;
I was just curious if anyone had come up with a naming convention for inter-plugin msgs? I know that it is completely up to the individual plugin yet I thought I'd ask anyhow.
I was thinking NPPP_MSG_ prefix... any opinions?
almostautomated
After taking a closer look at the N++ msg setup and noting that N++ is using WM_USER message blocks up to and including WM_USER+8000 it may be worthwhile to go with a message base of NPPP_MSG = ( NPPMSG + 10000 ) and then individual plugins could use blocks like ( NPPP_MSG + 100 ).
If there is a reason to not go this route please let me know.
Thanks.
almostautomated
Bah! Wish I could edit that...
I had also wondered about msg numbering for inter-plugin msgs, perhaps NPPMSG + 1000 ?
Hi Don,
After looking over the latest revisions I see why you reserved margin 3. :)
Looks like we have similar lines of thought on how to do this. That's cool. How much control are you thinking about giving to the user over the marker? Similar to bookmarks with a show/hide per view, or also line coloring if margin is hidden. I'd be interested in hearing your thoughts on that kind of stuff...
The plugin route that I'm taking is pretty user control motivated. ie. Target margin, show/hide, line background, and I was even considering giving the user the ability to define an external xpm via an xml config in the same GUIConfig format your already using...
almostautomated
> How much control are you thinking about giving to the user over the marker?
> Similar to bookmarks with a show/hide per view, or also line coloring if margin is hidden.
> I'd be interested in hearing your thoughts on that kind of stuff...
Which margin are you talking about?
If you are talking about modification state margin, user can only show/hide this margin.
> The plugin route that I'm taking is pretty user control motivated. ie.
> Target margin, show/hide, line background, and I was even considering giving the user
> the ability to define an external xpm via an xml config in the same GUIConfig format your
> already using...
That's fine. What purpose is your plugin for?
Don
Line Change markers...
It's the one I started working on prior to finding out you where working on an implementation...
Line Change: Saved
Line Change: Not Saved
Both values read into N++ via a GUIConfig node in the plugins xml to show in the global params, and the plugin menu items for:
Jump: Prev Change
Jump: Next Change
----
Display: With Line Number // These four are checkmark items when none
Display: With Bookmarks // are checked the changes are still tracked but
Display: In plugin margin // this is no indicator until the user wants them.
Display: As line highlight
----
Disable Change Tracking // Clears the change history and doesn't process modification notifications.
// it also disables the other six menu items.
I've had to side track this plugin to create the plugin to check for available markers, which caused me to create a Plugin Interface Library (which is almost ready for posting a release announcement).
almostautomated
Current state of line change markers feature contains only saved change and unsaved change markers. User can only hide/show the margin but cannot change the markers. Jumping is a good feature, only if saved and unsaved change state are well restored in undo/redo actions - unfortunately it's not the case of current state of implementation.
What is the current state of your plugin? Could you send it to me to see how far you have gone?
Don
You bet I'll send it over, give me a day or two to wrap up a few items on it and the NppPluginIface lib though. Hopefully it will be worth it. ;)
BTW Don,
What do you think of implementing the change that Neil suggests for determining if a marker is used as outlined in post 9 of http://groups.google.com/group/scintilla-interest/browse_frm/thread/dc5c815eb26b4664?hl=en&tvc=1
All it would really require from the app is to add those items and a routine to set markers 0-15 to SC_MARK_AVAILABLE when a view is created.
If not, that's OK; I've implemented something similar to what is outlined in post 4 as part of a plugin that can be used by other plugins.
almostautomated
What is this SC_MARK_AVAILABLE for?
Don
The SC_MARK_AVAILABLE would be a new marker type ( marker type 28 ), which the Scintilla container app would apply to whatever markers it wanted to make available to plugins. Then with the SCI_MARKERSYMBOL the plugin would would have a message that would return a marker's type, and the plugin could iterate through the markers looking for available ones that it could use.
You've defined that 0-15 are available to plugins, yet how does a plugin know which ones are already in use by another plugin? Earlier you mentioned they could communicate via the CommunicationInfo struct, so I ran with that idea and created a plugin that accesses the Scintilla Editor and returns the type, if the type of the marker is at a default state it returns SC_MARK_AVAILABLE.
As a side note: I also added a function to the 'Notepad++ Plugin Interface Lib' (to be announced for release at the same time as the Change Marker plugin) that will iterate through both views looking for ones that are available until it has found the number of line markers that the plugin requested and sends back a marker array that the plugin can use to define it's markers.
Sorry I haven't gotten that code over to you yet; I spent a good day and a half in VS configuration hell, but now have SVN setup to track these projects and very simplified new project setup using propsheets ( which will be included with the lib).
Cheers! :)
almostautomated
I've just noticed that if you use the Compare plugin to compare 2 files, the lines with differences are marked as changed, in yellow, and when you clear the Compare results, the yellow markers stay, though N++ correctly recognizes the file as unchanged (tab is grey and not red).
Fabio;
Could you please try with the latest verion of N++ as well as with the latest Compare plugin. This issue was known to happen with the older version of Compare but should have been fixed.
Thanks
Hi Thell, thanks for your reply. Unfortunately, I am already using the latest versions of both N++ and the Compare plugin: N++ is 5.4.3 Unicode, Compare plugin is version 1.5.3. I can reproduce it very easily; if it can help I can attach screenshots.
Fabio,
Yes it would be greatly helpful to post a couple of screenshots for that, unfortunately SF forums don't allow images, so perhaps photo-bucket or some such? Also, I'm not sure if you have notified the new Compare plugin maintaner on the Notepad++ Plugins project forums yet or not, but that would also be helpful.
Thanks,
almostautomated