Hello!
After last changes on 1.28 for GTK3, in trying once again to be if I could move to Geany with GTK3 , which I prefer over GTK2.
One thing I've noticed is that the colours of the toolbar does not match with the colours of the rest of the interface.
Here is a snapshot of my Geany with GTK - 3.0:
 and it would not be good to start embedding deep knowledge of specific programming languages into the core, this is why it's crucial that such advanced (read: bloated) features remain completely contained in some kind of plugin. No user should pay the cost for such language support for languages they don't use. It's also important that Geany always provide at least its current baseline functionality. Some of the default functionality could indeed be moved into such a plugin, but it should always be the default/fallback and should work out-of-the-box.
Since, for better or worse, we're already tightly tied with the GObject framework (via GTK+) and a GObject-based plugin loader is in the works by @kugel, I propose we use GObject interfaces where appropriate to provide object oriented, language neutral extension points for some or all of the needed features. Some of these interfaces could take some cues from [GtkSourceView's APIs where a plugin implements a "provider" interface](https://developer.gnome.org/gtksourceview/stable/GtkSourceComple… if it wants to provide the particular feature.
I have experimented in the past at trying to integrate libclang into a plugin to provide some of this support for C/C++, but I assume much of it would transfer over to other languages such as using libpython to enhance Python support, or V8 engine to enhance JavaScript.
## Requirements
Though there are probably some things I have not thought of, some of the requirements I've come up while experimenting with implementing this kind of advanced language features and run into road-blocks with are as follows:
- [ ] Allow plugins to provide syntax highlight.
> Remark:
> This could be in the form of providing the Scintilla lexer, either by allowing plugging in as "container lexers" or by allowing plugins to provide a lexer library loaded dynamically into Scintilla (already supported by Scintilla). Alternatively we could provide some kind of interface non-specific to Scintilla for this and have Geany deal with making the styles appear on the screen. This is to allow for advanced semantic highlighting and the likes.
- [ ] Allow plugins to provide the symbols for the tagbar tree, based on their own knowledge of the current document.
> Remark:
> It has been suggested that TagManager (with appropriate enhancements) may be suitable as a means of providing this information to Geany. Some kind of hook/provider interface would still be required in all cases.
- [ ] Allow plugins to provide the auto-complete list, given the current location in the document and the part of the word already typed.
> Remark:
> In the future this could be extended to allow plugins to provide information required to insert those templates where, for example, if a particular function is completed, it inserts a "template" of the prototype and the caret jumps to the first editable position, like the function argument name, or if no arguments into the body of the template where the user probably wants to start typing, when you press tab it keeps jumping to the next editable template placeholder. Some IDEs such as XCode provide this, and I believe Scintilla has some kind of builtin support for implementing this. Further research is required. This particular enhancement could be added afterwards and should not block this issue.
- [ ] Allow plugins to provide a list of calltips to be shown when Geany shows the calltips.
> Remark:
> In the future this could be extended to support additional features like enhanced keyboard navigation, ability to display documentation comment text, etc. Such enhancements should not block this issue.
- [ ] Allow plugins to hook into the build system runner.
> Remark:
> Plugins should be able to provide not only the default build commands, but to dynamically modify them based on user's input (eg. through some configuration dialog they provide). This would allow plugins to do stuff like generating a Makefile based on the user's choices/source code and to update the build commands to run the Makefile in some particular directory, environment, etc.
- [ ] Allow plugins to provide diagnostics when build commands are run.
> Remark:
> This could include not just allowing them to add compiler messages (which is already kind of supported if the plugin inserts Make-like change-directory messages and such into the compiler tab view), but also a more specific than current API for displaying diagnostic messages such as adding those various coloured squiggly lines below errors, putting diagnostic icons (eg. warning, info, error, etc) into the margin for affected lines, and also providing Scintilla annotations or tooltips to give the user more detailed information about the error when hovering over the squigglied text or margin markers. It should also be possible for plugins to nest further information in the compiler messages tab's treeview, so that it can show more than one line, like perhaps in the case of multiple definitions, where the original location was or other such information which may not make sense as the main information line in the compiler tab but can still be useful for some kinds of errors.
## Development/Contribution Strategy
I propose that we create a branch on the main repo (eg. "ft-plugins") against which all pull requests are made. The branch should be kept up to date at regular intervals with the development branch (ie. master) to prevent it getting stale and unmergable. Although it's a significant additional overhead, it would be nice if we could, when merging any changes to master branch, merge them also to and ensure no conflicts with the "ft-plugins" (or whichever) branch.
Everyone who is able should feel free to edit this issue description, but please limit it to gramatical and formatting corrections, adding references/links or if obvious information is missing. Please do fix this description if you are able to improve what it conveys without changing the overall meaning.
Since the changes won't be made on the stable master branch, I propose that we are much more aggressive with making changes, and are much more laid back with what changes get merged, even if not 100% in agreement with them. Once a pull request is merged, it can always be improved, tweaked, or even reverted later. The most useful kind of contribution is actual pull requests/commits. It is often the case with changes to the master branch that discussion ends up defeating progress, so I propose rather than endless discussions we let the code do a lot of the talking. Code reviews are always welcome but should be accompanied by the appropriate patches/PRs/commits. If one is not able/willing to contribute patches/PRs/commits directly, I propose that they wait until the particular changes are ready to be merged back to the master branch to raise minor issues (who knows maybe the issue has been removed or fixed by then). Of course it's useful to discuss fundamental design flaws regardless if one is willing to contribute code or not (see below).
## Discussion Guidelines
Since Github comments are not an ideal discussion platform and can grow out of control, as well as to include more people, foster broader discussions (bikesheds), and in order to keep this issue nice and clean, I propose that we do all of the discussion on the development mailing list. This suggestion is only for this particular Github issue, and need not apply to all related PRs, of course. If nobody minds, I would like to delete extaneous comments on this Github Issue, and keep the comments limited to such stuff as progress reports, meta discussions about the Github issue iself (assignees, labels, milestones), notes about a related PR, etc.
If there is a particular item you wish to discuss, quote it in your mailing list message and provide your suggestions, comments, issues, etc. I propose we choose some unique kind of tag (eg. "FT-Plugins") to put in the subject line of each related mailing list thread to improve searchability. This way we can look back in the archives and easily find related discussions regardless whether they all happened to be nested under a single thread.
Please feel free to "add your reaction" (thumbs up or down) whether you like the overal proposal presented here, in principle, even if not some of the details.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1195
Anybody mind if I add `*.s` and `*.S` to `filetype_extensions.conf` for `ASM`? It's the extension commonly used by/for GCC/GAS.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/904
When I search for some text, I can use the "find" window (`ctrl+f`). In this window I have the "mark" button which can highlight the searched phrase. Sometimes I want to replace some text, and this can be easily done via the "replace" window (`ctrl+h`). In the second case, there's no "mark" button. Often I want to know where exactly the phrase that is going to be replaced appears in the text. In such cases I have to call the "find" window first, mark the text, and then switch to the "replace" window and replace the text. Could you add the "mark" button to the "replace" window?
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/972
This is a wrapper around `tm_get_real_path()` but is in a more suitable namespace/module.
I think it makes more sense like this. I typically dislike adding general-purpose functions to the API, but since Glib doesn't provide any equivalent, it really is useful.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1224
-- Commit Summary --
* Add utils_get_real_path() and use it
-- File Changes --
M src/app.h (2)
M src/document.c (8)
M src/libmain.c (2)
M src/plugindata.h (2)
M src/tagmanager/tm_source_file.c (2)
M src/utils.c (29)
M src/utils.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/1224.patchhttps://github.com/geany/geany/pull/1224.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1224
Now that a new enough GLib is available the signal can be handled cleanly on the main loop using the GSource for Unix signals. This replaces the illegal SIGTERM handling that was disabled in
fbb89f523af47b35e238678d348cfa98e56c760a.
In the future, we might also like to handle `SIGPIPE` which was ignored in cc511a78d80fde742e1794c32b2738ae8ddd4792 to log the error instead of just ignoring it (or handling `write()` failures at their source).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1255
-- Commit Summary --
* Re-enable SIGTERM handling
-- File Changes --
M src/libmain.c (21)
-- Patch Links --
https://github.com/geany/geany/pull/1255.patchhttps://github.com/geany/geany/pull/1255.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1255
This is to get the ball rolling on the [Port to GSettings project](https://github.com/geany/geany/projects/1).
See individual commit messages for more details.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1257
-- Commit Summary --
* Add initial GSettings support
* Change 'sidebar_pos' to use GSettings
* Port "fullscreen" preference to GSettings
* Port "sidebar_visible" preference to GSettings
* Port "msgwindow_visible" preference to GSettings
* Port "statusbar_visible" preference to GSettings
* Port "sidebar_*_visible" preferences to GSettings
-- File Changes --
M configure.ac (2)
M data/Makefile.am (4)
A data/org.geany.Settings.gschema.xml (53)
M po/POTFILES.in (1)
M src/Makefile.am (2)
M src/build.c (11)
M src/callbacks.c (70)
M src/keybindings.c (5)
M src/keyfile.c (29)
M src/libmain.c (33)
M src/msgwindow.c (25)
M src/msgwindow.h (2)
M src/prefs.c (44)
A src/settings.c (77)
A src/settings.h (35)
M src/sidebar.c (46)
M src/sidebar.h (2)
M src/ui_utils.c (63)
M src/ui_utils.h (13)
M src/vte.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/1257.patchhttps://github.com/geany/geany/pull/1257.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1257
){kind=link}