There doesn't 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 - I'll 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.patchhttps://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/3903(a)github.com>
I have in my Geany 2.1 Preferences set Tab width to 8 and to usage of Tabs. In Lua, Shell and Python scripts Tabs are inserted on Tab-key. I have changed all on the system available filetypes.julia files to width=8 type=1, but nothing helps. On Tab in *.jl files I am getting four spaces as result of using the Tab key on the keyboard.
Any idea what might be the reason and how to achieve insertion of actual Tabs in Julia script files?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3914
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3914(a)github.com>
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 there's 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 --
* Don't include geanyfunctions.h from geanyplugin.h
-- File Changes --
M plugins/geanyplugin.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/3913.patchhttps://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/3913(a)github.com>
After calling
```
ui_progress_bar_start("foo");
...
ui_progress_bar_stop();
```
which should theoretically completely stop the progress bar, I get elevated CPU usage of the whole Geany process ~1% CPU on idle (and around 4% on macOS) compared to 0% after Geany launch before the status bar progress bar is used (e.g. by compiling). GTK seems to keep the widget connected to "tick callback" which causes the higher CPU (in fact, there's no gtk_progress_bar_stop() so it can't do it).
The workaround to fix this problem is to call
```
gtk_progress_bar_set_fraction()
```
which switches the progress bar to the mode where it shows the user-provided progress and this removes the "tick callback".
Am I crazy or can others reproduce this too? It was quite a bug hunt - first I suspected the LSP plugin (clangd indexes files on start which creates the progress bar which made it confusing), then jsonrpc-glib, then the blinking caret or Scintilla notifications, then Geany, and finally I got to GTK (3.24.38 to be precise).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3902
-- Commit Summary --
* Fix elevated CPU usage after ui_progress_bar_start/stop() is used
-- File Changes --
M src/printing.c (2)
M src/ui_utils.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/3902.patchhttps://github.com/geany/geany/pull/3902.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3902
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3902(a)github.com>
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) I'm 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 don't 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.patchhttps://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/3910(a)github.com>
After losing focus, the key release of Ctrl+tab isn't delivered to the handler and the MRU window is shown "forever" (or until it's removed by repeated ctrl+tab).
There are 2 situations when focus loss may happen:
1. In the 600ms interval when the MRU popup isn't 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 isn't 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.patchhttps://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/3907(a)github.com>
My proposial is to add possibility that the user could exclude specific folders and files from showing inside of the explorer of the project and workspace.
Currently seem that the above either doesn't exist or is not documented.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3876
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3876(a)github.com>
This is just a quick test of multiple carets for Geany. IMO we don't need a full support of everything working on multiple carets, users typically just need to insert/delete things at multiple places simultaneously for which this is sufficient.
Ideally, this should be mapped to alt+click as this is what vscode does and also we use alt+shift for the block caret. I only did run into a problem on macOS where (currently in a virtual machine) I get `GDK_MODIFIER_RESERVED_25_MASK` instead of `GDK_MOD1_MASK` but I'm always confused with GDK events so I'm maybe doing something wrong.
(Comparing to the LSP plugin, the ratio of the number of thumbs up for this feature to the amount of time spent on implementing it is quite favorable ;-)
Fixes #1141
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3899
-- Commit Summary --
* Preliminary support of multiple cursors
-- File Changes --
M src/editor.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/3899.patchhttps://github.com/geany/geany/pull/3899.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3899
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3899(a)github.com>
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: <geany/geany/issue/3369/issue_event/13204668841(a)github.com>