I saw this code in src/symbols.c at line 1917:
while (sci_get_style_at(sci, start) != fn_style
&& start < max_pos) start++;
If start >= max_pos then sci_get_style_at will be called (with out of
bounds value?) and then the loop will bail out.
I suggest that the condition is reordered as:
while (start < max_pos
&& sci_get_style_at(sci, start) != fn_style)
Then sci_get_style_at will only be called if start is less than max_pos.
It is just my humble suggestion.
I'm sending my stack of patches against geany again, this time as individual patches. Here's the full list:
[PATCH 01/19] Prevent -Wmissing-prototypes report warning when compiling a plugin
[PATCH 02/19] Add signals for project options dialog opening and closing
[PATCH 03/19] Make the project menu accessible by plugins
[PATCH 04/19] Make it possible to change project patterns by plugins
[PATCH 05/19] Don't be annoying when not necessary
[PATCH 06/19] Make it possible for plugins to change the base directory of msgwindow
[PATCH 07/19] Open the file in the msgwindow even if no linenumber is specified
[PATCH 08/19] When closing tab, return to the document at the top of the MRU list
[PATCH 09/19] Use wider entry for project file path
[PATCH 10/19] New utils function to get relative path from one directory to another
[PATCH 11/19] File name in the project settings dialog shouldn't look it is editable
[PATCH 12/19] Use relative paths in the project files
[PATCH 13/19] Remove the "set" button from the project properties dialog
[PATCH 14/19] Rewrite tab switching queue
[PATCH 15/19] Do not insert --include= when the search pattern entry is empty
[PATCH 16/19] Use project patterns in the FIF dialog
[PATCH 17/19] Make the tab switching dialog a bit more useful
[PATCH 18/19] Use standard include paths for "open selected file"
[PATCH 19/19] Use per document indent sizes
Only some of them are required by gproject - others are just suggestions for improvements. I didn't explicitly distinguish between these two types of patches but it should be pretty clear from the description. There have been some minor changes since my last post - mainly the change of the FIF dialog to contain combo box for pattern selection and there are also some new patches - the detailed description is in the individual emails. Of course many of the patches are suggestions only so further discussion is welcome.
Dear Geany Devs,
I recently switched from GeanyPRJ to Gproject. Since Gproject doesn't
support multiple open projects I have to switch between projects, but
it takes up to 4 minutes to close one project and open another. A
project consists of roughly 1000-2000 php-related files.
The "Generate tags for all project files" causes this massive delay,
but I really need that feature.
At work I have a 2-core CPU, where 1 is completely idle and on my
desktop at home there are 5 cores are doing nothing while generating
tags. Can't they be utilized to speed up the tag generation?
I want to discuss shortly the expected behavior of
plugin_help()-function implemented by plugins. Inside API-documentation
> Called whenever the plugin should show its documentation (if any).
> This may open a dialog, a browser with a website or a local installed
> HTML help file(see utils_start_browser()) or something else. Can be
> omitted when not needed.
Well... which means its not really defined what the user will expect
once he push the button. Therefore we do have at least 2.5 major behaviors:
- Geany is calling a browser and opening a webpage with info (spellcheck
- Its opening a message window with
* a short info about plugin (e.g. geanyLaTeX)
* a long help text about plugin (e.g. geanymacro)
Question is, what do we really want to have behind that function?
I have several suggestions and questions about certain line operations
implemented in Geany.
1) Recently I found that "move lines up/down" command does not work
properly for the last line not ending with a newline. You can easily
check it yourself. Couple of minutes ago I made a pull request 
with an implementation of `editor.c:move_lines()` which handles the
problem. Dear unknown someone, please review and pull if it's okay.
2) I want to raise a question, do we need a "join lines" command? This
command would be a companion of the existing "reflow paragraph"
command, but in contrast with the latter, it would only join lines, but
not split them.
This command may be useful when, let's say, you have a document created
by someone else who sticks with line breaking and inserts \n at column
80. Suppose that you prefer using line wrapping instead and want to
remove those \n in a peace of a document which you're editing. The new
command would help you a bit.
Implementation of the new "join lines" command could use the bits of
code already written for "reflow paragraph" (though, those bits need to
be extracted/refactored first). Moreover, I already implemented it
and, if the new command seems useful to anyone, I can put my
implementation in a pull request.
3) Here there should have been a point about some bug reports we have
in Geany bug tracker, referring to "reflow paragraph" glitches. As
this message is already too long, I decided to designate a separate
message for that (later).
Thank you for reading :) Please write your thoughts about 1) and 2)
I saw that the SM-branch is merged with trunk on a regular basis, but
not sure what's the current status of that branch. Can someone help me
On Tue, Jan 3, 2012 at 13:44, Matthew Brush <mbrush(a)codebrainz.ca> wrote:
> I already ported all of the existing old-style color schemes to work with
> the new filedefs, see the geany-themes project on Github to get them.
> Some might need a little tweaking, but should for the most part be quite
> similar to the original ones.
Unfortunately, the 'dark' scheme needs some serious tweaking to make
it look like I'm used to (it's very brownish dull right now), but I
guess some well-placed copy/paste actions will solve that for me! ;)
Armed with a screenshot of the old scheme, dark.conf, an old
filetypes.* file and the documentation I'll try to recreate the old
While running geany-plugins tests, I hit two failures.
The first one is that cppcheck is not happy about Vala, and since
multiterm is fully in Vala, it fails.
The second one is that it couldn’t detect an assignment nested in an array.
Attached two simple patches to fix these.
Quentin "Sardem FF7" Glidic