Devel

devel@lists.geany.org

1641 discussions

[ANN] Geany 1.29 is out!
by Colomban Wendling 13 Nov '16

13 Nov '16

We are happy to announce a new release of Geany! For a comprehensive list of changes please see: https://www.geany.org/Documentation/ReleaseNotes Some highlights: * Fix executing external commands on Windows. * Fix search entries color with the default GNOME 3.20 GTK2 theme. * Add support for keeping the cursor a number of lines from the edges to always show some context. * Update Scintilla to version 3.7.0. * Improve support for GTK 3.22. * Add support for VTE 0.38 and newer. * Update translations: ca, de, el, es, fr, id, it, kk, nl pt, pt_BR, sv, zh_CN. We want to thank all developers, translators and everyone who contributed to this release with patches, feedback, bug reports and so on. Thank you! As usual, all downloads can be found on https://www.geany.org/Download/Releases. - Colomban

1 0

String freeze for Geany-Plugins 1.29
by Frank Lanitz 30 Oct '16

30 Oct '16

Hi translators, As Geany is getting a new major release, the plugins are getting updated too. This time we are on the way of preparing 1.29. In preparation I have updated the po-files for Geany-Plugins at github and asking you whether you could update translations, review them or maybe add new languages. As on Geany core, I'd be very happy if you could send a patch, a pull request or single file with translation to either the geany-i18n mailing list or direct to me within the next two weeks so we can include it to the next release. Deadline will be also 2016-11-10 CET. To get most recent files you could just clone the repositories from Geany: https://github.com/geany/geany-plugins This can be done e.g. with git clone https://github.com/geany/geany-plugins.git Also at http://i18n.geany.org/plugins are statistics and daily updated files available. If you have any questions, don't hesitate to ping me directly via IRC: geany @freenode (frlan) Jabber/XMPP: frlan(a)jabber.ccc.de or via Mail: look above or some of the mailing lists. Happy translating! Cheers, Frank

1 0

String freeze for Geany 1.29 -- Please translate!
by Frank Lanitz 30 Oct '16

30 Oct '16

Hi dear translators and friends of Geany, Again a few months passed by and we are on the last steps for Geany 1.29. In preparation I've updated po-files for Geany core project inside github repositories and asking you whether you could update translations, review them or maybe add new languages. I'd be very happy if you could send a patch, a pull request or single file with translation to either the geany-i18n mailing list or direct to me within the next two weeks so we can include it to the next release. Deadline will be 2016-11-10 24:00hCET. To get most recent files you could just clone the repositories from Geany: https://github.com/geany/geany This can be done e.g. with git clone https://github.com/geany/geany.git Also at http://i18n.geany.org or are statistics and daily updated files available. If your language was translated by two or more in past, please double check directly with them or by pinging me, so we don't need to translate same things two or three times. Also please feel to ping me for every question or if you like to start a new translation for an unsupported language. If you have any questions, don't hesitate to ping me directly via IRC: geany @freenode Jabber/XMPP: frlan(a)jabber.ccc.de or via Mail: look above or some of the mailing lists. Thanks and happy translating Frank

1 0

Scintillua again.
by rhkramer＠gmail.com 21 Oct '16

21 Oct '16

As far as I can tell from reading some old posts and requests, Geany does not support Scintillua. I am neither a C nor C++ programmer (although I am making some feeble efforts at trying to write a lexer for Scintilla / Geany for a variation on the TWiki markup language). So, from an ignorant point of view, because Scintillua is a variant of Scintilla, I would think (or hope ;-) that it should be fairly easy to use Scintillua in place of Scintilla in Geany. Has anyone dug into this at all? I ask because it looks like it would be a whole lot easier to write my lexer in Scintillua than in C/C++ (and don't even think about me trying to integrate Scintillua into Geany unless it would be some very simple matter of changing sort of a dependency or something (like saying "include Scintillua" instead of saying "include Scintilla" if that is how Scintilla gets "attached" to Geany)).

2 2

OSX ports?
by Chris H 15 Oct '16

15 Oct '16

Greetings, Sorry if this has been asked in the past. I've attempted to find similar topics in the list archive. But to no avail. The link on Geany's MailingList page (http://news.gmane.org/gmane.editors.geany.devel) to search the archives returns 404. So my question is; are there any issues building on OSX? I'm currently maintaining over 100 ports on FreeBSD, and use Geany for most of my work, but have recently taken an interest in OSX, and now feel handicapped without it (Geany). While I see that you provide a link to an OSX dmg image for OSX, It's 64bit only, and is limited to ------------------------------------------------------------------------------------

4 7

[FT-plugins] Proposed "Features"
by Matthew Brush 02 Sep '16

02 Sep '16

Hi All, Related to my previous mail, and assuming it is somewhat reasonable, I would like to propose a list of initial features that will be useful to allow plugins to provide, in no particular order: ---- Syntax Highlighting ------------------- Most likely using an API based on/similar to Scintilla's "container lexers". At the minimum, it could have a callback something like: gboolean (*highlight)(GeanyPlugin*, GeanyDocument*, guint start_pos, guint end_pos, gpointer user_data); As with Scintilla's "container lexer", it would just tell the provider what and where to highlight. It might be pointless providing `end_pos` it could probably just highlight a whole line at time (maybe like Scintilla's 'style-needed' notification). If the providers are to setup their own colour schemes and such, then it may be required to add a callback such as: gboolean (*init_styles)(GeanyPlugin*, GeanyDocument*, gpointer user_data); for the plugin to configure all the Scintilla styles as it wishes. This will probably require some kind of conflict avoidance scheme if it is to support multiple providers providing the same feature. Perhaps it could also pass the start style ID the provider can use, and it could tell Geany the maximum style that it ended up using. Sidebar Symbol Tree ------------------- Could provide some API functions to populate the tree by plugins providing the needed information. The nesting could be handled by passing a scope path similar to GtkTreePath or TagManager's `::` delimited scope string, which would be parsed/expanded to apply to the right tree node. The callback function for the provider might be like: gboolean (*populate_symbols_tree)(GeanyPlugin*, GeanyDocument*, guint cursor_pos, gchar **current_node_path /* out */, gpointer user_data); When the providers are called in to, they could use a function something like this: void tagbar_add_node(const gchar *name, guint line, const gchar *signature, const gchar *scope_path, GeanySidebarIcon icon); I haven't looked closely at the existing sidebar/symbols code yet, maybe it already provides such a function that could be used. It has also been mentioned that this could be done using the TagManager API. Plugins would walk their own internal ASTs or tag lists and build up the TM tag array, and Geany would use it for updating the symbols tree as it currently does (IIUC). I don't know much about TM so I can't really give an example callback for such an API. Auto-Completion/Intellisense ---------------------------- This could be triggered at the exact same time in the same way it is now (and re-using the same preferences). It could call a callback function in the ft-plugins like: gboolean (*complete_at)(GeanyPlugin *, GeanyDocument *, guint position, const gchar *partial_word, GPtrArray completion_list /* out */, gpointer user_data); The `completion_list` would be filled in with whatever the provider thinks could be completed at `position`. It could be made more advanced in the future like allowing plugins to give icons, argument lists, documentation comment text, etc. For now it could just give strings to directly populate Scintilla's auto-complete listbox. Calltips -------- To provide calltips, a provider could be called into like: gboolean (*provide_calltips)(GeanyPlugin*, GeanyDocument*, guint position, const gchar *symbol, GPtrArray *overloads /* out */, gpointer user_data); The `overloads` array would populated by the provider with the various overloads for the given `symbol` (function). As with auto-completion, at first this could just be a list of overloads represented as strings which directly populate Scintilla's calltip infos. This could be enhanced in the future to provide documentation comment text and placeholder insertion points into the editor in the future, but for now should be kept simple (see GtkSourceView, XCode, etc). Go To Declaration/Definition ---------------------------- This could be either single callback passing a parameter to tell whether declaration or definition, or two separate callbacks. An example of the callbacks could be: struct SourceLocation { gchar *filename; guint position; }; gboolean (*get_declaration_location)(GeanyPlugin*, GeanyDocument*, guint position, const gchar *symbol, GPtrArray *results, gpointer user_data); and likewise for `get_definition_location`. The `results` array could be populated with `SourceLocation`s for each possible definition/declaration. For example there might be multiple declarations in different `#if` blocks you could jump to, for C-like languages. Geany already provides a UI popup list to pick where to jump, this should be re-used. Build/Run Support ----------------- I haven't thought much on this yet, but in general there should be a way for ft-plugins to get called into when a the build/run features are activated. Diagnostics ----------- I also haven't thought much on this yet. It needs to be possible for ft-plugins, after getting notified of build/run events, to be able to update diagnostics information. Some of the diagnostics display might include: - Scintilla marker margin icons, indicating the type of diagnostic info present for each line (could be more than one per line). - Scintilla indicators (little coloured squigglies) showing the specific range(s) of code where the diagnostics apply. - Scintilla annotations giving further details on request. - Tooltip messages when hovering over the marker margins or squigglied text giving further details. - Putting lines of diagnostics info in the msgwin compiler tab (already supported to some extent IIUC). Refactoring ----------- This is just an idea that is probably long in the future, but ft-plugins could provide some common re-factorings (ex. rename, generate definition code, etc). I haven't thought on this much at all yet. ---- Almost surely I have left some out. What do you think? Cheers, Matthew Brush

5 58

[FT-plugins] Proposed Design
by Matthew Brush 31 Aug '16

31 Aug '16

Hi All, After experimenting with a few different ideas and approaches, I think I have come up with a way to implement the core of "filetype plugins"[0] without too much effort or code. ---- Terminology: "Filetype plugin" - or "ft-plugin"; at this point is just normal plugin that would call special API functions and implement any number of features for any number of filetypes. "Feature" - one of the features an ft-plugin would want to override, for example syntax highlighting or auto-completion. "Provider" - an ft-plugin that provides one or more features for one or more filetypes. For example if it can provide calltips, it could be referred to as a "Calltip Provider". Each ft-plugin can have a number of "providers" for the various features and filetypes. "Registration" - the act (ie. function call) of an ft-plugin declaring its interest in providing a feature for a filetype. An ft-plugin can register to provide one or more features for one or more filetypes. ---- In this design, a new module (c/h file) would be added to manage the filetype plugins and which features they provide for which filetypes. A mapping (ex. GHashTable) could be used to map from Filetype to a list (ex. GQueue) of data describing the needed information for a registered provider. The list would be ordered in the same order as registration and could also be re-ordered by the user using a GUI (more on this below). The order of the list of plugins registered to provide a feature for a given feature/filetype pair would determine the priority given when Geany asks the provider to perform its function. The callback functions could return a boolean telling Geany whether the provider performed its function or whether it should try the next provider in the list, similar to many GTK+ callbacks. If no provider performs its function, or there are no providers registered for a given feature/filetype, then Geany would take its existing code path to provide the feature itself. When a plugin is unloaded, the mapping and lists of providers would be updated to remove any providers registered by that plugin so Geany doesn't call into an unloaded plugin. The next provider registered (if any) would have the first chance to now provide the feature. When a plugin registers its intent to provide a feature (or perhaps after it has registered all the features it wishes to provide), Geany could check whether there is already another plugin providing this feature. Geany could ask the user if they would like to resolve the conflict, and if they would, then it could show a management dialog (see attachment for mockup), allowing the user to control the priority of the plugin's provider for a given feature/filetype by moving them up or down in a list, and possibly being able to completely disable a provider entirely (via a checkbox in the list or something). To give an idea, the registration function called by plugins might look something like this: gboolean ftplugin_register_provider(GeanyPlugin*, GeanyFiletypeID, GeanyFiletypeFeature, GCallback, gpointer); Or perhaps it could use varargs similar to many GTK+/GObject functions, terminated by a sentinel, to register many filetype feature providers in one call, making it easier to implement a less annoying conflict handling scheme - not nagging after each registration call. The callback function would have an actual signature suitable for implementing the specific feature. For example, the callback for a syntax highlighting provider might be something like this: gboolean (*) (GeanyPlugin*, GeanyDocument*, guint start_pos, guint end_pos, gpointer user_data); The document would be the document that needs highlighting, and allow the plugin to access Scintilla and its buffer. The start/end positions would indicate where to highlight. This is in-line with Scintilla's 'style-needed' notification used to implement container lexers. I don't want to get bogged down on the actual specific signatures at this point, I just wanted to give an example. To enable Geany to use the providers, in the existing code just before it's about to provide the feature itself as it does now, we could insert a check/call to try the ft-plugin providers. If nobody performed the feature, then it would continue to the existing code path. This should limit the number of changes needed to Geany. Some features would necessarily require more changes, for example syntax highlighting would require Geany to switch from the Scintilla lexer to the container lexer and back as plugins start/stop providing the feature. It will require care for features that are activated often to ensure minimal performance degradation when looking up and calling into the provider, as this would happen in the main code paths (unless someone has a better way). Hopefully I have described enough details of my proposed design to allow everyone to understand what I mean. If there's any questions or suggestions, please let me know. Thanks, Matthew Brush [0]: I'm still waiting for someone to propose a better name :)

3 10

[FT-plugins] Allowing plugins to supply filetype specific functionality
by Lex Trotman 29 Aug '16

29 Aug '16

Not sure I agree that Github is bad for *development* discussions, for users, sure, the ML is likely to find the audience better, but most developers will also be githubians. Also github supports markup that mail doesn't. But anyway lets try mailing it in for this issue, and see how it goes. But everybody, please DO NOT EDIT THE SUBJECT LINE IF ON THREAD some mail agents thread by subject, and DO NOT REPLY IF YOU WANT ANOTHER THREAD some mail agents thread by previous ID. We should not dictate what sort of mail agent people must use to contribute, please respect individual or enforced choices and follow this procedure (codebrainz this should go on the issue guidelines). I agree with the approach in general, but for some major items (about the process): > rather than endless discussions we let the code do a lot of the talking No, not yet, we need to agree what we are going to code. This is a major change to Geany's design, and it should be designed, not just jump into coding it. Geany suffers from too much "heres some code I made earlier". codebrainz, you clearly have some design in mind, please *describe* (not code) it to get the ball rolling. > Code reviews are always welcome but should be accompanied by the appropriate patches/PRs/commits Too draconian. Just because someone has questions/doubts/misunderstandings about some proposed code or design doesn't mean they have the knowledge or time to immediately propose an alternative. If comments that don't have corrections/alternatives proposed are ignored, nobody will review. Using a branch is good, but, as PRs cannot be layered on PRs, what process do you suggest for corrections to be proposed? And how will alternatives be compared? More than one PR cannot be committed at the same time, and "first PR gets committed" is a bad recipe for new designs, the first is often the worst. Having later PRs have to revert previous PRs just makes them more complex and harder to review so better proposals tend to be rejected. On the requirements, not much to say, agree in principle. Minor comments/suggestions: > Allow plugins to provide syntax highlight. Probably sufficient for Geany to support "container lexers" and flick-pass it to plugins. But then the plugins probably have to have a way to define styles similar to how `highlightmappings.h` is used for included lexers. > Allow plugins to provide the symbols for the tagbar tree... Do you mean the symbols pane? Or do you mean to inject symbols into tagmanager so all existing functionality also sees them? > provide the auto-complete list, given the current location in the document and the part of the word already typed. Location in document is probably enough, the plugin probably has to check for preceeding context `aaa.bbb.ccc` anyway, so the partially typed name is no issue, and it can then be language specific, like lisp can include *s and -s and other things that C doesn't allow in names. > plugins to hook into the build system runner Plugins can now get and set any build command, not sure what else is needed, except maybe a way of telling Geany to not save the plugin set values, since the plugin is handling them. > plugins to provide diagnostics when build commands are run. Allowing the plugin to parse the command response *before* it goes in the message window would be good. General: I used to have a prototype of a change to load filetype specific plugins specified in the filetype file. I can't find it now (backups, whats that?) but it actually was so simple that it doesn't matter. Finally despite some disagreements on detail, the general idea and process is good (IMNSHO), thanks to codebrainz for starting the process. Cheers Lex

5 16

[FT-plugins] Vala for prototyping
by Matthew Brush 28 Aug '16

28 Aug '16

Hi All, With respect to the efforts described in PR #1195[0] is anyone opposed to using Vala as a GObject code generator? I propose we use Vala as a way to generate GObject boilerplate while we hammer out the design of FT-plugins, and later once the design is more concrete, that we port the GObjects generated by valac to their hand-written C equivalents (after they won't be changed as much). It amounts to a few lines of code in `configure.ac` and `src/Makefile.am`. Is OK? P.S. This is only for the proposed 'ft-plugins' branch, not in master/release code. Cheers, Matthew Brush [0]: https://github.com/geany/geany/issues/1195

1 2

Re: [Geany-Devel] [FT-plugins] Vala for prototyping
by Thomas Martitz 28 Aug '16

28 Aug '16

Am 28. August 2016 01:09:36 MESZ, schrieb Matthew Brush <mbrush(a)codebrainz.ca>: >Hi All, > >With respect to the efforts described in PR #1195[0] is anyone opposed >to using Vala as a GObject code generator? > >I propose we use Vala as a way to generate GObject boilerplate while we > >hammer out the design of FT-plugins, and later once the design is more >concrete, that we port the GObjects generated by valac to their >hand-written C equivalents (after they won't be changed as much). Do you suggest to use it only initially, and then continue working on the C code? In that case the vala code doesn't need to be checked in does it? The classbuilder plugin (shipped with geany) can also generate the boilerplate, bit much prettier with less noise. If you suggest to continue working on the vala code that's ok with me but not everyone is fluent with vala. Best regards

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel