Devel August 2011

devel@lists.geany.org

16 participants
37 discussions

Me, Geany and the future
by Enrico Tröger 13 Aug '11

13 Aug '11

Hey guys, as you certainly noticed, I didn't do any development nor replying mails regarding Geany. This is mostly because I tend to spend my spare time on other things (more offline activities and such). While this is good for me (:D), it sucks for the project and its further development. So? I'd like to find a new project maintainer who keeps the development going on, coordinate the project with the community, reviews patches, makes releases and so on. The first candidate is of course Colomban if he wants. Though, I don't mind much who wants to continue the project. The only thing I wish is that it is continued with the original spirit in mind: keeping Geany itself quite small, fast and simple as it has been in the past years. We don't need to clone Eclipse :D. It's just that I don't want to hinder Geany's development any longer by my absence as it was in the past months. I talked to Nick before and he feels the same way basically. Any volunteers for this should now raise their voice! I personally won't be completely away, just won't read each thread on the mailing list anymore nor do I plan to participate any big code design discussions. What I want to do is to commit small changes from time to time and to continue maintaining my plugin SpellCheck. If anyone wants to adopt the Addons plugin, I'd be happy. If not, I'd continue maintaining it as well. Also, I will continue administrating geany.org and the related things (the main website, the wiki, nightly.geany.org, irc.geany.org and such things). About the further progress: I want to finish (some content is still missing) and announce the already set up Wiki (wiki.geany.org) and ideally make a Geany 0.21 release soon together with the new project maintainer :). I'm afraid especially for the Windows builds some assistance is necessary as before, I always made the Windows builds on my own and never documented what's necessary and how this is done (shame on me). Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

7 17

Re: [Geany-devel] RFC: uninitialized variable in theoretical execution path.
by Daniel Marjamäki 07 Aug '11

07 Aug '11

Hi! >> I wrote a simple Cppcheck plugin that searches for "uninitialized >> variable" in "theoretical execution paths". It will assume that all >> conditions can always be both true/false. > Interesting, can it be found somewhere? I plan to make it available online. But it's not ready yet. It should at least handle switch and va_start first. Right now it contains many bailouts to reduce noise. And I just wrote "FIXME" as comments. I at least plan to fix those before I make it available online. Thanks a lot for reviewing those reports. Sorry about the trouble - I was hoping there would be more genuine problems. Best regards, Daniel

1 0

either uninitialized variable or a redundant condition
by Daniel Marjamäki 06 Aug '11

06 Aug '11

Hi! [src/tools.c:127]: (information) Suspecting that uninitialized variable is used: stock_id Either there is an "uninitialized variable" issue or else there is a redundant condition. In the file src/tools.c. The condition that might be redundant is on line 111: else if (g_shell_parse_argv(cmd, &argc, &argv, &err)) If the condition is always true, then the "else if" could be converted to a "else" and the function call could be moved into the "else" body. If the condition can be false then stock_id will be uninitialized when it's used on line 127. Best regards, Daniel

2 1

RFC: uninitialized variable in theoretical execution path.
by Daniel Marjamäki 06 Aug '11

06 Aug '11

Hi! I wonder what you think about fixing "uninitialized variable" issues for theoretical execution paths. What I mean with "theoretical" is that it is not assumed that parameters and global variables are restricted to the "possible" values - they could also have "impossible values". An example: An uninitialized variable "y" can theoretically be used in src/printing.c at line 753. Here is the code in shortened format: 514 gdouble x, y; 561 while (count < dinfo->lines_per_page) { 686 cairo_get_current_point(cr, &x, &y); } 742 if (printing_prefs.print_line_numbers) { 752 cairo_line_to(cr, (dinfo->max_line_number_margin * dinfo->font_width) + 1, y + dinfo->line_height); /* y is last added line, we reuse it */ } The variable "y" is initialized in the loop. If the loop is skipped the variable will not be initialized. Therefore if dinfo->lines_per_page is 0 and printing_prefs.print_line_numbers is true then there will be a "uninitialized variable" issue. I guess there is an assumption that dinfo->lines_per_page will always be greater than 0. Perhaps that assumption is ok. Best regards, Daniel PS. I wrote a simple Cppcheck plugin that searches for "uninitialized variable" in "theoretical execution paths". It will assume that all conditions can always be both true/false. I assume that most of the reports are false positives. But if you are interested.. here is what it says for geany/src: [src/dialogs.c:257]: (information) Suspecting that uninitialized variable is used: iter_parent [src/dialogs.c:684]: (information) Suspecting that uninitialized variable is used: resp [src/dialogs.c:740]: (information) Suspecting that uninitialized variable is used: title [src/dialogs.c:774]: (information) Suspecting that uninitialized variable is used: args [src/dialogs.c:1663]: (information) Suspecting that uninitialized variable is used: args [src/dialogs.c:1686]: (information) Suspecting that uninitialized variable is used: args [src/dialogs.c:1713]: (information) Suspecting that uninitialized variable is used: args [src/editor.c:2852]: (information) Suspecting that uninitialized variable is used: style_comment [src/editor.c:4890]: (information) Suspecting that uninitialized variable is used: mode [src/encodings.c:643]: (information) Suspecting that uninitialized variable is used: charset [src/filetypes.c:854]: (information) Suspecting that uninitialized variable is used: args [src/filetypes.c:1395]: (information) Suspecting that uninitialized variable is used: result [src/keybindings.c:1543]: (information) Suspecting that uninitialized variable is used: item [src/log.c:68]: (information) Suspecting that uninitialized variable is used: args [src/msgwindow.c:269]: (information) Suspecting that uninitialized variable is used: args [src/msgwindow.c:341]: (information) Suspecting that uninitialized variable is used: args [src/msgwindow.c:399]: (information) Suspecting that uninitialized variable is used: args [src/printing.c:753]: (information) Suspecting that uninitialized variable is used: y [src/socket.c:685]: (information) Suspecting that uninitialized variable is used: newline [src/stash.c:767]: (information) Suspecting that uninitialized variable is used: args [src/stash.c:1057]: (information) Suspecting that uninitialized variable is used: setting [src/symbols.c:205]: (information) Suspecting that uninitialized variable is used: tag_type [src/symbols.c:636]: (information) Suspecting that uninitialized variable is used: args [src/symbols.c:1917]: (information) Suspecting that uninitialized variable is used: fn_style [src/templates.c:577]: (information) Suspecting that uninitialized variable is used: args [src/tools.c:127]: (information) Suspecting that uninitialized variable is used: stock_id [src/ui_utils.c:148]: (information) Suspecting that uninitialized variable is used: args [src/ui_utils.c:885]: (information) Suspecting that uninitialized variable is used: widget_name [src/ui_utils.c:1842]: (information) Suspecting that uninitialized variable is used: args [src/ui_utils.c:2365]: (information) Suspecting that uninitialized variable is used: a [src/utils.c:1365]: (information) Suspecting that uninitialized variable is used: a [src/utils.c:2090]: (information) Suspecting that uninitialized variable is used: args [src/win32.c:713]: (information) Suspecting that uninitialized variable is used: t [src/win32.c:705]: (information) Suspecting that uninitialized variable is used: title There could be a real issue in one of those reports but I don't know how likely that is. I am in the process right now to analyse the results. If I see genuine problems I'll report them.

2 1

Keybindings for GeanyPy
by Matthew Brush 06 Aug '11

06 Aug '11

Hi, I'm seeking ideas/advice for how I can implement keybindings for Python plugins[1]. Since `geany_plugin` will be the same for all Python plugins, I don't think I could use the regular way. I wouldn't want every Python plugin's keybindings showing up under the same 'GeanyPy' group. I tried with a gtk.AccelGroup() on the geany.main_widgets.window from Python/PyGTK, but Geany seems to block most keybindings doing it that way. I really don't know much about this either. I'm at the design state right now, so if anyone has any ideas for how I should implement this, using either Geany's plugin API, PyGTK directly, or something else I don't know about, I'd much appreciate hearing them. I'm kinda at a loss here. [1] https://github.com/codebrainz/geanypy Cheers, Matthew Brush

3 17

Groovy Syntax Highlighting
by Daniel Horz 04 Aug '11

04 Aug '11

Hello and Good Morning Geany Folks! I’ve just now subscribed to this list and this is my first mail, so please be kind :) At the moment I am working on a little Groovy project, so I thought it would be nice to have syntax highlighting for that in geany. I read http://www.geany.org/manual/index.html#filetype-definition-files and hacked away. The attached tar ball is the first result, i thought you might have a use for it. `groovy/filetypes.groovy.diff` is a diff from `filetypes.java`. Linking `groovy/filetypes.groovy` as `groovy/filetypes.Groovy.conf` into `~/.config/geany/filedefs/` works fine for me, so it should be usable. Oh and @dmaphy pointed out that scintilla might aready have a groovy lexer. According to https://code.google.com/p/scintillua/wiki/LexerList they do, might be easier to just include that ;) Over and out, Daniel Horz

2 2

Re: [Geany-devel] SF.net SVN: geany:[5875] trunk/src
by Matthew Brush 01 Aug '11

01 Aug '11

On 07/31/11 06:35, colombanw(a)users.sourceforge.net wrote: > Revision: 5875 > http://geany.svn.sourceforge.net/geany/?rev=5875&view=rev > Author: colombanw > Date: 2011-07-31 13:35:43 +0000 (Sun, 31 Jul 2011) > > Log Message: > ----------- > Add missing documentation for GeanyInterfacePrefs and GeanyToolPrefs > Just a few more that seem to be missing: GeanyEditorPrefs GeanyFilePrefs GeanyBuildInfo GeanyFilePrefs GeanyEditorPrefs There's probably more, I will report as I sift through the API docs writing the Python bindings. Cheers, Matthew Brush

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel August 2011