I’ve been using Geany with patches whereby [typeahead search](https://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-v… in the symbols list and in [TreeBrowser](http://plugins.geany.org/treebrowser.html) uses [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-str-match-string) instead of simply matching by prefix.
Now, when I type “ba”, it finds not just `bar` but also `foo_bar` and `foo-bar`, etc. (not `FooBar` though).
It’s convenient.
The change itself is simple (all the heavy lifting is in GTK+/GLib), but I’m pretty sure this behavior cannot be made the default, as it might cause too many false positives, and would break habits.
What do you think of having such a feature as an option?
If suitable, what do you think its granularity should be? Should it be a checkbox for every tree view where it makes sense, like “Use fuzzy search in symbols list”, “Use fuzzy search in documents list” and so on?
(Also, I’m not sure it should be just [`g_str_match_string`](https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-str-match-string). Maybe typing “ba” should find `FooBar` as well. Maybe typing “fb” should find `foo_bar`, like in [Commander](http://plugins.geany.org/commander.html).)
--
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/1466
**Geany 1.38,GTK+ v3.24.30,Windows 10 Pro 22H2**
I'm running my program (" Hello world!”), Geany uses a Unix-style file path, but it is not supported on Windows 10 Pro, which caused my program to not run.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3496
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3496(a)github.com>
Add `parsers/c-based.c` from ctags (the only change was to remove the `macroConditionRoleIndex` argument to `cppInit` as our ctags doesn't have it yet).
This is work in progress, I am making a list of things which aren't handled correctly that were by Geany:
* function template calltips - the runtime parameter list is not shown
* `template` decl members don't have parent
* TODO other things
Improvements:
* `alias foo = bar;` now parsed
* `static if` bodies now parsed but don't set parent
* more tag types rather than reusing existing types, listed under templates, aliases, mixins
* mixin statements now parsed
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3479
-- Commit Summary --
* Add warning that geany_c.c is not used for C & C++
* [D] Switch to mainline ctags parser
* Tweak tagmanager types
-- File Changes --
M ctags/Makefile.am (1)
A ctags/parsers/c-based.c (3073)
M ctags/parsers/geany_c.c (11)
M meson.build (1)
M src/tagmanager/tm_parser.c (20)
-- Patch Links --
https://github.com/geany/geany/pull/3479.patchhttps://github.com/geany/geany/pull/3479.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3479
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3479(a)github.com>
Despite the heroic efforts of the Uctags crew and @techee and others there are some limitations that Geany can't overcome when using assistance features in C++.
Since its come up a few times in various issue/PR discussions I thought it might be useful to summarise the fundamental limitations imposed by the underlying design of the Geany/Uctags/Scintilla combination in relation to C++. Or to put it another way, how C++ has outgrown that design which was "adequate" for plain C.
I concentrate on C++ because I use and know it and because it has a Uctags parser that is more capable than most and because it manages to include nearly all the problems that the Geany design has for other languages :smile:.
Hopefully an overall understanding of the limitations can guide a coordinated approach to heuristics that attempt to improve usability rather than individual heuristics being applied independently as happens now.
These are in no special order.
1. Scintilla semantic styling (keywords, types, and the rest) for names is global, but C++ can re-use names for objects with different semantics in different scopes (`foo` can be a type in one scope but a variable or function in another), in different contexts (eg `final` and `override` are only keywords in specific contexts, they are variables elsewhere), and even in the same scope if a name is a struct/class/union type, a variable of the same name is allowed and hides the typename.
Idioms like "first letter caps"ing typenames help, but the STL, Boost++ and other major libraries have all lower case typenames, so if there tags are loaded local variables of the same name are shown by Scintilla as types.
2. Can't follow includes, neither Geany nor Uctags can see includes because the dependencies are specified in the build system and neither can understand those. The result is that the information provided to users is compromised, see below.
3. Types of declared entities depends on declarations in the include files, which are not read, so the variable type is just an opaque name, no members, member functions or constructors information is available either to Geany or the user.
4. Types of expressions are not deduced so inferred types cannot be deduced, eg `auto a = foo(bah);` This is for two reasons:
a. Uctags doesn't have any capability to do it, even the type of `1 + 1.0`
b. even if it did have the capability the lack of accurate type information and template definitions from the include files means it cannot.
5. The lack of type information means that assistance features (autocomplete, calltips) are empty.
6. To avoid the total lack of accurate assistance features Geany attempts to use name based lookup, but that spams the lists with many irrelevant names. There is some attempt to filter or to rank by relevance, but its not particularly good simply because it does not have the information to work off.
7. Tags do not provide lexical scope information for variables, so name hiding cannot be deduced, so again name based lookup will show irrelevant options.
8. When C++ modules start being used in the wild they will suffer from all the include file problems and a few extras.
How do a few other editor/IDEs do it?[^1]
- Vscode - via plugin API, C/C++ is custom plugin IIUC, but one plugin talks Language Server Protocol to a Language Server Process (LSP) for whatever the language is.
- Visual studio - C/C++ builtin custom MS intellisense, has LSP interface for other languages
- Eclipse - C/C++ custom Java code plugin, plugin talking to LSP for other languages eg Rust, C# and more
- Qt creator - LSP for some languages
- Sublime text - LSPs
- Xcode - LSPs for Swift, C/C++ (which is built on clangd)
- Code Blocks - C/C++ plugin talking to clangd via LSP
- Notepad++ - various alpha stage LSP plugins, but IIUC notepad does not use Lexilla.
I am somewhat surprised at how fast LSP use has infiltrated the big guys like MS, Eclipse, and Apple although C/C++ are still supported by legacy code that existed before LSPs in some cases.
So am I suggesting Geany should use LSPs, probably not, the previous attempt to use clangd showed that hard coded ways of doing things is heavily entrenched in Geany, its would take nearly a rewrite. Geany 2.0/GTK4 "somebody", anybody?
[^1]: this list is to the best of my and googles knowledge in 1/2 an hour, it may contain erorrs and is certainly incomplet
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/discussions/3493
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/repo-discussions/3493(a)github.com>
Help solve the annoyance of invisible autocompletion selection bar, which keeps on coming up, usually after update geany related packages or else
Please guide to the thorough solving action
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3494
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3494(a)github.com>
As per requirements - added a new color theme evg-ega-dark, along with screenshot. Theme is tested as per requirements. However when ran 'make index' noticed error and fixed it. Then ran it again to generate the meta-data.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-themes/pull/57
-- Commit Summary --
* Added new color theme evg-ega-dark, tested as per the Geany maintainers requirements.
* Ran 'make index' as per requirements to update meta data for new color theme. However also fixed mkindex.py to work with Python 3.10
-- File Changes --
A colorschemes/evg-ega-dark.conf (148)
M index/index.json (585)
M index/index.json.md5 (2)
A screenshots/evg-ega-dark.png (0)
M scripts/mkindex.py (2)
-- Patch Links --
https://github.com/geany/geany-themes/pull/57.patchhttps://github.com/geany/geany-themes/pull/57.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-themes/pull/57
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-themes/pull/57(a)github.com>
feature: need a option to hide or void wrap long line's marks for printing
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3492
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3492(a)github.com>
This is for geany 1.38 on MacOS.
On the Mac, the commonly used key combination for placing the cursor to the start and end of the line is
command+cursor_left : Start of line
command+cursor_right : End of line
Command+cursor_right does not seem to have any effect in Geany. Checking the Keyboard assignments in the Geany Preferences, I can see that "Cursor start of the line" is assigned to "Home" and "Cursor end of the line" is assigned to "End".
The keys "Home" and "End" don't have a representation on the Mac keyboard. Of course I can re-assign those two functions to what I like, but I suggest that Geany for the Mac initially uses those key assignments which are commonly used on the Mac.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-osx/issues/44
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-osx/issues/44(a)github.com>
This is for geany 1.38 on MacOS.
On the Mac, the commonly used key combination for placing the cursor to the start and end of the line is
command+cursor_left : Start of line
command+cursor_right : End of line
Command+cursor_right does not seem to have any effect in Geany. Checking the Keyboard assignments in the Geany Preferences, I can see that "Cursor start of the line" is assigned to "Home" and "Cursor end of the line" is assigned to "End".
The keys "Home" and "End" don't have a representation on the Mac keyboard. Of course I can re-assign those two functions to what I like, but I suggest that Geany for the Mac initially uses those key assignments which are commonly used on the Mac.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3491
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3491(a)github.com>
Is this intended behaviour? I thought using Alt + Arrow keys (up, down) should emulate mouse wheel behaviour, i.e. NOT move the text cursor, but only the visible region of the text file.
This is clearly uncomfortable if we have a text selection greater than the visible region, because in that case, using Alt + Arrow-keys deselects the text once the cursor is re-positioned due to visible region end.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3489
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3489(a)github.com>