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 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
Now that the geany-plugins has been converted to Git, I thought I'd post
this patch that adds the feature I've been working on (wrapping text with
characters) to the Addons plugin. Any chance of it being added?
And I've never really used Git before too, so please let me know if the
patch is incorrectly made or something.
I'm experiencing a bug where the project properties dialog is empty
when opened for the second time. Steps to reproduce:
1. Open project properties dialog.
2. Close it.
3. Open it for the second time.
Result: the project properties dialog is much smaller and it's empty.
I suspect it's related to the GtkBuiler transition. I haven't looked
into it because I guess Matthew knows better what might be wrong.
Unfortunately I didn't heard back of developer of
geany-mini-script-plugin so today I like to ask you whether somebody
likes to take over maintenance for geany-mini-script plugin inside
geany-plugins-svn. It's untouched since maybe 2009 and to be honest I
have no idea, what's the current status. Also I'm not 100% whether its
still a useful plugin or maybe some other plugin is taking over the
task in a better way. Personally I remember it as a possible useful
plugin but don't have the resources to look after and used it >>1 year
for the last time.
If nobody is feeling responsible I suggest, similar to previous plugins,
we remove it from official repository.
right now, we use the stock email commit hook from Github and let it
send commit mails to the geany-commits mailing list.
However, compared to the old Subversion commit mails, they are quite
First, they are not really commit mails but rather "push" mails, that
is all commits which are transmitted within one push are combined into
one mail instead of one mail per commit as it was previously.
Secondly, the commit mails only include the commit message and a link
to the commit diff at Github. I personally would prefer to have the
diff included (also as before).
So, I'm tempted to use something else for sending out commit mails.
For example, the Xfce guys have a simple Shell script to do the job and
it does it as I would wish:
An example mail:
What do you think?
Get my GPG key from http://www.uvena.de/pub.asc
Is anyone opposed to me committing the trivial patch attached here. The
comment I think describes it well enough, and if you're using recent
GTK+ 2.24.x you probably already know about it.
I didn't want to commit without asking since maybe some people will find
this new "feature" useful, I personally find it extremely
annoying, but I wouldn't want to fix it at the expense of annoying others.
 I think we can safely assume Geany users (ie. programmers) already
know how to manage files :)
Seasons greetings to all.
New year new idea.
Since Gnome seems to have irretrievably broken X session management it
does not seem likely that proper session management will be solved in
the near term. Sadly this seems to waste all the good work that the
guys put into the SM branch, thanks for the effort.
I am going to suggest an interim change to Geany that will at least
mean that it will re-start with the same main settings and
preferences. Actually two options.
1. Although I have argued against it in the past, having all settings
save on change would at least ensure that a Geany killed by logout or
shutdown will still restart with preference/session changes intact, or
2. add a user action to save preferences/session.
My problems with 1. are the performance impact of writing the session
file list every time a file is opened, closed or tabs re-ordered and
the risk of corruption that that increase in file activity causes
(especially with multiple instances).
My problem with 2. is I will forget to do it.
Perhaps a mixed solution of preferences always saved, but session only
when the user asks is the way to go.
Any thoughts and suggestions?