Hi,
Is there any technical reason to check cl_options.readonly in document.c, and clear it load_startup_files(), instead of simply invoking document_open_file(filename, cl_options.readonly, ...) from main_handle_filename()?
Am 17.11.2011 19:20, schrieb Dimitar Zhekov:
Hi,
Is there any technical reason to check cl_options.readonly in document.c, and clear it load_startup_files(), instead of simply invoking document_open_file(filename, cl_options.readonly, ...) from main_handle_filename()?
In an earlier version it also worked when opening a .geany file (so all session files would be opened readonly). As opening via socket also goes through main_handle_filename() (and hopefully nothing else?), I guess there's no real reason anymore.
Best regards.
On Thu, 17 Nov 2011 21:07:41 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 17.11.2011 19:20, schrieb Dimitar Zhekov:
Is there any technical reason to check cl_options.readonly in document.c, and clear it load_startup_files() [...]
In an earlier version it also worked when opening a .geany file (so all session files would be opened readonly). As opening via socket also goes through main_handle_filename() (and hopefully nothing else?), I guess there's no real reason anymore.
Here's a small patch that cleanups readonly handling, and adds the missing def_clo.readonly initializer, which was a bug. Tested with normal and socket open.
BTW, -Wmissing-field-initializers displays a huge number of warnings in highlightingmappings.h (fill_eol and merge), and no warnings in any other source file (except def_clo above).
Le 18/11/2011 18:44, Dimitar Zhekov a écrit :
On Thu, 17 Nov 2011 21:07:41 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 17.11.2011 19:20, schrieb Dimitar Zhekov:
Is there any technical reason to check cl_options.readonly in document.c, and clear it load_startup_files() [...]
In an earlier version it also worked when opening a .geany file (so all session files would be opened readonly). As opening via socket also goes through main_handle_filename() (and hopefully nothing else?), I guess there's no real reason anymore.
Here's a small patch that cleanups readonly handling, and adds the missing def_clo.readonly initializer, which was a bug. Tested with normal and socket open.
Looks fine to me, could you provide a git-formatted patch (so there are authorship information in it) please?
BTW, -Wmissing-field-initializers displays a huge number of warnings in highlightingmappings.h (fill_eol and merge), and no warnings in any other source file (except def_clo above).
I know it, and the "missing" initializer are expected to be missing. Actually -Wmissing-field-initializers warns about fields implicitly initialized to 0, which is not a real problem but that "often" is unwanted. Here it's wanted not to clutter the initializer lists with plenty of zeros, and there is even a note on the top of the file.
However, if it's a problem for many readers, we could imagine adding a plenty of 0/FALSE everywhere, though I don't think it's necessary. Actually the better would be to have a portable way to disable this warning only for this particular file, but I'm not sure it's easy?
Regards, Colomban
Le 21/11/2011 15:49, Colomban Wendling a écrit :
Le 18/11/2011 18:44, Dimitar Zhekov a écrit :
[...] BTW, -Wmissing-field-initializers displays a huge number of warnings in highlightingmappings.h (fill_eol and merge), and no warnings in any other source file (except def_clo above).
I know it, and the "missing" initializer are expected to be missing. Actually -Wmissing-field-initializers warns about fields implicitly initialized to 0, which is not a real problem but that "often" is unwanted. Here it's wanted not to clutter the initializer lists with plenty of zeros, and there is even a note on the top of the file.
However, if it's a problem for many readers, we could imagine adding a plenty of 0/FALSE everywhere, though I don't think it's necessary. Actually the better would be to have a portable way to disable this warning only for this particular file, but I'm not sure it's easy?
I just fixed this by using GCC's "diagnostic" pragma in highlightingmappings.h [1]. Tested and works with GCC and CLang, and it should do nothing on non-GCC-style compilers.
Regards, Colomban
[1] https://github.com/geany/geany/commit/102ce1d205f0f56ee3a56eb17a4be9e2d58466...
On Mon, 21 Nov 2011 15:49:52 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Looks fine to me, could you provide a git-formatted patch (so there are authorship information in it) please?
Sure.
Actually -Wmissing-field-initializers warns about fields implicitly initialized to 0, which is not a real problem but that "often" is unwanted.
I guess it's safe to expect that our CC will implement the 1990 standard on this. :)
Le 21/11/2011 19:48, Dimitar Zhekov a écrit :
On Mon, 21 Nov 2011 15:49:52 +0100 Colomban Wendling lists.ban@herbesfolles.org wrote:
Looks fine to me, could you provide a git-formatted patch (so there are authorship information in it) please?
Sure.
Thanks, committed.
Regards, Colomban