New, flexible interfaces to query tags from a workspace.
The existing functions are rather tied to their use case (either showing tag names in the autocomplete list or in the goto definition popup). E.g. there is currently no function to search for all tags starting with a prefix that does NOT do deduplication.
The goal is to provide these interfaces to plugins. In particular, python plugins (via my peasy plugin) can benefit. Mangling the global tag arrays manually is super slow (pygobject converts each tag in each array to a PyGObject on first use, even if no tag referenced).
Another goal is to eventually use this in the existing tag search/query functions.
@techee @b4n Please comment and review
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1187
-- Commit Summary --
* tagmanager: new query module
* gi: add support for array annoations
* plugin api: export new tagmanager query interfaces
-- File Changes --
M doc/Doxyfile.in (5)
M scripts/gen-api-gtkdoc.py (3)
M src/tagmanager/Makefile.am (6)
A src/tagmanager/tm_query.c (312)
A src/tagmanager/tm_query.h (37)
M src/tagmanager/tm_tag.c (35)
M src/tagmanager/tm_tag.h (12)
M src/tagmanager/tm_workspace.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/1187.patchhttps://github.com/geany/geany/pull/1187.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/1187
`lexer.cpp.track.preprocessor` lexer properties affects which styles
are used, and we don't set those, so no filetype inheriting C styles
should set it to 1.
Similarly, some properties like `styling.within.preprocessor` are
mostly general settings rather than selecting syntax details, so they
should probably match in all filetypes for consistency.
So, inherit the C lexer_properties everywhere C styles are used, and
only override specific properties in the inheriting filetype.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1217
-- Commit Summary --
* Inherit C lexer_properties in all filetypes inheriting C styles
-- File Changes --
M data/filedefs/filetypes.CUDA.conf (4)
M data/filedefs/filetypes.Genie.conf (2)
M data/filedefs/filetypes.Graphviz.conf (4)
M data/filedefs/filetypes.JSON.conf (2)
M data/filedefs/filetypes.Scala.conf (2)
M data/filedefs/filetypes.actionscript (2)
M data/filedefs/filetypes.cpp (4)
M data/filedefs/filetypes.cs (4)
M data/filedefs/filetypes.ferite (2)
M data/filedefs/filetypes.glsl (4)
M data/filedefs/filetypes.go (3)
M data/filedefs/filetypes.haxe (2)
M data/filedefs/filetypes.java (1)
M data/filedefs/filetypes.javascript (2)
M data/filedefs/filetypes.vala (4)
-- Patch Links --
https://github.com/geany/geany/pull/1217.patchhttps://github.com/geany/geany/pull/1217.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/1217
I don't think this needs to be or should be defined in a public header. It was [added here](https://github.com/geany/geany/commit/721009e262e9bc279122566a60e14af…, I suspect in order to provide documentation for it. Unless I'm mistaken, this function needn't be forward declared as it's just pulled out of the plugin DSOs using `g_module_get_symbol()`.
The reason it's an issue is two-fold. One is because it appears as though it's a public function which plugins should be able to call. More problematically, it prevents plugins from declaring it in their own way which is still compatible with the calling convention. For example, in C++ plugins, it prevents add a `noexcept` or similar specifiers because the (unused) forward declaration in the header doesn't have the same signature as the actual implementation.
I propose to move it to one of the *.dox files in the documentation directory so that it can still be documented but prevent interfering with plugins.
--
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/1215
Looks like problem of unity-gtk*-module, which I installed just from curiousity.
When I revmoved it, menu stopped disappearing. (I'm running Gnome on Opensuse).
--
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/633#issuecomment-244962418
Haxe (*.hx) file highlight becomes broken starting from the place where conditional occurs
Btw it works if one adds a negation to the condition:
Actually it's quite an old bug. I think it was there always.
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/936
Whenever a subplugin for a proxy plugin is selected or deselected in the Plugin Manager dialog, the proxy plugin's item is collapsed causing a confusing result in the GUI. I'm not good with GtkTreeView, which is why I'm not providing a pull request, but I would guess it's because the whole plugin list is being reloaded each time and the expanded/collapsed state of the proxy plugin isn't remembered.
--
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/1214
Syntax highlighting fails in PHP files when a parameter is a string more than one line long. It happens since (at least) several versions ago. To repeat the bug:
Type or copy/paste a PHP file with a function parameter of type string, more than one line long, such as this:
```
<p>Paragraph 1</p>
<?php function("1
2", 'sql') ?>
<p>Paragraph 2</p>
```
Save it as "example.php" and the syntax highlighting will be correct.
Now modify the second line of the function (for example, to change the 2 to a 3 or to add some text or a few extra lines) and the paragraph 2 (and all the following ones if they existed) will be "highlighted" in green color as if they still were part of the parameter.
---
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/1143