Hello everyone,
I'm trying to follow the instructions here.
https://www.geany.org/manual/reference/howto.html
But I'm a bit stuck on the files that are required, starting with the geanyplugin.h and where to put them and how to put them there.
I have geany installed with apt, but the headers are not in the include path of gcc, so I looked up which locations that would be and copied just the geanyplugin.h to that location. Now I'm having the same problem with all the headers mentioned in the geanyplugin.h. Copying those manually can't be the right approach, right?
I have not used C in a long time, so if this seems like a simple/obvious question, I apologize, but I would welcome a tip for where to read up on these kinds of issues.
Also if you have a different, preferred communications channel like matrix, irc or discord, please let me know.
Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1357
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1357(a)github.com>
This pull request aims to be a complete support for systems without gvfs-fuse or fuse installed. It supersedes #963 (I'm creating a new pull request because there are some changes to the used approach, not just addressing issues from the original pull request).
The main changes of this pull request compared to #963 are:
1. More fine-grained approach to GIO usage - previously I for instance replaced all g_file_test() usages with GIO (depending on the configuration) but now it's done only for files which can possibly be remote (i.e. not for config files etc.). If not remote, g_file_...() is still used.
2. Got less crazy about USE_GIO_FILE_OPERATIONS Geany configuration and use this one only when opening/closing documents is involved in the IO. This is when things can go wrong when mixing IO methods. But for other things there's no need to maintain both g_file_...() implementation and GIO implementation and only one of them is used (depending on whether the file can be remote).
3. There's no new plugin API - basically I think plugins don't need to know the value of USE_GIO_FILE_OPERATIONS as they aren't involved in opening/closing documents. If a plugin wants to support remote files, it should use GIO. All existing API functions that could possibly involve file IO have been converted to use GIO. It's not completely black and white as some functions are also used by Geany for opening documents so these still test the USE_GIO_FILE_OPERATIONS value. Not having the file IO functions in the API leads to some duplication of code in plugins but it's not that bad and probably better than adding more and more utility functions to the API.
4. It now works not only when gvfs-fuse is uninstalled, but also when fuse is uninstalled. I was still getting the remote location mounted before I uninstalled fuse and discovered more problems on the way. I recommend testing with fuse uninstalled.
5. Some things like file properties of remote files, TM or saveactions support were missing in the previous pull request. Everything should work now.
6. TM works only for parsing edited file's buffers - there's no support for parsing remote files (we'd have to change ctags for this). I think this is OK as loading complete projects over network could take ages and everything would be frozen as we use blocking GIO. For the same reason I don't plan support for remote projects in my projectorganizer plugin. I haven't really checked how other plugins behave but I don't expect big problems. doc->file_name and doc->real_path can now be URI and if plugins do some reasonable error checking, there should be no problem and they should fail gracefully if they don't use GIO. (I haven't checked but IMO plugins shouldn't read/write doc->file_name as this would interfere with the opened buffer in Geany. Most of the checks I've seen were like if (doc->file_name != NULL) {...}).
7. I didn't get too crazy about saveactions plugin GIO support - it now only supports saving backups into a local directory and not to a remote one. I think nobody will really use remote URI as a location for backups - it would be rather impractical and slow. But can easily add this if someone thinks the opposite.
Apart from the minor limitations I mentioned, I'm not aware of anything missing - I believe this pull request ticks all checkboxes from #1145 with the exception of Windows support which I probably won't do myself and which can be done later independently of this pull request.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1414
-- Commit Summary --
* Replace g_file_test() with a GIO variant when needed
* Update utils_get_path_from_uri() to return URI when using GIO
* Keep URIs in utils_tidy_path()
* Use g_file_new_for_uri() when needed
* Don't create separate tagmanager library
* Preserve URIs in tm_get_real_path()
* Allow parsing remote files opened in the editor
* Merge implementations of write_data_to_disk() and utils_write_file()
* Use gtk_file_chooser_get_uri() in file opening/saving dialogs
* Add GIO version of document_rename_file()
* Use GIO in utils_get_file_list_full()
* Add file reading utils function
* Load project config files using the new utility function
* Remove unnecessary utils functions
* Use g_file_set_contents() instead of utils_write_file() for local files
* Use GIO in utils_mkdir()
* Add GIO implementation to utils_is_file_writable()
* Use GIO for filetypes_detect_from_file()
* Eliminate g_path_is_absolute() direct calls
* Use GIO for file properties dialog
* saveactions: Make backups work for remote files
* Document that document file_name and real_path can be URIs
-- File Changes --
M configure.ac (1)
M plugins/export.c (23)
M plugins/filebrowser.c (74)
M plugins/htmlchars.c (2)
M plugins/saveactions.c (108)
M src/Makefile.am (25)
M src/callbacks.c (10)
M src/dialogs.c (78)
M src/document.c (137)
M src/document.h (4)
M src/filetypes.c (31)
M src/keybindings.c (8)
M src/keyfile.c (8)
M src/libmain.c (13)
M src/msgwindow.c (8)
M src/osx.c (2)
M src/project.c (74)
M src/sidebar.c (2)
M src/stash.c (3)
M src/symbols.c (1)
D src/tagmanager/Makefile.am (32)
M src/tagmanager/tm_source_file.c (54)
M src/tagmanager/tm_source_file.h (3)
M src/toolbar.c (2)
M src/ui_utils.c (8)
M src/utils.c (351)
M src/utils.h (24)
M src/win32.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/1414.patchhttps://github.com/geany/geany/pull/1414.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/1414
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>
Closed #454.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/454#event-13255544867
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/454/issue_event/13255544867(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
Closed #364.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/364#event-13255537690
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/364/issue_event/13255537690(a)github.com>
Closed #576.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/576#event-13255536768
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/576/issue_event/13255536768(a)github.com>
This is a work-in-progress PR to add the LSP plugin. There are still some things missing like the documentation but in general the plugin should work. There are 3 modes of operation:
1. Without Geany LSP support
2. With basic LSP support using https://github.com/geany/geany/pull/3849
3. With full LSP support using https://github.com/geany/geany/pull/3850
The plugin should detect with which of these modes Geany was compiled and adjust itself automatically.
For the time being I still plan continue the main development of the plugin under https://github.com/techee/geany-lsp and sync the changes here from time to time.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1331
-- Commit Summary --
* Add LSP plugin
-- File Changes --
M Makefile.am (4)
M build/geany-plugins.nsi (1)
A build/lsp.m4 (10)
M configure.ac (1)
A lsp/AUTHORS (1)
A lsp/COPYING (340)
A lsp/ChangeLog (0)
A lsp/Makefile.am (4)
A lsp/NEWS (0)
A lsp/README (0)
A lsp/data/Makefile.am (5)
A lsp/data/lsp.conf (102)
A lsp/src/Makefile.am (119)
A lsp/src/json-glib/json-array.c (838)
A lsp/src/json-glib/json-builder.c (845)
A lsp/src/json-glib/json-builder.h (108)
A lsp/src/json-glib/json-debug.c (38)
A lsp/src/json-glib/json-debug.h (51)
A lsp/src/json-glib/json-enum-types.c (123)
A lsp/src/json-glib/json-enum-types.h (33)
A lsp/src/json-glib/json-gboxed.c (301)
A lsp/src/json-glib/json-generator.c (807)
A lsp/src/json-glib/json-generator.h (113)
A lsp/src/json-glib/json-glib.h (44)
A lsp/src/json-glib/json-gobject-private.h (36)
A lsp/src/json-glib/json-gobject.c (1005)
A lsp/src/json-glib/json-gobject.h (250)
A lsp/src/json-glib/json-gvariant.c (1346)
A lsp/src/json-glib/json-gvariant.h (50)
A lsp/src/json-glib/json-node.c (1555)
A lsp/src/json-glib/json-object.c (1261)
A lsp/src/json-glib/json-parser.c (1707)
A lsp/src/json-glib/json-parser.h (244)
A lsp/src/json-glib/json-path.c (998)
A lsp/src/json-glib/json-path.h (88)
A lsp/src/json-glib/json-reader.c (1138)
A lsp/src/json-glib/json-reader.h (161)
A lsp/src/json-glib/json-scanner.c (1371)
A lsp/src/json-glib/json-scanner.h (120)
A lsp/src/json-glib/json-serializable.c (386)
A lsp/src/json-glib/json-types-private.h (185)
A lsp/src/json-glib/json-types.h (534)
A lsp/src/json-glib/json-utils.c (95)
A lsp/src/json-glib/json-utils.h (37)
A lsp/src/json-glib/json-value.c (280)
A lsp/src/json-glib/json-version-macros.h (261)
A lsp/src/json-glib/json-version.h (100)
A lsp/src/jsonrpc-glib/jsonrpc-client.c (1752)
A lsp/src/jsonrpc-glib/jsonrpc-client.h (165)
A lsp/src/jsonrpc-glib/jsonrpc-glib.h (39)
A lsp/src/jsonrpc-glib/jsonrpc-input-stream-private.h (30)
A lsp/src/jsonrpc-glib/jsonrpc-input-stream.c (398)
A lsp/src/jsonrpc-glib/jsonrpc-input-stream.h (67)
A lsp/src/jsonrpc-glib/jsonrpc-marshalers.c (0)
A lsp/src/jsonrpc-glib/jsonrpc-marshalers.h (0)
A lsp/src/jsonrpc-glib/jsonrpc-message.c (0)
A lsp/src/jsonrpc-glib/jsonrpc-message.h (0)
A lsp/src/jsonrpc-glib/jsonrpc-output-stream.c (0)
A lsp/src/jsonrpc-glib/jsonrpc-output-stream.h (0)
A lsp/src/jsonrpc-glib/jsonrpc-server.c (0)
A lsp/src/jsonrpc-glib/jsonrpc-server.h (0)
A lsp/src/jsonrpc-glib/jsonrpc-version-macros.h (0)
A lsp/src/jsonrpc-glib/jsonrpc-version.h (0)
A lsp/src/lsp-autocomplete.c (0)
A lsp/src/lsp-autocomplete.h (0)
A lsp/src/lsp-code-lens.c (0)
A lsp/src/lsp-code-lens.h (0)
A lsp/src/lsp-command.c (0)
A lsp/src/lsp-command.h (0)
A lsp/src/lsp-diagnostics.c (0)
A lsp/src/lsp-diagnostics.h (0)
A lsp/src/lsp-format.c (0)
A lsp/src/lsp-format.h (0)
A lsp/src/lsp-goto-anywhere.c (0)
A lsp/src/lsp-goto-anywhere.h (0)
A lsp/src/lsp-goto-panel.c (0)
A lsp/src/lsp-goto-panel.h (0)
A lsp/src/lsp-goto.c (0)
A lsp/src/lsp-goto.h (0)
A lsp/src/lsp-highlight.c (0)
A lsp/src/lsp-highlight.h (0)
A lsp/src/lsp-hover.c (0)
A lsp/src/lsp-hover.h (0)
A lsp/src/lsp-log.c (0)
A lsp/src/lsp-log.h (0)
A lsp/src/lsp-main.c (0)
A lsp/src/lsp-progress.c (0)
A lsp/src/lsp-progress.h (0)
A lsp/src/lsp-rename.c (0)
A lsp/src/lsp-rename.h (0)
A lsp/src/lsp-rpc.c (0)
A lsp/src/lsp-rpc.h (0)
A lsp/src/lsp-semtokens.c (0)
A lsp/src/lsp-semtokens.h (0)
A lsp/src/lsp-server.c (0)
A lsp/src/lsp-server.h (0)
A lsp/src/lsp-signature.c (0)
A lsp/src/lsp-signature.h (0)
A lsp/src/lsp-symbol-kinds.c (0)
A lsp/src/lsp-symbol-kinds.h (0)
A lsp/src/lsp-symbol.c (0)
A lsp/src/lsp-symbol.h (0)
A lsp/src/lsp-symbols.c (0)
A lsp/src/lsp-symbols.h (0)
A lsp/src/lsp-sync.c (0)
A lsp/src/lsp-sync.h (0)
A lsp/src/lsp-utils.c (0)
A lsp/src/lsp-utils.h (0)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1331.patchhttps://github.com/geany/geany-plugins/pull/1331.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1331
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1331(a)github.com>
Steps to reproduce:
1. With no project open, open some files
2. Open project A
3. Without closing project A first, open project B
4. Close project B
5. The originally open files from (1) are gone
The problem is that when project A closes and all its files are closed, load_config() gets called which contains
configuration_save_default_session();
This saves the session with all files closed and replaces the original session.
This patch modifies the code to call configuration_save_default_session() only when there are some open tabs so the above problem gets solved.
Even though I was worried that this would break saving default session when all its files get closed and then a project is loaded, it doesn't seem to be the case (I haven't investigated deep enough why).
An alternative to this approach would be to pass a boolean as a parameter of quite many functions and propagate the information whether project close preceded its opening but it introduces a much bigger diff and makes the complicated session opening stuff even wilder.
Fixes #3897.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3898
-- Commit Summary --
* Fix a problem when multiple project opens clear the default session
-- File Changes --
M src/project.c (3)
-- Patch Links --
https://github.com/geany/geany/pull/3898.patchhttps://github.com/geany/geany/pull/3898.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3898
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3898(a)github.com>