Geany 1.29 "Jowar" compiled 2016-07-16 / Windows 7-64 Bit and also Geany 1.29 "Jowar" compiled 2016-09-08 / Windows 7-64 Bit
If you select -> Lineend will be Set to CR -> 0x0d Set to LF -> 0x0d 0x0a Set to CR/LF -> 0x0d 0x0d 0x0a
Except with "Set to CR" there is an additional 0x0d.
SciTE 3.6.7 / Windows 7-64 Bit does it right. Geany Release 1.28 / Windows 7-64 Bit does it right.
The problem seems to be connected with the recognition of the lineend when opening a file. With Geany 1.28 when I open a file with CR/LF as lineend then "Document/Set Lineend/Set to CR/LF and convert" is preselected. When I open this file with Geany 1.29 then "Document/Set Lineend/Set to LF and convert" is preselected.
I attached three small test files with lineend CR, CR/LF and LF for convenience.
[test_cr.txt](https://github.com/geany/geany/files/464234/test_cr.txt) [test_crlf.txt](https://github.com/geany/geany/files/464235/test_crlf.txt) [test_lf.txt](https://github.com/geany/geany/files/464236/test_lf.txt)
Seems to work right on Linux.
Closed #1218.
Additional information: With Geany 1.28 Release for all three file types as attached above the status bar shows the mode correctly (mode:CR / mode:CRLF / mode:LF). With Geany 1.29 Nightly the status bar shows mode:LF for test_crlf.txt. (Still Windows 7-64).
Reopened #1218.
Sorry, I closed by mistake.
With Geany 1.28 Release for all three file types as attached above the status bar shows the mode correctly (mode:CR / mode:CRLF / mode:LF).
Current Git 2a2ae72 on Linux gets all three right, so its something strange about Windows or nightly builds.
The code for determining the line ending is [here](https://github.com/geany/geany/blob/master/src/utils.c#L102) and as you can see its not related to Windows or Linux. I notice it has a bug where it will undercount CRs for successive blank lines in CR only files, but thats not this. I am not aware of any change here lately, but your nightly is a couple of months old, you might try the latest.
I tested with the latest nightly Geany 1.29 "Jowar" (kompiliert am 2016-09-12 oder später) I saw a lot of changes in read.c since 1.28. Perhaps the input file is not opened in "binary mode" under windows any more. AFAIK only windows has this binary mode, so this wouldn't happen under linux.
Ok, thats new enough.
`read.c` is part of the tag parser, its not part of the Geany file reading so it won't be that.
The mode isn't controlled by Geany, we use the Glib or GIO libraries to read the file and neither has the option for us to specify a mode. Possibly the libraries have changed their file handling, but for your test files I doubt it would matter, the same characters will be read into the buffer. But you can see if the file was read correctly by setting `menu->view->show line endings` which will show exactly what characters are in the buffer.
All operations after that happen on the buffer in memory, so it only matters whats in the buffer.
...and with view/show line endings it shows only LF for the file with CRLF as line ending.
Can you use another application to show the file on disk actually has CRLF in it as its stored on your system? Not doubting you, but its the sort of mistake I would make :)
If the file on disk actually has the CRLF in it, then something is changing what is being read, and as its windows I can't help any further.
AFAIK if you don't `fopen` with explicitely specifying binary mode, then windows will not `fread` all characters of the input file into your buffer. When the input file is not opened in binary mode, windows will modify the line endings (CRLF -> LF) and eat other characters too (I think 0x00 and Ctrl-Z).
It is still the file test_crlf.txt I attached above. 
Thanks.
Well, I can't tell you what modes the file is opened in, because thats buried in the Glib/GIO libraries we use.
The library used for reading is chosen by the settings for saving, what are the `preferences->various->use_gio_unsafe_file_saving` and `preferences->various->use_atomic_file_saving` settings?
Atomic off, GIO on will use GIO, any other combination will use Glib. You could see if there is a difference between them.
PS, what version of Glib is Geany using on your system? `menu->help->debug messages` near the top.
A quick search returned: fopen: [(https://msdn.microsoft.com/en-us/library/yeby3zcb.aspx)] text vs binary mode: [(https://msdn.microsoft.com/en-us/library/ktss1a9b.aspx)] fread (see section Remarks): [(https://msdn.microsoft.com/en-us/library/kt0etdcs.aspx)]
Geany debug messages: 16:25:55: Geany INFO : Geany 1.29, German_Germany.1252 16:25:55: Geany INFO : GTK 2.24.28, GLib 2.48.1 16:25:55: Geany INFO : System data dir: D:\Programme\Geany\data 16:25:55: Geany INFO : User config dir: C:\Users\honrathxp\AppData\Roaming\geany 16:25:55: Geany INFO : System plugin path: D:\Programme\Geany\lib\geany 16:25:55: Geany INFO : Added filetype Clojure (61). 16:25:55: Geany INFO : Added filetype CUDA (62). 16:25:55: Geany INFO : Added filetype Cython (63). 16:25:55: Geany INFO : Added filetype Genie (64). 16:25:55: Geany INFO : Added filetype Graphviz (65). 16:25:55: Geany INFO : Added filetype JSON (66). 16:25:55: Geany INFO : Added filetype Scala (67). 16:25:55: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\filebrowser.dll (Dateibrowser) 16:25:55: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\splitwindow.dll (Fenster teilen) 16:25:55: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\saveactions.dll (Speicheraktionen) 16:25:55: Geany WARNING : failed to load icon 'classviewer-var': Unrecognized image file format 16:25:55: Geany WARNING : failed to load icon 'classviewer-method': Unrecognized image file format 16:25:55: Geany INFO : E:\Downloads\geany\test_crlf.txt : None (UTF-8) 16:25:55: Geany INFO : selection style is set to invisible - ignoring! 16:25:55: Gtk WARNING : Error loading theme icon 'geany-save-all' for stock: Unrecognized image file format 16:25:55: Gtk WARNING : Error loading theme icon 'geany-build' for stock: Unrecognized image file format 
Try switching on atomic file saving and see if it makes any difference.
I did and the result is still the same. BTW if the setting for file saving changes how geany reads files then this would IMHO be an error. When geany inspects the input file buffer to find out, what kind of line ending was mostly used in the input file (your code snippet `utils_get_line_endings` ), then geany definitely must always open and read the input files in binary mode under windows. 
As I have said twice above, Geany does not open the file and does not control the mode, Geany calls Glib or GIO library calls which claim to return the file contents. Perhaps the version of those libraries is different to the one used in 1.28 and they changed something. But unusual for both to change in the same way, does Geany 1.28 with line endings turned on show the CRLF properly and what version of Glib is it using?
Choosing the read library based on the write setting may seem strange, but IIRC the read library is GIO when the write library is GIO because GIO does some caching that the other library doesn't and so there can be subtle errors in metadata if they are mixed. I know there was a change to keep the two code paths totally separate.
Geany 1.28 debug messages: 17:29:16: Geany INFO : Geany 1.28, German_Germany.1252 17:29:16: Geany INFO : GTK 2.24.28, GLib 2.48.1 17:29:16: Geany INFO : System data dir: D:\Programme\Geany\data 17:29:16: Geany INFO : User config dir: C:\Users\honrathxp\AppData\Roaming\geany 17:29:16: Geany INFO : System plugin path: D:\Programme\Geany\lib\geany 17:29:16: Geany INFO : Added filetype Clojure (61). 17:29:16: Geany INFO : Added filetype CUDA (62). 17:29:16: Geany INFO : Added filetype Cython (63). 17:29:16: Geany INFO : Added filetype Genie (64). 17:29:16: Geany INFO : Added filetype Graphviz (65). 17:29:16: Geany INFO : Added filetype JSON (66). 17:29:16: Geany INFO : Added filetype Scala (67). 17:29:16: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\filebrowser.dll (Dateibrowser) 17:29:16: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\splitwindow.dll (Fenster teilen) 17:29:16: Geany INFO : Loaded: D:\Programme\Geany\lib\geany\saveactions.dll (Speicheraktionen) 17:29:16: Geany INFO : E:\Source\geany\geany\src\utils.c : C (UTF-8) 17:29:16: Geany INFO : Loaded D:\Programme\Geany\data\tags\std99.c.tags (C), 1619 symbol(s). 17:29:16: Geany INFO : selection style is set to invisible - ignoring! 17:29:16: Geany INFO : E:\Downloads\geany\test_crlf.txt : None (UTF-8)
And also with atomic off: 
Not sure whether it is related so just a guess: did you try 1.29 only from the nightly builds? They are cross-compiled with a very old gcc while the release tarballs are built natively with a recent toolchain. I don't really think this relevant here but I can't exclude it.
I hope to find some time on the weekend to test this on Windows.
Furthermore, I'm wondering about the warnings you posted, even though they are really unrelated: `16:25:55: Gtk WARNING : Error loading theme icon 'geany-save-all' for stock: Unrecognized image file format`
Yes, I tried 1.29 from the nightly builds. There are some other small problems with the nightlies (under windows): a) the german translation is not included as of github master (I reported an issue #1219 which as I found out later has already been fixed in master but is still wrong in the nightly) b) it seems that some icons are missing or broken - at least the Geany Aladdins Lamp icon in the about box is broken I am using Geany mostly under windows and normally I try the nightlies because I think that there are not so many Geany testers for windows and perhaps I can help a little bit. I know that I can't expect production quality from the nightlies so I usually try to report only errors when I think it might be an error in geany and not an error in the nightly build process.
Regarding the original issue: I will try to create a new build soon of current master natively compiled on Windows. It would be great if you could test it then. So we will know if the line break detection issue is related to the nightly builds.
Regarding the new issues above: a) this is expected as the translation files are not included in the nightly build ZIP archive b) I don't understand yet why there are issues with the icons but maybe this is also some incompability with the nightly builds. As I said before, the Windows release binaries are built using a recent toolchain (compiler, GLib, GTK, ...) while the nightly builds are cross-compiled on Linux system with a rather old toolchain (especially the compiler). I'd consider it very lucky that it runs at all.
Before someone might want to complain about this: the original goal of the nightly builds were to test and ensure the code can be compiled for different platforms and using different compilers and versions. The fact that they can be downloaded and used is rather a side effect. Still, when I'm bored some time, I will work on the nightly Windows builds to give them a recent toolchain and so produce binaries which are more compatible with the release binaries.
Still, when I'm bored some time, I will work on the nightly Windows builds to give them a recent toolchain and so produce binaries which are more compatible with the release binaries.
It would be cool if the nightly builds could produce the full win32 installer package. Maybe it's too much work, but it would be cool :)
Regarding the original issue: I will try to create a new build soon of current master natively compiled on Windows. It would be great if you could test it then.
Will test when I see a new nightly.
a) this is expected as the translation files are not included in the nightly build ZIP archive
Good to know. Next time I will check Github master before reporting an i18n issue.
b) I don't understand yet why there are issues with the icons ...
Normally the Nightlies work pretty well for me under windows. Sometimes when the new Nightly needs a newer version of GTK than the version of GTK that came with the previous Geany release then there are problems with parts of the GUI.
It would be cool if the nightly builds could produce the full win32 installer package.
Yes, this is the way to go. Technically it should be possible (makensis is available for Linux). It just requires me to do it :). Will do probably but it might take some weeks until I find time for it.
I just tested it on Windows with a freshly built Geany from master and it works as expected. Then I used the last nightly build and it failed as described.
So, it is indeed an issue with the nightly builds. For whatever reasons.
@Heihon if you want to test and confirm my assumption, I created test installers from current GIT master: http://download.geany.org/snapshots/geany-1.29nightly20160918_setup.exe http://download.geany.org/snapshots/geany-plugins-1.29nightly20160918_setup.... These include also updated translation files.
Btw, with the cross-compiled nightly builds I get also warnings like ` Error loading theme icon 'geany-build' for stock: Unrecognized image file format`. So I assume this is really some sort of binary incompability, probably between the Geany binaries and GTK/Glib.
As said, at some point I'll change the way the nightly builds will be created and then they should get more usable again.
http://download.geany.org/snapshots/geany-1.29nightly20160918_setup.exe
Wow, I installed this and all problems are gone. All three types of lineends are shown and converted properly (with and without use_atomic_file_saving). No more "Error loading icon". No missing icon in the about box. And with proper translation. Thank you! I did not close this myself because of the obvious issues with the nightly build process. But please feel free to close this as geany issue or to relabel it as nightly build issue. Thanks again.
And the bundle with all plugins
http://download.geany.org/snapshots/geany-plugins-1.29nightly20160918_setup....
works as well.
Thanks for testing. I created #1241 for the nightly build issue (and will work on this in a few weeks probably). So we can close this one.
Closed #1218.
github-comments@lists.geany.org