Depends on #2355 for docs.
* Add *Project patterns* to open dialog file filters
* Re-use "File patterns" string in Find in Files dialog vs "Files" for clarity
* Show ungrouped filetypes first in open dialog file filter (fixes #2296 - see [this comment in particular](https://github.com/geany/geany/issues/2296#issuecomment-5337963…)
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2356
-- Commit Summary --
* Add *Project patterns* to open dialog file filters
* Show ungrouped filetypes first in open dialog file filter
* docs: Document Open dialog options
* Update filter docs
* Re-use "File patterns" string in Find in Files dialog vs "Files"
-- File Changes --
M data/geany.glade (2)
M doc/geany.txt (40)
M src/dialogs.c (29)
M src/search.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/2356.patchhttps://github.com/geany/geany/pull/2356.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2356
I tried removing files from /usr/share/geany/filedefs and editing filetype-extensions.conf but neither of those changes resulted in a shorter file pick list. I use less than 10 file types on a regular basis, but picking them out of that scrolling, out of window, file list is a pain. How do I shorten that list?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2296
After the update to Scintilla 5.1.5, I started getting memory corruption crashes when saving some files. (Sorry for not noticing this before, I thought the Scintilla update didn't contain any changes on the Geany side.) I may be wrong but I think the problem is in
https://github.com/geany/geany/pull/3046/commits/d7c985e47412f8a53c5a8202a0…
and misunderstanding if the following Scintilla API change
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value. The value returned is 1 less than previous versions of Scintilla. Applications should allocate a buffer 1 more than this to accommodate the NUL. The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL. This is more consistent with other APIs.
This part
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value...
> ...The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL.
says that that the returned __length__ doesn't include NUL, not that the returned string misses the NUL character. The rest of the change description says that we should allocate `+1` buffer to accommodate for that.
I believe we should revert the above patch and then go through all the uses of `SCI_GETTEXT`, `SCI_GETSELTEXT`, and `SCI_GETCURLINE` and corresponding `sci_` wrappers and update the code where needed (including plugins). I don't think it's a good idea to update the `sci_` wrappers alone to mirror previous behavior since the whole Scintilla API is part of Geany's API so this is a API change anyway and making `sci_` functions do something else than direct Scintilla calls is confusing.
Rant: I really don't understand why Neil made this change - even though it fixes some inconsistency in Scintilla API, this is a hard to spot backwards incompatible change and such things shouldn't be made in minor releases of a library.
@kugel- @eht16 @elextr What do you think?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3095
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3095(a)github.com>
Instead of requiring the user to specify a browser just try to
use the system default browser through gtk_show_uri_on_window().
This is done when tool_prefs.browser_cmd is empty which is
also the new default.
This aligns with windows where we do this already. Though we're
bypassing tool_prefs.browser_cmd there entirely, while on non-Windows
we still honor tool_prefs.browser_cmd when it's set.
This is primarily useful for flatpak support where we cannot just
execute arbitrary commands on the host (unless using flatpak-spawn).
Also, firefox is arguably a bad default these days, given the
declined marked share.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3178
-- Commit Summary --
* Use gtk_show_uri_on_window() in utils_open_browser() by default
-- File Changes --
M data/geany.glade (1)
M src/keyfile.c (4)
M src/utils.c (18)
-- Patch Links --
https://github.com/geany/geany/pull/3178.patchhttps://github.com/geany/geany/pull/3178.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3178
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3178(a)github.com>
Like the documentation says, Reflow Lines/Block breaks lines **at** the long line marker if the line breaking is disabled. The problem is that the long line marker marks characters **after** the given column. This means that Reflow Lines/Block should probably reflow at `eprefs->long_line_column + 1`:
https://github.com/geany/geany/blob/b6fe9f17aeae40ab48e73481e618877e65db464…
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2078
I have been attempting to compile geany from git and although it appears to build successfully, when I try to run it, the following error is displayed:
> (geany:29825): Geany-ERROR **: 16:14:48.297: Cannot create user-interface: Failed to open file “geany.glade”: No such file or directory
Trace/breakpoint trap
I have configured the build with './autogen.sh --prefix=/opt/geany' and when I type in the following:
> /opt/geany/bin/geany --print-prefix
the following is displayed:
> /opt/geany
/opt/geany/share
/opt/geany/lib
/opt/geany/share/locale
Due to the error, I tried to install from the repository for my linux distribution (Debian testing/buster) on a 64 bit machine and even their version has the same problem.
I can change to the /opt/geany/share/geany directory and then run the program and it will start up (as the glade file is in that directory) but then it will not load the plugins that I have also built from git.
I note that in the Makefile that GEANY_DATA_DIR is being set to /opt/geany/share/geany which seems to be correct but it does not seem to be getting taken into account in the final executable or libraries.
Any help in this matter would be much appreciated.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1915
Currently the markdown preview always resets the scroll position of the preview on any modification of the markdown text.
I would be nice if the preview can remember the scroll position.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1055
Geany's markdown syntax highlighting (without the markdown plugin) is confused, when code block is indented.
All the text after code block end is blue and ignores *all following* markdown syntax highlighting .
![md_indented_code_block](https://user-images.githubusercontent.com/1393254/114905882-c0be4c80-9e19-11eb-8ebe-3d5bfc41b439.png)
When code block is *not* indented, everything is ok.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2797