While using Geany in Gnome I found that sometimes code navigations was slow,
changing to a new line o making selections were reflected after aprox 1 second
on the screen.
Just opening a file and navigating doesn't trigger this problem, after editing,
saving or selecting some text the issue shows up.
I have other setup of Stretch with MATE desktop and the problem isn't there.
I also compiled a clone of the geany github repo and I was able to reproduce the
problem (in Gnome).
(I filed a bug report to the debian package)
--
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/1532
For example, take this Ruby code:
```Ruby
(0..9).each do |i|
puts i
puts '-' if (i % 3) == 0
end
```
If you do Ctrl+E, it will produce this:
```Ruby
#(0..9).each do |i|
# puts i
# puts '-' if (i % 3) == 0
#end
```
But, I'd like it to produce this:
```Ruby
#(0..9).each do |i|
# puts i
#
# puts '-' if (i % 3) == 0
#end
```
You can imagine that code with many blank newlines makes it hard to distinguish if the whole block is commented, or just sections.
Is there a setting for this?
I think this is useful for usually-single-line-commented languages, like Ruby/Python, especially if your settings don't strip spaces on newline.
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/2239
For some reason I don't yet know, Travis fails fairly randomly building GP: I seen problems with `dh-marshal` (possibly due to out-of-tree build? but why is it random?) and now with WebHelper's enums (there doesn't seem to be an error but the enum types are missing (although they are present in Git).
--
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/650
I use geany with webhelper on debian 8.3 x 32.
On my previous PC (also with debian 8) I had the same problem but it disappeared after update of debian, geany and plugins.
Now I have new laptop with up-to-date debian and with the same problem. I have geany ver.1.26 and webhelper ver. 1.26+dfsg-1.
No difference which site or local html file I use, webhelper itself works great. But when I press web inspector button or choose 'inspect element' from right-click menu, geany immediately crashes.
If I start geany from terminal. after the crash I see:
> a@b:~$ geany
Segmentation fault
a@b:~$
Geany is the best lightweight IDE ever and I hope You'll help me to solve the problem.
TY in advance!
---
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/412
The current highlighting of dark blue (as opposed to black when not selected) is very difficult for me to see I imagine there's something I can edit, but there's nothing in the documentation and playing with brace_good in filetypescommon didn't appear to achieve much
Using geany 1241
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/885
Steps to reproduce:
1. create a new file using the tree browser
2. give the file a name
3. Try editing the file
4. Try saving.
OS: Windows 10
doing a file->new file via geany works fine.
[original issue](https://github.com/geany/geany/issues/1842)
--
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/737
Hello,
I was looking forward to change the entire windows to dark, but the theme only changed the color of the editor.
Is it possible to set the whole programm to dark on windows?
Regards
Andi
--
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/2225
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:
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