Revision: 1889 http://geany.svn.sourceforge.net/geany/?rev=1889&view=rev Author: ntrel Date: 2007-09-19 04:18:43 -0700 (Wed, 19 Sep 2007)
Log Message: ----------- Reformat text width with fmt. Add comment about running Glade 2.10 uninstalled.
Modified Paths: -------------- trunk/HACKING
Modified: trunk/HACKING =================================================================== --- trunk/HACKING 2007-09-18 16:04:22 UTC (rev 1888) +++ trunk/HACKING 2007-09-19 11:18:43 UTC (rev 1889) @@ -1,14 +1,17 @@ About this file --------------- -This file contains information for anyone wanting to work on the Geany codebase. -You should be aware of the open source licenses used - see the README file or the documentation. +This file contains information for anyone wanting to work on the Geany +codebase. You should be aware of the open source licenses used - see +the README file or the documentation.
Patches ------- -We are happy to receive patches, but it's best to check with us by email or mailing list whether a -new feature is appropriate, and whether someone is already working on similar code. +We are happy to receive patches, but it's best to check with us by email +or mailing list whether a new feature is appropriate, and whether someone +is already working on similar code.
-In general it's best to work from the current SVN, but we accept patches against other releases. +In general it's best to work from the current SVN, but we accept patches +against other releases. $ svn diff > fix-some-bug.patch
If you're not using SVN, you can use the diff command: @@ -27,51 +30,62 @@
Glade ----- -Use the code generation features of Glade instead of editing interface.c or support.c. -Glade 2.10 is recommended as long as we support GTK+ 2.6, because later versions of Glade are not -100% compatible with GTK+ 2.6 (e.g. they may use functions added in GTK+ 2.8). +Use the code generation features of Glade instead of editing interface.c +or support.c. Glade 2.10 is recommended as long as we support GTK+ 2.6, +because later versions of Glade are not 100% compatible with GTK+ 2.6 +(e.g. they may use functions added in GTK+ 2.8).
+You can build Glade 2.10 and run the binary in place, without installing +it - this should work fine even if you have another version of Glade +installed on the system. + Coding ------ Use static functions where possible. -Try to use GLib types and functions - e.g. g_free instead of free and try to use only GLib 2.6 and -GTK 2.6 functions. At least for the moment, we want to keep the minimum requirement for GTK at 2.6. -We currently try to support the old GCC 2.9.x compiler, so we always declare variables before -statements. You can use -Wdeclaration-after-statement in your ./configure CFLAGS to warn about -this. +Try to use GLib types and functions - e.g. g_free instead of free and +try to use only GLib 2.6 and GTK 2.6 functions. At least for the moment, +we want to keep the minimum requirement for GTK at 2.6. We currently try +to support the old GCC 2.9.x compiler, so we always declare variables +before statements. You can use -Wdeclaration-after-statement in your +./configure CFLAGS to warn about this.
Style ----- We use a tab width of 4 and indent completely with tabs not spaces. -To comment small blocks of code we use the C++ // comments and for functions descriptions or longer -explanations of code, the multiline comment /* */ should be used. In any case, the more comments -are in your code the better. -Lines should not be longer than about 100 characters and after 100 characters the lines should be -wrapped and more indented than the first line to highlight that the line is continued. -We avoid putting spaces between function names and the opening brace for argument lists. -Try to fit in with the existing code brace indenting style, comments, operator spacing etc. It's -not required but it makes our lives easier ;-) +To comment small blocks of code we use the C++ // comments and for +functions descriptions or longer explanations of code, the multiline +comment /* */ should be used. In any case, the more comments are in your +code the better. +Lines should not be longer than about 100 characters and after 100 +characters the lines should be wrapped and more indented than the first +line to highlight that the line is continued. We avoid putting spaces +between function names and the opening brace for argument lists. Try to +fit in with the existing code brace indenting style, comments, operator +spacing etc. It's not required but it makes our lives easier ;-)
Libraries --------- -We prefer to use an unmodified version of Scintilla - any changes should be passed on to the -maintainers at http://scintilla.org. -Tagmanager was originally taken from Anjuta 1.2.2, and parts of it (notably c.c) have been merged -from later versions of Anjuta. The independent Tagmanager library itself ceased development before -Geany was started. It's source code parsing is mostly taken from Exuberant Ctags (see -http://ctags.sf.net). +We prefer to use an unmodified version of Scintilla - any changes should +be passed on to the maintainers at http://scintilla.org.
+Tagmanager was originally taken from Anjuta 1.2.2, and parts of it +(notably c.c) have been merged from later versions of Anjuta and +CTags. The independent Tagmanager library itself ceased development +before Geany was started. It's source code parsing is mostly taken from +Exuberant CTags (see http://ctags.sf.net).
+ NOTES ===== -Some of these notes below are brief (or maybe incomplete) - please contact -the mailing list for more information. +Some of these notes below are brief (or maybe incomplete) - please +contact the mailing list for more information.
Modifying data types -------------------- -When reordering or changing existing elements of structs that are used as part of the -plugin API, you should increment abi_version in plugindata.h (and api_version if changing -elements). This is not needed if you're just appending fields to structs. +When reordering or changing existing elements of structs that are used as +part of the plugin API, you should increment abi_version in plugindata.h +(and api_version if changing elements). This is not needed if you're +just appending fields to structs.
Adding a file foo.[hc] in src/ or plugins/ ------------------------------------------ @@ -81,58 +95,66 @@
Adding a filetype ----------------- -You can add a filetype without syntax highlighting or tag parsing, but check to see if those -features have been written in other projects first. +You can add a filetype without syntax highlighting or tag parsing, but +check to see if those features have been written in other projects first.
-For syntax highlighting, it may be possible to use an existing Scintilla lexer in the scintilla/ -subdirectory - if not, you will need to find (or write) one, LexFoo.cxx. Try the Scintilla project -first. Remember to update scintilla/Makefile.am and scintilla/makefile.win32. +For syntax highlighting, it may be possible to use an existing Scintilla +lexer in the scintilla/ subdirectory - if not, you will need to find +(or write) one, LexFoo.cxx. Try the Scintilla project first. Remember +to update scintilla/Makefile.am and scintilla/makefile.win32.
-For tag parsing (e.g. for the symbol list), see 'Adding a TagManager parser' below. +For tag parsing (e.g. for the symbol list), see 'Adding a TagManager +parser' below.
Add GEANY_FILETYPES_FOO to filetypes.h. Initialize GEANY_FILETYPES_FOO in filetypes_init_types() of filetypes.c. -The filetype::style_func_ptr is a callback for setting up styling information. The callback, -styleset_foo(), should be added in highlighting.c. The first time it is called, the configuration -should be loaded in styleset_foo_init(). For more details, see styleset_c(). If there isn't a -Scintilla lexer, use styleset_none(). +The filetype::style_func_ptr is a callback for setting up styling +information. The callback, styleset_foo(), should be added in +highlighting.c. The first time it is called, the configuration should +be loaded in styleset_foo_init(). For more details, see styleset_c(). If +there isn't a Scintilla lexer, use styleset_none(). Rebuild Geany. From your geany/ directory, run: src/geany --generate-data-files
-(The src/ prefix may be different, depending on where the binary is generated.) -This will update data/filetype_extensions.conf. Note that you need GEANY_DEBUG to be defined when -building Geany for the --generate-data-files argument to work - this is always defined in the SVN -version. Alternatively, edit the file by hand. +(The src/ prefix may be different, depending on where the binary is +generated.) +This will update data/filetype_extensions.conf. Note that +you need GEANY_DEBUG to be defined when building Geany for the +--generate-data-files argument to work - this is always defined in the +SVN version. Alternatively, edit the file by hand.
-Most languages will also need a data/filetypes.foo configuration file. See data/filetypes.c -for an example. For languages with a Scintilla lexer, there should be a [styling] section, to -correspond to the styles used in styleset_foo(). +Most languages will also need a data/filetypes.foo configuration file. See +data/filetypes.c for an example. For languages with a Scintilla lexer, +there should be a [styling] section, to correspond to the styles used +in styleset_foo().
Programming languages should have: [keywords] if the lexer supports it. [settings] mostly for comment settings. [build_settings] for commands to run.
-Error message parsing is done in msgwin_parse_compiler_error_line() of msgwindow.c. See the -ParseData typedef for more information. (In future this may be done with a regex). +Error message parsing is done in msgwin_parse_compiler_error_line() of +msgwindow.c. See the ParseData typedef for more information. (In future +this may be done with a regex).
-For brace indentation, see lexer_has_braces() in editor.c; other indentation is done from -on_new_line_added(). +For brace indentation, see lexer_has_braces() in editor.c; other +indentation is done from on_new_line_added().
-If the lexer has comment styles, you should add them in is_comment() in editor.c. For now, -this prevents calltips and autocompletion when typing in a comment. +If the lexer has comment styles, you should add them in is_comment() +in editor.c. For now, this prevents calltips and autocompletion when +typing in a comment.
-If the Scintilla lexer supports user type keywords (e.g. SCLEX_CPP), see -editor_lexer_get_type_keyword_idx() in editor.c. +If the Scintilla lexer supports user type keywords (e.g. SCLEX_CPP), +see editor_lexer_get_type_keyword_idx() in editor.c.
Adding a TagManager parser -------------------------- This assumes the Geany filetype already exists.
-First write or find a CTags compatible parser, foo.c. Note that there are -some language patches for CTags at: +First write or find a CTags compatible parser, foo.c. Note that there +are some language patches for CTags at: http://sf.net/projects/ctags - see the tracker.
(You can also try the Anjuta project's tagmanager codebase.) @@ -162,8 +184,8 @@ Loading a plugin from GDB ------------------------- This is useful so you can load plugins without installing them first. -Alternatively you can use a symlink in ~/.geany/plugins or $prefix/lib/geany (where -$prefix is /usr/local by default). +Alternatively you can use a symlink in ~/.geany/plugins or +$prefix/lib/geany (where $prefix is /usr/local by default).
The gdb session below was run from the toplevel Geany source directory. Start normally with e.g. "gdb src/geany".
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.