Re: [Geany-devel] Commit messages on merges
On Mon, Feb 27, 2012 at 08:33, Matthew Brush mbr...@codebrainz.ca wrote: On 12-02-26 11:20 PM, Frank Lanitz wrote: Hi folks, Just something I thought on last merges based on Jiri's patches. Its hard to understand what this merges do just by reading the commit message. Given, that we want to create the ChangeLog based on git log it will be nearly impossible to create a good ChangeLog/Newsfile if we don't keep care. Not sure how, but can we be more verbose here? Do not show document change notification dialog when MRU switch is in progress When switching between MRU documents, Geany pops up a dialog about document change even for the intermediate non-final documents. This leads to both reload dialog and document switch dialog displayed at the same time and termination of document switching because the newly displayed dialog takes focus. This patch disables reload checks for the intermediate documents and forces reload check for the final document. Do not ignore system() return value to eliminate compiler warning Drop 'already' from the message in project close confirmation dialog Suppose you have project A open and want to open project B. Then the message saying The 'A' project is already open displays. This is slightly confusing and feels like if you were trying to re-open project A even though you are opening different project. The message without 'already' looks clearer in this context. Modify project dialog signals Rename project-dialog-create signal to project-dialog-open because now the dialog exists all the time and the signal name is misleading. Add project-dialog-close signal to indicate that project dialog has been closed and plugins can remove their tabs when needed. In addition, bump plugin API and ABI version. Just to give everyone who hasn't checked the commits an idea of the verbosity that those commit messages has. Is it too verbose? I was trying to add some more detailed info because from my experience even though the patch seems to be clear now, when looking at it one year later I often feel like what does the hell the patch do? and why did I write something like that?. But if it's the preferred way I can move the explanation into the merge comment on github. By the way, because the patches I submitted weren't related in any way, I think they could have been rebased on top of master instead of doing merge. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Tue, Feb 21, 2012 at 19:23, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Mon, 20 Feb 2012 22:40:50 +0100 Jiří Techet tec...@gmail.com wrote: On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Since you are changing the project signals anyway, can you do me a favor and add an unconditional project-before-save signal in write_config, with the same arguments as project-save? Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no before signal for the projects settings, and I need one for a plugin of mine. Hi Dimitar, what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file. To (a) temporarily revert some file settings before a possible save- session-files and (b) ignore emit_signal, since session save does not depend on it. Hi Dimitar, have a look at the attached patch - I've added the signal but as I don't know exactly when you need to emit it, you'll probably need to modify it. Also I haven't documented the signal as I still don't completely understand its purpose. Feel free to use this patch as a template for the modifications you need to do. Jiri project_before_save.patch Description: Binary data ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Hi, Jiří, On Mon, 20 Feb 2012 00:35:24 +0100 Jiří Techet tec...@gmail.com wrote: I've created new pull request with the changes here: https://github.com/geany/geany/pull/25 Since you are changing the project signals anyway, can you do me a favor and add an unconditional project-before-save signal in write_config, with the same arguments as project-save? Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no before signal for the projects settings, and I need one for a plugin of mine. Hi Dimitar, what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Sat, Jan 14, 2012 at 21:16, Jiří Techet tec...@gmail.com wrote:
On Fri, Jan 13, 2012 at 22:57, Lex Trotman ele...@gmail.com wrote:
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbr...@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add
the
project preferences dialog to GeanyMainWidgets structure, and just let
plugins use the response, hide and show signals on it as a normal
GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each
time
since the pointer in the main_widgets global would change all the time,
but
now it'll stay the same right from before `geany-startup-complete` all
the
way until after plugins are unloaded . We could even say with certainty
that
this API *won't ever* change, the project dialog in main_widgets would
*always* be a (subclass of) GtkDialog and so would only break if GTK+
broke
this.
But how much of the internal structure of the dialog are you going to
document?
Is Jiri expected to find the notebook widget within the dialog or will
it be passed some other way? If from the dialog it needs to be
documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to
add the dialog *and* the dialog's notebook to the main_widgets struct, like
we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have
to guarantee a name so it could be accessed through ui_lookup_widget() or do
the signals on the wrong object thing like is done for most signals (with
the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a
different preference.
I don't really care - both versions would work. But I too prefer using
So finally I had some free time to test and listening on the dialog
signals doesn't work as I need. The the code for displaying project
dialog in Geany looks like this:
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
{
if (update_config(e, FALSE))
{
Now when I connect to the dialog signals, they get emitted on the line
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
which means that in the signal handler I don't have access to the
updated config values from the dialog because these are updated
afterwards by
if (update_config(e, FALSE))
So if there aren't any objections, I'll go back to the implementation
I originally suggested and which emits the signal only after the
config has been successfully updated.
Cheers,
Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Sun, Feb 19, 2012 at 17:57, Jiří Techet tec...@gmail.com wrote:
On Sat, Jan 14, 2012 at 21:16, Jiří Techet tec...@gmail.com wrote:
On Fri, Jan 13, 2012 at 22:57, Lex Trotman ele...@gmail.com wrote:
On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbr...@codebrainz.ca wrote:
On 01/13/2012 03:31 AM, Lex Trotman wrote:
[...]
What if we deprecate the old project create/confirm API altogether, add
the
project preferences dialog to GeanyMainWidgets structure, and just let
plugins use the response, hide and show signals on it as a normal
GtkDialog?
Sounds fine to my limited understanding.
This wasn't possible before when the dialog was created/destroyed each
time
since the pointer in the main_widgets global would change all the time,
but
now it'll stay the same right from before `geany-startup-complete` all
the
way until after plugins are unloaded . We could even say with certainty
that
this API *won't ever* change, the project dialog in main_widgets would
*always* be a (subclass of) GtkDialog and so would only break if GTK+
broke
this.
But how much of the internal structure of the dialog are you going to
document?
Is Jiri expected to find the notebook widget within the dialog or will
it be passed some other way? If from the dialog it needs to be
documented (or at least its name does).
Yeah, I thought about this after I sent the last message. We would need to
add the dialog *and* the dialog's notebook to the main_widgets struct, like
we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have
to guarantee a name so it could be accessed through ui_lookup_widget() or
do
the signals on the wrong object thing like is done for most signals (with
the renames Jiri proposed).
Well I'd say the first or second, but Jiri or others may have a
different preference.
I don't really care - both versions would work. But I too prefer using
So finally I had some free time to test and listening on the dialog
signals doesn't work as I need. The the code for displaying project
dialog in Geany looks like this:
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
{
if (update_config(e, FALSE))
{
Now when I connect to the dialog signals, they get emitted on the line
while (gtk_dialog_run(GTK_DIALOG(e.dialog)) == GTK_RESPONSE_OK)
which means that in the signal handler I don't have access to the
updated config values from the dialog because these are updated
afterwards by
if (update_config(e, FALSE))
So if there aren't any objections, I'll go back to the implementation
I originally suggested and which emits the signal only after the
config has been successfully updated.
I've created new pull request with the changes here:
https://github.com/geany/geany/pull/25
If you are interested, these are the changes made to GProject:
https://github.com/techee/geany-plugins/compare/project_prefs_fix
Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Request: multithreaded tag generation?
On Tue, Jan 24, 2012 at 12:17, Lex Trotman ele...@gmail.com wrote: On Tue, Jan 24, 2012 at 9:56 PM, Harold Aling ge...@sait.nl wrote: On Tue, Jan 24, 2012 at 11:42, Jon Senior j...@restlesslemon.co.uk wrote: On Tue, 24 Jan 2012 11:35:40 +0100 Harold Aling ge...@sait.nl wrote: Just had a little time to check loading times with GeanyPRJ versus GProject. Starting Geany with 1 file open in a Drupal project with GProject enabled: 4 minutes and 1 second. Starting Geany with the same file with GeanyPRJ enabled: 23 seconds. Quitting Geany with an open Drupal project with GProject enabled: about 4 minutes. Quitting Geany with the same Drupal project with GeanyPRJ enabled: almost instant. The second time I opened the project with GProject, it only took 3 minutes, so it has some caching benefits. I'm reverting to GeanyPRJ! Too bad it causes a lag while typing, but that's way better than having to wait 4 minutes to start or quit Geany... Am I really that weird? Granted I'm using geanie's built-in project support (More like managed sessions), but I see a worst case for my use of about 45 seconds to load a series of files. I've set GProject to index all files in the project to be able to use ''Go to tag definition so it's the time to reindex all files and tags, not just opening them... But the thing is, my current session of geany has been open now for about 4 days. 4 minutes in that time frame is a drop in the ocean. How often do you open + close geany for a 4 minute start up to be more annoying than a continuous lag when typing? Well, I work on 1 to 4 Drupal projects per week and sometimes I have to bughunt on even more projects. Every switch will take 4 to 8 minutes, which is not very relaxing, especially if a collegue is standing here at my desk... I also like to shutdown my machine in the weekends to prevent me from logging in from home ;) There's an idea, but since I work from home the machine is right there, stalking me... What might be a better idea than re-generating 1000 files worth of symbols each time is to run offline tags file generation, hopefully loading those will be faster than re-parsing all the files. Maybe you can test it some time. And Geany will correct any errors in symbols for the files you have open and have changed. All we need to add is the ability to save this over the top of the old tags file when the source file is saved, so you continue to get right symbols with the file closed. This is something that will be much more likely to happen in the near future compared to threaded parsing, there are too many problems with data sharing with the GUI thread, as discussed several times on IRC in the past. Depends how much faster loading tags files is to see if its worth it. OK, there's a plugin called gctags which I've been using for almost two years now but haven't had time to polish it and make part of geany-plugins. I've uploaded the plugin here: https://github.com/techee/geany-gctags How it works: 1. You need to have ctags installed in your system 2. In project-properties you set the file patterns which should be scanned for tags 3. There's a new menu item Project-generate tags - it scans all the files satisfying the patterns and creates tags file with the same name as the project file but with the extension .tags 4. There's Project-Find tag menu item: it pops up a dialog where you can search for the tag (you can assign keybinding for this action). After hitting enter, all the tags which are found are printed to the Messages window. I use some space-based indentation so it's better to use monospace font for the Messages window. After clicking a tag, you get to the corresponding line/file. 5. Instead of (4) you can use the context menu which has two new entries - Find tag definition and Find tag declaration - these print the definition/declaration of the symbol under cursor immediately. The plugin doesn't do any smart reloading of tags - you have to do it manually from the menu. However in practice this has never been a problem for me - for recently used files you can use Geany's search in open files. When you find the tags are off or cannot be found, you can regenerate them manually - this is extremely FAST compared to what Geany needs for parsing (parsing is in apostrophes because it's not the parsing which is slow - it's some crazyness in the tag manager). I've been working on very large projects (2 millions LOC in C) and this has been working very well for me. I've always disabled the tag generation by Geany because it's way too slow for any bigger project. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Fri, Jan 13, 2012 at 22:57, Lex Trotman ele...@gmail.com wrote: On Sat, Jan 14, 2012 at 3:12 AM, Matthew Brush mbr...@codebrainz.ca wrote: On 01/13/2012 03:31 AM, Lex Trotman wrote: [...] What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the response, hide and show signals on it as a normal GtkDialog? Sounds fine to my limited understanding. This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this. But how much of the internal structure of the dialog are you going to document? Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does). Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the signals on the wrong object thing like is done for most signals (with the renames Jiri proposed). Well I'd say the first or second, but Jiri or others may have a different preference. I don't really care - both versions would work. But I too prefer using the existing GtkDialog signals instead of having custom signals for doing the same. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On Mon, Jan 9, 2012 at 01:05, Matthew Brush mbr...@codebrainz.ca wrote: On 12/26/2011 01:37 PM, Jiří Techet wrote: Hi, 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. I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f1e If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great. In general it seems to be fixed. However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Q: how to switch to new Git repo?
On Fri, Jan 6, 2012 at 18:00, Eugene Arshinov earshi...@gmail.com wrote: It seems that everything went fine. My personal fork is https://github.com/earshinov/geany/, and the new home for sm branch is https://github.com/earshinov/geany/tree/sm. Jiří, I suppose you can safely remove your sm-branch repository. Thank you for keeping it for so long! No problem, I've just removed it. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Empty project properties dialog
Hi, 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. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: git repo up and running
On Sun, Dec 18, 2011 at 19:01, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 12.12.2011 14:54, schrieb Frank Lanitz: Hi folks, Just I case you missed the news inside the threads: the new git repo for geany-plugins is online and can be found at https://github.com/geany/geany-plugins So, what is the policy for geany-plugins now? Can everybody push to the master repo as it was with svn, or did we switch to the pull-style where Frank would pull changes from the maintainers repos (changes in the common part or the plugin for a release)? I was wondering about the same myself. Apparently I have commit access so I can still push but I was wondering whether I should ever push or rather create a pull request. I believe a side-effect of having commit access is that I receive pull request notifications for geany-plugins by email which I'm not very interested in. Is there a way to remove email notifications per-project? (I want to keep pull request notifications for my own repositories) Can't find this option anywhere in GitHub... Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: git repo up and running
On Mon, Dec 12, 2011 at 14:54, Frank Lanitz fr...@frank.uvena.de wrote: Hi folks, Just I case you missed the news inside the threads: the new git repo for geany-plugins is online and can be found at https://github.com/geany/geany-plugins Hi Frank, it looks you have forgotten to push the 0.18 branch - you need to use git push --all origin to push all the branches. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins converted to git
On Thu, Dec 8, 2011 at 00:05, Colomban Wendling lists@herbesfolles.org wrote: Le 07/12/2011 22:54, Jiří Techet a écrit : Hi, I've completed the conversion of geany-plugins to git, the repository can be found here: https://github.com/techee/geany-plugins As with Geany's repository conversion, please have a look at it and don't use/fork it until more people check everything is alright and the repository is moved to its final location. 5bff19ecea993d9d2c3038efcfba63fecdc3342e and f3a667d624d31aec778e2ababeac96c25f6c5169 are the same commit, but it seems there was a tag created (r858), then removed (r861), and then crated again after a new commit (r863), so it's actually weird; not in the exact same way, but I don't thing it's a real problem. That's true. If you prefer, I've just created a new repository without the useless side-branch before 0.17.1 https://github.com/techee/geany-plugins2 Looks a bit nicer. You can use whichever repository you prefer. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Stop committing to geany-plugins SVN
Hi, I'm about to start the geany-plugins git conversion so please stop committing to the SVN repository. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] geany-plugins converted to git
Hi, I've completed the conversion of geany-plugins to git, the repository can be found here: https://github.com/techee/geany-plugins As with Geany's repository conversion, please have a look at it and don't use/fork it until more people check everything is alright and the repository is moved to its final location. I've also committed the repository I got from svn2git so you can easily compare what changes I have made. This repository is here: https://github.com/techee/geany-plugins-svn2git-unmodified Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 07:20, Lex Trotman ele...@gmail.com wrote: [...] First, note that I wasn't able to find the patch, so I'm only guessing from reading the thread and from my own (much less complete) attempt. I'm afraid that if I had the patch it is on my broken hard drive :-S And anyway we never got it to work satisfactorily. So. This looks pretty good for line-based indents (but not brace match :(), but I ran into a really annoying problem with SH: SH should indent after then, do, etc. and unindent fi, esac, etc. The problem is that you expect the fi line to be unindented (e.g. use unindent_this_line), but if you type file for example, it'd wrongly unindent that line too! I thought about unindenting the previous line when entering the \n, but this isn't a real solution either since re-adding a newline after a well indented line would unindent it again. Crap. So I haven't yet found a sensible solution for this problem -- which wouldn't apply for '}' since it's very unlikely it's part of a bigger word -- and would like to know it anybody got super clever ideas, or how other editors you know handle this. This said, I really like the idea of configurable indentation rules that could handle languages like SH, Pascal, Ruby, Ada, etc. without the need to hard-code it. WARNING, complex topic, big post :) Quick summary of ones I know: Emacs has language specific elisp, for C: It analyzes the line to determine its syntactic symbol(s) (the kind of language construct it's looking at) and its anchor position (the position earlier in the file that CC Mode will indent the line relative to). The anchor position might be the location of an opening brace in the previous line, for example. See Syntactic Analysis. It looks up the syntactic symbol(s) in the configuration to get the corresponding offset(s). The symbol +, which means “indent this line one more level” is a typical offset. CC Mode then applies these offset(s) to the anchor position, giving the indentation for the line. The different sorts of offsets are described in c-offsets-alist. And it admits that even then it gets it wrong sometimes :( Eclipse and Netbeans also use parser results for the indent guidance. I don't think parsing the source for indent guidance is in the Geany light and small spirit, so I reject that. Instead I propose the following correct most of the time but simple option based on a combination of Jiri's and Emacs' methods: 1. Each line N has an initial indentation which is the indentation of line N-1 plus the increments/decrements for all matches to indent next line regexes that occur in liine N-1. (Note that each regex has a signed count of columns to indent/exdent) Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line. Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer if block. If I insert new if inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the delta indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code. One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed. Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 08:27, Nathan Broadbent nathan@gmail.com wrote: 1. calculate the indent each change, and then ripple that through the file 2. calculate the indent each change and only apply it to this line 3. calculate and apply the indent to lines N and N-1 only on new line or user command 4. calculate and apply the indent on user command Option 1 is rejected because it is expensive and it will destroy manually adjusted indentation when editing an existing line and because indentation can change as you type causing distracting effects (happens with some Emacs indentation styles) Option 2 is rejected for the same reasons Option 4 is rejected because auto new line indent is really the minimum required to be called auto indentation So that leaves option 3. The upside is that new lines get a sensible indentation automatically, the downside is that lines that should be unindented won't be until enter or user command. I have used another editor that worked this way and after a while I became used to it. Note that editing an existing line won't destroy manual indentation unless you tell it to or create a new line after. Hello, Good auto-indentation is one of the last things I'm missing after my switch from Gedit to Geany. It was something that was handled really well by the 'Smart Indent' plugin. I would like to share a short video (1:24) of the indentation behavior that I grew accustomed to: http://vimeo.com/1890098 This style of auto-indentation requires Option 1 or 2 (calculate for each change), because it unindents the 'end', 'elsif' and 'else' keywords as soon as their last characters are pressed. I did find this behavior very useful, even though I admit that it would sometimes destroy my manual indentation. This is exactly what my regex-based indentation did and I assume what Colomban's experiment does too. The problem Colomban was trying to resolve was what to do when you have an end-block keyword fi which should unindent and then have an identifier file (notice the fi prefix) which shouldn't unindent. In this case there should be some undo indent when you add more letters after fi. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Dec 6, 2011 at 21:56, Lex Trotman ele...@gmail.com wrote: [...] Maybe I don't understand it correctly but does this mean that if you open an existing file, you'd re-indent it completely based on the regexes? I don't think this is a good idea because this could lead to whitespace change in every line when you edit just a single line. No, thats another reason why I rejected option 1 Or does it mean to have these indent numbers just internally and use them only when when auto-indentation is done? I often work with files edited by many people over many years which have inconsistent indents. Imagine the correct indent size is 4 but someone used just 2 indents in the outer if block. If I insert new if inside this block, the indent size will be 6 because of the incorrect outer indent. This is exactly why I used the delta indent solution to be locally correct and have minimal impact on (and be minimally affected by) the rest of the code. The algorithm will give 6 since it only considers the previous line and the line it is indenting which is the line with the cursor. One more thing - with global indents you have to be sure that the regexes catch all the indentation cases (without false positives) otherwise one error will affect the indentation everywhere in the rest of the file. You can do crazy stuff with some languages so I can imagine such a thing can happen easily (single line with end of multi-line comment followed by end block followed by another comment). With delta indentation it's much less critical - the indent may be incorrect for the next line but this won't affect the rest of the file in any negative way. Moreover, you usually don't do things like the comment example when you write the code and when you need auto-indentation; you usually add them afterwards when no autoindentation is needed. Final remark - better not to auto-indent at all than to indent incorrectly. There's nothing worse than an editor (actually anything) which tries to be smart in an annoying way. Don't worry there is no intention that auto-indentation does more than give a mostly right indent on new lines and mostly correct it when you type } on that new line. I did clearly say it should not change any manual indentation. Ah, sorry, after re-reading it again I think I misunderstood your algorithm originally so please forget what I said. What you propose sounds good. Basically the main difference is that you take the previous line indentation into account which is what my original algorithm didn't do. This really appears to solve all the problems in quite an elegant way (much nicer than the flags thing I suggested). Just a detail that strictly speaking the N-1 line should be previous non-empty line. I'm actually not completely against the immediate indent when typing (without having to press enter). Your algorithm is capable of indentation undo when the regex doesn't match any more. I think it's quite OK if fi unindents the line and subsequent letter returns it back. Something like that already happens with syntax highlighting where the keyword becomes blue when you type it but changes back to black when you add additional letters. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Mon, Dec 5, 2011 at 19:30, Colomban Wendling
lists@herbesfolles.org wrote:
Hi,
I know this is a more than one year old discussion, but I was messing
with a very similar thing a few minutes ago when wanting to add
autoindent support for SH.
Le 16/09/2010 22:17, Jiří Techet a écrit :
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
thomas.mart...@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 ;-).
First, note that I wasn't able to find the patch, so I'm only guessing
from reading the thread and from my own (much less complete) attempt.
It doesn't apply to current trunk anyway - I've discarded it because
it would need major update but more importantly, there was one
limitation I wanted to address.
The problem was that a single line could be indented several times
with single regular expression. Imagine a code like
if (foo)
{
if (bar)
{
baz();
}
}
Now imagine that you put cursor just behind the } following baz(); and
press backspace to delete it. Now if you press } at this position
again, it gets unindented again so you get
if (foo)
{
if (bar)
{
baz();
}
}
From the editors I tested, it seems they remember for which line
indentation was performed and don't perform it again. This means to
have some per-line flag which indicates this state (e.g.
NOT_INDENTABLE, INDENTABLE). When a file is loaded, all non-empty
lines would be marked as NOT_INDENTABLE and every empty line as
INDENTABLE (the newly created empty lines too). A line would stay in
INDENTABLE state even after you start typing some text. INDENTABLE
state would change to NOT_INDENTABLE under each of the following
conditions:
1. The line matches a regex - in this case is indented and shouldn't
be indented any more
2. The line is not empty, matches a regex and enter is pressed (you
have finished editing the line and don't want it to be indented when
you modify it later)
Now this approach requires some per-line data to be stored - is it
possible with Scintilla?
So. This looks pretty good for line-based indents (but not brace match
:(), but I ran into a really annoying problem with SH:
SH should indent after then, do, etc. and unindent fi, esac,
etc. The problem is that you expect the fi line to be unindented
(e.g. use unindent_this_line), but if you type file for example, it'd
wrongly unindent that line too!
I thought about unindenting the previous line when entering the \n, but
this isn't a real
Re: [Geany-devel] Request: multithreaded tag generation?
Hi Harold, On Mon, Nov 7, 2011 at 16:35, Harold Aling ge...@sait.nl wrote: 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. How much of this time is spent by opening the project and how much by closing? What time did the same take with granyprj? I think I have an explanation for longer project close times - geanyprj didn't properly remove the tags from the workspace and that's why the closing times were faster. If you don't mind that the tags aren't freed from the memory, you can comment-out lines 461 and 462 from gproject-project.c: if (g_prj-generate_tags) g_hash_table_foreach(g_prj-file_tag_table, (GHFunc)workspace_remove_tag, NULL); This should result in the same close times. If the open times are longer too with gproject, I'll have to investigate what's wrong. Now the interesting part about the tag manager is that from some number of files, removing file tags from the workspace takes longer than adding them. Without properly studying tag manager sources, I think I know what the reason is: it looks as if the hierarchy of tags was connected by pointers in one direction only so it is easy to find a particular tag but when you have a tag and you want to find which tags refer to this tag, you have to go through all the tags to find references to the particular tag. This is what happens when you want to remove a tag from the workspace because you need to delete all references to this tag. I have also experienced something like quadratic time complexity when generating tags for many files - the time needed to insert the tags definitely doesn't grow linearly with the number of files. This means that the problem isn't slow parsing of files by the ctags part of the tag manager but rather the creation of the hierarchy by the tag manager part. This also means that parsing the files in parallel won't help - it's the tag hierarchy creation which is slow for high number of files. And finding some fine-grained locking so more threads can create the hierarchy in parallel is a complete overkill. Having a good look at the tag manager, understanding the code and finding a way to avoid this quadratic time behavior (possibly by rewriting it completely) is something I'd really love to do (could be a lot of fun). The only problem is time right now (I might have more time in a few months but no promisses). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] sm-branch repository
On Thu, Nov 3, 2011 at 00:47, Lex Trotman ele...@gmail.com wrote: Hi Jiri, Your sm-branch repository referenced here http://article.gmane.org/gmane.editors.geany.devel/5576/match=sm+branch does not seem to contain any sm code? Hi Lex, it's under the sm branch of the repository - the rest is just ordinary Geany repository. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany Plugins SVN Commit URLs
On Thu, Nov 3, 2011 at 03:18, Matthew Brush mbr...@codebrainz.ca wrote: On 11/02/2011 08:17 AM, Jiří Techet wrote: On Tue, Nov 1, 2011 at 15:43, Matthew Brushmbr...@codebrainz.ca wrote: On 11-11-01 06:11 AM, Jiří Techet wrote: On Sun, Oct 30, 2011 at 23:25, Matthew Brushmbr...@codebrainz.ca wrote: On 11-10-30 03:03 PM, Frank Lanitz wrote: On Sun, 30 Oct 2011 02:15:33 -0700 Matthew Brushmbr...@codebrainz.ca wrote: Hi, I haven't heard too much about the Git conversion of Geany Plugins, but I wanted to offer a suggestion that might improve the commit messages compared to Geany's. In the Geany's Git repository there's links back to the SVN repository in the commit messages (the links are broken BTW). I was wondering if it would be better to have these links point to a place we have more control over, for example using a Geany commit, instead of this in the commit message: git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5970 ea778897-0a13-0410-b9d1-a72fbfd435f5 We could have something like this: git-svn-id: [ea778897-0a13-0410-b9d1-a72fbfd435f5] (http://svn.geany.org/svnroot/geany/trunk?rev=5970) That way we could make the links work and be able to move the old SVN repository without breaking all the links in the commit message. I guess we'd need a little redirect script or something on geany.org. Note also the use of Markdown link syntax, which might render better on Github (not sure). I'm afraid I don't get what is needed here? Did I got you right to setup complete mirror of ancient svn on geany.org? Or easier, just make some URL forwarders/rewrites on geany.org so we don't have to depend on SourceForge.net to always store the SVN repo and never change URLs. The SVN URLs in the Git commit messages will never be able to change ever in the future, so if we point it to a location we control, then we can ensure they remain valid. From Jiri's other message though, it sounds like the SVN URLs in the Git commit messages are all going to be broken like the one's in Geany's Git repository, since it's not an option of the conversion script to change them. I don't feel like hacking the conversion script to change the URL that goes in the commit message, and anyway, as long as it contains the SVN revision, it's still useful. Another option would be to use git filter-branch --msg-filter command where command would be some sed expression which would substitute the current format with the required format. Maybe a bit easier, still something I don't want to spend my time on ;-). The only reason I included the SVN metadata was the commit ID which is useful to have because some commits refer to it in their comments and this information would be lost otherwise. What about something as simple as: sed |git-svn-id: https://geany-plugins.svn.sourceforge.net/svnroot/geany-plugins/trunk/geany-plugins|SVN:| To at least remove the invalid URL, or better yet: sed |geany-plugins@|geany-plugins?revision=| Or similar, so that the URL is not broken? If it's easy enough, I'd say it's worthwhile. Hi Matthew, could you test if it does the right thing with git filter-branch? (I'm quite busy these days.) All on one line: git filter-branch --msg-filter sed -e 's|svnroot/geany-plugins/trunk/geany-plugins@|viewvc/geany-plugins\?view=revision\revision=|' HEAD Works fine at least looking at quite a few of the commits in gitk and has the advantage of linking to the better ViewVC code browser that SourceForge offers. OK, thanks. So is there any official conclusion which format should be used? (I don't have any strong preference here.) Also when should the final conversion be done? I fight with time a bit these days but the conversion of geany-plugins requires much less manual changes than the conversion of Geany's repository so I can reserve the hour or two for it (almost) any time. Just tell the date. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany Plugins SVN Commit URLs
On Tue, Nov 1, 2011 at 15:43, Matthew Brush mbr...@codebrainz.ca wrote: On 11-11-01 06:11 AM, Jiří Techet wrote: On Sun, Oct 30, 2011 at 23:25, Matthew Brushmbr...@codebrainz.ca wrote: On 11-10-30 03:03 PM, Frank Lanitz wrote: On Sun, 30 Oct 2011 02:15:33 -0700 Matthew Brushmbr...@codebrainz.ca wrote: Hi, I haven't heard too much about the Git conversion of Geany Plugins, but I wanted to offer a suggestion that might improve the commit messages compared to Geany's. In the Geany's Git repository there's links back to the SVN repository in the commit messages (the links are broken BTW). I was wondering if it would be better to have these links point to a place we have more control over, for example using a Geany commit, instead of this in the commit message: git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5970 ea778897-0a13-0410-b9d1-a72fbfd435f5 We could have something like this: git-svn-id: [ea778897-0a13-0410-b9d1-a72fbfd435f5] (http://svn.geany.org/svnroot/geany/trunk?rev=5970) That way we could make the links work and be able to move the old SVN repository without breaking all the links in the commit message. I guess we'd need a little redirect script or something on geany.org. Note also the use of Markdown link syntax, which might render better on Github (not sure). I'm afraid I don't get what is needed here? Did I got you right to setup complete mirror of ancient svn on geany.org? Or easier, just make some URL forwarders/rewrites on geany.org so we don't have to depend on SourceForge.net to always store the SVN repo and never change URLs. The SVN URLs in the Git commit messages will never be able to change ever in the future, so if we point it to a location we control, then we can ensure they remain valid. From Jiri's other message though, it sounds like the SVN URLs in the Git commit messages are all going to be broken like the one's in Geany's Git repository, since it's not an option of the conversion script to change them. I don't feel like hacking the conversion script to change the URL that goes in the commit message, and anyway, as long as it contains the SVN revision, it's still useful. Another option would be to use git filter-branch --msg-filter command where command would be some sed expression which would substitute the current format with the required format. Maybe a bit easier, still something I don't want to spend my time on ;-). The only reason I included the SVN metadata was the commit ID which is useful to have because some commits refer to it in their comments and this information would be lost otherwise. What about something as simple as: sed |git-svn-id: https://geany-plugins.svn.sourceforge.net/svnroot/geany-plugins/trunk/geany-plugins|SVN:| To at least remove the invalid URL, or better yet: sed |geany-plugins@|geany-plugins?revision=| Or similar, so that the URL is not broken? If it's easy enough, I'd say it's worthwhile. Hi Matthew, could you test if it does the right thing with git filter-branch? (I'm quite busy these days.) Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany Plugins SVN Commit URLs
On Sun, Oct 30, 2011 at 23:25, Matthew Brush mbr...@codebrainz.ca wrote: On 11-10-30 03:03 PM, Frank Lanitz wrote: On Sun, 30 Oct 2011 02:15:33 -0700 Matthew Brushmbr...@codebrainz.ca wrote: Hi, I haven't heard too much about the Git conversion of Geany Plugins, but I wanted to offer a suggestion that might improve the commit messages compared to Geany's. In the Geany's Git repository there's links back to the SVN repository in the commit messages (the links are broken BTW). I was wondering if it would be better to have these links point to a place we have more control over, for example using a Geany commit, instead of this in the commit message: git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5970 ea778897-0a13-0410-b9d1-a72fbfd435f5 We could have something like this: git-svn-id: [ea778897-0a13-0410-b9d1-a72fbfd435f5] (http://svn.geany.org/svnroot/geany/trunk?rev=5970) That way we could make the links work and be able to move the old SVN repository without breaking all the links in the commit message. I guess we'd need a little redirect script or something on geany.org. Note also the use of Markdown link syntax, which might render better on Github (not sure). I'm afraid I don't get what is needed here? Did I got you right to setup complete mirror of ancient svn on geany.org? Or easier, just make some URL forwarders/rewrites on geany.org so we don't have to depend on SourceForge.net to always store the SVN repo and never change URLs. The SVN URLs in the Git commit messages will never be able to change ever in the future, so if we point it to a location we control, then we can ensure they remain valid. From Jiri's other message though, it sounds like the SVN URLs in the Git commit messages are all going to be broken like the one's in Geany's Git repository, since it's not an option of the conversion script to change them. I don't feel like hacking the conversion script to change the URL that goes in the commit message, and anyway, as long as it contains the SVN revision, it's still useful. Another option would be to use git filter-branch --msg-filter command where command would be some sed expression which would substitute the current format with the required format. Maybe a bit easier, still something I don't want to spend my time on ;-). The only reason I included the SVN metadata was the commit ID which is useful to have because some commits refer to it in their comments and this information would be lost otherwise. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Geany Plugins testing repository
Hi, I've created a repository for testing geany-plugins conversion from svn to git here: https://github.com/techee/geany-plugins After consultation with Frank, it converts only the combined geany-plugins repository, not the individual plugins so the history starts 11.6.2009. This is the command I used: svn2git https://geany-plugins.svn.sourceforge.net/svnroot/geany-plugins --trunk trunk/geany-plugins --tags tags/geany-plugins --branches branches/geany-plugins -m --authors ./authors.txt The rest of conversion was very similar to Geany's conversion so there's not much more to describe. Please have a good look at it and let me know if something needs to be changed. Especially please check if all the committer info is correct. There's already one suggestion from Frank to drop commit 12dcf0 - i'll do it during the final conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany Plugins SVN Commit URLs
On Sun, Oct 30, 2011 at 10:15, Matthew Brush mbr...@codebrainz.ca wrote: Hi, I haven't heard too much about the Git conversion of Geany Plugins, but I wanted to offer a suggestion that might improve the commit messages compared to Geany's. In the Geany's Git repository there's links back to the SVN repository in the commit messages (the links are broken BTW). I was wondering if it would be better to have these links point to a place we have more control over, for example using a Geany commit, instead of this in the commit message: git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5970 ea778897-0a13-0410-b9d1-a72fbfd435f5 We could have something like this: git-svn-id: [ea778897-0a13-0410-b9d1-a72fbfd435f5](http://svn.geany.org/svnroot/geany/trunk?rev=5970) That way we could make the links work and be able to move the old SVN repository without breaking all the links in the commit message. I guess we'd need a little redirect script or something on geany.org. Note also the use of Markdown link syntax, which might render better on Github (not sure). I guess it's too late to do this for Geany's Git repository, but we could maybe consider something like this for Geany Plugins if the software can support it? Just an idea. Well, the only thing I can do with the script is exclude/include the info about the original commit with --metadata switch. But of course if I make the import from the repository at svn.geany.org, the links will be changed to svn.geany.org. If you need some more advanced formatting, you'd have to change svn2git scripts manually. Feel free to send me the modifications of svn2git ;-). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Geany Plugin Names
On Sat, Oct 29, 2011 at 08:09, Lex Trotman ele...@gmail.com wrote: On 29 October 2011 16:41, Matthew Brush mbr...@codebrainz.ca wrote: Hi all, Is anybody opposed to removing the geany and Geany prefix from the plugins in Geany-Plugins. I mean at least for the directory name in the source tree, README/Site, and PLUGIN_SET_INFO() name? It's always bothered me when I go into *Geany's* plugin manager and see plugin names like GeanyFooBar. Obviously the plugin is for Geany and the Geany prefix makes the plugin not ordered correctly. Same goes for the SVN/Git repository source tree directory names. For example: Geany-Zencoding plugin could be Zencoding under the directory in the repo called zencoding. This is like many plugins already, for example: addons, codenav, debugger, devhelp, gproject (sorta :), pretty-printer, shiftcolumn, spellcheck, tableconvert, treebrowser, updatechecker, webhelper, and xmlsnippets. IMO these would be reasonable renames for the others: Old Name Plugin Info Name Directory = GeanyDoc Documentation?[1] doc or geanydoc or Search Docs which describes its intended use, although it is much more general, and directory searchdocs which doesn't clash with the usual meaning of doc GeanyExtrasel Extra Selections extrasel Geanygdb GNU Debugger[2] gdb GeanyGenDoc Documentation Generator gendoc GeanyInsertNum Insert Numbers[3] insertnum GeanyLatex LaTeX (Addons) latex GeanyLipsum Lorem Ipsum Generator lipsum GeanyLua Lua Plugins lua GeanyMacro Macro Recorder macro GeanyNumberedBookmarks Numbered Bookmarks numberedbookmarks GeanyPg Privacy Guard pg or gpg GeanyPrj Project Manager?[4] prj or project GeanySendMail Send Mail sendmail GeanyVC Version Control vc or vcs --[coming soon]--- GeanyMultiTerm Multi-Tabbed Terminal multiterm GeanyPy Python Plugins python GeanyZencoding Zen Coding zencoding == [1] Could we merge Devhelp and GeanyDoc? [2] Could we replace in favour of Debugger? [3] Should this go in Addons? IIUC addons and insertnum have different maintainers [4] Could we merge GProject and GeanyPrj or are totally different? I bet their developers think so :) Although in my, probably poorly informed, opinion, gproject seems to encompass most of geanyprj Not completely. The main difference is that gproject is an extension of Geany's projects. As such, displays just single project's files in the sidebar and shares the Geany's project settings file for its settings. geanyprj on the other hand can display multiple project's files in the sidebar and has separate project settings file for every project. This is slightly messy because you have two different projects next to each other. Originally gproject was like this too but then I decided to sacrifice the multiple project ability and play more nicely with Geany. About the project name change - I don't care as long as someone is able to invent two different names for the project plugins ;-). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Thu, Oct 6, 2011 at 11:30, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 06.10.2011 11:01, schrieb Jiří Techet: Yeah, I have my .gitignore too. Anyway, I don't plan to make any real commits during the conversion so it's easier to verify the sources are in the same state as before (on the other hand, this could really speed up the merging of my patches; I'm starting considering it ;-). I'd suggest it should be handled as an ordinary patch by the maintainers after the conversion. Speaking of which, would you be so kind to bring your patches in sync with svn head? I had major headaches trying to do it myself yesterday. I've moved all my repositories from Gitorious to GitHub (It was real pain to delete all the repositories from Gitorious because it kept ending with errors. I had to try several times to succeed. GitHub was clearly a better option as a host for Geany's repository.) My up-to-date fork with patches is here now: https://github.com/techee/geany-patches Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git conversion completed
On Sun, Oct 9, 2011 at 04:57, Matthew Brush mbr...@codebrainz.ca wrote: On 10/08/2011 05:13 PM, Jiří Techet wrote: Please have a good look at it. It's no problem to change it now but it will be hard once people start using it. For this reason please resist the temptation and don't update your branches on top of the repository yet. It's safer to wait until everyone agrees the repository is alright. It seems to be pretty good; the branches are nice and cleaned up, the tags look good, and the commit authors have the correct info to match up to their Github accounts. I don't know too much what else to look for though :) Yes, I think it's alright but the more eyes look at it, the better chance someone notices something wrong. Just for fun I tried to checkout and compile some very old versions of Geany. Until commit 3f0512 (post 0.8 commit) everything compiles and runs fine. For earlier versions you have to apply the patch from this commit - after that you can run even the very first import to the repository. And even with this old version you can say yes, this is Geany. Quite amazing that everything runs despite all the compiler and library changes during the years. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git conversion completed
On Sun, Oct 9, 2011 at 15:38, Colomban Wendling lists@herbesfolles.org wrote: Le 09/10/2011 14:36, Jiří Techet a écrit : On Sun, Oct 9, 2011 at 13:55, Colomban Wendling lists@herbesfolles.org wrote: Le 09/10/2011 02:13, Jiří Techet a écrit : Hi, I've completed the conversion to git. It went quite smoothly because I did it already before and fortunately the checksums remained the same so I could reuse the grafts files I already had (to be sure, I checked all the entries one by one). The repository is here: https://github.com/techee/geany Please have a good look at it. It's no problem to change it now but it will be hard once people start using it. For this reason please resist the temptation and don't update your branches on top of the repository yet. It's safer to wait until everyone agrees the repository is alright. Looks good, great job again! :) Just a few questions/remarks: * the unstable branch don't seem to be always removed after merging, yet it is re-created (4f20d88, 2f9719e). This seem not correct since according to svn, in both commits the branch was actually created. * why does 3155474 have two parents? It's supposed to be a new branch out of 3a4a5b6; the old build-system branch was removed in r3939 (previous rev). These two are exactly the points 2 and 4 from http://lists.uvena.de/geany-devel/2011-September/005232.html Oops, my bad :o The problem is that svn2git doesn't delete the branch after merging it so when the branch is re-crated, it has two parents - the current trunk and the last commit from the branch before it was merged. This was the case both for the unstable branch and configurable menu branch which existed before already. I was asking whether to to fix these and the answer was that it's not so important but you're right it looks strange so I'll go through the repository and fix the most obvious cases. It's not much work anyway. I agree it's not so important, just looks a bit weird. If you can fix those easily it's cool, but if it's too hard just don't bother, it's not really a problem. * 03c3b75 (r3679) is a bit weird too, it has d3cdd27 (r3680) as parent, but as the SVN revision suggests, d3cdd27 is newer than it (13:53:04 vs 13:45:47). And I don't see from SVN log why this would be wanted. This is apparently my error - judging from the date I should have used d71d352 for merge trunk changes. I'll fix that. Great, looking forward to it. I think when this is done all is OK, so we could import it in the official repo :) OK, I've re-uploaded the repositories to the same locations. I've fixed the incorrect merge issue and updated parents for most of the re-created branches. The only one I haven't updated is the Create branch for configurable build menu development, now commit 80d2802. There's something strange - it appears the branch existed before but it was never merged into trunk. Instead it was probably deleted and re-created again. If I updated the parent to be the trunk only, we'd lose the history of this branch because we couldn't get to the previous commits in any way. So I think it's better to keep it the way it is. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git conversion completed
On Sun, Oct 9, 2011 at 17:59, Colomban Wendling lists@herbesfolles.org wrote: Le 09/10/2011 16:49, Jiří Techet a écrit : On Sun, Oct 9, 2011 at 15:38, Colomban Wendling lists@herbesfolles.org wrote: Le 09/10/2011 14:36, Jiří Techet a écrit : On Sun, Oct 9, 2011 at 13:55, Colomban Wendling lists@herbesfolles.org wrote: [...] * 03c3b75 (r3679) is a bit weird too, it has d3cdd27 (r3680) as parent, but as the SVN revision suggests, d3cdd27 is newer than it (13:53:04 vs 13:45:47). And I don't see from SVN log why this would be wanted. This is apparently my error - judging from the date I should have used d71d352 for merge trunk changes. I'll fix that. Great, looking forward to it. I think when this is done all is OK, so we could import it in the official repo :) OK, I've re-uploaded the repositories to the same locations. I've fixed the incorrect merge issue and updated parents for most of the re-created branches. Yep, looks great, bravo! The only one I haven't updated is the Create branch for configurable build menu development, now commit 80d2802. There's something strange - it appears the branch existed before but it was never merged into trunk. Instead it was probably deleted and re-created again. If I updated the parent to be the trunk only, we'd lose the history of this branch because we couldn't get to the previous commits in any way. So I think it's better to keep it the way it is. OK, makes sense, even though the old build-system branch was dropped because it was corrupted (according to r3939: Removing corrupted branch). Ah, OK, I've overlooked this. If you want to make some more changes, create a file called grafts inside .git/info. Each line of this file has format parent child1 child2 child3... (using commit SHAs depending on number of children) When you're finished with your modifications, run git filter-branch --tag-name-filter cat -- --all to write it permanently into the repository. Remove the grafts file afterwards. I also checked the repository against my own git-svn clone as you suggested, and all about 60 checkpoints in the history I checked did match, so I'm happy to see you didn't corrupt the sources ;) And the remaining 5000 commits in between contain code which will erase your hard drive completely ;-). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany is on Github
On Fri, Oct 7, 2011 at 17:28, Matthew Brush mbr...@codebrainz.ca wrote: Hi all, For the tl;dr crowd: https://github.com/geany And now for the long version :) I've setup Geany as an organization on Github.com[1]. I've also setup an empty repository[2] for when the SVN conversion is ready to push. I will try and explain how this works because it's a little bit complicated at first glance. To create an Organization, you first need to create a personal account. The personal account can't have the same name as the Organization. After the personal account is created, you convert it into an Organization which is almost a separate entity but is in some ways tied to the personal account. The personal account I created to do this is called 'geanyadmin' (to avoid clashing with the Organization name). Once the organization is created, you can add Owners to it. Owners have the exact same access as the 'geanyadmin' user, for example, an owner could theoretically sign up the Geany organization to a pay account, the Owners have wide-open access to everything. Basically there's no real reason to ever use the 'geanyadmin' account as far as I can see, once Owners are added to the Organization. Just to start, because I had their Github usernames, I've added Enrico and Colomban as owners, as well as myself since I need access to set the stuff up. Whoever else should be an Owner (Frank, Nick, etc.) just let me (or other Owners) know. Read below as for why not too many people really need to be Owners. Now with an Organization, and some Owners who are able to administer the Organization, we come to Teams. Teams are groups of users who all have the same permissions on one or more repository. Teams can be setup to have Pull Only, Pull and Push, and Pull, Push and Administer access. Just to give an example, we'll take the 'geany' repository which will be the main Geany core repository. We could add a team for Core Developers, this group of users could be the existing people with commit access to SVN. In fact I've already created this team, with all 3 permissions mentioned above, and since I had their Github usernames, I've added Colomban and Enrico to this group. Now, what we could do, for example, is to create another Team called Contributors or something, and this Team could have Pull only access (even without being in a team, anyone can still clone/pull). Myself, I would probably go into the Contributors Team, since I contribute a fair bit, but I don't have commit access. Another Team could be called Translators, and have one of the three levels of access control mentioned above, and it could be for all the Geany repositories, since translators likely work on both Geany and Geany-Plugins. Another Team could be Newsletter Writers or something and they could have perhaps Push and Pull access on the newletters repository only. For starting, I suggest the following Teams: - Core Developers (Pull/Push/Admin) - Core Contributors (Pull) - Plugin Developers (Pull/Push) - Plugin Contributors (Pull) - Translators (Pull/Push? or does it go through Frank?) - on both geany and plugins repositories? - Newsletter Editors (Pull/Push on newsletters repo) Is there any reason for creating teams with pull rights only (core contributors, plugin contributors, ...)? The whole world should have pull rights so making a team for them seems unnecessary to me unless there's some other advantage. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Stop using SVN repository from now
Hi everyone, I'm just about to start the import from SVN into git so please stop using SVN from now otherwise you'll have to re-apply your commits into git afterwards. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Git conversion completed
Hi, I've completed the conversion to git. It went quite smoothly because I did it already before and fortunately the checksums remained the same so I could reuse the grafts files I already had (to be sure, I checked all the entries one by one). The repository is here: https://github.com/techee/geany Please have a good look at it. It's no problem to change it now but it will be hard once people start using it. For this reason please resist the temptation and don't update your branches on top of the repository yet. It's safer to wait until everyone agrees the repository is alright. This isn't the final location for the repository so don't fork it for your work. Wait until Enrico pushes it into the final location. I've also created a separate repository containing sm and bs2 branches here: https://github.com/techee/sm-branch Lex has already mentioned he doesn't want to continue in bs2 branch so it's mostly Eugene's sm branch. Eugene, please tell me when you clone it so I can remove the repository. Finally, I've also pushed the repository which came as a result of svn2git without any modificatons: https://github.com/techee/geany-svn2git-unmodified This is meant for reference only in case you have a feeling that something is wrong with the official repository. I'll leave it there so you can always clone it in the future. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git switch (for real)
On Thu, Oct 6, 2011 at 01:23, Colomban Wendling lists@herbesfolles.org wrote: Le 03/10/2011 23:02, Enrico Tröger a écrit : On Mon, 03 Oct 2011 17:28:14 +0200, Colomban wrote: Hi all, Now the release is out, it's time for the real migration. There's things to do then, and perhaps a few we still need to agree on. Yay, yay, yay. @all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular While I usually plead for free software I'd also vote for Github in this regard. In the last weeks I started to use it for smaller personal stuff just to get it hosted somewhere, easily. And it worked. Github is just damn easy, fast and intuitive. While I have not much experience with Gitorious, it feels more like the opposite. Though this is just my personal opinion. Well then, let's try GitHub. I also prefer FOSS everywhere, but GitHub seems to be at least working fine, stable stuff. And as we don't stop to say, we can anyway switch to another host if it feels too bad at some point. Of course keeping the same hosting is easier for people tracking the repo, but it's not really hard to change the remote either if there is a good reason to do so. Finally, we'll need to all (at least committers -- Nick, Enrico, Frank and I --, Enrico and I) work a bit together to do the switch: * committers needs to stop committing to SVN when export to Git starts * somebody (Jiří?) needs to export the SVN repo * somebody (me I think) need to setup an upstream repo on GitHub/Gitorious * we'll have to update everything that assume we commit to SF's SVN (some mirroring, commit ML, etc). Enrico, I guess we'll need you at Well, the GIT mirror at git.geany.org gets rather useless when Geany's source itself is maintained in GIT, if we want, we can keep it up running for backup or whatever purposes. I assume it's no problem to change the repository to pull from a real GIT repo instead of SVN. I'd like to see it still up as a mirror if you don't mind (heh, it's your server after all). This would also make us have a stable hosting since we could change it's origin if it actually moves. The commit mails may be more complicated, at least on Github there seems nothing ready-to-use AFAIK. They have the HTTP-Push hook which seems quite appropriate. We just need a script to receive that push and make it into a mail. However, I'm optimistic there is somewhere a usable implementation out there on the net. Matthew seems to suggest it may be easy, let's hope so :D Maybe I/you could try with another project just to see if this work, not to rush the final day ^^ I'd also need to adjust the nightly builds and some update scripts on geany.org but this is less important and can be done asynchronously, read later. The only critical to me are the commit mails. Great then, makes the plan looking even more reasonable :) So, we'll need to work together soon, and that'll need us to coordinate ourselves. So Jiří (if you accept re-exporting), Enrico, Nick and Frank: when can we do the actual switch? I can have the time whenever I want this week, I just need to know ;) I'm also for as soon as possible, upcoming weekend would be fine for me, ideally on Sunday. OK, let's say Sunday then since it seems to fit :) ACK. Would it be possible that I start with the conversion on Saturday evening already? First I'm not sure how much time I'll have on Sunday, second it gives us some time buffer if something goes wrong or if I need some further clarifications during the conversion. From your side it would just mean to stop comitting to SVN Saturday evening (let's say 6 P.M. CET which is GMT+2 during summer - recalculate it to your time zone). In any case, I'll send an announcement that I started with the conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Wed, Oct 5, 2011 at 01:02, Matthew Brush mbr...@codebrainz.ca wrote: On 11-10-04 02:37 PM, Jiří Techet wrote: Hi, I'm trying to get everything ready for the conversion and there are Hi Jiri, I know it's a very small part of what you're doing but I've attached the .gitignore file I made (for the zillionth time) using a combination of the svn:ignore property for each directory and cleaned up by hand. Maybe it can save you a few minutes :) Yeah, I have my .gitignore too. Anyway, I don't plan to make any real commits during the conversion so it's easier to verify the sources are in the same state as before (on the other hand, this could really speed up the merging of my patches; I'm starting considering it ;-). I'd suggest it should be handled as an ordinary patch by the maintainers after the conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Thu, Oct 6, 2011 at 22:55, Colomban Wendling lists@herbesfolles.org wrote: Le 06/10/2011 22:45, Enrico Tröger a écrit : On Tue, 04 Oct 2011 23:50:06 +0200, Colomban wrote: Le 04/10/2011 23:37, Jiří Techet a écrit : Hi, I'm trying to get everything ready for the conversion and there are still a few points unresolved: I have a few comments (and questions) myself: 1. Some branch names should be renamed (e.g. Geany-0_19_1) because they have the same name as tags and they are ambiguous when doing git checkout. Some naming scheme for stable branches should be invented. I was proposing to have two digit branches and three digit tags: Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag Do you agree or do you prefer some different naming scheme? I don't mind much, but it looks sensible since it quite follows current scheme and is clear. So yes, I agree. What about changing the underscore by a point to make the version number more familiar? I don't remember why I chose the underscore scheme but I know this decision is very, very old. Either it was back in the CVS days or early when migrating from CVS to SVN (this was in late 2005 or early 2006, IIRC). Either I was afraid using points could cause problems or I read somewhere (maybe SF docs) better to use underscores or I was just drunk. Since now, after the GIT merge all references would need to be adjusted at all or they simply die, I guess we can also change the names. Makes sense, and actually I'd feel more natural by stripping the Geany- prefix and replace underscores by dots, eg: 0.19 - maintenance branch for 0.19 (if any) 0.19.0 - first 0.19 release tag 0.19.1 - second 0.19 release tag 0.19.2 - etc. Actually, I don't see the point of the Geany- -- we won't ever release something else than Geany in Geany's repository, right? Sounds good. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plan ahead (to fail to plan is to plan to fail)
On Tue, Oct 4, 2011 at 02:19, Lex Trotman ele...@gmail.com wrote: [...] Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me. Lets just use commonsense and judgement, it won't be right every time but often enough to be useful. Yes exactly. It was the blog post from which I had a feeling that everything has to be done this and only this way and that's why I tried to come up with some examples where it might not work. If the rules aren't carved into stone and allow some flexibility then I'm completely fine with it. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
Hi, I'm trying to get everything ready for the conversion and there are still a few points unresolved: I have a few comments (and questions) myself: 1. Some branch names should be renamed (e.g. Geany-0_19_1) because they have the same name as tags and they are ambiguous when doing git checkout. Some naming scheme for stable branches should be invented. I was proposing to have two digit branches and three digit tags: Geany-0_19 - maintenance branch Geany-0_19_0 - tag Geany-0_19_1 - tag Geany-0_19_2 - tag Do you agree or do you prefer some different naming scheme? [...] 3. I haven't found a merge point for the dynamic-editor-menu branch. Has it been merged to trunk? Does anyone know? If not, I'd just delete this branch. [...] 5. I kept the bs2 and sm branches in the repository but once the migration is done, they should be cloned by their owners and should be removed from the main repository. I can create official Geany repository without them and one clone that contains them so their authors can pick them after the conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Github vs. Gitorious )was: Re: Git switch (for real) (was: Re: geany on github; why not?)
On Mon, Oct 3, 2011 at 17:35, Frank Lanitz fr...@frank.uvena.de wrote: On Mon, 03 Oct 2011 17:28:14 +0200 Colomban Wendling lists@herbesfolles.org wrote: @all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line. I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more free as in freedom. I'm not very emotional here. Gitorious really looks a bit more free whereas at Github I always have the feeling they want to sell me something (ok... somehow the services needs to be paid). On the other hand the featureset around an project looks a bit better at github in my feeling. So. I don't care much and I do have an account on both :) While I also agree that Gitorious is more free, at the same time I also feel the lack of resources it has. The web pages have minor bugs like overflowing text in some cases which haven't been fixed for ages. The fact that GitHub has commercial part also guarantees they get some funds to maintain the pages, servers, etc. I don't know who's behind Gitorious but someone has to pay for the servers and if the funding is gone, Gitorious could end like BerliOS. For these reasons I'm more inclined towards GitHub. But with git it's never problem to change the hosting pages anyway. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git switch (for real) (was: Re: geany on github; why not?)
On Mon, Oct 3, 2011 at 17:28, Colomban Wendling lists@herbesfolles.org wrote: Hi all, Now the release is out, it's time for the real migration. There's things to do then, and perhaps a few we still need to agree on. Le 05/09/2011 23:05, Jiří Techet a écrit : [...] End of the long email finally! I tried to record all what needs to be done so nothing is forgotten once the real migration takes place because some of the stuff took some time to discover. @Jiří: Would you mind doing the real export since you know have a little experience? Sure, no problem. Just one thing I'd like to mention - I may be a security problem. During the export I can modify any commit (e.g. to send me the contents of the editor by email) and you probably won't notice. On the other hand, the good thing is that: 1. I don't feel it's something I'd like to do (but you cannot be sure I'm telling you the truth) 2. You can compare the current state of master with your SVN checkout so you'll see immediately if there's something wrong with the top of trunk. I might modify some past commits but these would have lower impact because everyone either uses the latest trunk or the latest stable release. Actually what's much more probable is that I screw up the conversion somehow ;-). @all: We will switch to Git, and we need to choose basically between GitHub and Gitorious. I'd vote for trying GitHub, just because it has one thing I quite liked and that Gitorious don't seem to have: comments on a particular commit's line. I did use it a few times with Matthew, and I felt it quite convenient to comment details [1] Apart that I don't mind, both have the necessary stuff, and Gitorious is more free as in freedom. Also, I think that we should at least try Vincent Driessen's branching model [2] (e.g. develop branch + feature branches + release branches). It might looks a bit containing at first glance, but also makes things clean -- but note I never tried it in a real project, maybe I'm wrong. Finally, we'll need to all (at least committers -- Nick, Enrico, Frank and I --, Enrico and I) work a bit together to do the switch: * committers needs to stop committing to SVN when export to Git starts * somebody (Jiří?) needs to export the SVN repo * somebody (me I think) need to setup an upstream repo on GitHub/Gitorious * we'll have to update everything that assume we commit to SF's SVN (some mirroring, commit ML, etc). Enrico, I guess we'll need you at least to help here still a bit, sorry ^^ So, we'll need to work together soon, and that'll need us to coordinate ourselves. So Jiří (if you accept re-exporting), Enrico, Nick and Frank: when can we do the actual switch? I can have the time whenever I want this week, I just need to know ;) It would be good if all this could be done as soon as possible so we can start development again using this new scheme. Sooner's better. About the timing, I'd prefer this weekend. There have been suggestions like 2011-10-29 but this is my birthday and even though I like Geany, I want to spend my birthday in a different way than making git conversions ;-). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plan ahead (to fail to plan is to plan to fail)
On Mon, Oct 3, 2011 at 19:00, Frank Lanitz fr...@frank.uvena.de wrote: On Mon, 3 Oct 2011 18:20:35 +0200 Jiří Techet tec...@gmail.com wrote: 1. The split between master and develop is completely unnecessary. I don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases. Here I need to disagree. I think its a good idea to have a separate releases branch. Its not a big effort to maintain it and will allow users to build releases direct from git more easily. git checkout RELEASE_TAG ./configure; make; sudo make install It's not that difficult. I'm not completely against the releases branch, but I'm strongly against this to be master. In addition I'm not sure how to handle situations when you want to release say 0.22 and few days after the last maintenance release of 0.21. e.g. 0.21.3 - those two will conflict badly. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Question about GTK+ version used
On Sat, Oct 1, 2011 at 13:44, Matthew Brush mbr...@codebrainz.ca wrote: On 11-10-01 03:05 AM, Enrico Tröger wrote: On Mon, 26 Sep 2011 01:21:59 -0700, Matthew wrote: So I was just curious *specifically* what distro(s) and version(s) sets the oldest version of GTK+ that Geany should support? I don't know anything as specific as you probably want to hear, sadly. It's just that it raises up from time to time when users tell on what old systems they compile Geany. It seems to me like this group of users would be very small and require that they are: - Enterprise/LTS users running a GUI - And who are willing to install unsupported software. - And whos distro doesn't backport newer libraries. - And who are developers, can compile Geany but can't compile GTK+. - And who are not satisfied with existing supported Geany packages. I would just be curious to know how many (or what percentage of) users fall into this group. I belong to this group (at work where we use SLES 9 with GTK 2.4) except that I compile GTK to run Geany. As a rule, I use old versions of programs for about everything except Geany. Because of chain of dependencies, you'd have to compile almost the whole desktop in order to make the program running. With Geany I'm really happy it has GTK dependency only so relatively little has to be compiled - pkgconfig, freetype, fontconfig, glib, pixman, cairo, pango, atk, gtk. Yes, I call it relatively little because things get much worse for other software. Conclusion: people on enterprise linuxes don't expect to be able to run the latest software because ABIs and APIs change very frequently for various libraries and you can be almost sure that you'll have to recompile lots of system libraries in order to get the particular application running. Since we recently bumped the GTK requirements to 2.12 for the upcoming release, do we need to discuss this already again? Yeah, newer versions are cooler but is it necessary or just cooler? It's not so much about cool as it is about using improved versions of the libraries. Lots of good stuff has been added since 2.12 (ie. in the last 4+ years of active development). Just one example would be the GtkBuilder stuff which would not really be cool, but it would make it easier to unglue some of the business logic from the GUI stuff and make fixing/developing Geany easier. Another example could be the use of GtkInfoBar, whether and where it might be useful is another discussion. What's more, some existing #if'd code could be fixed to be used proper, again making Geany easier to fix/maintain (assuming there's some existing #if'd code blocks...I think I saw some). Another reason, is to make it easier for people to help get Geany able to build with GTK+ 3 eventually, which probably many more users will care about in the somewhat near future than supporting extremely old versions of GTK+ 2. It would also help to attract new developers to Geany if they didn't have to go back in time to see what was the way to do GTK+ things 4+ years ago. No one likes writing deprecated code :) IMO, Geany releases should keep up to date with the versions of libraries of mainstream distros (Debian, Ubuntu, Fedora, Etc.). It's not like the older versions of Geany for older GTK+ versions are going to be any less usable over time. Of course this is just my $0.02 cents as some who has had many good ideas for improvements to Geany that have been stopped with needing to support ancient GTK+/GLib versions. In general I'm happy Geany is rather conservative about its dependencies however in moments like this, where old development tools stop being supported and more and more linux distributions are moving to GTK 3, I think the dependency bump is the better option. Otherwise it would mean that no work on GTK 3 support could be done in the following year(s). Moreover, if the next version of Geany will be released in say one year, the support of old systems should be about the same as now (with half-year release cycle 2.12 is one year from 2.16). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Sun, Oct 2, 2011 at 15:36, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Thu, 29 Sep 2011 22:52:19 +0200 Jiří Techet tec...@gmail.com wrote: By the way, there's a bug in the MRU code. 1. Open Geany with say 3 files, 2. ctrl-tab until you reach the very same file you have currently displayed, 3. release ctrl, 4. ctrl-tab again. Nothing happens until you ctrl-tab one more time. I have a patch for it in my yet-to-be-reviewed patch queue (for more than a year). I remember having this problem when I worked with very few files. Can you please drop a copy of the patch in Geany bug or patch tracker? Done: https://sourceforge.net/tracker/?func=detailaid=3417269group_id=153444atid=787793 Please apply patch https://sourceforge.net/tracker/?func=detailaid=3417268group_id=153444atid=787793 before - it slightly conflicts with the other patch and as I want to have it in Geany too, I didn't want to spend time resolving the conflicts. If the close window in MRU order patch isn't wanted, I can change the MRU fix patch to remove the dependency on the other patch. I also have a patch for the popup window so it shows the current file in bold and the following three files in MRU below it. It helps with predicting which file opens after ctrl-tab next. Nice. :) Here's the patch https://sourceforge.net/tracker/?func=detailaid=3417270group_id=153444atid=787793 Apply after the previous two patches. You could even return to the file before ctrl+tab press if you overshot [...] I could enhance my patch to allow this too if someone finds it useful. Ctrl+Shift+Tab would be very convinient. I'll have a look at it when I have time. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Fri, Sep 30, 2011 at 03:07, Lex Trotman ele...@gmail.com wrote: On 30 September 2011 06:52, Jiří Techet tec...@gmail.com wrote: On Thu, Sep 29, 2011 at 10:03, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 29.09.2011 09:57, schrieb Jacques du Rand: BottomLIne: Almost like a MRU(Most Recently Use) Cache for the Open Document list a which highlight/icon'ify the top 3-6 Documents in order ? Your thoughts ? This is already implemented, though not visualized in the side bar. I don't remember if I use the default keybinding, but for me CTRL+TAB walks the MRU list of opened documents. Absolutely essential feature for me. By the way, there's a bug in the MRU code. 1. Open Geany with say 3 files, 2. ctrl-tab until you reach the very same file you have currently displayed, 3. release ctrl, 4. ctrl-tab again. Nothing happens until you ctrl-tab one more time. I have a patch for it in my yet-to-be-reviewed patch queue (for more than a year). I also have a patch for the popup window so it shows the current file in bold and the following three files in MRU below it. It helps with predicting which file opens after ctrl-tab next. Hi Jiri, I like this idea, I mostly gave up using ctrl-tab because I kept overshooting the one I wanted, giving me a little warning time is a great idea. Yes, this is exactly why I made the change. Before I discovered Geany, I used CodeBlocks which had a plugin with similar functionality (the plugin was extremely buggy and the code was completely crazy). You could even return to the file before ctrl+tab press if you overshot (the keybindings were alt+left_arrow [going back in the stack history like Geany does] and alt+right_arrow to go forward from the current position and undo your previous ctrl+tab). This could be also used to have a quick peek at the file you edited previously - alt+left_arrow, have a look at the file while holding alt, right_arrow, release alt and you're back in your current file with unmodified MRU list. I could enhance my patch to allow this too if someone finds it useful. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Thu, Sep 29, 2011 at 23:59, Colomban Wendling lists@herbesfolles.org wrote: Le 20/09/2011 12:07, Jiří Techet a écrit : Hi, Hey, just one very quick and possibly stupid idea. How about getting rid of the 0 version prefix and calling the next release 1.0? This would be just numbering change, not some milestone based on features that have to be implemented (similarly to renumbering linux kernel from 2.6.x to 3.0). [...] Next Geany release is very near (2011-10-01 or 2011-10-02 UTC), and since the thread seems to show nobody is strongly against a versioning change and some seems to think it's a very good idea, I think it's time to make a decision. I've created a Doodle poll [1][2], and I invite everyone to give his/her opinion. Note that there are 9 possible options, make sure you see all them ;) The final choice will be made just before releasing, but it's close so don't postpone if you want to give your opinion. Also if you think it's not time for a change but you also think that after 0.21 it'd be good, please still vote for 0.21 -- I didn't wanted (or forgot? :D) to add this to the poll yet not to confuse it. If it's too late to bump the version number for the upcoming release, 0.21 can be used for the release and the bump to 1.0 (1.22, ...) can be done as part of post-release version increment. My personal preference is 1.21 1.0 0.21 though. By the way, any other ordering doesn't fit mathematically and is therefore wrong. Q.E.D. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Thu, Sep 29, 2011 at 10:03, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 29.09.2011 09:57, schrieb Jacques du Rand: BottomLIne: Almost like a MRU(Most Recently Use) Cache for the Open Document list a which highlight/icon'ify the top 3-6 Documents in order ? Your thoughts ? This is already implemented, though not visualized in the side bar. I don't remember if I use the default keybinding, but for me CTRL+TAB walks the MRU list of opened documents. Absolutely essential feature for me. By the way, there's a bug in the MRU code. 1. Open Geany with say 3 files, 2. ctrl-tab until you reach the very same file you have currently displayed, 3. release ctrl, 4. ctrl-tab again. Nothing happens until you ctrl-tab one more time. I have a patch for it in my yet-to-be-reviewed patch queue (for more than a year). I also have a patch for the popup window so it shows the current file in bold and the following three files in MRU below it. It helps with predicting which file opens after ctrl-tab next. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] editing big files can be too slow with tag reparsing - HTML
On Tue, Sep 27, 2011 at 14:17, Nick Treleaven nick.trelea...@btinternet.com wrote: On 26/09/2011 23:00, Colomban Wendling wrote: Le 26/09/2011 13:48, Nick Treleaven a écrit : I'm reduced to using Windows. I guess the reason is the regex code that is really old which is used for Windows builds. Maybe yeah, but I find it a little weird you see *so much* slowness... For comparison, on my machine [1] parsing and updating the list takes less than 60ms for geany.html. Just to be sure, are you seeing the 'built-in regex' debug message: 12:42:07: (null) INFO : GTK 2.22.0, GLib 2.26.0, built-in regex It might help to update it from CTags (we had a patch from Jiri Techet but it didn't look like it would build on Windows, i.e. wasn't from CTags). Maybe we could use GRegex now we have a GLib recent enough? Anyway tagamanger/regex.c looks like a few glibc source file concatenated with a 0xff separator, I'd then guess any POSIX RE implementation (e.g. today's glibc's one) would do, wouldn't it? That's probably what Jiri did, but I noticed CTags had some modifications to build on Windows. Perhaps glibc would work, but I think taking it from ctags is safer. Basically I took the (then) latest versions of the regex files plus the makefile from ctags. The patch still applies by the way. I've just diffed the result of my patch with the ctags regex and there aren't big differences. What I've forgotten include into my patch is a conditional include under windows in regex_internal.h so if you want to use my patch, substitute this file with the ctags one. I haven't tested it under Windows myself so I don't know what happens. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On Mon, Sep 26, 2011 at 13:08, Lex Trotman ele...@gmail.com wrote: [...] I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work! Hi Jiri, And I'm responding as a member of the Jiri category :-) How much do you (or anyone) know about supporting both GTK2 and 3, 1. with the same source, 2. with the same binary, 3. differing platforms The reason I ask is that my very preliminary evaluation is that 1. is possible but may need a bunch of #if sections :(, Right. For the most common ones it would be best to create some utility functions that encapsulate the ifdefs so the ifdefs aren't everywhere. 2. is basically impossible (, and Right, forget about it. 3. is unknown. ? No idea but I don't expect major issues once (1) is done. In general it would be best just to try to substitute GTK version in configure, see what happens and start fixing the errors. I'm really tempted to try it myself but I'm not sure if I'll have enough time for that in the following few months. Also for changes like that it would be better to have git in place for easier merges once the work is done. My personal feeling is that the sooner some support for GTK 3 is added, the better. Of course first, until it is stable and working as expected, it could be an experimental configure option which ordinary mortals would be discouraged to use. Meanwhile thanks to the ifdefs the old GTK 2 code should work as before. And maybe the conversion will be quite easy - it's just you never know unless you try it, so it's better to try it to know :-). Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
Hi Matthew, On Sun, Sep 25, 2011 at 10:53, Matthew Brush mbr...@codebrainz.ca wrote: Hi, I just wanted to let everyone who I haven't bothered on IRC know that I'm working on converting the old Geany Glade 2 generated user-interface code to Glade 3 using GtkBuilder. I'm really happy about this change. First we get rid of the horrible old glade editor and second it's the most important step towards making Geany compile under GTK 3. Thanks for your work! I'd like to get this committed to Geany shortly after the 0.21 release if possible. It requires a minimum GTK+ version of 2.16 due to the use of GtkBuilder, which may or may not be a problem. I figure if there's any chance of Geany upgrading to a minimum of GTK+ 2.16 then it would be beneficial to do so early after the next release. If there's no chance of updating to GTK+ 2.16 after the next release, then ignore the rest of this email. The changes add two API functions to Geany; ui_lookup_object() and ui_hookup_object() which behave similarly to their widget counterparts. The old ui_lookup_widget() and ui_hookup_widget() are deprecated in favour of the new functions, but they still work as before. The first parameter to these functions, the parent widget, is no longer used. The new functions are added to the plugin API. I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the Terminal tab in the preferences dialog just won't be shown. The new code adds a GHashTable which is used to register GObjects, either from the GtkBuilder file (data/geany.glade) or added elsewhere with the ui_hookup_object() function. Each GObject registered is referenced when hooked-up and de-referenced when the new ui_finalize_builder() function is called. I honestly have no idea what the implications of this change are in regards to i8n translations, but IIUC there is a facility for this in the GtkBuilder file. One bug I've experienced, which may be unrelated to my changes, is that the main VBox splitter (between the sidebar/documents and the message window) position is not remembered. The position is stored in the keyfile but it's not reloaded the next time Geany is run. I've had a brief glance at the relevant code and I couldn't spot any obvious problems. If anyone feels like giving me a code review, feedback or testing the changes, I have a branch on my geany repository on GitHub. My working copy, which is rebased on Geany's Git repository every now and then can be found at: https://github.com/codebrainz/geany/tree/gtkbuilder I gave it a quick try and in general it appears to work really great (i.e. I don't see any difference between this and the old version). The only glitch I have noticed is that under Document-Indent Type, Document-Indent Width and Document-Set Line Endings all the items are selected with the radio selection circle. The fix is to disable Active for these items in the glade editor (not attaching patch because for some reason Glade changes also other elements in the XML file when I save it). Not sure if they were active before or there is some bug in the conversion from the old format. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Tue, Sep 20, 2011 at 13:02, Lex Trotman ele...@gmail.com wrote: On 20 September 2011 20:14, Jon Senior j...@restlesslemon.co.uk wrote: On Tue, 20 Sep 2011 12:07:23 +0200 Jiří Techet tec...@gmail.com wrote: Hi, just one very quick and possibly stupid idea. How about getting rid of the 0 version prefix and calling the next release 1.0? This would be just numbering change, not some milestone based on features that have to be implemented (similarly to renumbering linux kernel from 2.6.x to 3.0). Rationale: the 0.xx versioning scheme makes an impression that Geany is something very unstable that crashes every five minutes and whose first release was made a few months back. Instead, Geany is a very stable and reliable editor with lots of features and several years of history. I agree with this argument, I tend to introduce Geany anywhere I have a contract and one of the first reactions is always But its just a fractional version number. And I know when I am looking for software I want to use I tend to have the same reaction. Following the Kernels example and going to 1.0 or better yet 1.1 would be a good idea. And it is likely to attract more contributors since it doesn't look like the project is just starting. Or 1.21 - i.e. raise the stability flag in the first digit but continue with current numbering after the dot. The message would be we consider Geany stable but the current release is just an incremental release. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Thu, Sep 22, 2011 at 15:34, Frank Lanitz fr...@frank.uvena.de wrote: Am 22.09.2011 15:28, schrieb Colomban Wendling: Le 20/09/2011 23:26, Enrico Tröger a écrit : On Tue, 20 Sep 2011 16:10:34 +0300, Yura wrote: Hi But why only 1.0? GNOME 3.* KDE 4.* Scite 2.* What about Geany 3000? Or some kind of other stupid release name like ''busel', 'verabei', 'krumkach' ... Heh, I like krumkach, sounds in German quite funny :). BTW, how are Geany codenames chosen? :-' More seriously, I personally don't mind much about version numbers. It's good to have some but the actual value doesn't mean much to me. But I realise other people take more care about this and 0.x might seem not that mature to many users. So, I'd say: why not. I'd say quite the same. I don't really mind, and it seems it's something important for many of you so... But can we do it post 0.21? Only one week left and I want to concentrate on improving translation etc. instead of searchreplace version numbers. Hi Frank, if it should cause problems, of course it can wait, it was just a suggestion... ...on the other hand I've just tried to make the renaming from 0.21 to 1.21 and it isn't too hard to do and doesn't seem to be very intrusive - see the attached patches both for Geany and geany-plugins. The only missing things are: 1. The documentation should be regenerated 2. Version should be updated in *.po files (I didn't do it because you'll be receiving po files from translators with version 0.21 now and it will be easiest to update all of them at once before the release) 3. The version number change should be mentioned in ChangeLog/NEWS Cheers, Jiri geany_plugins_1_21.patch Description: Binary data geany_1_21.patch Description: Binary data ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Please check for ChangeLog-entries on commit
On Mon, Sep 19, 2011 at 08:15, Frank Lanitz fr...@frank.uvena.de wrote: Hi folks, Another episode from topic improving plugins by Frank ;) In last time I saw a lot of changes going in into plugins without having a ChageLog entry set. Its not always useful in every case but its a nice thing for users of trunk and also stable releases to have a middle view between NEWS-file which is in most cases only a very short compilation of changes and the very, very verbose svn/git log view. So I'm bagging you to have in mind updating your ChangeLog and when every updating po-files or something else inside geany-plugins/trunk/geany-plugins/po I make it mandatory ;) Hi Frank, it would be useful to have all the recommendations/requirements mentioned somewhere - e.g. the HACKING file. There could be a list of points plugin developers should keep in mind when making commits and preparing for release. Without it I'm afraid many people (and especially me) will forget to do something (e.g. update the ChangeLog file which is something I'm used to get generated from the git repository). One more thing that could appear in the file is that the developers should run rst2html on the README file - I had a syntax error in the file without knowing it because I just didn't check whether it's a valid reStructuredText. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Tue, Sep 6, 2011 at 05:29, Lex Trotman ele...@gmail.com wrote: Hi Jiri, Great job, thanks. Its going to take a while to inspect, but a couple of comments below (I'm only looking at the final rewrite-history version). Note I don't think we need perfection for its own sake, we need to be able to use the history to identify where regressions were introduced and fix them and to show attribution as well as SVN did. As far as I can see those requirements are met. Yes, exactly, one could play with the repository almost infinitely to make it look beautiful but then it makes no difference in reality. 1. Some branch names should be renamed (e.g. Geany-0_19_1) because they have the same name as tags and they are ambiguous when doing git checkout. Some naming scheme for stable branches should be invented. I notice there is some inconsistency in naming recent branches whilst naming for tags is consistent. In olden times branches were named like Geany-0.10.2 but only lately has it changed to underscores. Tags always used underscores. So maybe go back to using dots in branch names (and rename clashing ones). There are actually three different naming schemes for stable branches now: 0.20.1 Geany-0_19_1 Geany-0_19_2 geany-0.10.1 geany-0.10.2 geany-0.18.1 Now looking at it again, Geany-0_19_1 and Geany-0_19_2 aren't actually different branches (similarly geany-0.10.1 and geany-0.10.2), there are just two refs to the single branch: http://dl.dropbox.com/u/2554438/10.png http://dl.dropbox.com/u/2554438/11.png To me the most logical and consistent naming scheme would look like Geany-0_19_0 - release tag Geany-0_19 - optional maintenance branch Geany-0_19_1 - tag Geany-0_19_2 - tag ... That is - tags would always consist of three digits and branches of two, the rest of the name would be identical. Also the branch refs should be moved to the very end of the branch (they are before the tag commit now) and the extra refs removed. 2. There are some strange places in the history like this: http://dl.dropbox.com/u/2554438/8.png The commit says create branch but it appears the branch is actually merged. Moreover, the merged branch appears not to contain any commit. There are more examples like this in the history. Any idea what may have caused this? Should the empty branches be deleted from the history or kept as they are? This looks like attachment to me (sorry for the attachment, firewall prevents uploading to most sharing sites) It appears at the start of the branch which is right, how are you viewing it? Ah, forget about this comment of mine. You are looking at the svn2git repository and I was showing the final geany-rewrite-history repository, that's why we see something different. However, in fact it's just a different graphical representation of the same. The straight line in my case isn't trunk but your branch and the side line is trunk. I think the reason for not seeing the branch creation is identical to the unstable branch - that your branch was periodically merged, deleted and re-created but this isn't visible after the conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Wed, Aug 31, 2011 at 18:41, Colomban Wendling lists@herbesfolles.org wrote: Le 31/08/2011 18:18, Frank Lanitz a écrit : Am 31.08.2011 17:21, schrieb Colomban Wendling: 3) We won't probably be able to create Git tags from the SVN tags because they (at least Geany-0_18 do) don't all tag a single commit (e.g. it's a branch) Can you go into more detail which are not working? IIRC we only had one or two of tag/branches issues within the releases. $ git log --graph --decorate --pretty=oneline --abbrev-commit remotes/tags/Geany-0_18 * 8c84d70 (tags/Geany-0_18) Tag the 0.18 release. |\ | * d6ec2f3 Fix opening of local files in the browser on Windows. * | 6df16fe Tag the 0.18 release. |/ * cb9c34f Add missing include path to fix 'make distcheck'. Hum, actually it looks like it's my bad since it simply looks like a re-tagging, so the forked history isn't interesting. So maybe tags aren't a problem -- which would be cool :) Hi, I've finally had some time to experiment a bit more with the svn-git conversion and I'm quite satisfied with the result. This is what I did: 1. Used svn2git for the conversion. I used the authors file with entries Colomban found and ran svn2git https://geany.svn.sourceforge.net/svnroot/geany --authors ./authors.txt --metadata I used the --metadata parameter so the original SVN revision gets recorded into the git commit comment. I found this useful because some commit entries refer to SVN commit number and it wouldn't be clear which commit it was without this information. The resulting repository is here: https://gitorious.org/geany-svn2git/geany-svn2git There are a few problems with the import. First, tags are in separate mini-branches like http://dl.dropbox.com/u/2554438/1.png and some (but not all) branches are not merged: http://dl.dropbox.com/u/2554438/2.png I tried to address these issues in the following steps. 2. I created file named grafts under .git/info in the project's directory. To correct the mini-branches, I changed parents of individual commits. These are the lines in the grafts file that correct the mini-branches of tags: deed5dbc6e0af7bc5e7ddb774bb70438b5bb0463 0a1305bcfbff3323256d01068aca7dffd409183f dd93684f9107fa4ec70b5aa4eaf576fc7a5512f6 f2a189ea49917b046fea454ff34cffb2a1e7aad0 5ebc0a946f6e7b240ad62f9105bc2b92c577f621 2440f909eb293010043bbcfbf40351524539a72a ec68e76a2cfd0f779d9fa3b9d1c0b63703bd4fdb b532fed1cffd4fc120490261bce7a20a657eb06d f8e36105279aa9ec41abf1a2f3c3d1d370523ce8 b3ccfe1c32119bf2e111823305f1a49ee7215507 366724520ab3f1ee54978f4eac2524859fbf8567 14cacf9f9b73a2eeaeb26cc5c5d4d722efff9992 811eaab72831e3041df22f04463712beebeb8bd9 88becfe38d73130caa944592b5082e219c554a8b 1b8dd6c8f0220384be44397a508ac5aa0190a80a c0b1035cbb72d4f664a9fc42690d89e42f46abb7 850f1c1711a956f6a7c8c83332ee35d3033d4514 18b4e590235912a0a9390b5edcef08465e1457fc 6eb88a4a04591bd558c45052a7eb37f8bec8c09e 9113a9eb882b963375d1fc498ad916ad6a264fca 1e61eb481ed35d5bb850f04657ee789b226525e9 9ea6b3b1c3e463a46af0cfdbf68269c8326f9356 6bc8aee98c28e349d862d7c47d9251507aa0c80d 39ff8bc39822e30e7c992979e60c12ae337b7a49 091cb63d5b69195f0002c11ea165667b8f4d4b16 5fc1d82f8b6f983755979e1ad6e018703fe4bc3a b9a233a0e5d6ae23eb5c98dd6d11f7e681891225 6b04d0f873b4395e8323cb1b761149d5cc2abb79 b8e0d52196a8ef49c8af65bbba786fcf0396aac3 f0ca43729bb26b333eba66ae196748a587aef07c d872050b45eb0983ed1c0bbd1f74d12cc42781d2 9681a8ad259310b2dff453b4fe92fcbd9c1e73c8 43be67bfd601a97810883a17ff3ffe2dd7837ae8 ef90d0c96ec09d10a04db1ed554b1a36e0b3f09b f0ca43729bb26b333eba66ae196748a587aef07c c0c1f36bb5be85d6b17762a61008f9a453b1aa86 The result looks this way: http://dl.dropbox.com/u/2554438/3.png 3. I tried to add all the merges information that wasn't performed automatically. It was quite easy - I found all commits with merge in their name and they usually specified what branch was merged. Then I set the parents accordingly in the grafts file: 1882805f70d86561f644c45a5d06172a02335ec7 a0c12ca379bd44e4929d041a1786bfee4a948b31 3a2d26742529ecbd6db47faf1ace1a3f3e19ae93 5f4a5775e2d1bbf1cd6015865a45c38b736b62c2 336b35bfcb3996b5cc9d2f0765dc6d2d3564cd00 6b6edbee734e8cb2860f3688ce79b9ef7d84007b 11f8bf94032160756cc92bd620126c91ee4407b7 a564ed802cda2075b475c37646ace8f604f6a78d 89cf69f5a5e67c094efed6ed74a039e1d851bb51 9eef0db54c3a1bdb15bafbfc9889f2c5f3c21763 dfc78a1a9cd7ee7871a2ad095fd4bcf5ec025a72 df3574e118ea49e15a6e8ff5c33384ea318765d5 08da5856b9f313e64dc2e0b43f08a9dba3936d26 75480426f3e577a3fd72fc4e7885228762068be8 4957f1ea34390a1e590841f22507711adf748382 406d18fe52905154cebdb7864f4c547a156ded72 91284b54fcf60f7f0538ef15a2b80a5d1b5195e6 eee74e4778c960e09fa9a7e5b9003c8da5e8fc6b 573e2f900b407f688b6316ae16cd5908696c8e23 9004b4a5db527ae92a3916121b5481c302d7df7b cea76d14ee1bb0ca0aff4f5a1f5332e4a584b10c 26d7edb2b117c8c4bebb99911e0a1fd561bd961b 34bffb9033bc243ca5e2e1862ca8d503c1193b26 e367ddba15c739afa269efb255b7ea56743835a4 428cc39ac6bbe604c6b136dfa0b7d78abdec58d2 3961ab135b1abcf41d6696fc90df498948688bb1
Re: [Geany-devel] geany on github; why not?
On Wed, Aug 31, 2011 at 17:21, Colomban Wendling lists@herbesfolles.org wrote: Hey, Le 31/08/2011 00:01, Jiří Techet a écrit : On Mon, Aug 29, 2011 at 13:17, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 28.08.2011 23:33, schrieb Jiří Techet: On Sat, Aug 27, 2011 at 20:50, Frank Lanitzfr...@frank.uvena.de wrote: So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV. I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here http://lists.uvena.de/geany-devel/2010-June/002672.html which I'd need to get first before performing the conversion. I could also ask the one that successfully converted our Rockbox svn repo to git, including proper branch, tag and author conversion, to write up the steps it needed. I think it was less than a day of work for him (and the Rockbox tree and history is considerably larger and more complicated than Geany's). I expect the whole conversion of Geany's vcs wouldn't take more than 4 hours. I believe I know enough to perform the complete conversion myself but of course it would be useful to know someone else's experience. FWIW, I've played a little with git-svn, and I've got a few things working/non-working: 1) as expected, it doesn't make merges looks like merges, but as a single commit. However Thomas said on IRC that SVN didn't knew merges either, maybe it makes this impossible to track then? Yes, as I said earlier, this has to be adjusted manually by the grafts file. 2) I've got a full commiters list, hopefully OK (that's the only useful part of this email actually...): colombanw = Colomban Wendling b...@herbesfolles.org eht16 = Enrico Tröger enrico.troe...@uvena.de (no author) = Enrico Tröger enrico.troe...@uvena.de fralan = Frank Lanitz fr...@frank.uvena.de frlan = Frank Lanitz fr...@frank.uvena.de kretek = Frank Lanitz fr...@frank.uvena.de ntrel = Nick Treleaven nick.trelea...@btinternet.com dmaphy = Dominic Hopf dma...@googlemail.com statc = Eugene Arshinov earshi...@gmail.com elextr = Lex Trotman ele...@gmail.com peterscholtens = Peter Scholtens peter.scholt...@xs4all.nl clytie = Clytie Siddall cly...@riverland.net.au Great, good to know. Frank especially, can you confirm your 3 nicks? (although I've based the matches on SF + commits) 3) We won't probably be able to create Git tags from the SVN tags because they (at least Geany-0_18 do) don't all tag a single commit (e.g. it's a branch) If I remember correctly, there should be tags as an output of svn2git. I'd just prefer getting rid of the created tag-branches by rebasing the rest of trunk on top of the tag-branches (for every tag). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
Hi Frank, On Thu, Aug 25, 2011 at 07:48, Frank Lanitz fr...@frank.uvena.de wrote: On Wed, 24 Aug 2011 23:56:52 +0200 Jiří Techet tec...@gmail.com wrote: It's not perfect - the branches aren't glued to the trunk in merge points and the tags are squashed with the previous commits which I don't like but it gives you an idea how a complete Geany's history looks like. Is there a way to prevent from such things? (First sorry for replying so late, I'm operating in semi-vacation mode these days :) I think using svn2git and then some manual adjusting the tags is the best option. The scripts don't don't do this automatically because in svn tags aren't real tags - it's a copy of the trunk state but at the same time you could in addition modify any file so for git it's something like tag + commit combined. So far I haven't seen any script automatically converting svn branch merges into git merges - again, the information what branch was merged where isn't stored by svn. So this information has to be provided manually with the grafts file. You can read about the grafts file here: http://blog.woobling.org/2009/06/git-svn-abandon.html Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Thu, Aug 25, 2011 at 08:15, Matthew Brush mbr...@codebrainz.ca wrote: We could also use the SVN import on GitHub. It's offered as an option when you create a new repository. I have no idea if it suffers from the same limitations you mentioned. My feeling is they use svn2git internally. Apart from that, this is what they say about the service: If the repo you are importing is very large, your import may time out. This was apparently my case - I tried it too with Geany but the import wasn't successful. With svn2git the whole import takes about 90 minutes and I guess this is too much for the GitHub server. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
On Sat, Aug 27, 2011 at 20:50, Frank Lanitz fr...@frank.uvena.de wrote: On Sat, 27 Aug 2011 20:46:37 +0200 Colomban Wendling lists@herbesfolles.org wrote: Le 27/08/2011 20:27, Frank Lanitz a écrit : On Sat, 27 Aug 2011 18:02:41 +0200 Colomban Wendling lists@herbesfolles.org wrote: Le 22/08/2011 00:27, Jiří Techet a écrit : [...] Well, in my opinion the whole topic of git transition is over-discussed. Looks the same for me, and I didn't see much new POV or useful infos since a bunch of emails. The reason why I haven't been very active on Geany's mailing list are exactly these endless discussions which lead nowhere. To your steps: 1 and 2: GitHub or Gitorious are the only options if you want personal repositories (which is the main reason I want the git switch). It's not a crucial decision at all which one you chose - if you pick GitHub and realize it stinks, you can always move the repository to Gitorious. The only problem is that contributors would have to move their personal clones too, but it's not a big deal. I'd like to at least have a synchronized version on git.geany.org. Even if it wouldn't have that personal clones, it could be the main clone source or at least a backup mirror. Can you provide a clone which is inclduing all point Jiri mentioned? - Branches - Tags - Merges? I only have a full git-svn --stdlayout copy, so basically no, though partially is also right: * I (can) have branches (needs to co remote/name; co -b name) * I (can) have tags (huh, they looks like branches) * I *don't* have proper merges (the history is linear) * I *don't* have proper authors Not sure how to fix this (especially merges, I have a script for the authoring part somewhere, and I think that true branches and tags should be easily created with a tiny script) but Jiří seems to know some ways. So I suggest this: Jiri can you help to do so (or does maybe the github svn clone tools does this correct?) we surely can also offer something like that from git.geany.org. But here import is needed FMPOV. I could, but it needs some manual work and I'd like to do it just before the switch because I'm not sure if I could easily add the commits (commits on different branches and especially merges) you do between now and the switch. I was too missing a few committer names - see the original email here http://lists.uvena.de/geany-devel/2010-June/002672.html which I'd need to get first before performing the conversion. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git for plugins
On Fri, Aug 26, 2011 at 02:47, Matthew Brush mbr...@codebrainz.ca wrote: On 08/25/2011 03:27 AM, Frank Lanitz wrote: On Thu, 25 Aug 2011 15:51:24 +1000 Lex Trotmanele...@gmail.com wrote: Yes, with DVCS each plugin can have its own repository and the Geany project only needs to manage the aggregated build. Yes, this was the outcome on IRC. So once a feature is ready/bug has been fixed a pull request is send to maintainer who is including them into his/her tree. Once this has been done a snapshot of that tree will be the release. I disagree with this. I think using a workflow more like I linked to previously where people work from feature branches, and only merge to devel when the feature is complete (or bug fixed, etc) would be better. I just feel like limiting access *more* than before is a step backwards for the project. In contrast, I agree with the original proposal because there are two different responsibilities: 1. Plugin bugfixing and development (plugin maintainers) - responsible for their plugins (development, bug fixes) 2. geany-plugins project maintenance (Frank) - responsibility for the overall combined project And the proposed workflow fits the different responsibilities very well. IMO, it would be better to give people the benefit of the doubt, and if someone continually pushes broken builds and stuff to the devel branch, then revoke access and work on a pull-request system like you mentioned. I think it could be discouraging for the developers for whom you revoke access. It's like telling them I don't trust you. If nobody of the plugin maintainers has commit access, it's the same rule for everyone and you won't hurt anyone's feelings. I do think there still is a place to have a maintainer, who will be the person who reverts changes made that break the build at will, without needing to ask other people for approval and who decides when it's necessary to revoke access. I believe it may be necessary sometimes for Frank to modify all the plugins (like when something changes in Geany and affects all the plugins). But in this case it's not necessary that the patches go first down to the individual maintainers and then back to geany-plugins. Frank just commits the changes directly and plugin maintainers will merge (or rebase) their repositories. Stuff like that is pretty easy with git. +1 for Frank for maintainer like this :) Of course! And feel free to revoke my commit access :-). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany on github; why not?
Hi Lex, On Tue, Aug 23, 2011 at 07:21, Lex Trotman ele...@gmail.com wrote: Hi All, Some mixed comments. @Jiri I would have thought that the process for creating the Git repo was to check the existing readonly mirror then move it to the chosen host and setup access. Or do you know of some problem with it? the disadvantage of using the current read-only mirror is the following: 1. It's not complete (just 3 years of history). Could be a problem if you want to bisect some bug which has been present for a long time. Apart from this it's just nice to see the complete history. 2. There are no tags visible. 3. There are no branches and branch merges visible. Even though it takes some time, I think it's worth doing the initial git repository setup properly because it's very hard to modify it afterwards (all contributors would have to throw away their personal clones). I think it's nice to see the complete history so you can see when each release was made, checkout any previous commit and think of the good old times when the individual commits were made. You can get a (one-year-old) complete SVN export of Geany from here: https://gitorious.org/geany/complete It's not perfect - the branches aren't glued to the trunk in merge points and the tags are squashed with the previous commits which I don't like but it gives you an idea how a complete Geany's history looks like. About plugins - I'd like to see them converted to git too but for me it's much less important. Plugins are usually one-man-show and require much less cooperation than Geany itself and their authors already have SVN access. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SF.net SVN: geany-plugins:[2096] trunk/geany-plugins/gproject/src/ gproject-project.c
On Mon, Jun 20, 2011 at 00:35, Frank Lanitz fr...@frank.uvena.de wrote: Hi folks, On Sun, 19 Jun 2011 22:30:57 + tec...@users.sourceforge.net wrote: -#include geanyplugin.h +#include geany/geanyplugin.h I'm not 100% sure, but is this really correct? No, thanks for noticing, got there by mistake. Will commit a fix in a few minutes. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Exuberant Ctags Support
On Wed, May 25, 2011 at 22:16, Matthew Brush mbr...@codebrainz.ca wrote: On 05/25/11 09:03, Jiří Techet wrote: On Wed, May 25, 2011 at 17:29, Matthew Brushmbr...@codebrainz.ca wrote: parsing the open source files. Dumping the list of tags parsed to a plain-text (Ctags format) file seems fairly trivial. This would remove the need for the user to *have* to have Ctags on her system. OK, one more idea - how about generating the Geany's tag file in the ctags format? (I don't like the current tags binary format much.) I think that would be best. Tag manager isn't really a binary format, but there's no reason to use a format that you can't punch in on a normal keyboard. The tags are saved in tm_tag_write() using code like fprintf(fp, %c%d, TA_TYPE, tag-type); so the file contains binary representation of integers and other types so it is a binary format. Seeing that the Ctags format is somewhat of a standard, supports all of the needed information, and is used by many other editors, it seems only logical to use this format. Completely agree. Another bonus is that Ctags format has the filename in it, which could potentially be useful for the Go to Tag Definition feature, maybe? Good point. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Exuberant Ctags Support
On Wed, May 25, 2011 at 06:29, Matthew Brush mbr...@codebrainz.ca wrote: Hi, I started working on support for reading Exuberant Ctags files. The commit message sums up most of the details I hope. If anyone wants to try it out and/or review the code, that would be much appreciated. The relevant commit is here on my 'ctags-support' branch: https://github.com/codebrainz/geany/commit/a642077c47ea444e9b13b9d2ad244be0866b562c Or the attached patch has the same information. I haven't tested a whole lot but it seems to be working well, allowing colourizing of the tags and auto-completion. It doesn't (yet) get the arguments list for functions (haven't found a clean way yet), so the calltips for function tags are pretty useless. Hi Matthew, as this is something I wanted to do myself, I really like it! I've been looking at the code only so far; I'll test it once I have access to my computer in the evening. A few comments: 1. In tm_tag.c it would be better to have ctagKinds languageKinds[] separate for each language and then have allKinds array indexed by lang_id containing languageKinds[] of all languages. So to get to language's tags, you would just do allKinds[lang_id] instead of going through the whole list every time. (a dummy entry would be used for lang_id's not present in the table) 2. You can get function parameters from extension fields when you run ctags with --fields=+S (and I believe you get variable type with t). Check the man pages of ctags. I think this is safer than using your USE_HACKS code. 3. More general comment - if we have ctags file parsing support, it's a question whether Geany should continue using the old format and its generation. Tags generation would be then redundant in Geany if you can do the same with ctags (and ctags is the right tool to generate tags, not a text editor). Geany's documentation would then just say what flags should be used for ctags in order to create all the necessary fields. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Exuberant Ctags Support
On Wed, May 25, 2011 at 17:29, Matthew Brush mbr...@codebrainz.ca wrote: On 05/25/11 06:37, Jiří Techet wrote: as this is something I wanted to do myself, I really like it! I've been looking at the code only so far; I'll test it once I have access to my computer in the evening. A few comments: Great, thanks! 1. In tm_tag.c it would be better to have ctagKinds languageKinds[] separate for each language and then have allKinds array indexed by lang_id containing languageKinds[] of all languages. So to get to language's tags, you would just do allKinds[lang_id] instead of going through the whole list every time. (a dummy entry would be used for lang_id's not present in the table) Good idea, then it only has to go through ~10 entries max before it finds the finds the langType (or doesn't). 2. You can get function parameters from extension fields when you run ctags with --fields=+S (and I believe you get variable type with t). Check the man pages of ctags. I think this is safer than using your USE_HACKS code. Yeah, that's certainly the way, but I wanted to support any CTags files that could be generated, particularly with the default (no) options/old format. But see below. 3. More general comment - if we have ctags file parsing support, it's a question whether Geany should continue using the old format and its generation. Tags generation would be then redundant in Geany if you can do the same with ctags (and ctags is the right tool to generate tags, not a text editor). Geany's documentation would then just say what flags should be used for ctags in order to create all the necessary fields. I wasn't thinking of it like this, but it does make sense. The only problems I see are that it requires the user to have another specialized program to generate tags and that some languages supported by Geany are not supported by the CTags (at least on my system), particularly Vala comes to mind. Maybe Vala support could be pushed back upstream. Also, as above, if the user was told which flags to use for Ctags, then it would make the parsing code more robust. What's more, if we used the Ctags format as the main format, then we could drop the pipe separated format as well since Ctags format is (nearly) as easy to generate by hand as the pipe-separated format and also Ctags program supports the languages that necessitated supporting that pipe-format in the first place I think (as the code comment says alternative parser for Pascal and LaTeX global tags files...). I personally think it's nice for Geany to be able to generate tag files itself though, especially since it would still have all the parsing code for parsing the open source files. Dumping the list of tags parsed to a plain-text (Ctags format) file seems fairly trivial. This would remove the need for the user to *have* to have Ctags on her system. Good points - it's a bit unfortunate that ctags hasn't been maintained very actively in the past few years and that Geany has to maintain its own fork of it instead of pushing the changes upstream. It wouldn't be easy to extract the Vala ctags generation from c.c because there are really many changes if you compare it with the ctags version. OK, one more idea - how about generating the Geany's tag file in the ctags format? (I don't like the current tags binary format much.) Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject geany-plugins integration
2011/5/23 Enrico Tröger enrico.troe...@uvena.de: On Mon, 23 May 2011 12:52:49 +0200, Jiří wrote: 2011/5/22 Enrico Tröger enrico.troe...@uvena.de: On Fri, 20 May 2011 22:04:40 +0200, Jiří wrote: Hi, I've finally found some time to integrate my GProject plugin into geany-plugins; for those who like git, the result is here: https://gitorious.org/geany-plugins-gproject/geany-plugins-gproject For those who dislike it, the patch is here: http://db.tt/esDNpPw I guess you waant to commit it yourself instead of depending on someone else, right? So, tell me your Sourceforge username and I'll add you to the project members. Thanks Enrico, my username is techet. I added you to the project, so you can write to the repository. Have fun :D. Perfect! I've just committed the plugin. As I said, at the moment there's a problem with the waf script - it compiles fine but I don't know how to install the icons from the icons directory and how to refresh the icon cache during installation. Any hints how to do this with waf? Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject geany-plugins integration
2011/5/22 Enrico Tröger enrico.troe...@uvena.de: On Fri, 20 May 2011 22:04:40 +0200, Jiří wrote: Hi, I've finally found some time to integrate my GProject plugin into geany-plugins; for those who like git, the result is here: https://gitorious.org/geany-plugins-gproject/geany-plugins-gproject For those who dislike it, the patch is here: http://db.tt/esDNpPw I guess you waant to commit it yourself instead of depending on someone else, right? So, tell me your Sourceforge username and I'll add you to the project members. Thanks Enrico, my username is techet. Regards, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] GProject geany-plugins integration
Hi, I've finally found some time to integrate my GProject plugin into geany-plugins; for those who like git, the result is here: https://gitorious.org/geany-plugins-gproject/geany-plugins-gproject For those who dislike it, the patch is here: http://db.tt/esDNpPw I hope I've updated all the necessary files. The automake build should be working correctly; however, in the waf build I'm not sure how to integrate icon cache rebuild into the waf script. From what I could see no other plugin ships with its own icons and even though Geany's waf script contains the necessary code to rebuild the icon cache, I'm not sure how to integrate it properly into the plugin build system. Anyone willing to help? Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Mon, May 9, 2011 at 20:12, Colomban Wendling lists@herbesfolles.org wrote: Le 09/05/2011 19:35, Jiří Techet a écrit : I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process. Well... this makes sense, but having the but tracker on SF and the code on GitHub seems a bit like a suboptimal option -- though since SF don't really link bug tracker and VCS maybe it'd not really change anything. But the point on the possible future of GitHub is important IMO. if we have no guarantee for the long-term viability -- and when I read you I read I'd not be really surprised if it happened --, do we really want to use this? I mean, if we need to switch to another official repo next year because GitHub decided not to continue to provide (free) hosting for us, it'd not be really good. But yeah, switching to Git doesn't even mean going away from SF (though it couldn't be bad :D), they also offers Git repositories. Just no fancy around like merge requests, reviews co. I haven't either checked the other sites (Gitorious, ?) deeper, maybe they are good candidates if we don't want the BT functionality? don't know -- apart that I already have and account on Gitorious and wasn't scared by their policy. I really have nothing specific against GitHub (actually from what I have seen I like it better than Gitorious) and I have no evidence they are planning to change their policy. What I wanted to say is that the selection of the right VCS hosting site is much less critical decision than hosting of the bug tracker. If you decide to change the git hosting site for some reason, there's no problem - you push your repository there, update a few links and you're done. But this is much harder to do with the bug tracker and it should be double-checked it satisfies all your needs from all possible perspectives. Bug tracker switch and VCS switch are really two different things. Actually one possibility is to really keep the main git repository under SF and just mirror it to GitHub so people can create their personal branches. Git is a distributed VCS so it doesn't matter where the master repository is located. In fact, there are three different questions: 1. Do we want to switch to git? 2. Where should we have our git repository hosted? 3. Where should we have our bug tracker hosted? I suggest answering and implementing them one by one. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Mon, May 9, 2011 at 16:16, Colomban Wendling lists@herbesfolles.org wrote: Cons from the previous thread: - It's more social I have some cons against social networks, but there are pros here, so... - Not plain enough (I guess too Web 2.0/feature-full/cluttered) I don't personally mind if it's not intrusive. - Effort required to move the project That's the big part! Not that bad if you move the repository only to GitHub - see below. - No need to maintain changelog and authors files That's not true. Our ChangeLog don't contain each and every commit, nor necessarily the whole commit message. Although I don't personally second such ChangeLog (mostly because we have to maintain it and it's the biggest source of conflicts), I understand the point of Nick and Enrico to keep it, and won't start discussion on this again. Could you point me to the discussion? I've missed that one. (I too find a manual-maintained ChangeLog to be too much effort with too little gain.) 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. The difficult part is moving bug tracking I guess. If we end up having 2 bug trackers it'd become quite a pain :/ I'd say that VCS migration and bug tracking system migration should be done separately and independently. Migration of the bug tracker is a lot of work while migration to git is quite easy. I'd also be rather cautious before moving the bug tracker to GitHub. At the moment they are offering hosting of open source projects for free but there's no guarantee it will be like that in the future as well. This is no problem with the git repository if they get evil - you can always upload the repository somewhere else and update a few links on the geany's home page. However with the bug tracker it would be a much more painful process. 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. Before moving all main commiters should agree (e.g. Nick and Enrico), Enrico doesn't care, you like it, so the one who will have to decide is Nick :-). but I think the creating par would not be the real problem. As discussed further later in thread the problem is more setting up correct hooks to keep all repos up to date. But those hooks were meant to be used to have a git mirror on GitHub if there's no VCS switch (mirroring the current git mirror of SVN). I don't see any point in having multiple git mirrors if you switch to git (well, actually everybody's personal clone would be such a mirror). Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
2011/5/8 Enrico Tröger enrico.troe...@uvena.de: Hi Enrico, in principle you have to put something like git push --mirror your_github_repository under .git/hooks/post-receive (in the local geany repository). When creating the github repository, you should create a new public/private key pair and make sure that the keys are available for the user who runs the git command. If you have multiple keys or there are several users, you may use this technique: Thanks for the information. However, this sounds like more work than I can effort to do. I just don't want to start with this and then it delays to ever like many other things I started (shame on me, but working on it :D). I can set up a repository at GitHub, test everything and describe what needs to be done in greater detail. But I'll do it only if the decision is _not_ to switch to git as a primary VCS for Geany in which case this work wouldn't be necessary. If anyone has time to write such a script, I'd be happy to include it as a hook script. Btw, we already have a GIT mirror at repo.or.cz: http://repo.or.cz/w/geany-mirror.git Not sure if that helps anything. Oh, I didn't know about it. How do you push commits there? It should be about the same for GitHub as well. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
On Thu, May 5, 2011 at 00:44, Colomban Wendling lists@herbesfolles.org wrote: Le 04/05/2011 23:40, Jiří Techet a écrit : [...] Last time I was using Glade 2 I had to modify some system header files because Glade was using some obsolete interfaces that apparently nobody else used/tested. That's not completely true, the fix can be done in Glade2 code rather than GTK headers. We even have a patch: http://download.geany.org/glade-2.12.2-build-fixes.patch :) Good to know, the patch really fixes the compilation errors. Maybe there should be a link to it here http://geany.org/manual/dev/hacking.html#glade under the Glade section (or the tarball could already provide the patched version). Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bumping Geany's GTK minimum requirement to 2.12
2011/5/4 Enrico Tröger enrico.troe...@uvena.de: Hi, any objections in increasing the GTK minimum requirement of Geany to GTK 2.12 (and GLib 2.16)? This would make quite some code obsolete and so could be removed. Also, it would make it easier to migrate to using Glade 3 with GtkBuilder instead of Glade 2 (and in the long term makes getting compatible with GTK3 easier, but really, later :D). Though I'd like to do this step some time later. Also we could rely on GIO which came with GLib 2.16 which should remove some #ifdefs. I think the current minimum of GTK 2.8 can be increased as GTK 2.12 is already about three years old already. Any objections? Hi Enrico, I definitely support that. Last time I was using Glade 2 I had to modify some system header files because Glade was using some obsolete interfaces that apparently nobody else used/tested. And this will be getting worse I'm afraid. Apart from that the UI of Glade 2 is pretty ugly. There will still be two options for people on older systems: 1. Use older version of Geany (these people will have to use old versions of all other software anyway so they are used to it) 2. Compile a newer version of GTK themselves. This is what I do at work on SLES 9 (which ships with GTK 2.4). Basically you have to compile pkgconfig, freetype, fontconfig, glib, pixman, cairo, pango, atk and finally gtk. About 3 hours of work (of which 2.5 hours is browsing the web while waiting until it gets compiled). Porting to GTK 3 is pretty straightforward but it really depends how many GTK2-specific things Geany uses. I can have a look at it once a GTK3-compatible Scintilla is used by Geany. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Mon, May 2, 2011 at 18:46, Colomban Wendling lists@herbesfolles.org wrote: Le 02/05/2011 00:03, Jiří Techet a écrit : I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns). A bit ugly in the idea, but I understand the point and it's nothing like a big change, so it's now done (API 211). Thanks. As the next step I'd like to get the plugin into the Geany Plugins project. Can I get commit access (or how does it work)? You need a SF.net account, and then tell it to one of the admins and he'll add you to the project. Apart from that the plugin is now missing some mandatory files like README's NEWS and so on - I'll fix that in the upcoming days. What else needs to be done? Integration with the geany-plugins build system if you want to be part of the geany-plugin releases. This may be done by others if you ask to -- e.g. Enrico maintains the Waf build system and Loong Jin the autotools one, but some others may be able to do it too, so just ask here. I think I can do it myself, the build system doesn't look too complicated. I'll ask for my plugin's inclusion into geany-plugins once I'm done with that. By the way, if you feel bored, you can have a look at the remaining patches in my branch ;-). A few of them are trivial ones, it's just a matter of deciding whether they should be part of geany or not. And if you don't like how something is implemented, just tell me and I'll make the necessary modifications. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Mon, May 2, 2011 at 16:33, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 02.05.2011 00:18, schrieb Jiří Techet: Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches. The core developers don't show very much enthusiasm since a while *in general*. Well, that's not entirely true I admit, Colomban is doing a great job and Nick has been more active recently too. But my general feeling, that the community around is more active these days, remains. But the question of whether to switch to git or not has to be decided by the very core developers (Enrico, Nick). Without their decision all our discussion is pointless because the switch just won't happen. So direct question: Enrico, Nick, what's your opinion on the git switch? As Matthew said, it seems that it's possible to access a github repository both via svn and git so both the current workflow and git-based workflow should be possible. Of course I'll try to help with whatever I can during the migration. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Sat, Apr 30, 2011 at 23:57, Colomban Wendling lists@herbesfolles.org wrote: Le 28/04/2011 22:58, Jiří Techet a écrit : On Thu, Apr 28, 2011 at 19:46, Colomban Wendling lists@herbesfolles.org wrote: Le 28/04/2011 01:49, Colomban Wendling a écrit : Le 10/04/2011 15:03, Jiří Techet a écrit : [...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified I'll review this one later (tomorrow if it goes right). I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice. I agree it's not very nice, on the other hand I think it's the smallest patch that achieves what I need. Modifying msgwin_parse_grep_line() isn't enough, you'd have to modify parse_file_line() and be _very_ careful because you could screw up parse_compiler_error_line() which uses this function too with different parameters. I wrote a different implementation, and I think it works OK. Actually I replaced parse_grep_line() by a more generic implementation of file[:line[...]] parsing. If it has any flaw, just let me know :) Looks good after both looking at the implementation and testing it briefly. Yeah true, even getting it to work properly is quiet a pain, right. Anyway, implemented in SVN now. I've tested it and my plugin works with mainline geany now - great! I'll need one more thing - to bump the plugin API version number. Even though the API hasn't changed, people shouldn't use my plugin with previous versions of geany (it wouldn't work because they couldn't specify the patterns). As the next step I'd like to get the plugin into the Geany Plugins project. Can I get commit access (or how does it work)? Apart from that the plugin is now missing some mandatory files like README's NEWS and so on - I'll fix that in the upcoming days. What else needs to be done? Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
On Sun, May 1, 2011 at 23:46, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 30.04.2011 11:48, schrieb Matthew Brush: I think the more important part is, are the core developers going to accept pull/merge requests on github/gitorious, apply commits/patches from there, etc.? If it's only going to be another read-only git mirror, it's kind of pointless. I don't mean to say that it's a bad idea to have the official Geany source available on various projects sites to fork/hack on and stuff, just that it doesn't address the problem being discussed at all. I agree it's not as useful, but I disagree that it'd be pointless. We can still benefit from the social coding aspects of github, including but not limited to an overview over the forks, pull requests between forks. I would greatly love to see that, as I'm subscribed to a number forks by now :) Yes, I would also prefer if there was a proper and complete git switch (it would greatly save maintainer's work IMO) but I haven't seen much enthusiasm from the core developers for the move so it's better if people who use git have at least an up-to-date git mirror from which they can create their private branches. BTW: is there some possibility to have an svn mirror of a git repo. Perhaps if you have admin access to the bare svn repo? I guess you could git svn dcommit from the post-receive hook if you have access to the git repository. But I guess it works for simple commits only and not merges and so on. (To your question regarding writing my name - I write it that way myself too because I'm lazy to switch to Czech keyboard so I guess it's OK ;-) Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Thu, Apr 28, 2011 at 19:46, Colomban Wendling lists@herbesfolles.org wrote: Le 28/04/2011 01:49, Colomban Wendling a écrit : Le 10/04/2011 15:03, Jiří Techet a écrit : [...] 2edb068b81cb6d541d667efecd0ec4c346f0df51 Open the file in the msgwindow even if no linenumber is specified I'll review this one later (tomorrow if it goes right). I don't really like the patch and preferred to change msgwin_parse_grep_line() to something that directly parse file[:line[...]] so no need to do everything twice. I agree it's not very nice, on the other hand I think it's the smallest patch that achieves what I need. Modifying msgwin_parse_grep_line() isn't enough, you'd have to modify parse_file_line() and be _very_ careful because you could screw up parse_compiler_error_line() which uses this function too with different parameters. Though, why did you add a g_file_test(filename, G_FILE_EXISTS) before document_open_file()? Was it not to show unable to open file when the line don't actually contain a file or is this just a duplicate? Precisely, otherwise the error appears in status bar every time you click a message without a filename in it. However, again, I'm not sure why it's so important for your plugin since it may easily add a line suffix, though it's a little hackish, I admit. Exactly. When I search for a file with the given name, then the result like foo_bar.c:851 looks a little strange (I had to put the current cursor's position there if the file was opened, otherwise the buffer scrolled to a different place). So even though there's a workaround, I'd prefer to have it handled in geany. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Thu, Apr 28, 2011 at 19:52, Colomban Wendling lists@herbesfolles.org wrote: Le 28/04/2011 02:06, Lex Trotman a écrit : I understand that if your plugin makes use of some file patterns, it then makes sense to show them in the FIF dialog. But Geany don't use project patterns, and adding such patters to projects seems useless to me since their only usage is to show them in the FIF dialog... but IMHO they don't make much sense since they don't mean anything more than an arbitrary set of patterns stored with the project files (we have pattern history, isn't that sufficient here?). So maybe there are good reason, but couldn't simply your plugin provide the functionality? (though showing them in FIF dialog would probably not be possible ATM) IIRC Jiri's plugin makes *heavy* use of file patterns, so showing them in FIF is important to giving the user an integrated experience, it wouldn't be good if the plugin provided another FIF system. As you say a patch is needed to allow that. Storing them in the existing project file was IIIRC a way of getting them to appear in the recent list for FIF. Well, we already have history to the pattern list anyway (AFAIK?)... and maybe something like fif_set_file_filter() or whatever would be just fine? Actually this is how it was originally implemented but (if I remember correctly) then someone on the mailing list suggested the way it's implemented now and I prefer the current implementation at the moment. Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git Switch (again)
Hi Matthew, you couldn't express my feelings better. On Thu, Apr 28, 2011 at 07:01, Matthew Brush mbr...@codebrainz.ca wrote: On 04/27/11 21:01, Lex Trotman wrote: - No need to maintain changelog and authors files Changelog and authors are still needed for tarballs, but maybe they can be automated? Seems not too hard with git log and some shell script[1]. I think the original thread also mentions a way (or that it's possible). http://live.gnome.org/Git/ChangeLog - Proper attribution, blame and history for contributors and not having to put Thanks in all the commit messages. Still needed as above. There would be no need to use Thanks in each commit message, since the author of the commit is the person who wrote the code in it, for example[2] where I just sent Neil a properly formatted patch of my local commit and he applied it directly, keeping the history in tact. If it needed fixing to get added into the main code, this will also be reflected in the history by the next commits to fix it (and I believe the original thread says another way to do this), so no need for Based on patch by ... in any commit messages either. Just for completeness, sometimes the patch needs to be modified by the maintainer but in these cases it's better to have 2 commits - one containing the original patch and one with the maintainer's changes (especially when the modification actually screws up the original patch). If you were maybe referring to the THANKS file, I would imagine that could be generated automatically as well from the log. From my experience this doesn't work so well because people sometimes send patches from different email addresses. But the THANKS file update can be done just before making a release and it's not the hardest thing to do. - Built-in Wiki software That could be useful to take some load off Enrico and his servers, currently the project still depends heavily on his resources. That was my thought. Does your somescript mean that both sites could work for an interim period with the old one being deprecated for later removal? I believe so, yes. I'm no expert on these things, but I guess there must be some way to mirror either the SVN to Git or vice versa by using some hooks or something. Another way probably is using git-svn and dcommit to SVN and then push them to Git. Google turns up this[3], amongst others. Geany already updates its official git mirror (http://git.geany.org) from SVN so this works and synchronization between git repositories is a matter of setting up a post-receive hook. One more idea - even if the core developers don't want the switch, at least the current geany git repository could be set up to push changes to github so people who want to use git have an up-to-date mirror from which they can clone and create their personal branches. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Wed, Apr 27, 2011 at 02:58, Matthew Brush mbr...@codebrainz.ca wrote: On 04/26/11 11:45, Dimitar Zhekov wrote: On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techettec...@gmail.com wrote: more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far. Not an exception, the X session management is 9 months old too. Perhaps we should create a geany-patches project or something?.. It seems to me that the whole problem could be (dis)solved using (for example) GitHub since you can just fork the main repository, hack hack hack, and send a pull request/patch, which winds up in a proper queue of pull requests right on the main project repo in a pretty list, so people wanting these features before the developers get time to review them, can see all of these requests in the queue and know they are coming or are available through the forked repositories. Additionally, the core developers get a nice list of pending pull requests to work through, that never gets buried or forgotten, and other outside developers can know what everyone else everyone is doing. Also, with using such a VCS, all the patches have the correct authors and can be blamed and so on, complete with a perfect history of the project (including developers who don't have commit access on the main repository). The icing on the cake, is all the cool network, impact, etc graphs and wicked interface for viewing project history, creating patches, and even committing small bits of code straight through the website (directly on the file or through Gists/pastebins). I'm saying GitHub because I've only really used this site, I know there are other similar sites, but GitHub interface is *very* nice in comparison to say Gitorious or Launchpad. Also, I don't mean to start a holy war of VCS, I know people all have preferences, but my observation is that all of these DVCS foster community involvement more and lower the barrier of entry to helping out greatly. Sorry if I sound like I'm on the sales team of GitHub or something, but after using it for a while, SourceForge/SVN seems crude in comparison, and I get really frustrated trying to use the SourceForge interface and contributing to projects hosted on it, especially ones using centralized VCS. I couldn't agree more! I was proposing a switch to git a year ago here: http://lists.uvena.de/geany-devel/2010-June/002602.html The conclusion was that nobody was really opposed to it but nobody felt an urgent need for it either so it was left as maybe in the future. But maybe it's a good time now to renew the discussion now. Apart from the advantages you mention, using git also greatly reduces maintainer's time when the maintainer trusts the developer who submitted the patches - then the patch review can be reduced just to git pull patches_for_review git push I'm using gitorious and have no experience with github but I must confess that I'm not completely satisfied with the user interface so maybe github is a better option (personally I don't care so much). So in short, I agree that using git as VCS could greatly contribute to both fixing the lost patches problem and, more importantly, significantly reducing the maintainer's work. I'll be more than happy to help with the VCS migration if the geany community decides for it. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Sun, Apr 10, 2011 at 15:03, Jiří Techet tec...@gmail.com wrote: 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, more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far. Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative. Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Tue, Apr 26, 2011 at 11:30, Frank Lanitz fr...@frank.uvena.de wrote: On Tue, 26 Apr 2011 11:18:16 +0200 Jiří Techet tec...@gmail.com wrote: On Sun, Apr 10, 2011 at 15:03, Jiří Techet tec...@gmail.com wrote: 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, more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far. Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative. Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them. As from my point, I'm afraid I cannot add much value to this as I'm not very experienced with GOBject and stuff. That's why I didn't mess around with your patches also. Hi Frank, you probably confuse my patches with something else - there's no GObject involved in my code. The G stands for Geany or Glob (whatever you prefer) and the plugin serves for better project management and easier handling of huge projects (displays project file tree, enables header/source swapping, makes searching inside project easier, enables searches by file name). However, there are still some missing patches (those three mentioned above) I need to get applied in geany in order to make it working. The rest are just random improvements and bug fixes. And as I mentioned according to plugin interface discussion, I like to have it this way for enabling GObject fun: I want to have someone with experince managing this kind of stuff. This is actually me but personally I have no interest in introducing gobject into Geany - you need quite a lot of boilerplate code and Geany's code is very nice in doing things in a simple way. Also as you say, it requires some extra knowledge so it reduces the number of possible contributors, which isn't a good thing IMO. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GProject - missing Geany patches
On Tue, Apr 26, 2011 at 14:30, Matthew Brush mbr...@codebrainz.ca wrote: On 04/26/11 02:18, Jiří Techet wrote: On Sun, Apr 10, 2011 at 15:03, Jiří Techettec...@gmail.com wrote: more than two weeks have passed without any response and I fear it will end the same way as many times before - that I post my patches, nobody looks at them and they get forgotten. I fully understand that people have limited time to work on geany (so do I), the problem is that most of the patches are 9 months old and they haven't been reviewed so far. I think in addition to time constraints, the limited number of committers means that there's basically only 3 people who can/will review patches and commit the changes to the core code. Of course I understand that you may not want to have some patches merged to geany - just tell me and I'll either remove or rework them. I'd just like to get some sort of feedback - positive or negative. Heh. I almost sent an identical sentence in a message to the ML a week ago, but then just decided to focus my (limited) development time elsewhere. Please let me know if there's anything I can help with to get the patches reviewed. Or, if you don't want my patches at all for some reason, please tell me as well so I stop spamming the mailing list with them. My only suggestions, as someone without commit access, who is outside of the core developers, but who has submitted some patches are to file bug/feature reports on SourceForge so at least your patches won't get buried over time in the archives. I can't imagine any of the developers searching through the ML archives for the word 'patches' to see what else they can review. Another thing would be to send small digestible patches as attachments, or at least hyperlink to the exact commits, in your email/bug reports/feature requests. Basically, if I was a committer with maybe an hour or two a week I did this already here: http://lists.uvena.de/geany-devel/2010-August/thread.html (search for emails with PATCH and my name). I can repeat the same, I just don't want to spam the mailing list too much in case nobody is interested in them. To be fair, some of the patches were applied eventually but still I find it a bit discouraging that most of the time I posted them to the mailing list, I didn't get any response. to review patches, I would not want to have to learn to use a new VCS, hunt down and clone a local repo, locate the 3 commits, pull out patches for review, and *then* review them. Last time I was asking Nick about whether I should rather send the patches by mail he said it was alright the way I did. And as I said above, I can send them by other means as well. Cheers, Jiri ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] GProject - missing Geany patches
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] update GNU regex - Re: What's the point of compiling geany without regex support?
On Fri, Oct 15, 2010 at 14:24, Nick Treleaven nick.trelea...@btinternet.com wrote: On Tue, 12 Oct 2010 14:30:00 +0200 Jiří Techet tec...@gmail.com wrote: Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way. I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it. It might be best to use the version from latest CTags. The gnu_regex/README.txt says: Minor changes were made to eliminate compiler errors and warnings. Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers. As far as I remember the CTags version and the glibc version of regex are basically the same. They're not the same, the diff is significant. OK, was doing it some time ago so I was probably wrong. I think we should use the CTags version. I also changed some symbol name in the regex sources because of a conflict with some symbol in my system header files. What's the conflicting symbol? It was in regex_internal.h - I had to change: # define __mempcpy mempcpy to # define ___mempcpy mempcpy but I expect CTags fixed this somehow too. Regards, Jiri Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] update GNU regex - Re: What's the point of compiling geany without regex support?
On Tue, Oct 5, 2010 at 17:03, Nick Treleaven nick.trelea...@btinternet.com wrote: On Wed, 25 Aug 2010 21:47:08 +0200 Jiří Techet tec...@gmail.com wrote: Attached you'll find a patch that updates the regex library to the latest version from glibc. This removes the warnings Lex was experiencing on a 64bit machine. I looked at how ctags does it and made the patch in a similar way. I'm not sure if the glibc version will build on Windows. I don't have a Windows build environment set up ATM to try it. It might be best to use the version from latest CTags. The gnu_regex/README.txt says: Minor changes were made to eliminate compiler errors and warnings. Using the same version as CTags could potentially also prevent any regex-incompatibility bugs with CTags parsers. As far as I remember the CTags version and the glibc version of regex are basically the same. I also changed some symbol name in the regex sources because of a conflict with some symbol in my system header files. Jiri Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman ele...@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong
prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo {
struct bar {
int i;
};
}
This works for me - if you press }, it should get unindented. How did
you enter the code (copy-paste or something like that)?
fair enough, the } regex doesn't expect anything after it so I added
.* after the } but now I get
class foo {
struct bar {
int i;
};
}
The }; line undents two levels??
Your regex is not correct - the (un)indent_this_line_regex is
evaluated every time you press a key and if it is satisfied, the
current line gets (un)indented. So with ^[[:blank:]]*\\}.*$ you used,
the regex first matches
}
and after you type ;, it again matches
};
so it unindents twice. This means the last character in the regex
should be the one that causes the change of indentation } in this
case.
Cheers,
Jiri
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Tue, Sep 21, 2010 at 03:10, Lex Trotman ele...@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong
prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo {
struct bar {
int i;
};
}
fair enough, the } regex doesn't expect anything after it so I added
.* after the } but now I get
class foo {
struct bar {
int i;
};
}
The }; line undents two levels??
Cheers
Lex
Another problem I found, if a comment line ends in { then the next
line indents when it shouldn't
Yes, this is a bug - I check whether I'm in a comment or in a string,
but when enter is pressed, I should check the previous line as well.
Should be easy to fix. Thanks for noticing.
Jiri
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [Patch] : On closing the last tab create new untitled document.
On Wed, Sep 22, 2010 at 02:34, Colomban Wendling lists@herbesfolles.org wrote: Le 22/09/2010 02:20, Erik de Castro Lopo a écrit : Nick Treleaven wrote: So closing the last new document doesn't create a new document straight away? Correct. Are you sure you're running current SVN? Absolutely. I have checked. Twice. For me it works perfectly well (SVN r5250). I close the last tab, a new empty one opens right away. Anyway, Frank Lanitz has asked for a pref for this and personally I don't really like the behaviour. Earlier you said: This is simply what every other app I can think of that uses tabs does when the last tab is closed. Gedit (2.20) does not do this. Do you have examples of a text editing app with this behaviour? I personally see the behavior Erik want as natural (don't know why), but I really don't care about it. That said, I don't see why it is be a problem since a single, fresh, empty tab is closed when opening a file. So perhaps: why *don't* do this? But again, I personally don't care. And just to keep the number of people who like/dislike this feature balanced, I must say I rather dislike it :-). I find it strange when I press the 'x' button on the tab and the tab reopens again. I had a look at other editors and it works this way: * editors which have x button in the tab to close it do not automatically open empty document (gedit, codeblocks) * editors which don't use tabs or don't have close button in the tab open empty document In my opinion the only correct way to implement the automatic empty document opening is also to hide tab bar completely when only a single document is open (SciTE does it this way). Actually this would be also nice to save some extra space in the editor for the editing area if people are editing just a single document. Alternatively the x button should disappear if a single tab is displayed (firefox works this way). That said, this is actually not a feature I care much about so can stay the way it is if the majority of people prefer the current behaviour. Jiri Regards, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Wed, Sep 22, 2010 at 13:47, Lex Trotman ele...@gmail.com wrote:
On 22 September 2010 20:47, Jiří Techet tec...@gmail.com wrote:
Hi Lex,
On Tue, Sep 21, 2010 at 02:41, Lex Trotman ele...@gmail.com wrote:
Hi Jiri,
Got it working, I'd put the regexes in the filetypes in the wrong
prefix, my mistake :-D
But it doesn't seem to be working as expected.
Using only the first two of your regexes the following gets:
class foo {
struct bar {
int i;
};
}
This works for me - if you press }, it should get unindented. How did
you enter the code (copy-paste or something like that)?
No, I just typed it in order from the first character to the last }.
Note that the } before did undent correctly. Any suggestions what to
look at?
Hmm. Do you use current chars or match braces method? I use match
braces normally and I haven't tested current chars so much so there
might be some bugs. Also what line endings does your document have? I
had some problems with matching lines containing CRLF because CR
remained at the end of line and the pattern never matched. But this
one should be fixed. No more ideas right now.
Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Wed, Sep 22, 2010 at 14:06, Lex Trotman ele...@gmail.com wrote: Welcome to the per project per filetype build command configuration problem :-D Exactly what I want to avoid ;-). Ditto :-) The build system solution of using the current file to select the filetype is, as you have pointed out in the past, potentially confusing, but the alternative is very bloating, especially since with custom filetypes you have to be able to handle an unknown number of filetypes. So I'd have to say that, for now anyway, the way to go would be for the combo box in the project and global prefs dialogs to show only the styles from the current filetype (plus none and basic) and to only set the current filetype. If it's for the current filetype only, then I would just copy the most confusing part of the per-filetype settings - I definitely don't want to do it this way. Maybe some standard indent styles could exist so e.g. if you select GNU style in the project settings dialog, geany would search for [indent-gnu_style] section in the filetype settings file for each file you are using in your project. Except for files where you have set it manually of course. Well gnu-style is meaningless for Python, and I wouldn't expect C to have a Stroustrup style etc. so the fixed list for all filetypes is always going to be insufficient. OK, another idea. There would be a global and per-project preferred indent style option containing the standard styles. What are the standard styles and where are they defined? There would be a list of styles e.g. in geany.conf, for instance something like this: preferred_style_list=GNU style;ANSI style; KR style Just a list of names that would be used to populate the preferred indent style combo. The styles themselves would then be defined in individual filetypes and based on the style name match with the preferred style, either the default or the matching style would be used. Every filetype would have its own default style and arbitrary number of additional styles. Are these hand edited in the filetypes files? (Personally I don't think there is anything wrong with saying they are manually edited in the filetype files) Yes, the GUI for that would be too bloated. If one of the styles matches the preferred indent style, this style will be used. Otherwise the default style will be used. This is still only ever going to be right for one language because only one will match, might as well just use the default from the filetype file.. So for python, which has basically one style only, this single style will be always used no matter what the preferred style is. Yep, Python is an exception since the indent style is part of the language syntax so there isn't any choice, but the bracketed languages have several options and they don't overlap much (I'm no Java style expert but as I understand it the default is different to GNU and ANSI but probably closest to Stroustrup, and Perl has no style :-) Depends what you want to indent. If we are talking only about indentation after braces (or, in general, begin and end block markers), I think C is a superset of all styles. Of course there are millions of variants like whether to indent public:, private:, ..., case: in switch and so on, but Geany shouldn't do that (of course if someone decides to write his own regexes, he can) because this is really very individual. So the basic set of indent styles is quite limited and can be applied to non-brace langauges as well (I think all the C styles make sense for pascal as well). In general I think indenting less is better than indenting more - it's not such a big problem to press tab in special cases when the text doesn't get indented automatically. Finally, the document menu would have a submenu with all indent styles for the document's filetype. This is IMO the only place which you expect to be per-filetype. Yes. Please note that my expectations for indenting may be a bit high because I am forced to use Emacs for work at the moment and the indenting works really well (for C/C++ anyway) but is much more complex. Have you given any thought to if there is a regex that would indent continuation lines (eg ending in comma) but for that line only. IIUC Jedit has a regex that indents only the next line without incrementing the indent level. I'm afraid that detecting such cases with regexes would be much harder - braces are quite unique but commas are much more overloaded. Also there are too many different options how much to indent - fized size, aligned after = in assignments, behind the latest opening brace and so on. These are almost impossible to do in a more generic way and would force the users to use some very specific style. As I said, indenting less is better IMO for a multipurpose editor like geany. Jiri Cheers Lex Cheers, Jiri Cheers Lex Cheers, Jiri Maybe a later extension would be to save the style with
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Fri, Sep 17, 2010 at 01:23, Lex Trotman ele...@gmail.com wrote:
On 17 September 2010 06:17, Jiří Techet tec...@gmail.com wrote:
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
thomas.mart...@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:]]*$
Yes, I read the instructions (rare I admit) and I copied these regexen.
I'll see if I get time to look at it some more today or tomorrow.
Note that unless you are going to add the regexes to all filetypes
then Geany still needs to behave as it currently does when there is no
filetype regex(es).
Currently geany only indents languages with braces (C, C++, Java,
Perl, ...) and Python, so these are the only languages whose patterns
have to be set. I think it is really best to set the patterns
per-langauge - there may be slight differences between C and Perl for
example. But it should be no problem to copy the patterns to the
filetype settings files that go under /usr/local/share/geany.
What I'd like to see and what I'm not sure about how to do it in a
nice way is the possibility to switch between different indent styles
for different projects/files. For instance I maintain a project that
uses the GNU indent style while geany uses the ANSI style. Suggestions
are welcome.
Cheers,
Jiri
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH 05/19] Don't be annoying when not necessary
On Wed, Sep 15, 2010 at 23:15, Colomban Wendling lists@herbesfolles.org wrote: Hi, Le 16/08/2010 02:51, Erik de Castro Lopo a écrit : Jiří Techet wrote: When reloading a file with ctrl+R don't display the warning dialog that the unsaved changes might be lost when the file has not been modified. I've been running with this patch for about a week. Looks good to me. This one seems to have been applied as r5190, and I have a little complain about it, so perhaps it would need a little more thought. The problem is that reloading a document not only looses unsaved changes, but also undo/redo stack. This is particularly annoying if you hit the shortcut by accident (which I unfortunately did :( ). So I propose to two possible solutions: 1) simply check whether there's possible undo/redo, and if yes, ask before reloading (little patch joined); 2) the solution 1 fixes my problem, but probably not (?) for somebody that was annoyed by this dialog like Jiří was. So, perhaps a... setting (!) would be useful? (1) is OK with me. The moment when I found the previous behaviour annoying was when I created a new project, opened several files and then realized that the indent indent size in the project settings was different than the actual indents in the files. I modified the project settings but the open files had to be reloaded in order to get the new indent settings. The patch was meant to fix this little annoyance I had with confirming the dialog in a trivial way but if it's causing troubles in other situations, it's OK with me if the patch is reverted. The above situation is not something I run into every day. Jiri What do you think? Regards, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indentation using regex (was [PATCH 14/19] Rewrite tab switching queue)
On Thu, Sep 16, 2010 at 19:27, Thomas Martitz
thomas.mart...@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@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH 14/19] Rewrite tab switching queue
On Thu, Sep 16, 2010 at 17:52, Nick Treleaven
nick.trelea...@btinternet.com wrote:
On Wed, 15 Sep 2010 21:34:52 +0200
Jiří Techet tec...@gmail.com wrote:
Thanks, I'd like to commit this now. I realize it's been a while, but
the patch doesn't apply cleanly and I can't see any commits since that
would have caused conflicts. Any chance you could update and resubmit
please?
Hi Nick,
no problem, I have just rebased all my patches on top of mainline.
This particular patch is attached.
Thanks, but still no joy. The problem is these 2 hunks:
@@ -599,7 +599,7 @@ static void on_document_close(GObject *obj,
GeanyDocument *doc)
{
GeanyDocument *last_doc;
- last_doc = g_queue_peek_head(mru_docs);
+ last_doc = g_queue_peek_nth(mru_docs, 1);
if (DOC_VALID(last_doc) document_get_current() == doc)
{
@@ -607,8 +607,10 @@ static void on_document_close(GObject *obj,
GeanyDocument *doc)
document_get_notebook_page(last_doc));
}
g_queue_remove(mru_docs, doc);
-
- g_idle_add(on_idle_close, NULL);
+ /* this prevents the pop up window from showing when there's a
single
+ * document */
+ if
(gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)
+ g_queue_clear(mru_docs);
}
}
I haven't been able to work out where they apply to. It didn't seem
that a conflict had been introduced since your first patch for this
code, but maybe I'm missing something.
I see, the patch depends on the When closing tab, return to the
document at the top of the MRU list commit. This is actually a commit
I'd really like to see in geany so even though I could make the patch
independent of this commit, I would like both to be applied in which
case their separation doesn't make sense.
Please see the attached files. First apply tab_closing.patch and then
tab_switching.patch. Everything should apply cleanly now.
Jiri
You can find the remaining pending
patches under for_review3 branch here:
http://gitorious.org/~techy/geany/gproject-geany
If you wish me to resubmit them by email, just tell me - I would
Thanks - no need to resend. I can download the patches.
really like to see the patches extending geany's API to be a part of
mainline so my gproject plugin would not depend on patched geany and
could be moved among other plugins repository.
I've applied some this afternoon, will get through them soon hopefully.
Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
diff --git a/src/keybindings.c b/src/keybindings.c
index 4cf2992..0d227c5 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -597,7 +597,17 @@ static void on_document_close(GObject *obj, GeanyDocument *doc)
{
if (! main_status.quitting)
{
+ GeanyDocument *last_doc;
+
+ last_doc = g_queue_peek_head(mru_docs);
+
+ if (DOC_VALID(last_doc) document_get_current() == doc)
+ {
+ gtk_notebook_set_current_page(GTK_NOTEBOOK(main_widgets.notebook),
+document_get_notebook_page(last_doc));
+ }
g_queue_remove(mru_docs, doc);
+
g_idle_add(on_idle_close, NULL);
}
}
diff --git a/src/notebook.c b/src/notebook.c
index a1d10bd..0a4af68 100644
--- a/src/notebook.c
+++ b/src/notebook.c
@@ -551,15 +551,6 @@ notebook_tab_close_clicked_cb(GtkButton *button, gpointer user_data)
/* Always use this instead of gtk_notebook_remove_page(). */
void notebook_remove_page(gint page_num)
{
- gint curpage = gtk_notebook_get_current_page(GTK_NOTEBOOK(main_widgets.notebook));
-
- /* Focus the next page, not the previous */
- if (curpage == page_num file_prefs.tab_order_ltr)
- {
- gtk_notebook_set_current_page(GTK_NOTEBOOK(main_widgets.notebook), curpage + 1);
- }
-
- /* now remove the page (so we don't temporarily switch to the previous page) */
gtk_notebook_remove_page(GTK_NOTEBOOK(main_widgets.notebook), page_num);
tab_count_changed();
diff --git a/src/keybindings.c b/src/keybindings.c
index 0d227c5..3d54cd0 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -562,17 +562,12 @@ static void init_default_kb(void)
}
-/* before the tab changes, add the current document to the MRU list */
-static void on_notebook_switch_page(void)
+static void update_mru_docs_head(GeanyDocument *doc)
{
- GeanyDocument *old = document_get_current();
-
- /* when closing current doc, old is NULL.
- * Don't add to the mru list when switch dialog is visible. */
- if (old !switch_in_progress)
+ if (doc)
{
- g_queue_remove(mru_docs, old);
- g_queue_push_head(mru_docs, old);
+ g_queue_remove(mru_docs, doc);
+ g_queue_push_head(mru_docs, doc);
if (g_queue_get_length(mru_docs) MAX_MRU_DOCS)
g_queue_pop_tail(mru_docs);
@@ -580,16 +575,21 @@ static void on_notebook_switch_page(void
Re: [Geany-devel] editor context menu - Re: Search submenu for editor popup menu
On Thu, Sep 16, 2010 at 13:57, Nick Treleaven nick.trelea...@btinternet.com wrote: On Thu, 16 Sep 2010 09:54:09 +1000 Lex Trotman ele...@gmail.com wrote: 2. let the user pick say four most used top level commands since we are *never* going to agree on them. Use a simplified version of the customise toolbar dialog. Personally I don't think it's worth doing this. Put the most useful things at toplevel, everything else in submenus. Ah but whats the most useful? Things which are useful for the largest number of users. There is also an issue of letting new users discover some useful things easily that they might not know Geany does. I *never* use insert comments from the popup and rarely from the menu (changelog mostly) so for me having any insert comments in the popup is a waste of space. Which is why a single Insert submenu would be better. I'm not suggesting its required, but if someone out there has the time to implement it this would remove all the disagreements :-) Is it so bad to solve the disagreements using submenus? This avoids maintenance and code complexity of popup configurability, which I predict isn't going to be pretty. C is not a good GUI language. Where I really see an advantage of having the context menu customisable are plugin actions. With my gproject plugin and my not-publicly-released ctags plugin I also added several items at the top of the context menu (plus separators). I can imagine that if several plugins do a similar thing, the context menu gets pretty messy (someone will put the new items to the top, someone to the bottom, someone will use separators, someone not, ...) Also the menu starts growing even if the user doesn't really use the context menu item of the given plugin. This is why I really like the Lex's idea of having a fixed set of items in the menu that are always present (possibly containing submenus) and a variable set of configurable items. If the configurable items can be arbitrary items from the keybindings list, the plugins won't have to add their own items into the context menu and the user can only pick those he wishes to be present. It's not necessary to have submenus in the customisable part of the menu - a plain list of items would be fine. By default the variable list could also contain the questionable entries that someone wishes to be present in the menu and someone not. Those who don't want to have them can just remove them if they wish. Of course this would require some work... Jiri ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] po/geany.pot is a generated file
On Thu, Sep 9, 2010 at 10:20, Erik de Castro Lopo mle+to...@mega-nerd.com wrote: Hi all, I would like to suggest that the file po/geany.pot be deleted from the repo. This is a generated file (from po/Makefile.in.in): +1 This is very annoying when using git which complains about missing po/geany.pot which is not created in my case and git consideres the working tree modified because of that. Jiri $(GETTEXT_PACKAGE).pot: $(POTFILES) $(GENPOT) In addition, doing make clean after a geany build, will cause it to be deleted. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH 14/19] Rewrite tab switching queue
On Tue, Sep 14, 2010 at 16:41, Nick Treleaven
nick.trelea...@btinternet.com wrote:
On Thu, 5 Aug 2010 01:59:48 +0200
Jiří Techet tec...@gmail.com wrote:
There was one more bug related to the tab switching. When we switch
so many times that we return back to the original document (so we
actually don't switch at all) then the following switch attempt
doesn't switch immediately to the next document.
After spending two hours thinking what is wrong, I gave up and rewrote
the whole thing in a different way. The problem with the previous
implementation was that before you couldn't just look what's in the queue
now - you had to imagine what will be inserted there in the next step
because the switch_in_progress variable was set after the first switch
(this is also why I put the long comment why mru_pos = 2 - that is not
clear at all when you first look at it). Also there were some not very
nice workarounds like the idle function that was executed after the
switch and removed the double entry on top of the queue.
So with the new implementation things are much simpler IMO. The queue
starts with the current document and the previously opened documments
follow. It's *always* like that, no exceptions. The idle function
is gone and cb_func_switch_tablastused() is simplified too. The rest of
the functionality should be clear from the code.
Thanks, I'd like to commit this now. I realize it's been a while, but
the patch doesn't apply cleanly and I can't see any commits since that
would have caused conflicts. Any chance you could update and resubmit
please?
Hi Nick,
no problem, I have just rebased all my patches on top of mainline.
This particular patch is attached. You can find the remaining pending
patches under for_review3 branch here:
http://gitorious.org/~techy/geany/gproject-geany
If you wish me to resubmit them by email, just tell me - I would
really like to see the patches extending geany's API to be a part of
mainline so my gproject plugin would not depend on patched geany and
could be moved among other plugins repository. By the way, the last
commit in my tree performes indentation based on regex matching as I
was proposing some time ago. I haven't published it yet because there
are already quite many of my patches pending here and I want them to
be reviewed first. Anyway, if you (or anyone else) are interested, you
can have a look.
Jiri
Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
diff --git a/src/keybindings.c b/src/keybindings.c
index 0d227c5..3d54cd0 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -562,17 +562,12 @@ static void init_default_kb(void)
}
-/* before the tab changes, add the current document to the MRU list */
-static void on_notebook_switch_page(void)
+static void update_mru_docs_head(GeanyDocument *doc)
{
- GeanyDocument *old = document_get_current();
-
- /* when closing current doc, old is NULL.
- * Don't add to the mru list when switch dialog is visible. */
- if (old !switch_in_progress)
+ if (doc)
{
- g_queue_remove(mru_docs, old);
- g_queue_push_head(mru_docs, old);
+ g_queue_remove(mru_docs, doc);
+ g_queue_push_head(mru_docs, doc);
if (g_queue_get_length(mru_docs) MAX_MRU_DOCS)
g_queue_pop_tail(mru_docs);
@@ -580,16 +575,21 @@ static void on_notebook_switch_page(void)
}
-/* really this should be just after a document was closed, not idle */
-static gboolean on_idle_close(gpointer data)
+/* before the tab changes, add the current document to the MRU list */
+static void on_notebook_switch_page(GtkNotebook *notebook,
+ GtkNotebookPage *page, guint page_num, gpointer user_data)
{
- GeanyDocument *current;
+ GeanyDocument *new;
- current = document_get_current();
- if (current g_queue_peek_head(mru_docs) == current)
- g_queue_pop_head(mru_docs);
+ new = document_get_from_page(page_num);
- return FALSE;
+ /* insert the very first document (when adding the second document
+ * and switching to it) */
+ if (g_queue_get_length(mru_docs) == 0 gtk_notebook_get_n_pages(notebook) == 2)
+ update_mru_docs_head(document_get_current());
+
+ if (!switch_in_progress)
+ update_mru_docs_head(new);
}
@@ -599,7 +599,7 @@ static void on_document_close(GObject *obj, GeanyDocument *doc)
{
GeanyDocument *last_doc;
- last_doc = g_queue_peek_head(mru_docs);
+ last_doc = g_queue_peek_nth(mru_docs, 1);
if (DOC_VALID(last_doc) document_get_current() == doc)
{
@@ -607,8 +607,10 @@ static void on_document_close(GObject *obj, GeanyDocument *doc)
document_get_notebook_page(last_doc));
}
g_queue_remove(mru_docs, doc);
-
- g_idle_add(on_idle_close, NULL);
+ /* this prevents the pop up window from showing when there's a single
+ * document */
+ if (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 2)
+ g_queue_clear(mru_docs);
}
}
@@ -1728,6 +1730,7
Re: [Geany-devel] [PATCH 09/19] Use wider entry for project file path
On Tue, Aug 24, 2010 at 13:57, Nick Treleaven nick.trelea...@btinternet.com wrote: On Thu, 5 Aug 2010 01:59:43 +0200 Jiří Techet tec...@gmail.com wrote: 30 is too little. For instance /home/techet/projects/geany/geany.geany is 39 characters long and this is really short path. I find 50 characters to be about minimal usable size so users do not have to scroll inside the edit box too often. 50 makes the dialog seem too wide IMO. The user can stretch the dialog as well as scroll the entry. I don't like forcing the entry to be at least 50 characters wide, I wouldn't mind so much if it displays as 50 so long as the screen can take it, but could be reduced by GTK or the user if necessary. I agree the dialog looks better with not so wide entries, on the other hand I *always* have to scroll the entry to be able to edit the path at the end. But I don't care so much about the future of this patch, it's just a minor usability problem I have noticed. Jiri Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
