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,
It's one month since I initially sent this, and the main developers
seem more or less online now, so I'm resending it.
--
On several occasions, we discussed that it would be a good thing to
save the find/replace settings. So I wrote it.
Note that when you check "regular expressions", Geany remembers the
"case sensitive" state, and restores it when regex is unchecked. This
remembered state is not saved, so after restart, you'll get "regular
expressions" and "case sensitive" as you see them.
This remembered state was partially wrong, shared between the Find and
Replace dialogs (their settings are separate), so I created separate
states. Truth to be said, I can't grasp why regex and case are bound
like that.
BTW, is there any reason to stash_group_display(fif_prefs) each time
the FiF dialog is shown, instead of doing it once on dialog creation?
The fif settings won't change between invokations.
--
E-gards: Jimmy
Hi folks,
And again it happen to me that Geany did crash due some issue with a
plugin which might not have been tested very well before checking in
/committing.
However, I don't want to point with my finger to any developer so I'm
asking how we could improve overall quality of plugins inside release as
well as on trunk.
Failures I was recognizing in past did start with simple case/data type
warnings on compile time up to segfaults caused by not correct
initialized pointers as well a number of memory leaks. I know its not
possible to write 100% clean code as well as I'm aware of my code isn't
very well too. But I really like to change something here.
So my 1st suggestion is to remove all plugins which do have known issues
and don't compile with some -W-flags (needs to be defined) from common
build until these are fixed. Also remove plugins which don't bring
propper documentation as well are unmaintained for some time.
As a first shoot this could be from my point of view
- Updatechecker (crash on Windows build)
- GeanyLUA (lot of warnings on compiling time)
- Pretty Printer (lot of warnings on compiling time)
- GeanyGDB (nearly unmaintained)
- GeanyVC (de facto unmaintained)
- WebHelper (Crash mentioned on SF)
Unfortunately this is not a complete list. So maybe we could just remove
every plugin and just start to create a white list.
Ideally (from my point of view) we could set up some kind of review
process but I'm afraid it will not possible due lag of resources -
somebody needs to read and understand the code. Also we might could work
with tests for typical things - somebody only have to code them. I just
don't see any big alternatives at the moment.
What do you think about?
Thanks,
Frank
Hi all,
I'm writing a plugin which integrates Devhelp documentation browser into
Geany (similar to Anjuta). The code is currently on my github site:
https://github.com/codebrainz/geany-devhelp
It's working quite well as is, but I can think of some more things to
improve it. It kinda mangles Geany's notebook layout a fair bit and I'm
not sure what the repercussions of this are (if any) although I'm fairly
satisfied with the results.
It also adds a menu item on the editor's context menu to look up the
current symbol/tag in the built-in devhelp, which is a nice feature
(thanks to b4n for suggesting this on IRC).
Obviously it requires having the Devhelp libraries installed as well as
WebKit GTK.
If anyone has any feedback (especially opinions about the way it lays
out the UI), I would very much appreciate hearing it. If you don't want
to install it, there's a screen shot in the repository:
https://github.com/codebrainz/geany-devhelp/raw/master/geany-devhelp.png
Thanks for your time,
Matthew Brush (codebrainz)
Hi!
I create this new thread because the original one was not really about
this, so please read that thread for some details, particularly my
previous mail:
http://lists.uvena.de/pipermail/geany-devel/2010-November/003567.html
Although I know it's probably not the best time for such huge changes
(Christmas and release coming soon, ...), but now's the news, now's the
mail :)
So, now the interesting stuff.
As you (might) already know, I've got the tagmanager to work in memory,
opening a little more the way to real-time symbols updating. For
convenience, I join the patch here (can be found in the previous thread)
as 0001-First-tagmanager-move-to-MIO-I-O.patch.
>From here, the next step is to use the in-memory capabilities and
reparse in (almost-)real-time. Here comes two more patches:
1) 0002-Enable-in-memory-tag-parsing.patch which is really tiny and
enables in-memory tag parsing
2) 0003-Update-tag-list-on-IDLE-time-right-after-any-documen.patch which
updates the tag list on IDLE time after any change in the document. This
patch is not really good (allowing a timeout and a user setting would be
probably a good idea), but it is here mostly for being able to test.
So with these on, you can test the in-memory tag parsing, and notice
that... it updates in real-time, yes, but the symbol list flickers a
lot, and it's very annoying. So here comes 5 (!) more patches:
1) 0004-Improve-implementation-of-hide_empty_rows-to-do-all-.patch: this
one is not needed, simply improves the implementation of
hide_empty_rows() -- note that it may be applied alone too;
2) 0005-Make-TMTag-reference-counted.patch and...
3) ...0006-Provide-a-GType-for-TMTag-and-use-it.patch: these two makes
TMTags reference-counted and add a GType for them, allowing the tree tag
store to keep a reference to them, so they never become invalid. I
needed it for the implementation of the last patch, read ahead;
4) 0007-Don-t-remove-and-add-the-symbols-tree-view-if-we-re-.patch: this
ones avoids removing and re-addind the tag view upon update if the final
state is the same as the original one, avoiding a part of the
flickering. Note that it applies alone as well;
5) and finally,
0008-Update-the-symbol-list-rather-than-clearing-and-re-b.patch: this is
the huge part of the thing: it re-implements tag store updating to avoid
clearing and re-filling the list, rather updating the rows when
possible. Apart avoiding flickering, this also keeps user's selection
and folding :)
As you might read at the top of the patch, this implementation is
probably not the better possible, but avoids lot of refactoring in a
code I'm not sure to understand perfectly well (add_tree_tag()) -- note
that I suggest another implementation in the patch's comment, and I have
a working sample (but not with the symbol list...) if somebody's interested.
About this patch, there is a question (as a FIXME in the patch): why did
you detached the tag store from the tag view before updating it? Was it
for performance reasons or what? I dropped this since it (obviously) led
to flickering, and it seems to work well, but I'm wondering.
Well! If you apply all these patches, you should have a working,
real-time, in-memory tag parsing that should look good :)
So, what's left? Testing of course, lot of it.
Also, for now it doesn't update tag list before the first save (for new
documents). I've not investigating the issue yet though.
So I'll stop here, thank you for your time reading and let you test
this, right? :)
Regards,
Colomban
PS: for the inpatients of you, I included a patch
(0000-In-memory-tag-parsing-all-together.patch) that combines all the 8
patches together.
Dear Geany devs,
Some time ago I received the attached patch though this list (from
Enrico?). I really love the added functionality to prevent duplicate
automatically added quotes and brackets.
Can this be added to Geany itself? Ideally this would be activated
with a checkbox in prefs > editor > completions.
-tnx!-
Harold
Hello all:
I'm working on a database query plugin written in Vala and have a couple
of questions regarding the general process of working with the geany
community.
First, when is the right time to request that my plugin be added to the
geany-plugins repo? My general principle as a developer has always been
to start using VC from the start, but maybe you don't want half finished
plugins in your repo.
Second, is there anyone interested in assisting me in working on this?
I'm fairly new to GTK/Vala, but not to programming. I've got the plugin
loading up a new window, connecting to a database and executing queries,
and very nearly displaying the data, but I've got a lot of questions
that I don't have the answers to, such as:
* What's the best way to make this plugin connect to different
databases? Right now it's working with postgresql only
* What's the best way to store the database config? Ideally I'd want the
option to store the connection information in the project data.
Thanks for your time.
--
--
Mike Thorn, Web Developer
