Devel

devel@lists.geany.org

1641 discussions

Blank completion popups on Windows
by Colomban Wendling 05 Jun '15

05 Jun '15

Hi everyone, I don't use my Windows VM very often, but I realized today that the completion popups were broken there during the 1.25 cycle [1]. Could everyone using a development version of Geany under Windows tell me whether it works for them or not, and their Windows and GTK versions? I myself tried on XP SP3 with GTK 2.24.10. I found a way to fix the issue, and although it doesn't make any sense, it seem to fix it reliably. Unfortunately it has a small side effect that completion popup will have a minimal height that might be taller than necessary when there is only one item in the list. But this cosmetic detail is probably less problematic than a blank popup, right? :) But I'd like to know if the problem happens to everyone or not, and whether the attached patch fixes the problem for everyone with the issue. Thanks in advance! Colomban [1] http://git.geany.org/geany/commit/?id=4d66bd3745eb3759539b116e7784d11d035eb…

5 19

Open Source Work At Geany
by Atal Akbari 03 Jun '15

03 Jun '15

Hi, my name Is Atal Akbari, I am a 3rd year Computer Science student at Ryerson University, currently looking for open source work in order to test my developing skills at a professional level. I choose Geany as my first open source project because I have previously used Geany and came across the development section while surfing through the website. In addition to this the C/C++ programming language is my strong suit and I am very interested in strengthening my C/C++ skill set. Thank you for the opportunity & looking forward to working with the team! , Atal Akbari

2 1

C# tags for Unity 5
by Deep Thought 21 May '15

21 May '15

Hi! I'm a general programmer/CS student who likes to use Geany for everything textual. I got around to installing the Unity 5 Editor a few days ago but was disappointed to find that its scripting workflow mainly went through MonoDevelop, so I switched that to Geany in the preferences. Unfortunately, this meant I lost all of the built-in autocomplete and hinting features, so I spent a few hours constructing building a .tags file for the Unity 5 Scripting API for Geany. You can find it here: https://github.com/DThought/unity-tags I thought I'd share it in case other people found it useful and could be added to http://www.geany.org/download/extras#tags. By the way, I thought I'd mention that http://www.geany.org/download/extras#colors seems severely outdated, considering there's a completely new theming system in Geany ( https://github.com/codebrainz/geany-themes/tree/master/colorschemes). Cheers ~ Ethan

2 2

Re: [Geany-Devel] [geany/geany] 826f65: Merge pull request #441 from zhekov/spawn
by Dimitar Zhekov 19 May '15

19 May '15

On 15.5.2015 г. 19:54, Colomban Wendling wrote: > Merge pull request #441 from zhekov/spawn > > Add a spawn module for Geany If you have any questions, notice bugs, or have ideas about API improvements, do not hesitate to [fill a bug and] drop me a note. > Thanks a lot for Dimitar's hard work, commitment and endless patience! Thanks to b4n, elextr, techee, and the others who helped. The final spawn was improved quite a bit compared to 1.01. -- E-gards: Jimmy

1 0

GeanyLua compatiblity with Lua > 5.2
by Dominic Hopf 25 Apr '15

25 Apr '15

Hi guys, I've noticed the GeanyLua plugin does not build with Lua versions greater than 5.2. I've stumbled over this since I updated to the current version of Fedora 22 Beta which is with Lua 5.3.0 already. Is someone able to fix the issues and make the plugin compatible with Lua versions greater than 5.2? Otherwise it will be quite a pity since I would have to disable the plugin in the Geany Plugins Fedora package then. I unfortunately am not able to have deeper looks into this myself, for both reasons, missing knowledge and missing time. Regards, Dominic -- Dominic Hopf http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D

5 5

Re: [Geany-Devel] [geany/geany-plugins] 73ae49: waf: Fix the checks for openpty() on FreeBSD
by Dimitar Zhekov 25 Apr '15

25 Apr '15

On 10.4.2015 г. 18:36, Colomban Wendling wrote: > waf: Fix the checks for openpty() on FreeBSD ACK. Please, be sure to use the same check for debugger, it probably needs it. While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version... -- E-gards: Jimmy

7 29

Re: [Geany-Devel] [geany/geany] f03206: Windows: Compile geany_private.rc into Geany.exe for version data and icon
by Colomban Wendling 25 Apr '15

25 Apr '15

Le 12/04/2015 22:54, Enrico Tröger a écrit : > Branch: refs/heads/master > Author: Enrico Tröger <enrico.troeger(a)uvena.de> > Committer: Enrico Tröger <enrico.troeger(a)uvena.de> > Date: Sun, 12 Apr 2015 20:54:16 UTC > Commit: f03206744361baac1c811db97f5d2816409d7787 > https://github.com/geany/geany/commit/f03206744361baac1c811db97f5d2816409d7… > > Log Message: > ----------- > Windows: Compile geany_private.rc into Geany.exe for version data and icon Should we integrate geany_private.rc in the library too? This isn't done with Autotools, but could be added. Though, `waf build -v` warns that geany_private.rc.o is created more than once (doesn't seem to be a real problem though).

3 5

Re: [Geany-Devel] [geany/geany-plugins] 377322: Scope: Fix a typo
by Dimitar Zhekov 25 Apr '15

25 Apr '15

On 20.4.2015 г. 20:09, Frank Lanitz wrote: > Log Message: > ----------- > Scope: Fix a typo > > -<property name="label" translatable="yes">Show =li_brary messages</property> > +<property name="label" translatable="yes">Show li_brary messages</property> That's not a typo, they are =library-... "library" alone does not carry enough info. -- E-gards: Jimmy

2 2

Desktop Entry file change
by Matthew Brush 12 Apr '15

12 Apr '15

Hi, If you package Geany for Linux, you might like to have a quick look at PR #461[0], I want to make sure the absolute path in the desktop file won't cause anyone issues. Cheers, Matthew Brush [0]: https://github.com/geany/geany/pull/461

1 0

Placeholder replacement in (build) commands
by Colomban Wendling 06 Apr '15

06 Apr '15

Hi, To offload the discussion from PR#441 [1] from this partly off-topic discussion and give it more visibility, I'm moving it here to the ML. There already was a thread on the subject that got mostly forgotten, see [2]. I apologize for the long and complex email, but I don't know how to present that in a more concise way without losing important information or clarity. Note: I will use *NIX-style command lines as examples. The ones for Windows are slightly different, but the problematic is basically the same (though we don't use the shell there so it's a bit simpler). 1. So, what are we talking about? Some of our commands can contain placeholders. The most important ones are the build commands, but also e.g. the terminal tool has '%c'. These placeholders are replaced by Geany with various things, like file names, paths, line numbers etc. Some of the commands are executed by a shell (build commands) and some aren't (terminal command). 2. What is the problem? The replacement for these placeholders can be anything, so they might contain characters that have a meaning in a command. The most obvious example is quotes: imagine a file named `foo "bar.c`. If we just replace the placeholder with the raw value (as we currently do) in a build command, e.g. `gcc -c -o %e.o "%f"`, it gives this: gcc -c -o foo "bar.o "foo "bar.c" which is obviously incorrect (see [1] or [2] if it's not obvious for you ;) We need to escape (or quote) replacements in some way or another. 3. So, how can we fix this? Several solutions have been suggested (well, actually 3.5 is new!), each with pros and cons: 3.1. Insert quoted replacement as needed where they appear This is what I first implemented: track the quotes in the user command, close them before inserting a quoted/escaped replacement, and reopen it right after. With the above command, it would give this: gcc -c -o 'foo "bar'.o ""'foo "bar.c'"" which is valid and as we want it (again, see [1] and [2] if it's not clear that it's valid). This is what the patch at [3] (and [2], but the version there is outdated) does. 3.1.1. Pros * compatible with any current user commands (no breakage of the user configuration, and fixes replacement in them); * the user doesn't have to worry about the issue. 3.1.2. Cons * requires understanding of the shell quoting rules (including sub-shell like `` and $()), which might be non-trivial. * if it gets something wrong, the users are mostly screwed (the only thing they could do would be try to adapt the command in a way for Geany to get it right) 3.2. Insert quoted replacements everywhere blindly Replace blindly each placeholder with an escaped/quoted version of itself. This is like 3.1 but doesn't try to manage quotes in the input command. It would give: gcc -c -o 'foo "bar'.o "'foo "bar.c'" (which is incorrect, see the cons below) 3.2.1. Pros * easy to implement; * simple, the user can easily know exactly what happens. 3.2.2. Cons: * Incompatible with (some) current user commands: as the placeholder is replaced without care, the placeholders need to appear outside other quotes. E.g. the above example would have to be altered to remove quoting around the %f placeholder not to be quoted twice: `gcc -c -o %e.o %f`. 3.3. Provide format modifier performing specific quoting Dimitar suggested introducing format modifiers like %"f or %'f that would quote in various ways (see https://github.com/geany/geany/pull/441#issuecomment-87272057). 3.3.1. Pros * The users can quote in various ways as they see fit; * Explicit control on how things are quoted/escaped; * Could support recursive quoting (quoting twice or even more), so Lex could use it in a `python -c` or similar called by the shell ;) e.g. `python -c "print(%\""f.replace(' ', '_'))"` could end up in `python -c "print("foo\ \\\"bar.c".replace(' ', '_'))"` -- assuming we implement the escaping Python requires. happy? :) 3.3.2. Cons * it doesn't fix existing user commands (needs to make use of the new format modifiers); * requires to implement various kind of quoting (which requires knowing several shell escaping rules); * complex and uncommon format modifiers (the users have to pick the right one, which might not be obvious); * the users can screw themselves up if they don't use the appropriate format (could work with some replacement but not others). 3.4. Parse command as an argument vector and replace in each argument Instead of working on the command itself, use g_shell_parse_argv() and perform replacements in argv[1:] (each argument separately). 3.4.1. Pros * no need for quoting or escaping the replacement (as each argument is done on its own). 3.4.2. Cons * doesn't work with shell constructs, so it's not a solution for build commands (as an argv is an argv, which can't support sub-shell, piping and whatnot). 3.5. Use environment variables, not placeholders Change the whole logic and use the environment to pass what currently uses placeholders. E.g. a command could be `gcc -c -o "${GEANY_FILENAME_NOEXT}.o" "$GEANY_FILENAME"`. 3.5.1. Pros * quite easy to implement (but see cons); * no need for quoting or escaping replacements; * works the same as any environment or shell variable; * environment variables can then also be used by the called commands themselves, not only on their command line. 3.5.2. Cons * it doesn't fix existing user commands (needs to make use of the new variables); * requires separate logic (e.g. 3.4) when the command is not run in a shell (as something has to read the replace on the command line itself); * the users can screw themselves up if they don't use the appropriate quoting around the variables (could work with some replacement but not others). 4. So, what? I like 3.1 ("smart" replacement) and 3.5 (environment variables) mostly. 3.1 is the only solution here that doesn't require changes in user commands, so it is seamless on the user. 3.5 leaves the actual replacement to the shell (so the limitations are the ones of the shell), and also gives the information to the children, grandchildren, etc. Note that we perhaps could use something like 3.1 simply to upgrade user commands to the format of one of the other solutions. This way an error in the implementation of 3.1 can be fixed by the user. What do you think? Regards, Colomban [1] https://github.com/geany/geany/pull/441 [2] http://lists.geany.org/pipermail/devel/2012-December/007329.html [3] https://github.com/geany/geany/pull/441#issuecomment-87336184 and https://gist.github.com/b4n/4c100d6f1defd4751217

4 14

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel