On Wed, 14 May 2008 08:46:49 -0700 eht16@users.sourceforge.net wrote:
Revision: 2581 http://geany.svn.sourceforge.net/geany/?rev=2581&view=rev Author: eht16 Date: 2008-05-14 08:46:48 -0700 (Wed, 14 May 2008)
Log Message:
Add new function document_set_indicator_on_line() for future use. Add some functions to the plugin API for the upcoming spell check plugin.
Hmm, maybe those indicator functions should be moved to editor.c - it seems to me that the current API document functions are strongly document related, like opening files or setting encoding of files. Indicators might fit better as editor functionality. What do you think?
Regards, Nick
On Wed, 14 May 2008 17:37:02 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 14 May 2008 08:46:49 -0700 eht16@users.sourceforge.net wrote:
Revision: 2581 http://geany.svn.sourceforge.net/geany/?rev=2581&view=rev Author: eht16 Date: 2008-05-14 08:46:48 -0700 (Wed, 14 May 2008)
Log Message:
Add new function document_set_indicator_on_line() for future use. Add some functions to the plugin API for the upcoming spell check plugin.
Hmm, maybe those indicator functions should be moved to editor.c - it seems to me that the current API document functions are strongly document related, like opening files or setting encoding of files. Indicators might fit better as editor functionality. What do you think?
Nothing much against it. Maybe there are some more candidates to move like document_strip_trailing_spaces(), document_replace_tabs(), document_get_eol_mode()?
Regards, Enrico
On Wed, 14 May 2008 18:55:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 14 May 2008 17:37:02 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hmm, maybe those indicator functions should be moved to editor.c - it seems to me that the current API document functions are strongly document related, like opening files or setting encoding of files. Indicators might fit better as editor functionality. What do you think?
Nothing much against it. Maybe there are some more candidates to move like document_strip_trailing_spaces(), document_replace_tabs(), document_get_eol_mode()?
Yes, I think these would probably fit better in editor.c. But the indicator functions are most important because they're now in the API.
Regards, Nick
On Wed, 14 May 2008 18:20:55 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 14 May 2008 18:55:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 14 May 2008 17:37:02 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hmm, maybe those indicator functions should be moved to editor.c - it seems to me that the current API document functions are strongly document related, like opening files or setting encoding of files. Indicators might fit better as editor functionality. What do you think?
Nothing much against it. Maybe there are some more candidates to move like document_strip_trailing_spaces(), document_replace_tabs(), document_get_eol_mode()?
Yes, I think these would probably fit better in editor.c. But the indicator functions are most important because they're now in the API.
Ok, I moved the indicator functions into editor.c, the other functions follow tomorrow. I didn't increase the API version because I already did a few hours ago ;-).
Regards, Enrico
On Wed, 14 May 2008 20:00:53 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 14 May 2008 18:20:55 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Wed, 14 May 2008 18:55:19 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 14 May 2008 17:37:02 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Hmm, maybe those indicator functions should be moved to editor.c - it seems to me that the current API document functions are strongly document related, like opening files or setting encoding of files. Indicators might fit better as editor functionality. What do you think?
Nothing much against it. Maybe there are some more candidates to move like document_strip_trailing_spaces(), document_replace_tabs (), document_get_eol_mode()?
Yes, I think these would probably fit better in editor.c. But the indicator functions are most important because they're now in the API.
Ok, I moved the indicator functions into editor.c, the other functions follow tomorrow.
The following functions have been moved from document.c into editor.c: document_set_font() document_get_eol_mode() document_fold_all() document_unfold_all() document_replace_tabs() document_strip_line_trailing_spaces() document_strip_trailing_spaces() document_ensure_final_newline() document_insert_colour() document_set_use_tabs() document_set_line_wrapping()
I skipped the document_colourise functions although they would also fit in editor.c but then delay_colourise had to be public to functions in both files. If anyone disagrees, just move it and make delay_colourise avaiable to both ;-).
Regards, Enrico
On Thu, 15 May 2008 15:43:18 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Ok, I moved the indicator functions into editor.c, the other functions follow tomorrow.
The following functions have been moved from document.c into editor.c: document_set_font() document_get_eol_mode() document_fold_all() document_unfold_all() document_replace_tabs() document_strip_line_trailing_spaces() document_strip_trailing_spaces() document_ensure_final_newline() document_insert_colour() document_set_use_tabs() document_set_line_wrapping()
Great ;-)
I skipped the document_colourise functions although they would also fit in editor.c but then delay_colourise had to be public to functions in both files. If anyone disagrees, just move it and make delay_colourise avaiable to both ;-).
I think the colourise functions can stay in document.c because they are necessary when opening multiple files - they are closely related to the document_open_file() function.
ATM I'm working on spliting up GeanyPrefs into individual types, probably I'll commit it tomorrow.
Regards, Nick
On Thu, 15 May 2008 19:06:35 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
ATM I'm working on spliting up GeanyPrefs into individual types, probably I'll commit it tomorrow.
Ah cool.
Maybe this is a good timing to also change some struct names. While we are at breaking plugin ABI, we could rename document into GeanyDocument, just for consistency.
Regards, Enrico
On Thu, 15 May 2008 21:02:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 15 May 2008 19:06:35 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
ATM I'm working on spliting up GeanyPrefs into individual types, probably I'll commit it tomorrow.
Ah cool.
Maybe this is a good timing to also change some struct names. While we are at breaking plugin ABI, we could rename document into GeanyDocument, just for consistency.
Yes, I think all typedefs that are used in the plugin API could have the Geany prefix - this might also make it easier to know whether something is in the API or not.
There are 2 other types that I can split up: * GeanyFunctions could be moved out of GeanyData so we can add struct pointers without breaking the ABI * GeanyWidgets could be moved out of GeanyApp so we can add any application-related settings whilst keeping the main widgets grouped together.
For the first one I can update the plugin macros so probably plugins won't fail to compile. For the second, plugins will have to be updated as probably every one uses app->window.
Regards, Nick
On Fri, 16 May 2008 12:33:36 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 15 May 2008 21:02:44 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 15 May 2008 19:06:35 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
ATM I'm working on spliting up GeanyPrefs into individual types, probably I'll commit it tomorrow.
Ah cool.
Maybe this is a good timing to also change some struct names. While we are at breaking plugin ABI, we could rename document into GeanyDocument, just for consistency.
Done and also for filetype -> GeanyFiletype.
Yes, I think all typedefs that are used in the plugin API could have the Geany prefix - this might also make it easier to know whether something is in the API or not.
There are 2 other types that I can split up:
- GeanyFunctions could be moved out of GeanyData so we can add struct
pointers without breaking the ABI
- GeanyWidgets could be moved out of GeanyApp so we can add any
application-related settings whilst keeping the main widgets grouped together.
Yeah.
Regards, Enrico