GCC 8 introduced `-Wsizeof-pointer-div` which is enabled by `-Wall` and
warns for sizeof divisions that look like they would compute the size
of a static array but are called on something on which this doesn't
work (e.g. a pointer as LHS). This is quite reasonable and useful, but
it fails to detect the case where the computation is guarded against
being called on problematic values, like our HL_N_ENTRIES() macro that
accepts NULLs but won't use the sizeof computation result then.
Work around this by implementing HL_N_ENTRIES() macro in a way that
cannot trigger such a warning yet yield the same result.
Example warning:
```
../../src/highlighting.c: In function ‘highlighting_init_styles’:
/usr/include/glib-2.0/glib/gmacros.h:351:42: warning: division ‘sizeof (HLKeyword * {aka struct <anonymous> *}) / sizeof (HLKeyword {aka struct <anonymous>})’ does not compute the number of array elements [-Wsizeof-pointer-div]
#define G_N_ELEMENTS(arr) (sizeof (arr) / sizeof ((arr)[0]))
^
../../src/highlightingmappings.h:74:48: note: in expansion of macro ‘G_N_ELEMENTS’
#define HL_N_ENTRIES(array) ((array != NULL) ? G_N_ELEMENTS(array) : 0)
^~~~~~~~~~~~
../../src/highlighting.c:966:5: note: in expansion of macro ‘HL_N_ENTRIES’
HL_N_ENTRIES(highlighting_keywords_##LANG_NAME)); \
^~~~~~~~~~~~
../../src/highlighting.c:1011:3: note: in expansion of macro ‘init_styleset_case’
init_styleset_case(CONF);
^~~~~~~~~~~~~~~~~~
```
---
Another solution could be reporting a bug to GCC for it to detect our use case and avoid the warning then, but that might or might not be much meaningful, and won't fix the issue on currently affected GCC versions anyway.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2398
-- Commit Summary --
* Rewrite HL_N_ENTRIES macro to avoid a GCC8 false positive warning
-- File Changes --
M src/highlightingmappings.h (12)
-- Patch Links --
https://github.com/geany/geany/pull/2398.patchhttps://github.com/geany/geany/pull/2398.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/2398
Related to https://github.com/geany/geany/issues/2185 and https://github.com/geany/geany/issues/2180,
I know that _"The colour scheme set for the editor widget where the code is, is again totally independent of any terminals, it's only used to style syntax highlighting of code in the documents notebook"_, but it is creating high-contract and not easy on the eyes.
This is what i get out of the box:
![image](https://user-images.githubusercontent.com/422244/59570765-336a0f80-906b-11e9-8bf5-b330b17b545b.png)
I.e., the editor widget is light-on-dark, while the side bar and the message windows are both dark-on-light. Such high-contract between the windows will make the eyes fatigue easily.
Please consider having a unified colour scheme on all three windows to easy the eyes. Thanks.
--
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/2196
Fixed deprecated gtk3 calls. The PR unfortunately includes an ugly list of all the GTK stockitems as I did not see a different solution.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/865
-- Commit Summary --
* commander: fixed deprecated gtk3 calls
-- File Changes --
M build/commander.m4 (1)
M commander/src/Makefile.am (7)
M commander/src/commander-plugin.c (22)
M utils/src/Makefile.am (3)
A utils/src/gp_gtkcompat.c (222)
M utils/src/gp_gtkcompat.h (5)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/865.patchhttps://github.com/geany/geany-plugins/pull/865.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-plugins/pull/865
I'm using the geany 1.32 default installation on ubuntu 18.04 64bit to edit test.md file.
for H1 - H6 headers, the "#" signs are bold, but not the rest of header, i.e. "# Header" only has bold for '#' not for the word 'Header'.
`**bold**` does not show bold, neither does `*italiic*` displays italic.
I can customize them all using filetypes.markdown, except for the H1-H6 headers, the header is not impacted at all as mentioned above, for example:
`header1=0xFFCB4F;0x1E1E1E;true;false` this change will make `#` bold with specified background/front color, but not the header content, i.e. "Header1" in `# Header1` stays non-bold.
At least I would like to have all markdown headers shown as bold inside Geany without the need of any previewer
--
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/2026
Most likely the string doesn't make sense to be transalted
--
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/587
This is a RFC regarding updating to the current version of Scintilla and getting off of the "fork" of the versions 3.x series (LongTerm3 branch).
The longer we wait to update, especially with the splitting off of lexers from Scintilla itself, we're basically just accumulating technical debt. Eventually the kind fellow currently maintaining the LongTerm3 branch will stop.
As far as I know, the main platforms Geany tries to support all have modern enough compilers/C++ standard libraries by now. There may be some older legacy/LTS platforms with users who won't be able to self-update to latest Geany without more effort, but with such limited developer time/interest/contributions for Geany, I don't think it's unreasonable to make some trade-offs like this in order to ensure Geany doesn't bitrot.
I might be willing to have a look at upgrading the code to work with latest Scintilla, but not if people are opposed, hence this RFC.
--
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/2519
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