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
It would be convenient to append items "copy filename" and "copy filepath" on tabs right click menu
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/868
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>
This adds a new option in the preferences dialog to show line ending characters only when they differ from what the majority of the line endings in the file use.
So it should be easier to spot accidentally misused line endings.
The idea is from @cousteaulecommandant and shamelessly implemented by me :D.
I guess we can improve the wording of the visible option name and its tooltip.
Screenshot:
Testfile: [show_differing_eols.zip](https://github.com/geany/geany/files/9542533/show_…
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3287
-- Commit Summary --
* Add option to only show line endings if they differ from file default
-- File Changes --
M data/geany.glade (52)
M doc/geany.txt (40)
M src/editor.c (1)
M src/editor.h (1)
M src/keyfile.c (2)
M src/plugindata.h (2)
M src/prefs.c (19)
M src/sciwrappers.c (25)
M src/sciwrappers.h (1)
-- Patch Links --
https://github.com/geany/geany/pull/3287.patchhttps://github.com/geany/geany/pull/3287.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3287
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3287(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