Devel April 2011

devel@lists.geany.org

18 participants
47 discussions

Patches for review
by Jiří Techet 08 Oct '12

08 Oct '12

Hi, 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. Cheers, Jiri

8 68

Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
by Jiří Techet 07 Dec '11

07 Dec '11

On Thu, Sep 16, 2010 at 19:27, Thomas Martitz <thomas.martitz(a)student.htw-berlin.de> wrote: > On 16.09.2010 02:23, Lex Trotman wrote: >> >> Hi Jiri, >> >> I couldn't get this to work at all, it printed "calling indent this >> line" all the time but didn't indent :-( >> >> I only had half an hour so I couldn't investigate much. >> > > I have the same experience. Auto-indentation doesn't seem to work anymore > (e.g. when hitting enter after on a line that ends with {, or when typing > }). I have just re-tested it again and it works on my machine (I have forgotten one trace in the code - that's what you see in the console). A quick question: have you read the commit log? This patch makes it possible to specify several regex patterns for every filetype which determine under what condition the indentation is performed. The pattern variables are specified under the [settings] section of the given filetype and their value is the regex to be used. The variables are as follows: * indent_this_line_regex - the match is performed after every keystroke and if the regex matches, the indentation is performed on the current line * indent_next_line_regex - the match is performed only when enter is pressed. The indentation is applied on the next line * unindent_this_line_regex - like indent_this_line_regex but unindents instead * unindent_next_line_regex - like indent_next_line_regex but indents instead Comments and strings are detected from the lexer so these can be ignored inside the patterns. For instance these are very basic rules for GNU indent style: indent_next_line_regex=^.*\\{[[:blank:]]*$ unindent_this_line_regex=^[[:blank:]]*\\}$ indent_this_line_regex=^[[:blank:]]+\\{$ unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$ By commenting-out the last two lines you get ANSI indentation style. If you replace \\{ and \\} with begin and end, respectively, you get analogous rules for pascal. Notice the double-escaping of { and } - the first escape sequence is for the keyfile ini format (so for the regex itself \\ becomes \). This means that in order to make it work e.g. for C, you have to edit ~/.config/geany/filedefs/filetypes.c (or the corresponding file under /usr/local/share/geany) and add indent_next_line_regex=^.*\\{[[:blank:]]*$ unindent_this_line_regex=^[[:blank:]]*\\}$ indent_this_line_regex=^[[:blank:]]+\\{$ unindent_next_line_regex=^[[:blank:]]*\\}[[:blank:]]*$ under the [settings] section (+ restart geany). Please let me know if it works (but also in the opposite case ;-). Jiri > > Best regards. > _______________________________________________ > Geany-devel mailing list > Geany-devel(a)uvena.de > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >

6 35

Changed file saving implementation for systems with GIO
by Nick Treleaven 30 Jun '11

30 Jun '11

Hi list, To workaround bug(s) in GVFS, I've now changed the file saving implementation for systems with GIO in SVN trunk. See also: http://lists.uvena.de/geany-devel/2010-November/003412.html Please help test this. File permissions should be preserved after saving, and disk space exhaustion should now be handled without losing the previously saved file. Also, running geany --version (or -V) should now also show 'GIO' if your system has it and Geany knew about it at build time. Begin forwarded message: Date: Tue, 02 Nov 2010 17:42:54 +0000 From: ntrel(a)users.sourceforge.net To: geany-commits(a)uvena.de Subject: SF.net SVN: geany:[5361] trunk Revision: 5361 http://geany.svn.sourceforge.net/geany/?rev=5361&view=rev Author: ntrel Date: 2010-11-02 17:42:54 +0000 (Tue, 02 Nov 2010) Log Message: ----------- Use g_file_replace_contents() if available to save documents - this should help workaround bugs in GVFS. Needs testing. Nick

7 67

Vala Tags
by Matthew Brush 05 Jun '11

05 Jun '11

Hi, I generated tags for all of the Vala .vapi files on my system. If you want to add them to the contrib section, feel free. Maybe there should be a subdirectory for Vala tags since theres 135 different tag files. I put them up at: https://github.com/codebrainz/geany-vala-tags/tree/master/tags (To get them all at once, use the "Downloads" button) Also, should there be a set of default tags for Vala as there are for other languages (php, python, etc)? I've included a separate vala.tags that combines tags for vala-0.10 and glib-2.0, which could be included as a default. It is here: https://github.com/codebrainz/geany-vala-tags/raw/master/vala.tags Note: loading all 135 tags at once locks up Geany's UI for over 2 second on my computer :) Cheers, Matthew Brush (codebrainz)

4 4

Git Switch (again)
by Matthew Brush 11 May '11

11 May '11

Hi, I'd like to revive this thread[1]. I wasn't around during the initial thread but Jiri has just pointed me to it and I read it through. I'd like to summarize (at least my take) on that thread and then list some pros and cons to stimulate a discussion. Disclaimer: I am not an expert on anything, but I've used both Subversion (via SourceForge and Google Projects) and Git (via GitHub.com and Gitorious). Also, this is as much about not using SourceForge as it is about switching away from Subversion. Summary from previous thread: The people in the thread who do not want to switch to Git, or those who don't seem to care either way, are those who have commit access to Subversion on SourceForge. Most (if not all) contributors to Geany are using Git (via git-svn). The workflow for those who don't have commit access on the subversion repository, when contributing to Geany is sub-optimal (to put it politely). SourceForge is painfully slow and the interface for viewing SVN source code online isn't great. I think the reason GitHub/Gitorious is mentioned so much is not only because of the "Git" in their name, but also because it allows people who don't have commit access to actually be active members in the community, by means of having their public forked repositories, sending merge/pull requests, etc. Cons from the previous thread: - It's more social - Not plain enough (I guess too Web 2.0/feature-full/cluttered) - Effort required to move the project - Having to learn a new VCS for those not familiar with Git Pros from the thread: - It's more social - It's not so plain (ie. has more features which work well). - Moving the codebase and history is very easy, for example using the script from the thread or GitHub offers you to import a SVN repository through the web interface when creating a new repository. - Easier to contribute to the project for those without write access - Faster hosting and better interface. - Harder to have patches slip through the crack. - Not having to maintain/create patches as much/at all. - Public contributor repositories associated with the main one. - No need to maintain changelog and authors files - Proper attribution, blame and history for contributors and not having to put "Thanks" in all the commit messages. Not sure if I missed any, or misconstrued them. Here's some features of better project hosting sites. I'm listing things from GitHub because I know it better than Gitorious and others: - Great source code viewer, branch/file browser, history/commit viewer. - Ability to link to and comment on commits and even specific lines of a commit, for code review, etc. - Nice network graph viewer to get a better idea of what everyone else is working on, needs to be commited, etc[2]. - Tracker for pull/merge requests so no need for contributors to generate/maintain patch(sets) and keep bumping ML threads so their patches don't go forgotten. - Fork queue to compare other peoples repositories' commits against your repository to cherry pick specific commits, with an indication of whether or not the commit/patch will likely cleanly apply - Good issue/bug tracker - Built-in Wiki software - Nice graphs to show languages, impact, commit activity, etc - Web hooks to notify by email/ML, IRC and other services of commits, etc.[4] - No need to create nightly tarballs separately since the server takes care of this automatically when users clicks the Download link. Hopefully this will stir up a little discussion about actually switching because every time I use SourceForge I die a little inside :) I think switching to one of the Git project hosting sites will really help the community/contributors get involved and feel like part of the team while still making sure the official code is controlled by a great team of core developers. Obviously I'm not suggesting that the SourceForge project page is deleted, just switching the main development activity to elsewhere. We could have a git/svn mirror over at SourceForge still, and even keep their bug/feature tracker, though I can't see why, since it's pretty lousy. It really wouldn't be hard either, the whole "switch" be done in probably 10-15 minutes, maybe 1-2hrs to wait for the history to be imported. There's no real reason it needs to be a big deal either, we could test out another project site and keep it the way it currently is still with not much extra effort, just someone/somescript needs to push to the new project page after committing to SVN. Basically all it would take beyond that is for one of the founders/core members to take some time to setup an account and push the code. I already have a Geany repository[5] I use over at GitHub.com if you want to play with it to test out that site. Also, Jiri has an old repository[6] on Gitorious. Neither are exactly up to date. It's fun also to see the Geany hackery already happening on these sites[7][8]. Sorry again for the long message. Cheers, Matthew Brush [1] http://lists.uvena.de/geany-devel/2010-June/002602.html [2] https://github.com/blog/39-say-hello-to-the-network-graph-visualizer [3] https://github.com/blog/270-the-fork-queue [4] https://github.com/github/github-services [5] https://github.com/codebrainz/geany [6] http://gitorious.org/geany/complete [7] https://github.com/search?langOverride=&q=geany&repo=&start_value=1&type=Re… [8] http://gitorious.org/search?q=geany

7 32

hex mode
by Liviu Andronic 10 May '11

10 May '11

Hello Does Geany have a hex mode, that is can I open files in hex mode? And a bit more OT, Geany refuses to force-open a PDF file. Nano, for example, opens the PDF. Is it normal? Regards Liviu -- Do you know how to read? http://www.alienetworks.com/srtest.cfm http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader Do you know how to write? http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

7 11

GProject - missing Geany patches
by Jiří Techet 04 May '11

04 May '11

Hi, first sorry for disappearing for such a long time - I didn't have much free time left in the past months and from the time I had I dedicated most of it to the libchamplain library I maintain to make some bigger changes and adapt it to GTK 3 in time for Gnome 3. The good news is that I didn't convert to Eclipse or Emacs meanwhile ;-). There are still quite many patches I have against geany in my repository and I'd like to have at least part of them merged so I don't have to maintain my own geany branch. So at the moment the highest-priority patches for me are those which are necessary in order to make GProject working so it can become one of official geany plugins. The patches can be found at usual place: https://gitorious.org/~techy/geany/gproject-geany under the for_review4 branch. Only the first three of them are needed for GProject so they should have the highest priority when reviewing: 4774306b7f65237ef75b01e8d6c8312dcc5c526e Make project patterns visible 57b4120f94e611e8143fba89e397588de8693ec3 Use project patterns in the FIF dialog 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified More info about the patches is in the commit description. If there are some questions, please ask me. Also if you prefer the patches in the form of ordinary patches rather than git repo, just let me know. Cheers, Jiri

7 25

Colorschemes/geany-themes branch
by Matthew Brush 03 May '11

03 May '11

Hi, I started working on merging geany-themes project into the Geany tree, as well as a few "fixups" to the Colorschemes menu, some of which are same as patches sent to the mailing list some time ago. Mostly left is cleaning up themes that cause warnings on geany verbose output and to test the themes with more lexers. If you want to see the progress and/or test it out, the branch is here: https://github.com/codebrainz/geany/tree/colorscheme_fixup Cheers, Matthew Brush

3 3

Set Filetypes Menu
by Matthew Brush 03 May '11

03 May '11

Hi, I just noticed the change[1] in wording of the set filetypes menu which was something that had (slightly) bothered me before, since I personally consider most of the scripting languages as programming languages as well. I'm not sure that the word "Compiled" is the best choice though, since it's kind of vague: Is Vala a compiled language because it's compiled into C code? Is Python *not* compiled because it's compiled into bytecode? Is Java a compiled language? I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on. Unfortunately I don't really have much for alternative terms, but a few possibilities for better categorization could be: - By the current categories, but putting filetypes under each one they fit in. - By changing Scripting to Interpreted and then shuffling some filetypes around to reflect the way the languages are usually compiled/run. - By the current categories, no change, since users will get used to where to find their languages pretty quickly. - By Static vs Dynamic Typing - By programming language paradigm (ie. oop, functional, etc), and then each programming language could fall below more than one menu item if they are multi-paradigm. - By just Programming Languages, so that the Compiled and Scripting menus get merged. This could make the menu long/scroll. SciTE does this but with fewer languages. - By alphabetic order, with a menu item for each letter of the alphabet unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?). There's also a few other quirks I've noticed in the 'Set Filetypes' menus: - I generally wouldn't consider CSS a markup language, but it probably technically is. IMHO it would be more apt to put it under Miscellaneous. - I believe LaTex, Markdown, and reStructuredText are Markup Languages. - I don't know COBOL but I think it's a programming language isn't it? - NSIS and CMake files, while domain-specific, are still scripting/programming languages. - 'SQL Dump file' seems a bit odd, since it's a file containing language constructs and is "run" by the db engine, maybe it should be 'SQL file' or 'SQL source file'. I know a file containing SQL is often the result of dumping a database, but is it the only time you would end up with such a file? - The wording 'Miscellaneous Languages' makes you think the contents of the submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally. I could be wrong on these, they're just my observations. None of these are a big deal, but it was something I questioned probably even the first time I opened Geany and every time I select a filetype since. P.S. Sorry if this previously been discussed, I'm not too sure how to search the geany-devel archives (no link on geany.org Mailing List), and google didn't seem to find anything. Cheers, Matthew Brush [1] http://git.geany.org/geany/commit/?id=856ea318e65f1b5cb038f04b7cd68dfc219b6…

5 21

Color Schemes Menu Patches
by Matthew Brush 03 May '11

03 May '11

Hi, I have made some minor changes to the Color Schemes menu, I wanted to see if they look ok. One of my concerns is that maybe opening/reading each color scheme file like this might be "too slow", but it seems to only happen once, so I'm not sure whether it's significant. It "feels" fine when I use it with all of the geany-themes color schemes. I wasn't sure how to regenerate the other formats after editing doc/geany.txt so that is not done in these patches. Cheers, Matthew Brush

4 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel April 2011