This should allow one to edit keybindings without too many surprises again. I didn't review everything though, and just fixed the couple I found (I got hit :boom: but the first crash, and suspected the second one).
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/4226
-- Commit Summary --
* prefs: Fix crash changing a keybinding
* prefs: Edit the correct keybinding when there is a filter
-- File Changes --
M src/prefs.c (14)
-- Patch Links --
https://github.com/geany/geany/pull/4226.patchhttps://github.com/geany/geany/pull/4226.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/4226
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/4226(a)github.com>
- version locally the script `geany-release.py` so far hosted in the wiki
- applied fix for building without signing (missing key/certificate in the filesystem)
- added copying geany.nsi from the build directory into the root directory so that no need to run configure twice
- changed version num to 2.1
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/4223
-- Commit Summary --
* version locally the script geany-release.py so far hosted in the wiki + fixes applied for building without signing/missing key/certificate
-- File Changes --
A scripts/geany-release.py (135)
-- Patch Links --
https://github.com/geany/geany/pull/4223.patchhttps://github.com/geany/geany/pull/4223.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/4223
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/4223(a)github.com>
Standard gettext should be used over glib's glue these days.
AM_GLIB_GNU_GETTEXT and glib-gettextize are deprecated. This helps
possible meson build (no concrete plans yet) as well as working with
intltool is harder over there. gettext, on the other hand, is supported
out of the box in meson.
Beware, autopoint is a new dependency when building from git,
should not affect tarballs. Also, it's already required by Geany core.
Additionally, autogen.sh follows Geany's autogen.sh more closely,
allowing for out-of-tree builds.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/1183
-- Commit Summary --
* Use standard gettext, following Geany core.
* Fix issues found by standard gettext
* Update po files after gettext transition.
-- File Changes --
M .github/workflows/build.yml (1)
M .gitignore (7)
M autogen.sh (11)
M build/common.m4 (1)
M build/i18n.m4 (10)
M configure.ac (8)
A po/LINGUAS (1)
A po/Makevars (82)
M po/POTFILES.in (8)
M po/be.po (710)
M po/ca.po (771)
M po/da.po (697)
M po/de.po (966)
M po/el.po (690)
M po/es.po (952)
M po/fr.po (950)
M po/gl.po (780)
M po/it.po (847)
M po/ja.po (770)
M po/kk.po (720)
M po/nl.po (812)
M po/pt.po (0)
M po/pt_BR.po (0)
M po/ru.po (0)
M po/tr.po (0)
M po/uk.po (0)
M po/zh_CN.po (0)
M treebrowser/src/treebrowser.c (0)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/1183.patchhttps://github.com/geany/geany-plugins/pull/1183.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/1183
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/pull/1183(a)github.com>
Geany 2.0-1, I am on Manjaro-Mabox Linux (openbox).
I can not mark a collumn in my document using ctrl-shift arrow keys.
I searched in the adjustments->shortkeys and could not find anything in this matter. (Maybe the shift-ctrl interferes with operating system controls and I should use different keys)
Sorry to ask here, but mailing list users seems to be closed for registration.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/4219
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/4219(a)github.com>
Trying to compile the `lsp-plugin` I get the following error message.
```
Making all in lsp
make[2]: Entering directory '/home/knizek/.cache/yay/geany-plugins-git/src/geany-plugins/lsp'
Making all in deps
make[3]: Entering directory '/home/knizek/.cache/yay/geany-plugins-git/src/geany-plugins/lsp/deps'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/knizek/.cache/yay/geany-plugins-git/src/geany-plugins/lsp/deps'
Making all in src
make[3]: Entering directory '/home/knizek/.cache/yay/geany-plugins-git/src/geany-plugins/lsp/src'
CC lsp_la-lsp-autocomplete.lo
CC lsp_la-lsp-goto-anywhere.lo
CC lsp_la-lsp-goto.lo
CC lsp_la-lsp-goto-panel.lo
In file included from lsp-goto-panel.c:29:
lsp-symbol-kinds.h:146:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
146 | TMIcon lsp_symbol_kinds_get_completion_icon(LspCompletionKind kind);
| ^~~~~~
| GIcon
In file included from lsp-autocomplete.c:27:
lsp-symbol-kinds.h:146:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
146 | TMIcon lsp_symbol_kinds_get_completion_icon(LspCompletionKind kind);
| ^~~~~~
| GIcon
In file included from lsp-symbol.h:22,
from lsp-goto.c:27:
lsp-symbol-kinds.h:146:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
146 | TMIcon lsp_symbol_kinds_get_completion_icon(LspCompletionKind kind);
| ^~~~~~
| GIcon
lsp-symbol-kinds.h:147:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
147 | TMIcon lsp_symbol_kinds_get_symbol_icon(LspSymbolKind kind);
| ^~~~~~
| GIcon
lsp-symbol-kinds.h:147:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
147 | TMIcon lsp_symbol_kinds_get_symbol_icon(LspSymbolKind kind);
| ^~~~~~
| GIcon
In file included from lsp-symbol.h:22,
from lsp-goto-anywhere.c:27:
lsp-symbol-kinds.h:146:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
146 | TMIcon lsp_symbol_kinds_get_completion_icon(LspCompletionKind kind);
| ^~~~~~
| GIcon
lsp-symbol-kinds.h:147:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
147 | TMIcon lsp_symbol_kinds_get_symbol_icon(LspSymbolKind kind);
| ^~~~~~
| GIcon
lsp-symbol-kinds.h:147:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
147 | TMIcon lsp_symbol_kinds_get_symbol_icon(LspSymbolKind kind);
| ^~~~~~
| GIcon
lsp-symbol.h:45:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
45 | TMIcon lsp_symbol_get_icon(const LspSymbol *sym);
| ^~~~~~
| GIcon
lsp-symbol.h:45:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
45 | TMIcon lsp_symbol_get_icon(const LspSymbol *sym);
| ^~~~~~
| GIcon
lsp-goto-anywhere.c: In function 'goto_line':
lsp-goto-anywhere.c:82:17: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
82 | TMIcon icon = TM_ICON_OTHER;
| ^~~~~~
| GIcon
In file included from lsp-goto-panel.c:31:
lsp-symbol.h:45:1: error: unknown type name 'TMIcon'; did you mean 'GIcon'?
45 | TMIcon lsp_symbol_get_icon(const LspSymbol *sym);
| ^~~~~~
| GIcon
make[3]: *** [Makefile:812: lsp_la-lsp-autocomplete.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
lsp-goto-anywhere.c:82:31: error: 'TM_ICON_OTHER' undeclared (first use in this function)
82 | TMIcon icon = TM_ICON_OTHER;
| ^~~~~~~~~~~~~
lsp-goto-anywhere.c:82:31: note: each undeclared identifier is reported only once for each function it appears in
lsp-goto.c: In function 'goto_cb':
lsp-goto.c:215:65: error: 'TM_ICON_OTHER' undeclared (first use in this function)
215 | TM_ICON_OTHER);
| ^~~~~~~~~~~~~
lsp-goto.c:215:65: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [Makefile:861: lsp_la-lsp-goto.lo] Error 1
lsp-goto-panel.c: In function 'lsp_goto_panel_fill':
lsp-goto-panel.c:169:35: error: implicit declaration of function 'symbols_get_icon_pixbuf'; did you mean 'gtk_entry_get_icon_pixbuf'? [-Wimplicit-function-declaration]
169 | COL_ICON, symbols_get_icon_pixbuf(lsp_symbol_get_icon(sym)),
| ^~~~~~~~~~~~~~~~~~~~~~~
| gtk_entry_get_icon_pixbuf
make[3]: *** [Makefile:868: lsp_la-lsp-goto-panel.lo] Error 1
lsp-goto-anywhere.c: In function 'goto_file':
lsp-goto-anywhere.c:152:75: error: 'TM_ICON_OTHER' undeclared (first use in this function)
152 | sym = lsp_symbol_new(name, "", "", file_name, 0, 0, 0, 0, TM_ICON_OTHER);
| ^~~~~~~~~~~~~
make[3]: *** [Makefile:854: lsp_la-lsp-goto-anywhere.lo] Error 1
```
I did a
```sh
./autogen.sh --prefix=/usr \
--sbindir=/usr/bin \
--libexecdir=/usr/lib \
--sysconfdir=/etc \
--localstatedir=/var \
--runstatedir=/run
make
```
What compile environment information do you need?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1409
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany-plugins/issues/1409(a)github.com>
The symbol tree construction code assumes that tag parents appear before their children. At the moment tag list is sorted by line numbers which works for C structs
```C
struct Foo {
int bar;
int baz;
}
```
where the tag Foo (which is a parent of bar and baz) is sorted before bar and baz. However, this doesn't work when the name of the struct (or a variable of an anonymous struct) follows the struct members such as in the following SystemVerilog example:
```systemverilog
struct packed {
byte s_a, s_b, s_c;
string s_str;
} s_member;
```
Here the members are sorted before the parent and the symbol tree construction code doesn't work correctly.
This patch sorts symbols so that parents are sorted before their members - only if tags aren't in a parent-child relationship the original sorting by line is performed.
@b4n Does this look alright to you?
Fixes #4060.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/4063
-- Commit Summary --
* Make sure that parents appear before their children when constructing symbol tree
-- File Changes --
M src/symbols.c (40)
-- Patch Links --
https://github.com/geany/geany/pull/4063.patchhttps://github.com/geany/geany/pull/4063.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/4063
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/4063(a)github.com>
When the user drags the message window or the sidebar window too much towards the edge of the main window, it may become too hard or even impossible to drag them back as towards the edge of the main window the cursor resizes the main window and doesn't allow dragging the sidebar separator. The only workaround in this case is to manually edit the Geany config file which is annoying.
This patch does two things:
1. When the sidebar/msgwindow divider is dragged to the edge of the window, at the 10px distance from the window border it "snaps" completely to the edge and toggles sidebar/msgwindow visibility.
2. When sidebar/msgwindow is toggled to be shown again, if its previous distance from the edge of the window is less than 10px, its size is restored to some reasonable size (300px for the sidebar, 200px for the message window)
This patch has been tested with all the sidebar/msgwindow location settings and should work correctly in all the configurations.
Fixes #4017.
Fixes #1753.
Fixes #3329.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/4023
-- Commit Summary --
* Improve sidebar and message window resizing behavior
-- File Changes --
M data/geany.glade (2)
M src/callbacks.c (37)
M src/msgwindow.c (15)
M src/ui_utils.c (13)
-- Patch Links --
https://github.com/geany/geany/pull/4023.patchhttps://github.com/geany/geany/pull/4023.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/4023
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/4023(a)github.com>
One more warning I overlooked in https://github.com/geany/geany/pull/4228.
clang reports:
```
[202/372] Compiling C object libregex.a.p/ctags_gnu_regex_regex.c.o
In file included from ../ctags/gnu_regex/regex.c:63:
../ctags/gnu_regex/regex_internal.c:697:36: warning: variable 'q' set but not used [-Wunused-but-set-variable]
697 | const unsigned char *raw, *p, *q, *end;
| ^
```
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/4232
-- Commit Summary --
* regex: Remove unused variable
-- File Changes --
M ctags/gnu_regex/regex_internal.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/4232.patchhttps://github.com/geany/geany/pull/4232.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/4232
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/4232(a)github.com>
In https://github.com/geany/geany/pull/4013 I forgot to add a unit test for meson.
However, when I tried to add it now (naming the test file `meson.build`), I got the following in `meson.build.log`:
```
Unknown filetype extension for "/tmp/tmp.XJrc9S8Suo/test.build.tags".
```
The reason is that unlike other filetypes, the Meson configuration in `filetype_extensions.conf` doesn't start with `*.` but instead the whole filename is used:
```
Meson=meson.build;meson.options;meson_options.txt;
```
The unit test runner creates test files starting with `test`, followed by the filetype extension and this doesn't match what's in `filetype_extensions.conf`.
What should we do about it?
A simple (but ugly) way would be to add some `*.meson_unittest` extension to `filetype_extensions.conf` which we would use for the unit test but which wouldn't be used in real life.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/4074
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/4074(a)github.com>