[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 2 commits. e5287871054759c45d3f19871daa5d4db2bec769 Fix parameter name 2b0b55df399eb3685c88e254a290f89fb0fb3efd Add simple PluginExtension demo -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/3785bc92bf24e2898ffc2b40abbc516e3a9ba04d..2b0b55df399eb3685c88e254a290f89fb0fb3efd You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] "persistent temp files" feature for saveactions plugin (sqashed PR) (PR #3911)
@techee requested changes on this pull request. Thanks for the patch - looks good to me in general except for some of the notes below. I personally think that having such a feature in Geany (i.e. multi-tab Scrilbble backed by Scintilla with all the Geany features) would be nice, but depends what others think. I didn't go through all the things in detail and this is just a rough quick review. > Includes one small extension to API (new function in main.h) - if i > understood correctly, this does not require incrementing any versions Yes, it does, but it can be done one everything is ironed-out. > + ui_set_statusbar(TRUE, "%s", message); + g_warning("%s", message); + g_free(message); + g_free(new_filename); + return; + } + + close(fd); /* close the returned file descriptor as we only need the filename */ + + doc->file_name = new_filename; + + if (ft != NULL && ft->id == GEANY_FILETYPES_NONE) + document_set_filetype(doc, filetypes_lookup_by_name(default_ft)); + + /* force saving the file to enable all the related actions(tab name, filetype, etc.) */ + document_save_file(doc, TRUE); Couldn't document_save_file_as be used here instead? It should do the filetype detection for you and shouldn't require the kind of hacky `doc->file_name = new_filename`. (I know this was copied from the previous code but this might be better unless I overlook something.) > + + if (file_path == NULL) + { + return FALSE; + } + + filename = g_path_get_basename(file_path); + matched = is_temp_saved_file(filename); + + g_free(filename); + + return matched; +} + + +static void load_all_temp_files_into_editor(const gchar *path) Is this whole function needed? Couldn't persistent temp files just use the standard Geany session management so they are stored either in the global session or a project based session and restored from it automatically by Geany? > + } + else + { + g_remove(locale_file_path); + + ui_set_statusbar(TRUE, _("Empty temp file %s was deleted"), short_filename); + } + + g_free(short_filename); + g_free(locale_file_path); + } + } +} + + +static void persistent_temp_files_document_before_save_cb(GObject *obj, GeanyDocument *doc, gpointer user_data) I guess you are trying to handle the "save as" case here, right? Then you could use the newly added `document-before-save-as`: https://github.com/geany/geany/pull/3572 > @@ -347,8 +706,13 @@ static gboolean on_document_focus_out(GObject *object, > GeanyEditor *editor, PluginCallback plugin_callbacks[] = { { "document-new", (GCallback) _document_new_cb, FALSE, NULL }, + { "document-new", (GCallback) _temp_files_document_new_cb, FALSE, NULL }, I'd suggest having a single handler which then dispatches it to either the instantsave case or the persistent temp file case. Same for `document-save` below. > + locale_file_path = g_build_path(G_DIR_SEPARATOR_S, path, > filename, NULL); + + if (is_temp_saved_file(utf8_filename)) + { + document_open_file(locale_file_path, FALSE, NULL, NULL); + } + + g_free(utf8_filename); + g_free(locale_file_path); + } + + g_dir_close(dir); +} + + +static gboolean file_exists(gchar *utf8_file_path) Instead of this function you can just check `doc->real_path != NULL`. > + } +} + + +static void persistent_temp_files_document_close_cb(GObject *obj, GeanyDocument *doc, gpointer user_data) +{ + gchar *file_path, *locale_file_path, *short_filename; + + file_path = doc->file_name; + + if (enable_persistent_temp_files && file_path != NULL && ! geany_is_quitting()) + { + if (is_temp_saved_file_doc(doc) && file_exists(doc->file_name)) + { + short_filename = document_get_basename_for_display(doc, -1); + locale_file_path = utils_get_locale_from_utf8(file_path); You can use `doc->real_path` instead. > @@ -462,6 +462,18 @@ gboolean main_is_realized(void) } +/** + * Checks whether Geany is quitting completely right now. + * + * @return @c TRUE if the Geany is exiting right now or @c FALSE otherwise. + **/ +GEANY_API_SYMBOL +gboolean geany_is_quitting(void) I don't think you want `main_status.quitting` here - IMO you want `main_status.closing_all` instead. Note that the plugin should work both for: - the default session (list of open files) when no project is open - project session when some project is open I think you can just safely rely on Geany's session management and let Geany store persistent temp files into
[Github-comments] Re: [geany/geany] Fix a problem when multiple project opens clear the default session (PR #3898)
> 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). The reason why this doesn't happen is the default ``` save_config_on_file_change=TRUE ``` When disabled, the problem happens. I.e.: 1. With project closed, open some files. 2. Restart Geany to make sure the files from (1) are stored in the default session 3. Close all of the open files 4. Open a project 5. Close the project 6. The open files from (1) are restored but, instead, there should be no open files because of (3) So this patch is trading one problem for another, but IMO still worth it because the second problem is much more rare. Even though I suggested passing some boolean in the description above, this affects several session management functions at various places and makes the already complicated code even worse so I'd prefer the slightly buggy approach from this PR. In the future, I think the best solution would be rewriting the session management from scratch, moving it to a separate file and making sure its API would abstract-away the callers from details of what state the session is in. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3898#issuecomment-2180390989 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix a problem when multiple project opens clear the default session (PR #3898)
@techee pushed 1 commit. 6c1fdf6f8e78512bd43ba2e84169f0321979eebf Add an explanation comment -- View it on GitHub: https://github.com/geany/geany/pull/3898/files/d267fa2d92b069a9c0c19675a0b88a842d967181..6c1fdf6f8e78512bd43ba2e84169f0321979eebf You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Don't include geanyfunctions.h from geanyplugin.h (PR #3913)
Merged #3913 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3913#event-13226158594 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Move utils_utf8_strdown() under GEANY_PRIVATE in utils.h (PR #3912)
Merged #3912 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3912#event-13226030069 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Don't include geanyfunctions.h from geanyplugin.h (PR #3913)
Clangd complains with ``` main file cannot be included recursively when building a preamble ``` and I suspect geanyfunctions.h is the old (and now empty) version of geanyplugin.h so theres no need to include it anyway. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3913 -- Commit Summary -- * Dont include geanyfunctions.h from geanyplugin.h -- File Changes -- M plugins/geanyplugin.h (1) -- Patch Links -- https://github.com/geany/geany/pull/3913.patch https://github.com/geany/geany/pull/3913.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3913 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] [geany/geany] Move utils_utf8_strdown() under GEANY_PRIVATE in utils.h (PR #3912)
It isnt part of Geanys public API. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3912 -- Commit Summary -- * Move utils_utf8_strdown() under GEANY_PRIVATE in utils.h -- File Changes -- M src/utils.h (4) -- Patch Links -- https://github.com/geany/geany/pull/3912.patch https://github.com/geany/geany/pull/3912.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3912 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
> I think I'll report this to GTK because this is very unexpected Done in https://gitlab.gnome.org/GNOME/gtk/-/issues/6793 -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2179430032 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Possible plugin extension interface for symbol tree (PR #3910)
> GObjects are nice for language inteop with GI indeed, but they aren't as cheap That's a good point, it should be cheap because for the symbol tree code, all the `TMTag`s have to be wrapped by `GeanySymbol` first and it would be best to have the overhead as small as possible. If we wanted, we could change `GeanySymbol` to something like ```C typedef struct GeanySymbol { ExternalSymbol *ext; TMTag *tag; gint refcount; } GeanySymbol; ``` where `ExternalSymbol` would contain all the other members so `GeanySymbol` with the `TMTag` "backend" would be smaller and would not have to zero-fill so many members. > GBoxed works for non-C. You just have to add a non-C-friendly > allocation/constructor because there's no generic g_boxed_new(). For GeanySymbol, this is hidden behind the two constructors: ```C GeanySymbol *geany_symbol_new_from_tag(TMTag *tag); GeanySymbol *geany_symbol_new(gchar *name, gchar *detail, gchar *scope, gchar *file, TMParserType lang, glong kind, gulong line, gulong pos, guint icon); ``` so I believe it should be satisfied already. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3910#issuecomment-2179365178 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
> @techee I shamelessly pushed 2 more commits, please see if that works better > for you as well (your commit didn't seem to work really well for me…) Thanks! It really seems to work! Nice! I've added two more commits on top of that - not sure if they are completely needed but may prevent some hard-to-find bugs: 1. I moved the connection of `notify::is-active` to `notebook_init()` so it's performed only once. 2. For the `g_timeout_add(600, on_switch_timeout, NULL)` I store the returned `source_id` and make sure that `on_switch_timeout()` is scheduled for execution only once - the previous code didn't guarantee that and there could be some surprising timing issues because of that. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2179318789 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
@techee pushed 2 commits. 4cfbf9e14e79d53bdffc1febcad701a526baf3b2 Connect notify::is-active on main_widgets.window only once a2548b66de7bd79c9811ebd244a952edbcf5a46a Make sure that there is at most one scheduled on_switch_timeout() -- View it on GitHub: https://github.com/geany/geany/pull/3907/files/aac6b16d3eee1093b1a846320304992be85877c1..a2548b66de7bd79c9811ebd244a952edbcf5a46a You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
> Also, shouldn't we enable these for multiple carets (also affects rectangular > selection): If I understand correctly #625, this should fix it. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2176750376 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Issue with the terminal of the mac (Issue #3369)
Closed #3369 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3369#event-13204668841 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee pushed 1 commit. 58557119565ef34fb17b3ffac712c96ba45159b6 Fix defines in keyfile.c and indent them a bit to avoid similar problem in the future -- View it on GitHub: https://github.com/geany/geany/pull/3899/files/979a79a5faffbd01bdc6c154abdbb64d515c0291..58557119565ef34fb17b3ffac712c96ba45159b6 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee pushed 1 commit. 979a79a5faffbd01bdc6c154abdbb64d515c0291 Merge branch 'master' into multi_cursor -- View it on GitHub: https://github.com/geany/geany/pull/3899/files/e221a9886cc146e4483364b984b04e627c677b53..979a79a5faffbd01bdc6c154abdbb64d515c0291 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
Also, shouldn't we enable these for multiple carets (also affects rectangular selection): - `SCI_SETMULTIPASTE` - paste is performed at all caret positions instead of the main one - `SCI_AUTOCSETMULTI` - autocompletion is performed at all caret positions When someone creates a multiple selection, I guess the desired behavior is to perform one thing everywhere so both paste and autocompletion should be performed at all caret positions IMO. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2176120227 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee pushed 1 commit. e221a9886cc146e4483364b984b04e627c677b53 Don't use event->state directly -- View it on GitHub: https://github.com/geany/geany/pull/3899/files/fc5bdd6f969e84f94ae00302ee4a974aad16b0d9..e221a9886cc146e4483364b984b04e627c677b53 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee commented on this pull request. > @@ -288,6 +288,21 @@ void editor_snippets_init(void) } +gboolean motion_notify_event(GtkWidget* widget, GdkEventMotion event, gpointer data) +{ + GeanyEditor *editor = data; + + if (event.state & GDK_BUTTON1_MASK && event.state & GDK_MOD1_MASK) `keybindings_get_modifiers(event.state)` filters-out `GDK_BUTTON1_MASK` so it cannot be used for it. What is the correct way to handle this situation? ```C if (event.state == (GDK_BUTTON1_MASK | GDK_MOD1_MASK)) ``` works for me though it might break if there's some extra stuff in `state`, one could also use ```C if ((event.state & GDK_BUTTON1_MASK) && keybindings_get_modifiers(event.state) == GDK_MOD1_MASK)) ``` but the condition might be satisfied also when there is more than `GDK_BUTTON1_MASK` pressed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#discussion_r1644437346 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
Alright, I added the configurability of modifiers - for now it's under Editor->Features, could be placed somewhere else if someone has a better idea: https://github.com/geany/geany/assets/713965/7ceb31e3-b9fa-4a59-9553-bd82256da463;> For - "Goto definition" and "Multiple carets", one can choose from Ctrl, Alt, Super, Ctrl+Shift, Alt+Shift, Super+Shift, Ctrl+Alt, Ctrl+Super - "Rectangular selection" one can use Ctrl+Shift, Alt+Shift, Super+Shift (as supported by Scintilla) I've also updated the selection logic not to create multiple overlapping selections and, instead, drop the previous selections at the overlapping positions (something similar is also done by vscode). As the default value for "Multiple carets" I used "Ctrl+Alt" which I first thought might be pretty universal, but on Raspberry Pi this is used for switching desktops using mouse. Not sure if we manage to find something that works out of the box everywhere. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2176019039 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee pushed 1 commit. fc5bdd6f969e84f94ae00302ee4a974aad16b0d9 Disallow overlapping selections -- View it on GitHub: https://github.com/geany/geany/pull/3899/files/e01bd7fe10324eddc4219bf96a33b68e041d567b..fc5bdd6f969e84f94ae00302ee4a974aad16b0d9 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
@techee pushed 1 commit. e01bd7fe10324eddc4219bf96a33b68e041d567b Make click modifiers configurable -- View it on GitHub: https://github.com/geany/geany/pull/3899/files/be7c8c9a73930104e111e6ead069e8d2e3fbe74c..e01bd7fe10324eddc4219bf96a33b68e041d567b You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Possible plugin extension interface for symbol tree (PR #3910)
> Have you looked the gtkdoc that's generated from the new interfaces? What should I look for exactly? My main worry is ```C typedef struct { gboolean (*autocomplete_provided)(GeanyDocument *doc, gpointer data); void (*autocomplete_perform)(GeanyDocument *doc, gboolean force, gpointer data); gboolean (*calltips_provided)(GeanyDocument *doc, gpointer data); void (*calltips_show)(GeanyDocument *doc, gboolean force, gpointer data); gboolean (*goto_provided)(GeanyDocument *doc, gpointer data); gboolean (*goto_perform)(GeanyDocument *doc, gint pos, gboolean definition, gpointer data); gboolean (*symbol_highlight_provided)(GeanyDocument *doc, gpointer data); } PluginExtension; ``` which in C you would use this way: ```C static gboolean autocomplete_provided(GeanyDocument *doc, gpointer user_data) { } static void autocomplete_perform(GeanyDocument *doc, gboolean force, gpointer user_data) { } static PluginExtension extension = { .autocomplete_provided = autocomplete_provided, .autocomplete_perform = autocomplete_perform }; void plugin_init(G_GNUC_UNUSED GeanyData * data) { plugin_extension_register(, 100, NULL); } ``` PluginExtension can also be allocated dynamically which would probably be necessary for other languages. Is such an interface OK for other languages? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3910#issuecomment-2173988731 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@elextr Agree, I was thinking about it myself too - the documentation looks the whole thing is much more complicated than it really is. I think I'll create some `PluginExtension` howto similarly to e.g. `Proxy Plugin HowTo` https://www.geany.org/manual/reference/proxy.html with some minimal plugin example. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2173799955 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Possible plugin extension interface for symbol tree (PR #3910)
> If it has a refcount, why not make it a GObject so that it's easy to create > from non-C plugins (python via peasy for example). I just copied what was in `TMTag` to implement it quickly but good point, it could be a `GObject`. I'm not so familiar with what might be necessary for non-C plugins but how does https://github.com/geany/geany/pull/3849 look from this perspective? Could anything be improved there? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3910#issuecomment-2173691912 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Ctrl-Tab "popup" stays on screen (Issue #3330)
@b4n Is there anything else other than the `focus-out-event` signal we could use? When I tested it in #3907, the signal was fired when the window lost focus for some "real" window such as a dialog but not for the case reported by OP here with the menus. To be precise, I connected `main_widgets.window` because we cannot connect every possible widget in the main window and then `focus-out-event` is fired only when focus truly leaves the main window for some other window. But maybe even if we aren't able to fix the menu item click problem, `focus-out-event` fixes most of the other situations so it might still be worth adding (don't look much at #3907, it's not completely right). > Also happens if you e.g. switch windows or workspace while holding Ctrl -- > and this is entirely out of our control. I'd expect `focus-out-event` would be fired in this case, right? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3330#issuecomment-2173680659 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Possible plugin extension interface for symbol tree (PR #3910)
This is one more attempt on unifying `TMTag`s and externally provided symbols for the symbol tree before giving up and making the plugins create the symbol tree by themselves (which leads to quite a significant code duplication). This time (unlike the previous attempts) Im quite happy with the result though. I called the new structure `GeanySymbol` - could be renamed to something else if someone has better idea. The idea is to make `GeanySymbol` operate in two modes: - either it is backed by a `TMTag` and created using `GeanySymbol *geany_symbol_new_from_tag(TMTag *tag)` - or it is created by some external source such as the LSP plugin using ```C GeanySymbol *geany_symbol_new(gchar *name, gchar *detail, gchar *scope, gchar *file, TMParserType lang, glong kind, gulong line, gulong pos, guint icon) ``` The corresponding structure looks this way: ```C typedef struct GeanySymbol { gchar *name; gchar *detail; gchar *scope; gchar *file; TMParserType lang; gulong line; gulong pos; glong kind; guint icon; TMTag *tag; gint refcount; /* the reference count of the symbol */ } GeanySymbol; ``` where either `tag != NULL` when using `geany_symbol_new_from_tag()`, or `tag == NULL` for `geany_symbol_new()`. The important part is that the members of `GeanySymbol` cannot be accessed directly from other files but only using getters that either use the `tag` or the member of `GeanySymbol` such as ```C const gchar *geany_symbol_get_name(const GeanySymbol *sym) { if (sym-tag) return sym-tag-name; return sym-name; } ``` By this interface, all callers like the symbol tree implementation are completely shielded from the details of where the symbol comes from. The bulk of the diffs inside `symbols.c` is pretty much just using this interface instead of using `TMTag` directly and renaming `tag` to `symbol`. `get_symbol_name()` and `get_symbol_tooltip()` were moved to `GeanySymbol` implementation, and also (previously inlined) `geany_symbol_get_name_with_scope()` was moved there too. The additional `PluginExtension` interface for using these symbols would be more or less identical to what I proposed in https://github.com/geany/geany/pull/3850, i.e. ```C gboolean (*doc_symbols_provided)(GeanyDocument *doc); GPtrArray *(*doc_symbols_get)(GeanyDocument *doc); ``` and - either additional `void (*doc_symbols_request)(GeanyDocument *doc, GCallback on_done);` in this interface making Geany request the extension for symbols (asynchronously) - or some `symbol_tree_reload()` function the plugin could call which would make Geany re-request symbols using `doc_symbols_get()` after the plugin gets them e.g. from the LSP server @b4n How does something like this sound? The implementation here is incomplete (only tested with the `TMTag` backend of `GeanySymbol`) but I dont want to continue in case you have some reservations regarding this approach. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3910 -- Commit Summary -- * Possible extension interface for symbol tree -- File Changes -- M meson.build (3) M src/Makefile.am (1) M src/sidebar.c (7) M src/sidebar.h (2) A src/symbol.c (341) A src/symbol.h (67) M src/symbols.c (426) M src/symbols.h (2) -- Patch Links -- https://github.com/geany/geany/pull/3910.patch https://github.com/geany/geany/pull/3910.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3910 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] Avoid unwanted selection when infobar shows by mouse click in Scintilla (PR #3909)
Merged #3909 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3909#event-13176481433 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Single click inside editor makes selection when modified warning appears (Issue #3906)
Closed #3906 as completed via #3909. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3906#event-13176481471 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Single click inside editor makes selection when modified warning appears (Issue #3906)
Closed #3906 as completed via abbe1c984f6da1f1a1fa89851b9d010e5d3a19ae. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3906#event-13176481473 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Avoid unwanted selection when infobar shows by mouse click in Scintilla (PR #3909)
@eht16 Thanks for testing! Merging now. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3909#issuecomment-2171772577 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
Closed #3901. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#event-13175295863 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
OK, closing then. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2171435986 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
> The GTK settings docs for GTK4 say it follows system settings (if they exist > I guess) on Macos I wasn't even able to modify the cursor behavior for the whole system on macOS - the command-line commands from the link I posted didn't work for me. It was possibly for some older macOS version. > No sure modifying filetypes.common is a great GUI Well, it was because the rest of the cursor stuff is there (and probably shouldn't be). And storing this settings to `gboolean` isn't beautiful either ;-) Anyway, as I said, I don't care much myself whether this gets merged - we can just leave this PR open and wait if there are more requests. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2171413918 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
> I guess this depends on whether GTK gets its default from the system there, > or just has its own default. There isn't even a GUI way to change that system-wide on macOS - I tried https://ask.libreoffice.org/t/is-there-any-way-to-disable-the-blinding-cursors-in-macos/45910 but it didn't seem to work. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2171361921 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
I'm fine with either decision. I primarily created this for debugging https://github.com/geany/geany/pull/3902 where I needed to make Geany completely silent. And on macOS or Windows I don't expect it would respect any system settings. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2171321517 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Drop win32_message_dialog()s (PR #3903)
OK, let's give this one week of silence - if nobody complains in the meantime, I'll merge it. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3903#issuecomment-2171306902 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
> We could extend the comment to explain that this setting overrides the GTK > default and when changed, the GTK blinking rate is fully ignored. It kind of says that with the last line of the comment: ``` # set to 0 to disable blinking, comment-out to use system default value ``` (Yesterday I force-pushed this so if you pulled this branch before, it might be missing in the comment.) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2171286875 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 1 commit. 3785bc92bf24e2898ffc2b40abbc516e3a9ba04d Rename plugin_name parameter of plugin_extension_register() to ext_name -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/4a40ff0e3a0bb90818c7a31fbe778bf4efcb2039..3785bc92bf24e2898ffc2b40abbc516e3a9ba04d You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
@techee pushed 1 commit. 625a6a43028f7c72b8126dcac14fdfa782759739 Support setting SCI_SETCARETPERIOD -- View it on GitHub: https://github.com/geany/geany/pull/3901/files/bb51c303c3488c625ba2db041e6a734a67c18ba5..625a6a43028f7c72b8126dcac14fdfa782759739 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
By the way, I can reproduce this problem also on Wayland on Raspberry Pi - around 0.7% CPU. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2170432079 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Drop win32_message_dialog()s (PR #3903)
One thing worth noting is the reversed order of buttons with GTK dialogs vs native Windows dialogs ![Screenshot 2024-06-15 193909](https://github.com/geany/geany/assets/713965/15e00747-922c-4fd1-ade8-245447531bc9) ![Screenshot 2024-06-15 193233](https://github.com/geany/geany/assets/713965/2caf2a4f-4966-4e2e-9461-7fb8b1a1b1a7) GTK dialogs have confirmation on the right, Windows on the left. Would this be a problem for Windows users? Note that for other custom dialogs like search, replace, preferences, etc. Geany already uses the GTK order so this change would make things "consistently wrong" instead of "inconsistently correct". -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3903#issuecomment-2170422760 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
> Maybe olde GTKs worked right and its a bug introduced by these young > programmers, think they know everything gripe gripe [end grumpy olde guy > rant] Oh yeah, it will be them. Those terrible young people aren't what they used to be in our times... :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2169351345 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
> …and I'd think it should definitely stop on unmap, there's no point in > keeping tabs on the animation at that point I don't think. That would fix it in our case but GTK shouldn't do this even when the progress bar is kept displayed all the time. >> @elextr BTW, do you use Wayland? > No. I think the CPU usage could be affected by the used theme - whether it has to draw rounded corners or not, some gradients, etc. When I tried to profile it, I could see some cairo operations (and lots of `poll()`s) in the profile. Still I would suspect that `tick_cb()` from gtkprogressbar gets called all the time in your case too. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2169193410 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
@b4n Thanks for testing! I'll only be able to test on the real hardware tomorrow (edit: later today :-). But at least on the Xorg VM I use, when I added some printfs into `tick_cb()` of the GTK progressbar and recompiled GTK, it fired like crazy even after `ui_progress_bar_stop()`. I think I'll report this to GTK because this is very unexpected - either there should be some `stop()` method in the API that does the same as `gtk_progress_bar_set_fraction(progressbar, 0.0)` or it should be documented that `gtk_progress_bar_set_fraction(progressbar, 0.0)` should be called to stop this. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2168829061 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
It's just that many things in Geany are written with a great attention to detail and it feels a bit clumsy when things like - the problem from this PR - https://github.com/geany/geany/pull/3909 - https://github.com/geany/geany/pull/3560 appear (but these are really the only ones of this nature I'm aware of). None of them are really serious problems, I've just been looking at them for a long time and thought it would be nice to have them fixed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2168216726 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
The patch I posted has problems, this focus stuff is tricky. I may end up deciding the current behavior is a feature :-). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2168153934 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
> Just out of my head, without testing anything, I think if the popup were made > modal, the whole tab switching wouldn't work as for the switching itself the > main window needs all the events to be delivered to it. Just tried to make it modal and it's not a good idea at all - if both the tab switching popup is displayed and there's another modal popup created by the tab switch, the two have the potential to block each other and the situation is much worse than now. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2168082228 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Avoid unwanted selection when infobar shows by mouse click in Scintilla (PR #3909)
Steps to reporduce: 1. Open file A in Geany 2. In a separate window, edit the same file (using e.g. vi) 3. Click to Geany editor so it regains focus 4. An infobar appears. As it appears, several lines in editor are selected The selection is caused by the fact that as the same time the editor is being clicked, Geany checks if the document was modified and shows the info bar. The info bar makes the Scintilla editor smaller and it scrolls by the amount of lines corresponding to the height of the infobar. All this happens in the click handler and for Scintilla it appears as if the mouse button was presses during the scroll and it makes the selection. Showing infobars on idle seems to fix the problem. Fixes #3906. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3909 -- Commit Summary -- * Avoid unwanted selection when infobar shows by mouse click in Scintilla -- File Changes -- M src/document.c (34) -- Patch Links -- https://github.com/geany/geany/pull/3909.patch https://github.com/geany/geany/pull/3909.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3909 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
>> The popup should be modal, nothing else should be able to steal focus. > If I remember correctly, the popup cannot be modal as when you switch between > documents, you need the Scintilla editor to have focus. I don't remember why > exactly, I can try. Just out of my head, without testing anything, I think if the popup were made modal, the whole tab switching wouldn't work as for the switching itself the main window needs all the events to be delivered to it. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2167525953 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
> The popup should be modal, nothing else should be able to steal focus. If I remember correctly, the popup cannot be modal as when you switch between documents, you need the Scintilla editor to have focus. I don't remember why exactly, I can try. > Fixing individual issues is going to be a game of whack a mole because almost > all of Geany is not written to handle it This is the only case where dialog appearance depends on a key being pressed and its disappearance on a key being released. Nothing else needs to be changed. I don't completely understand why to defend a stuck popup being shown as something non-buggy. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2167469834 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Single click inside editor makes selection when modified warning appears (Issue #3906)
Are you sure you are trying to reproduce it correctly? Maybe I didn't describe the reproduction steps in enough details - in (2) you have to switch to another window (e.g. terminal containing`vi`) and after you modify the document there, the click inside Geany's editor must be the one by which Geany gains focus (i.e. do not first click in Geany's title bar to get it in the foreground and then inside Scintilla). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3906#issuecomment-2167405610 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
> It seems to me that you (and others probably) are violating Geany's > non-reentrancy. I'm not sure what you mean by this. It's Geany's bug that it doesn't handle this situation correctly. The majority of keybindings work by waiting for a keybinding to happen once which typically works (or doesn't work if something steals focus in the meantime but that's alright and expected). This particular keybinding is different though - it is triggered by Ctrl+Tab but then you keep holding Ctrl and list through documents through just pressing tab. So Ctrl is held by users for a relatively long time in which many things may happen and e.g. some popup stealing focus may appear - then the Ctrl release isn't delivered to Geany. And it's Geany's responsibility to handle it correctly. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2167396765 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
The example given in #3330 is a bit artificial but it may happen that tab switching triggers some dialog popup which steals focus and then this situation happens. This happens regularly with the LSP plugin where, for now until there's the official API, I show warning that both TM and LSP are active if there are tags in the current document. But I have seen it on other occasions too. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907#issuecomment-2166897261 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Fix stuck MRU dialog when Geany loses focus (PR #3907)
After losing focus, the key release of Ctrl+tab isnt delivered to the handler and the MRU window is shown forever (or until its removed by repeated ctrl+tab). There are 2 situations when focus loss may happen: 1. In the 600ms interval when the MRU popup isnt shown yet but tabs are already being switched. This is handled by checking whether the main window has focus in on_switch_timeout() and the MRU window isnt shown when the focus is lost. 2. After the MRU popup is shown. This is handled by connecting to focus-out-event of the main window and stopping the switch in its handler. Fixes #3330. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3907 -- Commit Summary -- * Fix stuck MRU dialog when Geany loses focus -- File Changes -- M src/notebook.c (47) -- Patch Links -- https://github.com/geany/geany/pull/3907.patch https://github.com/geany/geany/pull/3907.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3907 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany-plugins] projectorganizer: Use GtkFileChooserNative when configured in Geany (PR #1355)
Merged #1355 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-plugins/pull/1355#event-13152604379 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Single click inside editor makes selection when modified warning appears (Issue #3906)
Steps to reproduce: 1. Open document `foo.bar` in Geany. 2. Open the same document in e.g. `vi` and modify it. 3. Click inside the Scintilla widget inside Geany containing `foo.bar` 4. This single click selects several lines of code. The selection below is a result of a single click: https://github.com/geany/geany/assets/713965/89e45dd2-c49b-4ba8-945e-b62d5019f1c9;> What I think happens is that when the widget with the warning appears at the top of the window, Scintilla scrolls the text by the amount of the height of the widget and all this happens within the click handler. As the scroll happens while the click is in progress, selection is made between the start Scintilla position of the click and the end position after the scroll. Maybe postponing the display with the warning to idle would help here. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3906 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@b4n @elextr Alright, documentation pushed, please let me know if I missed something, something should be reworded or fixed. I didn't write much about the "priority" parameter of `_register()` because I don't know yet if Geany itself will use this interface too or not or what priority it will have. If Geany starts using priorities and has priority 0, do we want to allow plugins to have negative priorities too and serve as a fallback if geany doesn't implement something? I can imagine something like Geany's `autocomplete_doc_word()` to be placed after anything else. Anyway, this is not very important at the moment. Also, even though we don't have settings in Geany yet, I think plugins could provide the priority settings by themselves e.g. in their config file and if the value is changed, just re-register their extension. But again, we have just one plugin now. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2165686224 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 2 commits. 37194e920cd671d660a483d6b813e5ab88dd7e00 Add PluginExtension documentation 4a40ff0e3a0bb90818c7a31fbe778bf4efcb2039 Remove currently unused plugin_name from PluginExtensionEntry -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/052eb37425a3ec32535de35b0712f01bf9488317..4a40ff0e3a0bb90818c7a31fbe778bf4efcb2039 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > + const PluginExtensionEntry *entry_b = b; + + return entry_b->priority - entry_a->priority; +} + + +GEANY_API_SYMBOL +void plugin_extension_register(PluginExtension *extension, const gchar *plugin_name, + gint priority, gpointer data) +{ + PluginExtensionEntry *entry = g_malloc(sizeof *entry); + + entry->extension = extension; + entry->data = data; + entry->priority = priority; + entry->plugin_name = g_strdup(plugin_name ? plugin_name : "unnamed plugin"); Will do that. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1637188236 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > + plugin_extension_calltips_show(editor->document, FALSE); + plugin_extension_autocomplete_perform(editor->document, FALSE); Well, I have just 2 real-world examples to base this on - the LSP plugin and Geany itself. For Geany, both calltips and and autocomplete originate in `on_char_added()` (except the `force` variants triggered from elsewhere). For calltips, LSP uses "trigger characters" which, when typed, trigger the calltip display (it's typically `(` and `,`). Autocompletion also happens as you type and what we call "scope autocompletion" is also based on trigger characters. One could think of some kind of autocompletion also happen when e.g. deleting characters but I think it would be annoying and don't think anyone does that. So I think it is reasonably safe to assume `on_char_added()` is sufficient. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1637186085 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Add "document-before-save-as" signal (PR #3572)
Merged #3572 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3572#event-13137901256 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
> Anyway, apart from those two fairly little things, I think I'm happy with how > this looks I'm mostly done with the documentation, I just need to read the garbage I have written after myself with a fresh head tomorrow :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2163972947 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > + plugin_extension_calltips_show(editor->document, FALSE); + plugin_extension_autocomplete_perform(editor->document, FALSE); Technically they could be obtained from `editor-notify` and plugins could call `plugin_extension_autocomplete_provided()` and `plugin_extension_calltips_provided()` to check it is them who executes them. But then you have the calls where the `force` parameter is `TRUE` and these are still needed. So you'd end up with something like ``` plugin_extension_calltips_show_force(GeanyDocument *doc); plugin_extension_autocomplete_perform_force(GeanyDocument *doc); ``` inside the API and the non-force variants would have to be handled in a separate way outside the API which is quite strange IMO. So I'd leave them as they are. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1637156127 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > + const PluginExtensionEntry *entry_b = b; + + return entry_b->priority - entry_a->priority; +} + + +GEANY_API_SYMBOL +void plugin_extension_register(PluginExtension *extension, const gchar *plugin_name, + gint priority, gpointer data) +{ + PluginExtensionEntry *entry = g_malloc(sizeof *entry); + + entry->extension = extension; + entry->data = data; + entry->priority = priority; + entry->plugin_name = g_strdup(plugin_name ? plugin_name : "unnamed plugin"); Well, I thought it was for the user interface (we don't have). But maybe for now I could even remove it from `PluginExtensionEntry` completely as it is unused and we can decide later what we want to do with the parameter. What do you think? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1637140782 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Drop win32_message_dialog()s (PR #3903)
> I'm all for it, but given I don't use Windows I don't think my vote is fair Yeah, @eht16 is the official Windows guru and enthusiast :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3903#issuecomment-2163358478 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Autocompletion plugins support (#1854)
See #3849. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1854#issuecomment-2163303007 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > { + GeanyDocument *doc = document_get_current(); + + if (plugin_extension_goto_provided(doc, NULL)) + return plugin_extension_goto_perform(doc, pos, definition); So what should I do here? The options I see are: 1. Make the function non-static in keybindings.c and export it (but it has nothing to do with keybindings so not good API-wise) 2. Move it to say editor.c and make keybindings.c and symbols.c use it from there (makes more sense API-wise) 3. Make another copy of it in symbols.c 4. Keep the code as it is and not to use the selection mode -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1636598858 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-osx] Open dialog enter file path text (#14)
Native dialog support has been implemented in https://github.com/geany/geany/pull/3861 and it will be included in the next release. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-osx/issues/14#issuecomment-2162876399 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Drop win32_message_dialog()s (PR #3903)
There doesnt seem to be much need for these and they look a little different from the rest of Geany (or a lot different when Windows uses the dark theme and Geany the light one). Before removing the native win32 file open dialogs, win32_message_dialog() was called from the native file dialog implementations so its presence was necessary but I think normal GTK dialogs will serve their purpose well. This is just a suggestion, anyone please feel free to disagree :-) Also, completely untested - Ill only be able to test it on Windows at the end of the week. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3903 -- Commit Summary -- * Drop win32_message_dialog()s -- File Changes -- M src/dialogs.c (35) M src/win32.c (61) M src/win32.h (2) -- Patch Links -- https://github.com/geany/geany/pull/3903.patch https://github.com/geany/geany/pull/3903.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3903 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
But finally msys2 downloads work now and it builds alright. Merging. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#issuecomment-2162834394 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
Merged #3861 into master. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#event-13130806321 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Unlimited Zoom (#2750)
Neil increased the hard-coded Scintilla zoom level to 60 in https://sourceforge.net/p/scintilla/feature-requests/1517/ which I believe should be sufficient for everyone. Once we update to new Scintilla (or backport the patch), we should be able to close this bug report. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/2750#issuecomment-2162391289 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
> the idea to e.g. be able to cleanup extensions on plugin unload is starting > to grow on me I wouldn't do that, extensions should just behave correctly. And if the plugin is unloaded and the extension is still registered, there will probably be a huge crash that the extension developer notices (not sure what happens with resident plugins in this case which the LSP plugin is). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2162383926 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > { + GeanyDocument *doc = document_get_current(); + + if (plugin_extension_goto_provided(doc, NULL)) + return plugin_extension_goto_perform(doc, pos, definition); > or just use get_current_word_or_sel()? But it's static inside `keybindings.c` and we'd need it in `symbols.c`. And with this epochal discovery, I'm going to bed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635564732 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > { + GeanyDocument *doc = document_get_current(); + + if (plugin_extension_goto_provided(doc, NULL)) + return plugin_extension_goto_perform(doc, pos, definition); Just tested and yes, I get identical numbers from ```C int start = sci_get_selection_start(doc->editor->sci); int end = sci_get_selection_end(doc->editor->sci); ``` placed inside `symbols_goto_tag()` and after control-clicking and having something selected. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635557278 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
> @techee yeah, the only thing is whether to pass GeanyPlugin* to the register > function, the rest looks good to me. Since we'll be flooded by plugins wanting to implement this API, some of them using Peasy, some implementing several extensions just for fun, we'll need to distinguish all these extensions so let's leave the string. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161713277 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 1 commit. b7c6b84ee0d77af826994bce8c59073d1f363dd8 Add missing check -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/d34a0a36e761cb2844ae50ffaceaee18fee0d348..b7c6b84ee0d77af826994bce8c59073d1f363dd8 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > if (plugin_extension_goto_provided(doc, NULL)) return plugin_extension_goto_perform(doc, pos, definition); + editor_find_current_word(doc->editor, pos, + editor_info.current_word, GEANY_MAX_WORD_LENGTH, NULL); + name = *editor_info.current_word ? editor_info.current_word : NULL; + Yeah, midnight, my enemy :-). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635550130 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@b4n I believe I addressed all your comments - if I forgot about something, please let me know. Can I start working on the documentation or is there still a risk the API will turn into something completely different? :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161687243 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 2 commits. 0f1bf7cedd3b13cb964539e78c196020b26ed0ad Move plugin_extension_calltips_provided() check inside on_editor_notify() d34a0a36e761cb2844ae50ffaceaee18fee0d348 Make plugin_extension_goto_provided() free to decide whether to perform goto -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/5f18bbfd7f755918dcfa0cd15ee6f9cbe2a4bcb3..d34a0a36e761cb2844ae50ffaceaee18fee0d348 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > { + GeanyDocument *doc = document_get_current(); + + if (plugin_extension_goto_provided(doc, NULL)) + return plugin_extension_goto_perform(doc, pos, definition); I'd just point out that this eliminates `get_current_word_or_sel()` from the original `goto_tag()` so `editor_find_current_word()` is used both in the ctrl+click and keybinding case. Is the goto selection something worth preserving? I've never used it myself and didn't even know it existed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635519766 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 1 commit. 5f18bbfd7f755918dcfa0cd15ee6f9cbe2a4bcb3 Remove unnecessary _provided() calls -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/80fbed1671c5901059c34acce9e93245333933dd..5f18bbfd7f755918dcfa0cd15ee6f9cbe2a4bcb3 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > { + GeanyDocument *doc = document_get_current(); + + if (plugin_extension_goto_provided(doc, NULL)) + return plugin_extension_goto_perform(doc, pos, definition); > there's still the question of whether this should really be guarded behind > Geany thinking there's a word. IMO it shouldn't, and callers should stop > being guarded behind it, and the perform() call should return FALSE if > there's no word to act on. This would alleviate the artificial dependency on > Geany dictating there's a word -- but not actually providing it. Completely agree - it should be the plugin's decision regardless of what Geany itself considers to be the necessary condition for the goto to be performed. I'll modify the code accordingly. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635475740 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
> LGTM OK to merge as it is or do some squashing? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#issuecomment-2161581125 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
>> In theory this should be all it's needed but something else may appear >> during implementation. How does it sound? > Good if it's not too hard to implement the details like activating a row, > navigating them an whatnot, but I guess we don't have much custom stuff apart > knowing where to go, which is exactly what the extension would know how to do. I'd really just copy/paste what's in Geany and just replace TMTag with some other struct so the code creating/updating the tree would mostly be the same apart from some details like: - no support of root groups - no copying icons from the parents in the symbol tree - no construction of displayed name or tooltip (these we get directly from the server) I'd even artificially construct `scope` from the tree-like information that is obtained from the server because really scared to touch anything in the symbol tree code. In any case, I think the good starting point would be to create a separate Symbol tab with all the functionality and then try experimenting with connecting the tree to the existing Geany code. Not stuff for the upcoming release (unless it's postponed before Christmas :-). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161573221 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
> I thought of it, but I don't know… on one hand it indeed allows accessing a > lot more stuff if need be, and we could even make sure the extension got > unregistered on plugin unload (so a plugin forgetting to unregister wouldn't > crash, although I wouldn't love authors to disregard deregistration), but it > also means that it's not possible to discriminate several extensions > registered by a single plugin, which might (or might not) be an issue for > e.g. Peasy-based plugins (not that I can tell whether this API is > Peasy-friendly to begin with). Oh sure, multiple extensions provided by a single plugin - we must have that! :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161557376 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee commented on this pull request. > + if (plugin_extension_calltips_provided(editor->document, NULL)) + plugin_extension_calltips_show(editor->document, FALSE); + + if (plugin_extension_autocomplete_provided(editor->document, NULL)) + plugin_extension_autocomplete_perform(editor->document, FALSE); > There's no need to manually call _provided(), at least not anymore, is there? No, there isn't, it's a left-over from the previous implementation. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#discussion_r1635444976 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
Now thinking, instead of `name`, shouldn't rather `GeanyPlugin *` be passed as an argument of `register()`? The function can read from it whatever it wants. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2161132509 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
I just noticed some more dead code inside `win32.c` that was used by the native implementation so I removed it. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#issuecomment-2160488828 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
@techee pushed 1 commit. f1a2870609d855c4ba3acbfc341bb314cc96b687 Remove some more win32 code that was previously used by native dialogs -- View it on GitHub: https://github.com/geany/geany/pull/3861/files/7a259e8ed7e76f3861d192afa083dae78de44e7b..f1a2870609d855c4ba3acbfc341bb314cc96b687 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
I won't be able to check on a real linux/windows machine until the end of the week, I'll see then. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2160205451 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
> Having human readable names for extensions is useful in many ways, even just > having something to debug print, so @b4n is right, adding a name now is a > good idea and we can then use it lots of ways. OK, done. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3849#issuecomment-2160185414 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Plugin extensions (aka LSP API) (PR #3849)
@techee pushed 1 commit. 80fbed1671c5901059c34acce9e93245333933dd Add plugin name argument to plugin_extension_register() -- View it on GitHub: https://github.com/geany/geany/pull/3849/files/947ea7b377fa76a9118972ccf7ac74f09e9cfecb..80fbed1671c5901059c34acce9e93245333933dd You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Fix elevated CPU usage after ui_progress_bar_start/stop() is used (PR #3902)
> PS I wouldn't say you are crazy, but your system might be ;-) Well, if it happened just on one, it could be. But this happens both with the macOS binary and on Linux VM (on the same macOS but it's a different GTK backend). Basically the CPU oscillates somewhere between 0.3%-1.0% in `top` after first using the progress bar: https://github.com/geany/geany/assets/713965/3522d620-fcb3-4101-87e1-021c31f87543;> -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3902#issuecomment-2160166721 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
> Just to verify, I assume where you say "multiple carets" you also mean > multiple selection? Yes, it's the same thing. You either Modifier+click to add a new caret or Modifier+drag (or Modifier+double-click on an identifier) to make a new selection -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2160106744 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
> Thats a better UI, but as @b4n pointed out Alt+click is stolen by some WMs on > Linux (mine too), so how do you know if its available as an option to show? It can be shown but unassigned to anything or assigned depending on the platform. But I actually don't think this is the better UI - the better one was the one I proposed before: we have 3 actions we need to assign some key+click combinations to and then a set of modifiers and it should rather be the modifiers that are selectable: - Ctrl, Alt, Super for goto definition and multiple carets - Ctrl+Shift, Alt+Shift, Super+Shift (which are already configurable in Scintilla) for rectangular selection Reasonal defaults would be - Ctrl for goto definition/declaration everywhere as this has always been used - Linux: Super for multiple carets, Ctrl+Shift for rectangular selection - Windows: Alt for multiple carets, Alt+Shift for rectangular selection - macOS: depending on what other editors use, I think it will be the same as on Windows Note that the Windows/Linux rectangular selection is already hard-coded here: https://github.com/geany/geany/blob/7909ce299350e1ea882be3a559240aa374cec454/src/editor.c#L4947-L4952 > Thats a possibility. But since goto definition is already in the right click > menu its not much of a saving, and still needs @techee to retrain his muscle > memory but maybe existing Ctrl_click users would find it useful. I really won't use it this way - I'll much rather abandon this PR ;-) (but seriously, in such a case this is a much better option for me personally) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2159940537 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support setting SCI_SETCARETPERIOD (PR #3901)
About this: ```C get_keyfile_ints(config, config_home, "styling", "caret_period", 1, 0, _style_set.styling[GCS_CARET].italic, NULL); ... if (common_style_set.styling[GCS_CARET].italic < 1) SSM(sci, SCI_SETCARETPERIOD, common_style_set.styling[GCS_CARET].italic, 0); ``` As I said, nobody will want to see the caret on for 10s and off for 10s so the default value 1 is safe to use and if such value is set, `SCI_SETCARETPERIOD` won't be applied and you get the default caret period from your system. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3901#issuecomment-2159910678 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Use GtkFileChooserNative for opening files on Windows and macOS (PR #3861)
> I suggest handling this case in this PR as without it it's not possible to > use XDG portals, and with it and a "bad" config (and GTK_USE_PORTAL=1) it > breaks selecting a file: Looks good. > PS: I can add a commit with this here if you prefer Should I squash some of the previous commits or do you want to keep it as it is? In any case, I think you can add your commit so I for once can't pretend it's my own work :-) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#issuecomment-2159272178 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Support for multiple carets (PR #3899)
> I'm not against infinite flexibility, but as @nyamatongwe pointed out, > various combinations work or don't work and are available or not available > depending on the platform and as @b4n pointed out on Linux it also depends on > the desktop being used. My point isn't an infinite flexibility, it's just a matter of being able to "sacrifice" one feature for another in case there are not enough modifiers left. If I had to choose to either have multiple carets or goto definition/declaration and the only modifier available were Ctrl, I would choose goto definition/declaration without any question. But someone else may pick multiple carets. Ctrl+click has been used for goto definition/declaration forever in Geany and it should stay this way by default. The GUI I proposed could be also "inverted" and look this way: ``` Modifier configuration Control+click [combo containing: Goto definition, Multiple carets] Alt+click [combo containing: Goto definition, Multiple carets] ``` -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3899#issuecomment-2159249448 You are receiving this because you are subscribed to this thread. Message ID: