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
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
>
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
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)
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
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
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
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…
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