Devel January 2016

devel@lists.geany.org

9 participants
6 discussions

Dropping waf
by Frank Lanitz 13 Mar '16

13 Mar '16

Hi folks, It's been a while since Enrico opened https://github.com/geany/geany/pull/769 As we are going straight to March, I'd like to merge it soonish. Any comments about this? Cheers, Frank

2 2

Zombified pull requests
by Jiří Techet 09 Jan '16

09 Jan '16

Hi, happy new year and let's celebrate it with something cheerful - zombies! I've noticed there are more and more pull requests on github which don't get merged to Geany. It's clear that people are fighting with time to make reviews of pull requests (and Colomban does a great job here!), however, it seems to me there are quite many patches where all the hard work has already been done (review, patch updates) and the only missing thing is the merge - which doesn't happen. I think this is quite unfortunate - there are many patches which might be useful for users; at the same time it might be discouraging for contributors to see their patches unmerged. I've been thinking about what may be the cause of this and several things come to my mind: 1. Not enough feedback from other developers. Typically I am for instance in the mode "I don't want to add too much noise" so unless I love or hate something, I just don't write anything. I think Colomban's own patches suffer from this most as he reviews other people's patches but there's no feedback for his own patches. Maybe it would be a good idea if regular Geany contributors go through the pull requests from time to time and just LGTM those that sound reasonable functionality-wise. I'm not talking about full code review here, just a very quick assessment whether the given feature makes sense for Geany (we should distinguish somehow "I made a review of the patch and LGTM" and "the functionality LTGM to be in Geany"). To give an example of such a "functionality review", the fractional font sizes patch https://github.com/geany/geany/pull/407 LGTM - even though I probably won't use it myself, I understand it may be useful for someone and it modifies just 23 lines so it's nothing intrusive and can go in from my point of view. Such a review can be done in a few seconds so if everyone goes through the new pull requests from time to time, the patches will receive some feedback and it will be clearer whether it's something others want it in Geany. 2. Unclear status of some patches. Sometimes it might not be clear in what state the pull request is - I'd suggest adding at least the following two tags: needs-work (reviewed with some comments that need to be addressed) work-in-progress (not meant for review in the current state) This will help to distinguish pull requests awaiting merge and pull requests that aren't there yet. 3. Fear that the pull request isn't tested enough. I believe that if a patch did undergo a review and there doesn't seem anything obviously wrong with it, it can be merged to master. I think there's no need for some long-term private testing of a patch before it gets merged - people using the development versions of Geany should be aware it may contain bugs and should know how to deal with them. There are also more eyes so a potential bug is spotted earlier. Of course it makes sense getting more conservative towards the end of the development cycle to stabilise things. OK, these are things that come into my mind regarding the zombie pull requests but there may be other problems. What do you think? Do the points above look reasonable to you and do you think they might help a bit? Is there anything else that might help killing the bloody zombies? Cheers, Jiri

6 15

RFC: Merge C and C++ Filetypes (no troll)
by Matthew Brush 07 Jan '16

07 Jan '16

Hi, I have been using Geany without the C filetype and opening all C files as C++. I use about 50% each of C and C++, and since I merged the two filetypes quite a few of headaches went away. Some of the benefits: - C or C++ tags always work - Special highlighting of C++ keywords so I know to avoid in C - All C and C++ constructs always work - No ambiguity of *.h files (except w/ Obj-C) Some of the drawbacks: - Using C++ build commands for C doesn't make much sense (although some claim compiling plain C as C++ to be a virtue) - The default C++ extension wouldn't be suitable for plain C Some non-issues (AFAICT): - Both filetypes already use the same Scintilla C++ lexer - For Geany's purposes the CTags C++ parser works for both C and C++ It might be useful to only have one filetype for both. I'm content editing my config files locally, but I just thought it worth discussing to see if I'm mistaken on the perceived benefits/drawbacks. Cheers, Matthew Brush

5 14

RegEx warning on make update-po
by Frank Lanitz 07 Jan '16

07 Jan '16

Hi folks, I'm getting a regex warning when running make update-po from inside po folder. > zh_TW: > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^(.*)\${ <-- HERE ?([A-Z_]+)}?(.*)$/ at /usr/bin/intltool-update line 1064. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?AC_PACKAGE_NAME}?/ at /usr/bin/intltool-update line 1192. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?PACKAGE}?/ at /usr/bin/intltool-update line 1193. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?AC_PACKAGE_VERSION}?/ at /usr/bin/intltool-update line 1194. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?VERSION}?/ at /usr/bin/intltool-update line 1195. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?AC_PACKAGE_NAME}?/ at /usr/bin/intltool-update line 1221. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?PACKAGE}?/ at /usr/bin/intltool-update line 1222. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?AC_PACKAGE_VERSION}?/ at /usr/bin/intltool-update line 1223. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?VERSION}?/ at /usr/bin/intltool-update line 1224. > Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ?\w+}?/ at /usr/bin/intltool-update line 1225. I'm using very recent Debian $ cat /etc/debian_version stretch/sid Just for reference. Anyone able to "fix" this? ;) Shall I open a gh issue (I have no clue about the autotools thing) Cheers, Frank

2 1

New Lexer
by Mark Robinson 02 Jan '16

02 Jan '16

Hi Guys, Some time ago, I asked how I go about adding a new filetype/language to Geany called DMAP. You kindly told me first to request a new lexer be added to upstream Scintilla, which I did, and it was accepted (it was added to Scintilla 3.3.7). Geany has moved to a Scintilla 3.6.1, which indeed contains the new language. However, when I look in the ~/geany-1.26/scintilla/lexers directory, I do not see the lexer's file (LexDMAP.cxx). In fact, the Geany build does not contain many of the Scintilla files. Is this because only the files that are used are placed in the Geany build? Sorry if this seems like a naïve question (which it is), but if I now move to add a new filetype to Geany, will the references to the "missing" Scintilla source be handled automatically or is there something I need to do? - I don't want to mess things up. Kind regards...M

4 3

Regex in 1.25 and 1.26
by Mark Robinson 01 Jan '16

01 Jan '16

Hi Guys, Is the regular expression capability broken in 1.25 and 1.26 In 1.24, if I pop up the Find dialogue on a simple text file, I can search for \n with reg. expressions ticked and I find the end of the line. If I do this in 1.25 or 1.26, it does not find the end of the line and claims it cannot find \n. I notice single line reg. exp. was added at 1.25. Thanks...M

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel January 2016