Hi, I'm writing a simple plugin for geany (which I will call LiveDiff) which allows for having indicators inside the editor for changed/added/modified lines, which is updated as you type. The base for comparing the buffer can be either the version of the file on disk or (which I will soon attempt to add) the latest version from the git repository, if the file is versioned so. This resembles what netbeans does (one something I really liked). So far it works OK but there are some quirks. I'm doing this out of spare time so dont expect a pretty serious commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my plugin needs to define RGBA markers (which are used to indicate the diff results per-line). What it is not really clear to me is that there appears to be one ScintillaObject associated with each GeanyDocument. However, some messages sent to the ScintillaObject (like changing the margin or defining markers) appear to be global across all instances (unless I'm mistaken). Is this so? What would be the proper handling? Is it ok to repeat the definition of the markers for each editor?
Moreover, I'm not sure how to handle correctly the size of the RGBA markers since it depends on the font size of the editor. I tried to set the marker scale using the text_height to image height ratio, but the marker still appears to be a bit taller than the line and this creates some visual artifacts.
Best, Matias
Hi Matias,
Le 07/10/2013 12:27, v01d a écrit :
Hi, I'm writing a simple plugin for geany (which I will call LiveDiff) which allows for having indicators inside the editor for changed/added/modified lines, which is updated as you type. The base for comparing the buffer can be either the version of the file on disk or (which I will soon attempt to add) the latest version from the git repository, if the file is versioned so.
Sounds neat! I wanted to add such thing to a Git plugin I started, but I never took the time to continue it :/
This resembles what netbeans does (one something I really liked). So far it works OK but there are some quirks. I'm doing this out of spare time so dont expect a pretty serious commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my plugin needs to define RGBA markers (which are used to indicate the diff results per-line). What it is not really clear to me is that there appears to be one ScintillaObject associated with each GeanyDocument. However, some messages sent to the ScintillaObject (like changing the margin or defining markers) appear to be global across all instances (unless I'm mistaken). Is this so?
No it's not, each ScintillaObject only represents one editing component and fires event for it. I can't think of any reason why it could be wrong, unless we have a serious bug somewhere, but that's very unlikely since it'd break more than just your plugin ^^
What would be the proper handling? Is it ok to repeat the definition of the markers for each editor?
Yes, since each editor have a separate marker handling (since it's a separate ScintillaObject), you have to re-define the markers for each document.
Moreover, I'm not sure how to handle correctly the size of the RGBA markers since it depends on the font size of the editor. I tried to set the marker scale using the text_height to image height ratio, but the marker still appears to be a bit taller than the line and this creates some visual artifacts.
I'm not quite sure right now without any testing, but couldn't you end up with a fractional value that gets wrongly rounded or something? Sorry, I'm not so familiar with markers. BTW, couldn't you use one of the builtin markers instead of an image? Like a green SC_MARK_PLUS and a yellow SC_MARK_FULLRECT or something? If this is ok for you it would save you from having to bother image definition, loading, scaling, whatever.
Regards, Colomban
Hi, thanks for the response.
Yes, since each editor have a separate marker handling (since it's a
separate ScintillaObject), you have to re-define the markers for each document.
Ok, great. Then I programmed it correctly =)
I'm not quite sure right now without any testing, but couldn't you end
up with a fractional value that gets wrongly rounded or something? Sorry, I'm not so familiar with markers.
It is possible, I will look into cropping the image on run-time somehow.
BTW, couldn't you use one of the builtin markers instead of an image?
Like a green SC_MARK_PLUS and a yellow SC_MARK_FULLRECT or something? If this is ok for you it would save you from having to bother image definition, loading, scaling, whatever.
I would be glad to use Scintilla's symbols but I have two problems: a) I have only plus or minus (which makes sense) but couldn't decide which was a good symbol for modified lines. This is a matter of aesthetics anyway. Currently I'm using simply a block of solid color using for each (red, yellow and green). However... b) The tricky part is that there are no lines which are marked as deleted because, well, there are gone. So the "deleted" marker should actually go between lines. Netbeans puts an arrow-shaped marker pointing in between lines. So I emulated this as you can see in the attachment, but it doesn't look really pretty and has these issues. Since Scintilla only lets me add markers to lines (and not in between) I resorted into creating a fourth type of marker named "deleted-modified", which is used whenever the current line is modified and previous lines were deleted (see picture).
I will use these for now (unless someone suggests a simpler/better solution) and continue into git integration.
Best, Matías
Regards, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Not sure if this will help you, but I wrote a plugin to highlight anything selected and a search string using separate highlighting from the other searches and AddOn plugin. It sounds like you are putting markers in the margin, but this code may be useful to look at if you wanted to mark the changes inline (such as using green to indicate added code). You'll notice the gints I use for the indicators must be unused by geany for other highlighting.
Github - Quicksearch https://github.com/sblatnick/geany-plugins/blob/quick-search/quick-search/src/quick-search.c
Thanks,
Steve
On 10/07/2013 06:54 AM, v01d wrote:
Hi, thanks for the response.
Yes, since each editor have a separate marker handling (since it's a separate ScintillaObject), you have to re-define the markers for each document.Ok, great. Then I programmed it correctly =)
I'm not quite sure right now without any testing, but couldn't you end up with a fractional value that gets wrongly rounded or something? Sorry, I'm not so familiar with markers.It is possible, I will look into cropping the image on run-time somehow.
BTW, couldn't you use one of the builtin markers instead of an image? Like a green SC_MARK_PLUS and a yellow SC_MARK_FULLRECT or something? If this is ok for you it would save you from having to bother image definition, loading, scaling, whatever.I would be glad to use Scintilla's symbols but I have two problems: a) I have only plus or minus (which makes sense) but couldn't decide which was a good symbol for modified lines. This is a matter of aesthetics anyway. Currently I'm using simply a block of solid color using for each (red, yellow and green). However... b) The tricky part is that there are no lines which are marked as deleted because, well, there are gone. So the "deleted" marker should actually go between lines. Netbeans puts an arrow-shaped marker pointing in between lines. So I emulated this as you can see in the attachment, but it doesn't look really pretty and has these issues. Since Scintilla only lets me add markers to lines (and not in between) I resorted into creating a fourth type of marker named "deleted-modified", which is used whenever the current line is modified and previous lines were deleted (see picture).
I will use these for now (unless someone suggests a simpler/better solution) and continue into git integration.
Best, Matías
Regards, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 07.10.2013 12:27, schrieb v01d:
Hi, I'm writing a simple plugin for geany (which I will call LiveDiff) which allows for having indicators inside the editor for changed/added/modified lines, which is updated as you type. The base for comparing the buffer can be either the version of the file on disk or (which I will soon attempt to add) the latest version from the git repository, if the file is versioned so. This resembles what netbeans does (one something I really liked). So far it works OK but there are some quirks. I'm doing this out of spare time so dont expect a pretty serious commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my plugin needs to define RGBA markers (which are used to indicate the diff results per-line). What it is not really clear to me is that there appears to be one ScintillaObject associated with each GeanyDocument. However, some messages sent to the ScintillaObject (like changing the margin or defining markers) appear to be global across all instances (unless I'm mistaken). Is this so? What would be the proper handling? Is it ok to repeat the definition of the markers for each editor?
Moreover, I'm not sure how to handle correctly the size of the RGBA markers since it depends on the font size of the editor. I tried to set the marker scale using the text_height to image height ratio, but the marker still appears to be a bit taller than the line and this creates some visual artifacts.
Hello,
[1] might be of interest for you. It does something very similar.
Regarding your other question, are you talking about the "editor-notify" signal? Yes, that's not really per-document, I came across this recently. The solution is to connect to "sci-notify" of ScintillaObject directly, this will give a proper per-document signal (the document-specific ScintillaObject pointer). However you need to get the GeanyDocument pointer elsewhere. See how I did it here[2].
Some might consider this as a defect in Geany.
[1]: http://lists.geany.org/pipermail/devel/2010-June/002584.html [2]: https://github.com/kugel-/geany-plugins/commit/7f19c3035abf6f8a7fa66c7b4c1ef...
Best regards.
Am 07.10.2013 21:53, schrieb Thomas Martitz:
Am 07.10.2013 12:27, schrieb v01d:
Hi, I'm writing a simple plugin for geany (which I will call LiveDiff) which allows for having indicators inside the editor for changed/added/modified lines, which is updated as you type. The base for comparing the buffer can be either the version of the file on disk or (which I will soon attempt to add) the latest version from the git repository, if the file is versioned so. This resembles what netbeans does (one something I really liked). So far it works OK but there are some quirks. I'm doing this out of spare time so dont expect a pretty serious commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my plugin needs to define RGBA markers (which are used to indicate the diff results per-line). What it is not really clear to me is that there appears to be one ScintillaObject associated with each GeanyDocument. However, some messages sent to the ScintillaObject (like changing the margin or defining markers) appear to be global across all instances (unless I'm mistaken). Is this so? What would be the proper handling? Is it ok to repeat the definition of the markers for each editor?
Moreover, I'm not sure how to handle correctly the size of the RGBA markers since it depends on the font size of the editor. I tried to set the marker scale using the text_height to image height ratio, but the marker still appears to be a bit taller than the line and this creates some visual artifacts.
Hello,
[1] might be of interest for you. It does something very similar.
Regarding your other question, are you talking about the "editor-notify" signal? Yes, that's not really per-document, I came across this recently. The solution is to connect to "sci-notify" of ScintillaObject directly, this will give a proper per-document signal (the document-specific ScintillaObject pointer). However you need to get the GeanyDocument pointer elsewhere. See how I did it here[2].
Some might consider this as a defect in Geany.
I need to correct myself. "editor-notify" is correctly per-document and you can get the GeanyDocument pointer via the GeanyEditor pointer passed to it. What I meant to say is that you cannot use "editor-notify" if you need to attach user_data on a per-document basis. The user_data pointer passed to plugin_signal_connect("editor-notify", ...) will be overwritten on each successive all. My suggested workaround works for this case. With sci-notify you can attach user_data on a per-document basis.
Best regards.
Le 07/10/2013 22:06, Thomas Martitz a écrit :
Am 07.10.2013 21:53, schrieb Thomas Martitz:
[...]
Regarding your other question, are you talking about the "editor-notify" signal? Yes, that's not really per-document, I came across this recently. The solution is to connect to "sci-notify" of ScintillaObject directly, this will give a proper per-document signal (the document-specific ScintillaObject pointer). However you need to get the GeanyDocument pointer elsewhere. See how I did it here[2].
[...]
I need to correct myself. "editor-notify" is correctly per-document and you can get the GeanyDocument pointer via the GeanyEditor pointer passed to it. What I meant to say is that you cannot use "editor-notify" if you need to attach user_data on a per-document basis. The user_data pointer passed to plugin_signal_connect("editor-notify", ...) will be overwritten on each successive all.
It's not perfectly right either, if you connect to the "editor-notify" signal several times, each callback will be called (I believe in reverse registration order) until one returns TRUE. So the behavior you describe is probably simply you connecting several time and your callback always returning TRUE, preventing the previously registered callbacks to fire up.
Anyway, it's indeed not the right signal if you need per-document user_data, but it's fine if you don't need it since it will fire for any document without the need to manually connect to each. It probably depends on your specific needs, and it's indeed worth noting the difference.
Also note that the "sci-notify" signal is valid on ScintillaObjects, while "editor-notify" is on the global GeanyObject (which is the one used if you pass NULL as the object to plugin_signal_connect()).
Regards, Colomban
On 13-10-07 01:06 PM, Thomas Martitz wrote:
Am 07.10.2013 21:53, schrieb Thomas Martitz:
Am 07.10.2013 12:27, schrieb v01d:
Hi, I'm writing a simple plugin for geany (which I will call LiveDiff) which allows for having indicators inside the editor for changed/added/modified lines, which is updated as you type. The base for comparing the buffer can be either the version of the file on disk or (which I will soon attempt to add) the latest version from the git repository, if the file is versioned so. This resembles what netbeans does (one something I really liked). So far it works OK but there are some quirks. I'm doing this out of spare time so dont expect a pretty serious commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my plugin needs to define RGBA markers (which are used to indicate the diff results per-line). What it is not really clear to me is that there appears to be one ScintillaObject associated with each GeanyDocument. However, some messages sent to the ScintillaObject (like changing the margin or defining markers) appear to be global across all instances (unless I'm mistaken). Is this so? What would be the proper handling? Is it ok to repeat the definition of the markers for each editor?
Moreover, I'm not sure how to handle correctly the size of the RGBA markers since it depends on the font size of the editor. I tried to set the marker scale using the text_height to image height ratio, but the marker still appears to be a bit taller than the line and this creates some visual artifacts.
Hello,
[1] might be of interest for you. It does something very similar.
Regarding your other question, are you talking about the "editor-notify" signal? Yes, that's not really per-document, I came across this recently. The solution is to connect to "sci-notify" of ScintillaObject directly, this will give a proper per-document signal (the document-specific ScintillaObject pointer). However you need to get the GeanyDocument pointer elsewhere. See how I did it here[2].
Some might consider this as a defect in Geany.
I need to correct myself. "editor-notify" is correctly per-document and you can get the GeanyDocument pointer via the GeanyEditor pointer passed to it. What I meant to say is that you cannot use "editor-notify" if you need to attach user_data on a per-document basis. The user_data pointer passed to plugin_signal_connect("editor-notify", ...) will be overwritten on each successive all. My suggested workaround works for this case. With sci-notify you can attach user_data on a per-document basis.
As long as the Scintilla view doesn't switch document models, like some view recycling optimizations or split/multi view magic or something. I don't think anything actually does this at present, but it could in theory, without "breaking" the API, or it could even be done by another plugin.
Last time I needed to do this, I made a hash table that used g_direct_hash on the GeanyDocument pointer as the key, and the value was my custom/user data structure. Then I had a function that effectively did this:
void *document_get_context(GeanyDocument *doc) { return g_hash_table_lookup(global_hash, doc); }
Then to keep it sync, I used code like this:
http://pastebin.geany.org/Y1O3d/
Where the dm_*() calls are keeping the hash table consistent with the current set of documents. It's kind of a lot of boiler-plate to attach data to a document, but it seems to work quite well :)
Cheers, Matthew Brush
