By default, ctags generates scope information using
```
parent_kind:A::B::C
```
where `A::B::C` is the scope of the parent tag. This is a bit problematic when parsing such fields because we have to compare the `parent_kind` value against all valid kinds of the language and if it matches, it means that what follows is the scope. This slows down parsing of such tags and also requires that `parent_kind` is really a valid kind for the given languages.
ctags can also add extra "scope:" prefix to this field when using the sZ field specification option on the command line:
```
scope:parent_kind:A::B::C
```
This way, the scope field can be detected easily by comparing against "scope:" which speeds up parsing. Also, the parsing code doesn't care about the value behind "scope:" so "class" can be used also for languages that don't have the "class" kind.
I haven't regenerated the tag files to avoid a big diff but the result will add "scope:" for every tag's scope field and this should be done separately.
By the way, this could help anyone reviewing #3049 understand what's going on. Parsing scope fields with the `scope:` prefix happens here:
https://github.com/techee/geany/blob/f49b19f3bfe61cf7ae27075f28ec5bd7c570a1…
If scope is not obtained this way, the code tries to go through all the fields which weren't parsed before and check if they start with a kind name of that language. If they do, the field is considered to be scope, see:
https://github.com/techee/geany/blob/f49b19f3bfe61cf7ae27075f28ec5bd7c570a1…
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3592
-- Commit Summary --
* Prefix generated scope field by the "scope:" prefix
-- File Changes --
M scripts/create_tags_helper.py (6)
-- Patch Links --
https://github.com/geany/geany/pull/3592.patchhttps://github.com/geany/geany/pull/3592.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3592
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3592(a)github.com>
This change makes the main window show immediately after launching Geany
so it's immediately visible Geany started. With big files/projects this
gives users better feedback about it's starting than not showing anything
until all the files are ready.
This is a separated patch suggested by @codebrainz in https://github.com/geany/geany/pull/576. It might be a bit risky for Geany 1.27 because plugins might make some assumptions when geany-startup-complete is called so this one might need some more testing. Possible candidate for early 1.28 merge.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/924
-- Commit Summary --
* Open files session files after entering main loop
-- File Changes --
M src/libmain.c (59)
-- Patch Links --
https://github.com/geany/geany/pull/924.patchhttps://github.com/geany/geany/pull/924.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/924
My proposial is to add possibility that the user could exclude specific folders and files from showing inside of the explorer of the project and workspace.
Currently seem that the above either doesn't exist or is not documented.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3876
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3876(a)github.com>
This could be X windows or XFCE related, sorry I have no idea.
geany -V; geany 1.36 (built on 2020-03-22 with GTK 3.24.14, GLib 2.64.1)
OS is Mint 20.3 Una XFCE edition
To reproduce;
- open geany
- type "a" in untitled
- ctrl-n
- press and hold ctrl-tab to switch tabs, release tab key but keep ctrl key held down till popup shows
- click any menu
- release ctrl
- Now popup is stuck as always on top until geany is closed
See attached screen capture for example (you may need to download it first to view)
https://user-images.githubusercontent.com/72730470/200763465-e06bbdc2-bba1-…
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3330
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3330(a)github.com>
Hello everyone,
There is a problem while trying to use the integrated terminal. I have bash as shell. When using 'git push' or 'git pull,' I get an error message:
Bad owner or permissions on /etc/ssh/ssh_config.d/50-redhat.conf
fatal: Could not read from remote repository.
When I use git status it seems to read the remote repository, although I have GitHub return:
On branch main
Your branch is up to date with 'origin/main'.
When in fact it's not 'up to date'
I'm using Fedora Linux 39 Silverblue with Geany 2.0
All permissions are correct in my .ssh folders and the files within that folder. Everything works using external terminal, or other code editors. I prefer to use Geany.
Any suggestions?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3679
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3679(a)github.com>
Since many distros now distribute the GTK3 version of Geany the nightly builds should also check GTK3.
--
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/2003
The real name of the struct in Lua 5.1 is luaL_Reg. Lua 5.1 contains a define for compatibility, but it is not present in LuaJIT or later 5.x releases.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1231
-- Commit Summary --
* GeanyLua: Use luaL_Reg instead of luaL_reg
-- File Changes --
M geanylua/glspi_app.c (2)
M geanylua/glspi_dlg.c (2)
M geanylua/glspi_doc.c (2)
M geanylua/glspi_init.c (2)
M geanylua/glspi_kfile.c (2)
M geanylua/glspi_run.c (2)
M geanylua/glspi_sci.c (2)
M geanylua/gsdlg_lua.c (2)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1231.patchhttps://github.com/geany/geany-plugins/pull/1231.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1231
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1231(a)github.com>
On Windows, when I open a file, press Ctrl-L, and enter a relative path using forward slashes (`/`) instead of Windows's official backslash path separator (`\`), Geany doesn't understand that and produces a confusing error message.
Specifically, if I go to `C:\Users\cousteau\` and enter `AAA/BBB/ccc.txt`, I get "Error: couldn't find `C:\Users\cousteau\AAA\BBB\AAA\BBB\cc.txt`. Note that the directory part (`AAA/BBB/`) appears twice, but other than that it looks like Geany is somewhat able to parse the path. If instead I enter `AAA\BBB\ccc.txt`, Geany will open `C:\Users\cousteau\AAA\BBB\cc.txt` without complaining.
This is a bit inconveniencing because I often work with Unix-like environments (Git bash shell, MinGW, MSYS, WSL, tools and languages that ignore Windows's odd decision to use backslashes and use the usual `/` instead, etc), so whenever I get a file name (e.g. after running `find` on bash) the path is specified using forward slashes. I'd love to be able to just copy-paste that in Geany and have it open without manually replacing every `/` with `\`.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3868
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3868(a)github.com>