l noticed that the underscores disappear or become cut when increasing the font size to specific values.
![2017-03-18-104811_1920x1080_scrot](https://cloud.githubusercontent.com/assets/3192173/24071016/bd21312e-0bc8-11e7-8929-3896bc174085.png)
When putting solely underscores in a line, they are invisible. When a space or some letter is added to the line, the underscores are slightly visible. l use sub-pixel-geometry, thus that the slightly visible underscore is green means it's the top part and the lower pixels (or whatsoever) are cut.
line 934: 3 underscores, 1 space
line 935: 3 underscores
--
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/1431
Updated to git just after 1.30 release:
20:42:01: Geany INFO : Geany 1.31 (git >= f5be2fa), en_AU.UTF-8
20:42:01: Geany INFO : GTK 3.18.9, GLib 2.48.2
now calltips are located far off to the left actually partially off the screen (see screenshot).
![screenshot from 2017-03-06 20-45-48](https://cloud.githubusercontent.com/assets/811085/23606802/065862…
--
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/1422
I noticed this bug when I received a text file that Geany opened as something unreadable, but I found out that it is easily reproducible.
Let's say I create a file test.txt with some cyrillic content. For example, just one word "Тест", which is "Test" in Russian. Of course, it's two lines: the line with "Тест" and the last empty line. Then I select any Cyrillic encoding (e.g. Cyrillic/Russian (CP866)) and save the file. At this moment I still can discern its content: "Тест".
Then I close this file and open it again. Now it's content reads (in case I chose CP866) as "¥áâ". Checking the encoding setting I see that it's now set to ISO-8859-1 (and no, I have not enabled the setting "Use fixed encoding when opening non-Unicode files"). Setting the encoding to the right one does not fix the issue because Geaby does not recode the content of the file, it just sets the encoding in which the current (wrong) content will be saved.
So it seems that Geany when it determines that the file is not Unicode tries to open it as ISO-8859-1. I don't know if it requires a lot of work to fix, but Notepad2 and Notepad++ on Windows, whichever the encoding is, determine it correctly.
My system is:
Kernel: 4.10.1-1-MANJARO i686 (32 bit)
Geany 1.29
GTK 2.24.31, GLib 2.50.3
--
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/1429
```
▓▒░frlan@trabant░▒▓██▓▒░ Di Mär 14 05:45:22
/home/frlan> cd /tmp
█▓▒░frlan@trabant░▒▓██▓▒░ Di Mär 14 05:45:32
/tmp> virtualenv test
Running virtualenv with interpreter /usr/bin/python2
New python executable in /tmp/test/bin/python2
Also creating executable in /tmp/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
█▓▒░frlan@trabant░▒▓██▓▒░ Di Mär 14 05:45:41
/tmp> cd test
█▓▒░frlan@trabant░▒▓██▓▒░ Di Mär 14 05:45:43
/tmp/test> source bin/activate
(test) █▓▒░frlan@trabant░▒▓██▓▒░ Di Mär 14 05:45:52
/tmp/test> gdb geany
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from geany...done.
(gdb) r --verbose
Starting program: /usr/local/bin/geany --verbose
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Geany-INFO: Geany 1.31 (git >= 994cb479), de_DE.utf8
Geany-INFO: GTK 2.24.31, GLib 2.50.3
Geany-INFO: System data dir: /usr/local/share/geany
Geany-INFO: User config dir: /home/frlan/.config/geany
[New Thread 0x7fffeeb80700 (LWP 31380)]
[New Thread 0x7fffee37f700 (LWP 31381)]
Geany-INFO: System plugin path: /usr/local/lib/geany
Geany-INFO: Added filetype Arduino (61).
Geany-INFO: Added filetype CUDA (62).
Geany-INFO: Added filetype Clojure (63).
Geany-INFO: Added filetype Scala (64).
Geany-INFO: Added filetype JSON (65).
Geany-INFO: Added filetype Cython (66).
Geany-INFO: Added filetype Genie (67).
Geany-INFO: Added filetype Graphviz (68).
Geany-INFO: Loaded libvte from libvte.so
Geany-INFO: Loaded: /usr/local/lib/geany/automark.so (Auto-Mark)
Geany-INFO: Loaded: /usr/local/lib/geany/treebrowser.so (Baumnavigator)
Geany-INFO: Loaded: /usr/local/lib/geany/commander.so (Commander)
Geany-INFO: Loaded: /usr/local/lib/geany/geanydoc.so (Doc)
Geany-INFO: Loaded: /usr/local/lib/geany/geanyprj.so (GeanyPrj)
Thread 1 "geany" received signal SIGSEGV, Segmentation fault.
0x00007fffe77bd221 in PyModule_AddObject () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
(gdb) bt
#0 0x00007fffe77bd221 in PyModule_AddObject () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#1 0x00007fffe7bde7c8 in initkeybindings () at geanypy-keybindings.c:200
#2 0x00007fffe7bdf5f0 in GeanyPy_start_interpreter () at geanypy-plugin.c:96
#3 geanypy_init (plugin_=0x555555c956a8, pdata=0x555555c96780) at geanypy-plugin.c:376
#4 0x00007ffff79afb75 in plugin_load (plugin=0x555555c95680) at plugins.c:582
#5 plugin_new (proxy=0x7ffff7dcd920 <builtin_so_proxy_plugin>, fname=fname@entry=0x555555ba4e50 "/usr/local/lib/geany/geanypy.so",
load_plugin=load_plugin@entry=1, add_to_list=add_to_list@entry=0) at plugins.c:733
#6 0x00007ffff79b1276 in load_active_plugins () at plugins.c:1135
#7 plugins_load_active () at plugins.c:1280
#8 0x00007ffff79aa455 in main_lib (argc=<optimized out>, argv=<optimized out>) at libmain.c:1169
#9 0x00007ffff4ae22b1 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#10 0x00005555555547ba in _start ()
```
--
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/546
Or we just update the pbuilder box to Debian Stable (Jessie). For some reason it took until today that we were talking about Oldstable and not Stable...
I replaced the Wheezy pbuilder box with a Jessie one and now the plugin compiles fine again.
I'm pretty sure nobody will miss the Wheezy nightly builds.
--
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/commit/6b8920c918327eee226483c46c927…
When I want to close a project to create another, when closing the project geany falls, it closes unexpectedly.
Thanxs!
--
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/1423
This change broke the nightly builds for Debian Oldstable. The most recent version of libsoup available in Debian Oldstable is 2.38 (https://packages.debian.org/wheezy/libsoup2.4-dev).
I think we can either keep the code more backwards compatible and revert the change or add some guards for older libsoup versions or we just keep the requirement on newer libsoup versions for this plugin and disable it in nightly builds for Debian Oldstable.
--
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/commit/6b8920c918327eee226483c46c927…
I use the "Find in files" dialog extensively in my everyday work *because* it is a very elegant interface to `grep` but nevertheless integrates so well with Geany. However, sometimes I am not interested in the contents of files but merely there names. In these situations I would love to have a similar interface to POSIX `find` that simply takes find arguments and presents any found paths similarly to the "Find in files" dialog (i.e. clickable to open the respective file). Please consider this as a feature request - I won't try to implement it (partially due to the outcome of my "reload all" PR #54 :P)
--
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/1178