[Github-comments] Re: [geany/geany] Fix crash by protecting tm_ctags_*() functions against TM_PARSER_NONE (PR #3865)
What does upstream say about the changes? What is the setting set to if the `tag_parser=` is not present? And can `tag_parser=` mean that? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3865#issuecomment-2094556791 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
@AtomicRobotMan0101 since you mentioned LM maybe you should read their [blog](https://blog.linuxmint.com/) on the topic of flatpack verifications, its a ways down but there is no direct link AFAICT. Note that (at least on the website) the "Geany team" on the Geany flatpack is marked " :warning: Unverified ". -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#issuecomment-2094555833 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
@eht16 be polite. I did the groundwork beforehand. The archive sure does look official - https://flathub.org/apps/org.geany.Geany Thanks for letting me know the Flatpak isn't official... its sure does look that it is. I'll report it there and ask the Flatpak team what the process is to ensure it isn't being passed off. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#issuecomment-2094547204 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] [geany/geany] Fix crash by protecting tm_ctags_*() functions against TM_PARSER_NONE (PR #3865)
This can happen when in the filetype configuration we set ```ini [settings] tag_parser= ``` This then leads to this crash in the ctags code: ``` #0 countKinds (kcb=0x0) at main/kind.c:230 #1 0xf7e802c8 in countLanguageKinds (language=language@entry=-2) at main/parse.c:300 #2 0xf7e15f88 in tm_ctags_get_lang_kinds (lang=lang@entry=-2) at tm_ctags.c:467 #3 0xf7e173e8 in read_ctags_file (file_tags=0xaad7e260, lang=-2, tags_file=0xaaf86de0 /usr/local/share/geany/tags/std.py.tags) at tm_source_file.c:313 #4 tm_source_file_read_tags_file (tags_file=tags_file@entry=0xaaf86de0 /usr/local/share/geany/tags/std.py.tags, mode=-2) at tm_source_file.c:552 #5 0xf7e1a4dc in tm_workspace_load_global_tags (tags_file=tags_file@entry=0xaaf86de0 /usr/local/share/geany/tags/std.py.tags, mode=optimized out) at tm_workspace.c:379 #6 0xf7c9937c in symbols_load_global_tags (tags_file=0xaaf86de0 /usr/local/share/geany/tags/std.py.tags, ft=ft@entry=0xab4cdf40) at symbols.c:166 #7 0xf7c997bc in load_user_tags (ft_id=GEANY_FILETYPES_PYTHON) at symbols.c:1377 #8 symbols_global_tags_loaded (file_type_idx=optimized out) at symbols.c:193 #9 0xf7c53bdc in document_load_config (doc=0xac1c90d0, type=0xab4cdf40, filetype_changed=optimized out) at document.c:2820 #10 0xf7c53cc8 in document_set_filetype (doc=0xac1c90d0, type=0xab4cdf40) at document.c:2859 #11 0xf7c55ac4 in document_open_file_full (doc=optimized out, doc@entry=0x0, filename=optimized out, pos=pos@entry=0, readonly=readonly@entry=0, ft=ft@entry=0x0, forced_enc=forced_enc@entry=0x0) at document.c:1490 #12 0xf7c55b00 in document_open_file (locale_filename=optimized out, readonly=readonly@entry=0, ft=ft@entry=0x0, forced_enc=forced_enc@entry=0x0) at document.c:904 ``` Until theres some LSP support in Geany, setting `tag_parser` to the empty value is necessary to disable ctags parsing so it doesnt clash with the LSP implementation. You can view, comment on, or merge this pull request online at: https://github.com/geany/geany/pull/3865 -- Commit Summary -- * Protect tm_ctags_*() functions against TM_PARSER_NONE language parameter -- File Changes -- M src/tagmanager/tm_ctags.c (29) -- Patch Links -- https://github.com/geany/geany/pull/3865.patch https://github.com/geany/geany/pull/3865.diff -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3865 You are receiving this because you are subscribed to this thread. Message ID: geany/geany/pull/3...@github.com
[Github-comments] Re: [geany/geany] windows下中文字体乱码 (Chinese font garbled under Windows) utf8 unicode (Issue #3862)
> @xueyeyu these fonts (such as Ubuntu Mono and Fira Code) can be displayed > normally in other editors (such as atom vscode), and these fonts also support > multiple languages. Fira Code does not contain Chinese characters. This is quite clear even from just looking at the file sizes. There are many more Chinese characters than Roman characters and each takes up room in font files. A CJK font like Yu Gothic Regular `YuGothR.ttc` is 13 MB but Fira Code Regular `FiraCode-Regular.otf` is 120 KB. Open the fonts up in a font editor like FontForge and Fira Code includes 1353 characters whereas Yu Gothic includes 15622 characters with 12469 in the CJK Unified Ideographs range. When an application asks for Fira Code, a graphics stack component called a 'font mapper' determines how to implement that request. The requested font name is matched to a file. If there isn't a matching file then a default is used. That file is opened and its supported character ranges checked. Where there are gaps, other font files are used for characters in those gaps - maybe Yu Gothic is used for Chinese characters and EmojiOne Color Regular is used for emoji. It is the font mapper component that seems to be behaving poorly or is misconfigured. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3862#issuecomment-2094478059 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-plugins] [WIP] Add LSP plugin (PR #1331)
@techee pushed 6 commits. b3df23d328f504752688a6fb5c45beaa1447f1ab Add some GeanyDocument validity checks 4229993c86319ba4479dd289a2b0ee7ac0f4cf35 Make sure cached diagnostics and semantic tokens are cleared when document closed fbf54ff4305b67787fc6f377d0576ab62836 Make semantic tokens a little more robust against unexpected server values e43cf6ab59874417f726765f7c83cb7ba9126595 Fix goto document symbol de326e727106fa2702a2b031ca3dbc6151c3f77e Re-highlight symbols after performing a rename 0e90acb5d58649780dfe324fc104b4d38e8000ea Improve the global config file documentation -- View it on GitHub: https://github.com/geany/geany-plugins/pull/1331/files/59dd55a2dfa04412f45837b14b726de3ff20045b..0e90acb5d58649780dfe324fc104b4d38e8000ea You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Add Dockerfile filedef (PR #3757)
Nice. I think we could add this new filetype and then update the wiki page to have it only a seperate docker-compose filetype and a reference to the GIT version of this Docker filetype. I'm happy to do this after merge. Regarding the `extension=` setting: what do you think about using lower case? So that new files will be named "untitled.dockerfile". I don't know if there is a correct answer at all but IIRC what I've seen when there are mutliple dockerfiles is rather something like "Dockerfile.dev" or "Dockerfile.production" but we don't support this ordering in Geany. So, when using extensions, they are usually written in lowercase in my experience. For the reasons outlined above, I would add to the filetype extension list the pattern "Dockerfile.*" as this is more common than the others in my experience. Do we need to adjust anything for the Meson build system? -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3757#issuecomment-2094212685 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] Add Dockerfile filedef (PR #3757)
@eht16 commented on this pull request. > @@ -0,0 +1,14 @@ +[styling=Sh] + +[keywords] +primary=ADD ARG CMD COPY ENTRYPOINT ENV EXPOSE FROM HEALTHCHECK LABEL MAINTAINER ONBUILD RUN SHELL STOPSIGNAL USER VOLUME WORKDIR + +[lexer_properties=C] ```suggestion [lexer_properties=Sh] ``` Or am I missing something? It won't make much difference as the lexer properties for the C lexer will be probably ignored by the Sh lexer. But to be less confusing, I think it inherit from "Sh". -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3757#pullrequestreview-2039357473 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)
> Maybe one more question - should the open dialog show hidden files by > default? [...] > I'm not sure if it's possible on Windows too though (on the other hand > Windows hidden files aren't so important I think because it's not those > beginning with `.` like `.gitignore` that typical developer needs to edit). I don't think it's necessary because as you said, hidden files on Windows are usually less relevant and have stronger means than on Linux. The dialog in the current configuration shows files like `.gitignore` and this is good, I think. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/3861#issuecomment-2094125442 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
Closed #47 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#event-12704196950 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
Why do you use Geany as Flatpak at all? I don't understand why users go this way and then wonder why things won't work. This issue is clearly caused by the Flatpak package and should be reported to the maintainers of this package - whoever this is, it is very well hidden on FlatHub and falsely marked as "by Geany Team". -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#issuecomment-2094123941 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-plugins] geniuspaste: Port to libsoup3 (and avoid GTK3 deprecations) (PR #1342)
I tried to test it on Windows but got mixed results :(. First, we need more dependencies on Windows: ``` diff --git a/build/gtk-bundle-from-msys2.sh b/build/gtk-bundle-from-msys2.sh index 408d727f..529fa24a 100644 --- a/build/gtk-bundle-from-msys2.sh +++ b/build/gtk-bundle-from-msys2.sh @@ -21,7 +21,7 @@ EXE_WRAPPER_64="mingw-w64-x86_64-wine" # enchant, hunspell - for SpellCheck plugin # lua51 - for GeanyLua plugin # gnupg, gpgme - for GeanyPG plugin -# libsoup - for UpdateChecker plugin +# libsoup3 - for UpdateChecker & GeniusPaste plugins # libgit2 - for GitChangeBar plugin # gtkspell3 - for GeanyVC plugin # the rest is dependency-dependency @@ -30,6 +30,7 @@ ca-certificates ctags ctpl-git enchant +glib-networking gnupg gpgme http-parser @@ -39,8 +40,9 @@ libgcrypt libgit2 libgpg-error libidn2 +libproxy libpsl -libsoup +libsoup3 libssh2 libsystre libunistring ``` (The diff probably won't apply cleanly against this PR but should be easy enough to adopt, sorry.) It is important to remove "libsoup" as it cannot be installed together with "libsoup3". There is a runtime warning when both libraries are loaded. This obviously has a direct impact on the UpdateChecker plugin, so we probably need to merge them in order and rebase the latter one after the first one is merged. Then, I got a compiler warning which might or might not be new but still worth to look at: ``` In file included from C:/msys64/mingw64/include/glib-2.0/glib/giochannel.h:36, from C:/msys64/mingw64/include/glib-2.0/glib.h:56, from C:/msys64/mingw64/include/glib-2.0/gobject/gbinding.h:30, from C:/msys64/mingw64/include/glib-2.0/glib-object.h:24, from C:/msys64/mingw64/include/glib-2.0/gio/gioenums.h:30, from C:/msys64/mingw64/include/glib-2.0/gio/giotypes.h:30, from C:/msys64/mingw64/include/glib-2.0/gio/gio.h:28, from C:/msys64/mingw64/include/libsoup-3.0/libsoup/soup-types.h:9, from C:/msys64/mingw64/include/libsoup-3.0/libsoup/soup-auth.h:8, from C:/msys64/mingw64/include/libsoup-3.0/libsoup/soup.h:11, from geniuspaste.c:22: geniuspaste.c: In function 'json_request_new': C:/msys64/mingw64/include/glib-2.0/glib/gstring.h:74:5: warning: ignoring return value of 'g_string_free_and_steal' declared with attribute 'warn_unused_result' [-Wunused-result] 70 | (__builtin_constant_p (free_segment) ?\ | ~~~ 71 | ((free_segment) ? \ | ~ 72 | (g_string_free) ((str), (free_segment)) : \ | ~~~ 73 | g_string_free_and_steal (str))\ | ~~~ 74 | : \ | ^ 75 | (g_string_free) ((str), (free_segment))) | geniuspaste.c:612:5: note: in expansion of macro 'g_string_free' 612 | g_string_free(str, FALSE); | ^ ``` When trying to paste some file, Geany crashes for me when it is executed natively. I don't know yet why this happens and I didn't manage it yet to debug it with gdb. This might be related to my system where I use some firewall rules to block unwanted internet access from Windows and also have proxy connections configured and after all, it is Windows 7. When I start Geany from within the MSYS2 environment, pasting some file works to some extend, at least no crash :). But the response look weird:  The link below "\1" is actually also "\1". The `response_str` in `pastebin_parse_response` is "https://www.geany.org/p/6vzVo; which is correct. So there seems to be a problem with parsing the URL. I don't know if this related to these changes or not. Anyway, with the bundle changes above, we should get usable installers from the CI and so others could test it as well with a less weird Windows setup :). -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-plugins/pull/1342#issuecomment-2094122392 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
> Can a flatpack access the internet? Chrome is a Flatpak, so the answer must be yes, at some level. I was thinking of whether a flatpak can access the local filesystem, or whether it is all sandboxed/VM'd up (I love Geany, but dont have the skills to do this work) -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#issuecomment-2094041871 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany] windows下中文字体乱码 (Chinese font garbled under Windows) utf8 unicode (Issue #3862)
There are unlikely to be many other editors that use the GTK toolkit on Windows (vscode definitely does not) so the fact that fonts work elsewhere does not help. GTK tends to do its own thing, so how it handles fallback fonts on Windows is unknown. Vscode uses electron which is a browser library and likely uses the browser fallback list. -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/3862#issuecomment-2094041404 You are receiving this because you are subscribed to this thread. Message ID:
[Github-comments] Re: [geany/geany-themes] Flatpak directory location (Issue #47)
For others who may stumble upon this, attached is a silly little script I made to automate the process. For one-off ill-remembered esoterica, I often have these in directory called /Linux_software and it saves me remembering anything :) Simply create a directory called colorschemes and run the file. ``` #!/bin/bash ## # # GEANY - colour schemes add # 4 May 2024 # Ver 1.0.0 # ## # https://github.com/geany/geany-themes # https://www.geany.org/download/themes/ # put them in colorschemes/ (note USA spelling) sudo cp colorschemes/*.conf /var/lib/flatpak/app/org.geany.Geany/current/active/files/share/geany/colorschemes ``` -- Reply to this email directly or view it on GitHub: https://github.com/geany/geany-themes/issues/47#issuecomment-2094040019 You are receiving this because you are subscribed to this thread. Message ID:
