On 10 November 2015 at 03:08, Devyn Collier Johnson devyncjohnson@gmail.com wrote:
Geany Dev Team:
I have various ideas for Geany (that do not pertain to the file-extensions and language support) that I would like to share before I write or submit any code.
Also, I found an issue on Geany.org. On http://wiki.geany.org/config/scripts/shell , there is a deadlink ( https://svn.enlightenment.org/svn/e/trunk/devs/discomfitor/geany_tagger.sh ).
The wiki is, well a wiki, that means pages can be added by anyone who has registered (registration required to discourage spammers). The Geany dev team does not spend much time looking at the wiki and does not necessarily check it for accuracy. It would be best to try to contact the page author.
By the way, thank you again, Matthew Brush, for the link to QML on Geany. I then found http://wiki.geany.org/config/start . Why are many of these "goodies" not in the mainstream Geany release?
Because the authors or devs don't want to have to support them. You will notice contributions from Geany devs on the wiki, not in geany, thats because they do not have the time and inclination to test and support these things, but are happy for them to be available to others.
Unless I over-looked it in http://www.geany.org/Contribute/Developers , I assume discussion on plugin and color-scheme development are allowed in this mailing list, or is there a separate mailing list?
The dev list is more for development details, ie how something needs to be implemented. Discussions of user facing stuff (colour schemes, new plugins) should probably be on the user list where it might get more contributions about its usefullness or how it should work.
Ideas
I noticed that on Geany's GitHub page under ./data/templates, there are two license templates ("gpl" and "bsd"). These templates appear in the "Edit > Insert Comments" menu. I would like to add some more license templates and include them in the menu. Does anyone disagree with this idea? I would like to add agpl, lgpl2, lgpl3, gpl3, cc0, and others. To make it easier to add menu items, could Geany be re-programmed to dynamically create that menu based on the templates included in ./data/templates and ~/.config/geany/templates , thus allowing users to add licenses to their own systems?
There was a discussion in the past about what licenses to add, try searching the MLs (user and dev) and the issues (and the olde sourceforge issues if you can) to find the discussion. Whatever is in Geany is the result of those discussions.
In my opinion, ./data/templates/gpl be renamed to ./data/templates/gpl2 to indicate that this is version 2 of the GNU General Public License. Also, should the menu entry explicitly indicate version 2?
Probably, and which BSD too. Pull requests are welcome.
To improve the highlighting used by C source-code, could "bool" be added to "primary=" in ./data/filetypes.c? "bool" existed since C99 ( http://pubs.opengroup.org/onlinepubs/9699919799/ && https://en.wikipedia.org/wiki/C_data_types#stdbool.h ). Also, what about "true" and "false" (lowercase) as seen in the <stdbool.h>? Currently, in Geany, "bool" looks like a variable (no highlighting) while other data-types use highlighting. True, "bool" is not in the "core" C-language without libraries, but it seems to me that "bool" should be added.
It is defined by the tags made from parsing the system headers into C99.tags. Perhaps its not defined as a type in stdbool.h?
Could more "Independent commands" and "Filetype commands" be added to the "Set Build Commands" window opened under "Build > Set Build Commands"? On my system, for C and Python, I have all of the entries filled, but I need to add more.
See the manual, that is already possible.
I would also like to add additional "Build > Set Build Commands" commands to various languages. Are there any objections to me doing so? Obviously, I will share such ideas and apply the given feedback before submitting a PR.
Or you can submit a PR and the discussion can be there. Just keep the PR tightly focussed. Of course if its a general idea applicable to multiple PRs, discuss it on the ML first.
Soon, I will experiment with compiling Geany using various GCC compiler flags and parameters. When I perform such an experiment, would you like me to share my results about successful, unsuccessful, and optimized compiling options (with included benchmarks)?
Its not a problem to share them, just don't be disappointed if your ideas are not used. The (few) options set by default in the Geany configure are ones that will work in a wide range of places and I suspect we would be reluctant to add any specific ones in case they caused issues in some places (I can't even get --no-deprecated added :). Since distribution packagers set their own flags and options to suit their distro, defaults in Geany may not have any effect on actual distributed versions of Geany anyway.
Again this is something you may want to add to the wiki so those few users interested in building their own highly optimised Geany can see what worked for you.
Also I suspect most work in Geany is in GTK so your results might not be significant.
For instance, I have configured and
compiled the Linux kernel src for my system, and I have seen significant improvements in memory usage, speed, boot-up time, etc.. Afterwards, I had become interested in compiling source code myself rather than using the pre-compiled *.deb files. I would like to see if I can make Geany faster and more light-weight (on RAM).
The RAM for code is pretty small, my 64 bit libgeany is 18Mb *including symbols and debugging data*, which is a fraction of the memory used for the files I have open. And *most* of the memory for files is used in Scintilla and GTK, again things we can't influence.
Cheers Lex
Since I will be doing such an experiment, the Geany Dev Team may find the results of my experiment to be beneficial to the project.
-- Thanks, Devyn Collier Johnson DevynCJohnson@Gmail.com
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel