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 .
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
I'm using Geany 1.30.1 on Windows 7.
After happily editing a file over some time, suddenly Geany refuses to save it with this error message:
I know that Windows sometimes grabs a lock on a file when I'm just looking at it with another tool, but I am pretty sure that the only way I'm operating on this file since the last bootup of my machine, is by editing it in Geany. Still, for the safe side, I run the [Handle](https://technet.microsoft.com/en-us/sysinternals/bb896653) utility to see whether someone has a handle to either the file or the directory where the file is in - nothing. I also used Geany's "File/Properties" to check, whether maybe the file secretly became readonly; this is also not the case. Finally I turned on the gio_unsafe_save_backup and tried again, but same result. Note that it is a local file, so there can't be network issues involved either.
Then I tried "save as" with "rename", to store it under a new name in the same directory. This was refused with the same error message. I could see that the file got renamed, but still had the old content. This is weird: If the cause would be a directory lock, the rename should ALSO have failed.
Needless to say that it is not a disk space problem either.
I resolved the problem temporarily by using the following strategy:
1. Using "Save as" to save it to a completely different directory.
2. Copying the file back (on the command line)
3. Closing the Buffer in Geany
4. Reopening it
I then checked with my remaining open files in Geany. Modifying the buffer and saving, caused the same error with two of the files, while it worked fine with two others. One of the two where the error occured too, belonged to a different directory, while all the others - including those which could be saved - belonged to the same directory as the file where the problem occured initially.
I don't see yet in what respect the two files which did not have the problem, differed significantly from the two files where the problem occured.
Closing Geany, starting it, and I can continue editing like normal, but my feeling is that it will be only a question of time until the problem occurs again. Is there anything I can do to help the Geany developers to nail down the cause of this strange problem?
--
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/1500
Since distros are now not defining `python` and python 2 is dead, should be changed to `python3`, see also discussion on #2223
--
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/2615
Given that Markdown has lots of undefined semantics, this may very well be a valid interpretation of certain broken Markdown documents. But I guess most would agree that the priority should be the other way around.
Example: (Save as `something.md` and open with Geany)
_This is "underlined"
```
should_be code
```
This sentence is considered code, because the
"matching" underscores had priority (?)
Note that the "stray underline" can also occur in HTML inline-comments, where they don't stand for underlining anyway.
<!-- Like this one. I know very well that this won't usually appear. -->
--
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/1439
1- Enable Tools -> Split Window -> Side by side
2- Open one file in both left and right sides
3- Change cursor position in one side so that cursor and scroll position in 2 sides are different
4- Type something in the right side, then press Control + Z
5- The cursor and scroll position in left side changes (unexpectedly) to the position of right side, so that you loose where you were (writing something in a different part of the same file)
---
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/988
I'm using Geany 1.33 on Windows 10 and invoke it from command line for an empty (zero byte) file. Though in the Geany preferences on the Files page the "Default end of line characters" combobox is set to "Windows (CRLF)", pressing enter and saving in the empty file will write Unix (LF) line endings.
--
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/1950
I know this isn't a Geany issue directly, but maybe there's something that can be done to improve the build times. I ran some tests to measure the actual build times.
## Machines
* "Linux Native"
* Ubuntu 18.04
* 32GB RAM
* 6-core i7 @ 3.7GHz
* Entirely on SSD
* "Windows with MSYS2"
* Windows 10 Pro
* 32GB RAM
* 6-core i7 @ 3.7GHz
* Geany source code on SSD, system headers and build tools on mechanical HDD.
* "Linux VM Guest on Windows Host"
* ElementaryOS from 2018, in VirtualBox on Windows 10
* 4GB RAM
* 1-core emulated CPU (presumably 3.7GHz + VM overhead)
* All files in virtual disk stored on a mechanical HDD.
## Tests
* "configure" - `./configure [opts]`
* "make" - `make -j12` after a `make clean`
* "imake" - `touch src/build.h && make -j12` to do an incremental build
* "install" - `make -j12 install`
I used 12 `make` jobs on account of the 12 hyperthreads in the CPU, even in the VM which makes no sense since I only assigned it a single core. I used `time` on the above commands and took the average of 3 runs for each. All 3 runs were quite similar in all cases.
## The results
The Y axis is in seconds.
## Observations
* As expected `configure` was really slow on Windows since it spawns tons of processes.
* The Windows build seems to be spending a large portion of the time linking which is why even incremental build was still very slow.
* In the wimpy Linux VM with 1 core, the vast majority of the compile time was spent compiling Scintilla's C++ code, shown by how the incremental build that didn't touch C++ code is comparatively fast.
* I don't know whether it's the `ld` linker which is slow, the `libtool` stuff, or some combination.
## Possible Solutions?
The linking times even in the Libtool helper libraries is really slow, so maybe for Windows we could not use helper libraries and link all of the `libgeany` objects together in one go.
Maybe there's a way to get linking itself to be faster, needs investigation. Maybe a different build of `libtool` or something?
--
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/2305