Devel July 2015

devel@lists.geany.org

16 participants
17 discussions

Re: [Geany-Devel] [Geany-Users] [ANN] Geany 1.25 is out!
by Jiří Techet 13 Jul '15

13 Jul '15

On Sun, Jul 12, 2015 at 11:59 PM, Russell Dickenson < russelldickenson(a)gmail.com> wrote: > Congratulations to everyone involved with Geany's development and > ongoing support. Fantastic work! I love the idea of time-based > releases, though I would have thought you would choose 6-monthly > instead of 4-monthly sprints. > > Thank you to Jiří Techet for the OSX build as it looks fantastic and > works well. A colleague who uses OSX and Linux was recently frustrated > with trying to find a suitable text editor for OSX, given his love for > Geany. The advent of the OSX build solved his problem immediately. Good to hear you find it useful! Let me know if you run into some OS X specific problems. There are a few GTK-related quirks which would require patching GTK and which I probably won't fix but things which are inside Geany itself should be fixable quite easily. Cheers, Jiri

1 0

ANN: Geany-Plugins 1.25 is out
by Frank Lanitz 13 Jul '15

13 Jul '15

Hi folks, Right after the release of Geany 1.25 we are happy to announce also the release of Geany-Plugins 1.25 available via http://plugins.geany.org/ A lot of smaller and bigger changes have been made. For details on a special plugin, please check its ChangeLog. However, these are the most amazing ones: General: * GProject is renamed to ProjectOrganizer * New plugin Automark * New plugin GeanyCtags * New plugin GitChangeBar * New plugin Overview Addons: * Improve URI selection Autoclose: * Add Whitesmith style bracket formatting support CodeNav: * Implement Go to File feature Commander: * Improve sorting algorithm Debugger: * Fix crash with GDB 7.7 GeanyLaTeX: * Fix automatic capitalization of multi-byte characters GeanyVC: * Add support for WinMerge external diff viewer ProjectOrganizer: * Add an "external directory" feature * Add find tag by name * Add ignored file patterns * Performance improvements in tag generation using updated Geany API MultiTerm: * Fix build with recent Vala versions PairTagHighlighter: * Fix clearing previous indicators (PR #200) PoHelper: * Add a statistics dialog * Fix handling of plural forms Scope: * Fix building on GNU/Hurd (PR #146) Spellcheck: * Don't check code of scripting languages embedded in HTML * Add option to perform a spell check on document open Tableconvert: * Improve handling of non-LF line ends * Add support for DokuWiki syntax WebHelper: * Add support for basic bookmarks Internationalization: * Update translations: de, fr, pt, ru You can download a Windows-installer as well as source-tarballs from http://plugins.geany.org/downloads.html For user of Apple's MacOS X it's included to the package. Have fun! Frank

1 0

Windows installer snapshots with GTK 2.24
by Enrico Tröger 11 Jul '15

11 Jul '15

Hi, I've built new Windows installers from current GIT master. Downloads can be found here: http://download.geany.org/snapshots/ Please note that these are test builds from the current development version, don't expect release quality. You have been warned :). After you installed the snapshots, you can also use the nightly builds again on Windows (i.e. copy the archive contents over the installation). Any feedback is welcome. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

6 23

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins
by Steve 09 Jul '15

09 Jul '15

On Jul 8, 2015 7:18 PM, Matthew Brush <mbrush(a)codebrainz.ca> wrote: > > On 2015-07-08 10:57 AM, Steven Blatnick wrote: > > So I've finally got a chance to look at my non-API calls. I was able to > > code around most of them, but there are two that would be much easier if > > we could make them APIs. (I haven't pushed any of these changes to my > > git repo yet.) Could we consider making these API? > > > > * keybindings_load_keyfile - I dynamically add/remove a variable > > number of plugin keybindings based on the plugin settings, so this > > allows me to refresh the results easily. This allows my > > external-tools plugin to have any number of tools with each their > > own keybinding. Otherwise, most plugins have a set number of bindings. > > This sounds dubious. > > I assume you're talking about `external-tools` plugin? Maybe I don't > understand the code enough, but it looks to me like it's just leaking > GeanyKeyGroups in `reload_tools()` and then calling > `keybindings_load_keyfile()` happens to reload the key group it newly > created? > > I completely agree there needs to be a way to dynamically add/remove > keybindings, but I'm not sure we should promote this way if I understand > it correctly. IMO, it would be much better to fix Geany. I agree. Maybe a reload_plugin type function? I saw a similar problem in gedit plugins, where you have to restart the editor for some things to take effect. And you're right, if i remember correctly, I just want to be able to reload my own shortcuts, and the existing call does them all, which is overkill to say the least. > > > * keybindings_lookup_item - I know keybindings_get_item is available > > already, but I am attempting to look up a core group keybinding and > > not plugin's own keybindings. > > This sounds reasonable, though I think it would be better if made public > to rename it to something like `keybindings_get_builtin_item()` or > something. Also I think we should change the signature to use the > correct types (those enums we already expose). Alternatively, is there an event i can tie in to? Basically the issue here is in focusing on the side panel or bottom panel, the focus lands in the wrong place to then capture ctrl+pg_up/down to switch notebook tabs. For example, when focusing my panel in external-tools, I need the focus to update to the read-only text field instead of the notebook tab label. I know I can use tab, but I'm trying to make the usage fluid. > > > * keybindings_dialog_show_prefs_scroll - I remember someone saying the > > "Configure Plugins" window would have a button to this already in a > > later version, but I still don't see it. I only need this API if > > the button isn't added. > > > > Could probably make such a button/link use the same code as the > "Keybindings" button in the Plugin Manager dialog, since it does just > that. It might be a bit awkward UI-wise though. I'm not sure why that would be awkward? I'm away from the code right now, but I think this call is the same as that button, it just needs to be made an API. > > > Let me know if this is possible or how I should proceed. I use geany > > with my plugins daily, and can't upgrade my code base until my plugins > > are working. > > > > Best is to make a PR with the changes you want. Second best is to raise > an Issue and hope somebody else wants them enough to do it. Ok, thanks! I'll see what I can do based on the feedback. Steve > > Cheers, > Matthew Brush > > _______________________________________________ > Devel mailing list > Devel(a)lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel

4 6

Fwd: Re: Github loses comments
by Thomas Martitz 09 Jul '15

09 Jul '15

-------- Weitergeleitete Nachricht -------- Betreff: Re: Github loses comments Datum: Tue, 07 Jul 2015 00:29:38 -0700 Von: Ivan Žužak <support(a)github.com> An: Thomas Martitz <kugel(a)rockbox.org> Hi Thomas, Thanks for sharing those details about your workflow. If you create a comment on a commit which is a part of a pull request, and later on blow away that commit from the pull request with a rebase + force-push combo -- then that commit is no longer a part of the pull request so the comments are no longer shown inline on the pull request page. However, if you create comments on the pull request's diff itself -- then those comments are tied to the pull request. After you update a pull request (even with a rebase), those comments will still be around on the pull request page, but will be shown as "user commented on an outdated diff a day ago". So, my suggestion would be to comment on the pull request's diff if you're using a rebase-based workflow. We understand that commenting on specific commits is helpful in some situations, and we're looking into ways to keep comments around on pull request pages even after you rebase away the commits they were created on. I can't make any promises about this, but it is on our radar. Let me know if I misunderstood anything, if you have any questions or if you want to share more details so that I can pass the feedback to the team. Cheers, Ivan > Hello, > > when a pull request is updated though a history rewrite (e.g. rebase, amend, commits reodered) to make the history accepatable for the main repository, then github sometimes loses comments associated with the pull request. This is annoying as it really makes reviewing *more* difficult. But only ever adding fixup commits is not acceptable either as it would add unwanted commits in the main repository (for example, if they break the build of a project it makes bisecting harder than necessary, therefore some commits are not acceptable for merging into the master branch). > > Can this be fixed? I do notice that github some other times shows comments through "X commented on an outdated diff". This seems a lot better than deleting valuable comments altogether. > > Best regards

4 6

f403e7e (PR#188) - Maintain edit history on document reload
by Thomas Martitz 08 Jul '15

08 Jul '15

Hello I have just noticed that current git, by default, doesn't prompt anymore when reloading documents, even when they are changed. I traced it back to the $SUBJECT commit. IMO it's fine to keep the undo history on reload and not prompt, but it's not fine if the file is currently modified (unsaved) and reloading throws all unsaved changes away, without warning. This is especially problematic because the new pref is on by default so users will probably be surprised by the new, changed behavior and lose some hours of work (happend to me...). I'm asking for restoring the prompt (by default), at the very least if the file is unsaved. Best regards

4 23

Questions about bugs/features trackers
by Minh Bui 04 Jul '15

04 Jul '15

Hello, I'm a student who wants to contribute to Geany. I've read the HACKING file and surf through the bug/features tracking list. There are several questions I would like to ask: 1. What are the "open" tickets? Are they issues that people have proposed and haven't been picked up by the development team? If the answer to the question above is "yes" then: Are the "open-accepted" tickets are tickets that the development team has accepted to work on? 2. Why do we have to use 2 different tracking systems? I noticed that the issues tracking on Github and the one on SourceForge do not match with others. Which is the most active recent tracking system? 4. Assuming my assumption for the first question is correct, I would like to work on this: http://sourceforge.net/p/geany/bugs/1026/. But I'm in doubt because I don't know if someone has already working on this. Thanks a lot! Minh Bui

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel July 2015