On 13 March 2010 00:16, Nick Treleaven nick.treleaven@btinternet.comwrote:
Hi, There seems to be a bug in trunk if you edit an execute command field then restart Geany, the changes aren't saved.
Regards, Nick
Hi Nick,
I can only get it to fail if you set the commands when the filetype is none.
This is because executes are saved in the filetypes file and the function filetypes_save_commands() starts at index 1 not 0 so no commands are saved for filetype none.
Same happens for the filetype commands as well of course.
Options are:
1. give filetypes none an extension (currently NULL) and let it save 2. make filetype and execute rows of the dialog insensitive if the filetype is none
I favour option 1 since filetype none is a valid filetype (you can set it from the document menu) so why can't a user define commands for a filetype that Geany doesn't understand yet.
Example use case is editing the test file for the domain specific language they are developing the compiler/interpretor for.
Cheers Lex
On Sat, 13 Mar 2010 09:16:51 +1100 Lex Trotman elextr@gmail.com wrote:
There seems to be a bug in trunk if you edit an execute command field then restart Geany, the changes aren't saved.
I can only get it to fail if you set the commands when the filetype is none.
Sorry I forgot to mention that ;-) I ought to know better.
This is because executes are saved in the filetypes file and the function filetypes_save_commands() starts at index 1 not 0 so no commands are saved for filetype none.
Same happens for the filetype commands as well of course.
The None build commands are disabled in the dialog...
Options are:
- give filetypes none an extension (currently NULL) and let it save
- make filetype and execute rows of the dialog insensitive if the filetype
is none
I favour option 1 since filetype none is a valid filetype (you can set it from the document menu) so why can't a user define commands for a filetype that Geany doesn't understand yet.
Yes, I think 1 is better. Supporting filetype & execute commands for ft None is useful.
On a wider point, I don't think the GUI should limit setting filetype commands just because the config file has no entries listed - e.g. XML. The user should still be able to use the dialog to set some commands.
Regards, Nick
On 13 March 2010 23:16, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Sat, 13 Mar 2010 09:16:51 +1100 Lex Trotman elextr@gmail.com wrote:
There seems to be a bug in trunk if you edit an execute command field then restart Geany, the changes aren't saved.
I can only get it to fail if you set the commands when the filetype is
none.
Sorry I forgot to mention that ;-) I ought to know better.
This is because executes are saved in the filetypes file and the function filetypes_save_commands() starts at index 1 not 0 so no commands are
saved
for filetype none.
Same happens for the filetype commands as well of course.
The None build commands are disabled in the dialog...
Hmmmm I'm testing with a new build of r4748 and they are not disabled for a document with filetype none????
Options are:
- give filetypes none an extension (currently NULL) and let it save
- make filetype and execute rows of the dialog insensitive if the
filetype
is none
I favour option 1 since filetype none is a valid filetype (you can set it from the document menu) so why can't a user define commands for a
filetype
that Geany doesn't understand yet.
Yes, I think 1 is better. Supporting filetype & execute commands for ft None is useful.
There appear to be some wrinkles on extensions for config files that prevent this working, so I better ask before I change it and break the world.
Commands are loaded and saved in a file with extension from filetypes_get_extension which does not use the extension field of the filetype structure, but sets extension to lowercase of filetype name except in a couple of cases.
On loading filetypes_load_config does not call filetypes_get_extension for FILETYPE_NONE, instead hard coding it to "common".
Is there any reason (other than historical) to ignore the extension field when loading and saving, and if so whats the extension field for?
On a wider point, I don't think the GUI should limit setting filetype
commands just because the config file has no entries listed - e.g. XML. The user should still be able to use the dialog to set some commands.
AFAICT It doesn't limit it,specifically I re-tested with XML & it changed & saved and restored filetype commands, are you having problems?
It sounds like there is something different in your setup if the dialog sets filetype commands insensitive somewhere.
Have you also set the filetype command in your project?? If so and the project is open then the item in the standard dialog is set insensitive so that you don't edit it and then wonder why it doesn't work (because the project entry continues to override it). Thats one of the reasons I want to put it all in the one dialog in v2 so you can see this.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 14 Mar 2010 10:52:47 +1100 Lex Trotman elextr@gmail.com wrote:
This is because executes are saved in the filetypes file and the function filetypes_save_commands() starts at index 1 not 0 so no commands are
saved
for filetype none.
Same happens for the filetype commands as well of course.
The None build commands are disabled in the dialog...
Hmmmm I'm testing with a new build of r4748 and they are not disabled for a document with filetype none????
I have r4757 (but the revisions are the same for trunk).
The 'no filetype' commands are all disabled, but the make commands and execute are not disabled.
Options are:
- give filetypes none an extension (currently NULL) and let it save
- make filetype and execute rows of the dialog insensitive if the
filetype
is none
I favour option 1 since filetype none is a valid filetype (you can set it from the document menu) so why can't a user define commands for a
filetype
that Geany doesn't understand yet.
Yes, I think 1 is better. Supporting filetype & execute commands for ft None is useful.
There appear to be some wrinkles on extensions for config files that prevent this working, so I better ask before I change it and break the world.
Commands are loaded and saved in a file with extension from filetypes_get_extension which does not use the extension field of the filetype structure, but sets extension to lowercase of filetype name except in a couple of cases.
On loading filetypes_load_config does not call filetypes_get_extension for FILETYPE_NONE, instead hard coding it to "common".
Is there any reason (other than historical) to ignore the extension field when loading and saving, and if so whats the extension field for?
The extension field is a default for saving new files and it is configurable, so we can't use this as the basis for config filenames as it can change.
Probably we can fix this to return "none" instead of "common" and adjust all calling code to still work.
But for now (if it's easier) I think we can just disable the None filetype's Execute command (and its filetype build commands if there is a situation where they're not disabled [but I can't find one myself]).
On a wider point, I don't think the GUI should limit setting filetype
commands just because the config file has no entries listed - e.g. XML. The user should still be able to use the dialog to set some commands.
AFAICT It doesn't limit it,specifically I re-tested with XML & it changed & saved and restored filetype commands, are you having problems?
Yes, the XML filetype build commands are all disabled.
It sounds like there is something different in your setup if the dialog sets filetype commands insensitive somewhere.
I don't think there can be because I tried this with a new config dir (-c option). Same for the filetype None issue above.
Have you also set the filetype command in your project?? If so and the
All this is without a project open.
project is open then the item in the standard dialog is set insensitive so that you don't edit it and then wonder why it doesn't work (because the project entry continues to override it). Thats one of the reasons I want to put it all in the one dialog in v2 so you can see this.
That's a separate issue, but I agree that the current situation can be confusing when a project is open and it needs improving.
Regards, Nick
On 15 March 2010 23:21, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Sun, 14 Mar 2010 10:52:47 +1100 Lex Trotman elextr@gmail.com wrote:
This is because executes are saved in the filetypes file and the
function
filetypes_save_commands() starts at index 1 not 0 so no commands are
saved
for filetype none.
Same happens for the filetype commands as well of course.
The None build commands are disabled in the dialog...
Hmmmm I'm testing with a new build of r4748 and they are not disabled for
a
document with filetype none????
I have r4757 (but the revisions are the same for trunk).
The 'no filetype' commands are all disabled, but the make commands and execute are not disabled.
Options are:
- give filetypes none an extension (currently NULL) and let it save
- make filetype and execute rows of the dialog insensitive if the
filetype
is none
I favour option 1 since filetype none is a valid filetype (you can
set it
from the document menu) so why can't a user define commands for a
filetype
that Geany doesn't understand yet.
Yes, I think 1 is better. Supporting filetype & execute commands for ft None is useful.
There appear to be some wrinkles on extensions for config files that
prevent
this working, so I better ask before I change it and break the world.
Commands are loaded and saved in a file with extension from filetypes_get_extension which does not use the extension field of the filetype structure, but sets extension to lowercase of filetype name
except
in a couple of cases.
On loading filetypes_load_config does not call filetypes_get_extension
for
FILETYPE_NONE, instead hard coding it to "common".
Is there any reason (other than historical) to ignore the extension field when loading and saving, and if so whats the extension field for?
The extension field is a default for saving new files and it is configurable, so we can't use this as the basis for config filenames as it can change.
Ok, that makes sense.
Probably we can fix this to return "none" instead of "common" and adjust all calling code to still work.
Or just store it in filetypes.common, doesn't matter so long as we write to the file we read from :-) Its a separate section so it won't upset any other content.
But for now (if it's easier) I think we can just disable the None filetype's Execute command (and its filetype build commands if there is a situation where they're not disabled [but I can't find one myself]).
Wierd, for me they are always enabled, looking at the code the only time they are set insensitive is if something is overloading them (but you don't have a project), or if doc==NULL or doc->filetype==NULL Maybe we've got another uninitialised variable that is NULL on your machine but not on mine, but I can't find it. GCC gives no warnings with -Wall, but thats not authoritative.
Are the regex fields sensitive or not?
On a wider point, I don't think the GUI should limit setting filetype
commands just because the config file has no entries listed - e.g. XML. The user should still be able to use the dialog to set some commands.
AFAICT It doesn't limit it,specifically I re-tested with XML & it changed
&
saved and restored filetype commands, are you having problems?
Yes, the XML filetype build commands are all disabled.
It sounds like there is something different in your setup if the dialog
sets
filetype commands insensitive somewhere.
I don't think there can be because I tried this with a new config dir (-c option). Same for the filetype None issue above.
I'm using a separate user so I don't conflict with the new stuff, so the whole .config/geany is clean, is that the difference maybe? Don't see how though?
Have you also set the filetype command in your project?? If so and the
All this is without a project open.
Ok
project is open then the item in the standard dialog is set insensitive
so
that you don't edit it and then wonder why it doesn't work (because the project entry continues to override it). Thats one of the reasons I want
to
put it all in the one dialog in v2 so you can see this.
That's a separate issue, but I agree that the current situation can be confusing when a project is open and it needs improving.
Regards, Nick
I'm giving up for the night, if you have any sudden insight during your day let me know, otherwise tomorrow.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 16 Mar 2010 00:06:58 +1100 Lex Trotman elextr@gmail.com wrote:
On 15 March 2010 23:21, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Sun, 14 Mar 2010 10:52:47 +1100 Lex Trotman elextr@gmail.com wrote:
This is because executes are saved in the filetypes file and the
function
filetypes_save_commands() starts at index 1 not 0 so no commands are
saved
for filetype none.
Same happens for the filetype commands as well of course.
The None build commands are disabled in the dialog...
Hmmmm I'm testing with a new build of r4748 and they are not disabled for
a
document with filetype none????
I have r4757 (but the revisions are the same for trunk).
The 'no filetype' commands are all disabled, but the make commands and execute are not disabled.
Options are:
- give filetypes none an extension (currently NULL) and let it save
- make filetype and execute rows of the dialog insensitive if the
filetype
is none
I favour option 1 since filetype none is a valid filetype (you can
set it
from the document menu) so why can't a user define commands for a
filetype
that Geany doesn't understand yet.
Yes, I think 1 is better. Supporting filetype & execute commands for ft None is useful.
There appear to be some wrinkles on extensions for config files that
prevent
this working, so I better ask before I change it and break the world.
Commands are loaded and saved in a file with extension from filetypes_get_extension which does not use the extension field of the filetype structure, but sets extension to lowercase of filetype name
except
in a couple of cases.
On loading filetypes_load_config does not call filetypes_get_extension
for
FILETYPE_NONE, instead hard coding it to "common".
Is there any reason (other than historical) to ignore the extension field when loading and saving, and if so whats the extension field for?
The extension field is a default for saving new files and it is configurable, so we can't use this as the basis for config filenames as it can change.
Ok, that makes sense.
Probably we can fix this to return "none" instead of "common" and adjust all calling code to still work.
Or just store it in filetypes.common, doesn't matter so long as we write to the file we read from :-) Its a separate section so it won't upset any other content.
But for now (if it's easier) I think we can just disable the None filetype's Execute command (and its filetype build commands if there is a situation where they're not disabled [but I can't find one myself]).
Wierd, for me they are always enabled, looking at the code the only time they are set insensitive is if something is overloading them (but you don't have a project), or if doc==NULL or doc->filetype==NULL Maybe we've got another uninitialised variable that is NULL on your machine but not on mine, but I can't find it. GCC gives no warnings with -Wall, but thats not authoritative.
Are the regex fields sensitive or not?
On a wider point, I don't think the GUI should limit setting filetype
commands just because the config file has no entries listed - e.g. XML. The user should still be able to use the dialog to set some commands.
AFAICT It doesn't limit it,specifically I re-tested with XML & it changed
&
saved and restored filetype commands, are you having problems?
Yes, the XML filetype build commands are all disabled.
It sounds like there is something different in your setup if the dialog
sets
filetype commands insensitive somewhere.
I don't think there can be because I tried this with a new config dir (-c option). Same for the filetype None issue above.
I'm using a separate user so I don't conflict with the new stuff, so the whole .config/geany is clean, is that the difference maybe? Don't see how though?
Have you also set the filetype command in your project?? If so and the
All this is without a project open.
Ok
project is open then the item in the standard dialog is set insensitive
so
that you don't edit it and then wonder why it doesn't work (because the project entry continues to override it). Thats one of the reasons I want
to
put it all in the one dialog in v2 so you can see this.
That's a separate issue, but I agree that the current situation can be confusing when a project is open and it needs improving.
Regards, Nick
I'm giving up for the night, if you have any sudden insight during your day let me know, otherwise tomorrow.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Regards, Nick
Sorry for the noise, accidental Ctrl-Enter.
On Tue, 16 Mar 2010 00:06:58 +1100 Lex Trotman elextr@gmail.com wrote:
Probably we can fix this to return "none" instead of "common" and adjust all calling code to still work.
Or just store it in filetypes.common, doesn't matter so long as we write to the file we read from :-) Its a separate section so it won't upset any other content.
I suppose this is OK. (I think there may be good reasons to have separate filetypes.common and filetypes.none so that filetypes.common only has common settings. But really this is yet another separate issue ;-))
But for now (if it's easier) I think we can just disable the None filetype's Execute command (and its filetype build commands if there is a situation where they're not disabled [but I can't find one myself]).
Wierd, for me they are always enabled, looking at the code the only time they are set insensitive is if something is overloading them (but you don't have a project), or if doc==NULL or doc->filetype==NULL
No, with doc open and GDB proves doc->ft is not NULL.
BTW which function(s) are you talking about (I haven't looked yet)?
Maybe we've got another uninitialised variable that is NULL on your machine but not on mine, but I can't find it. GCC gives no warnings with -Wall, but thats not authoritative.
I think you only get uninitialised warnings if you have -O2 on. I might try this later.
Are the regex fields sensitive or not?
Yes, both.
It sounds like there is something different in your setup if the dialog
sets
filetype commands insensitive somewhere.
I don't think there can be because I tried this with a new config dir (-c option). Same for the filetype None issue above.
I'm using a separate user so I don't conflict with the new stuff, so the whole .config/geany is clean, is that the difference maybe? Don't see how though?
With -c some_dir geany shouldn't read .config/geany.
...
I'm giving up for the night, if you have any sudden insight during your day let me know, otherwise tomorrow.
OK, cool ;-)
Regards, Nick
On Mon, 15 Mar 2010 13:26:42 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Are the regex fields sensitive or not?
Yes, both.
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
(This is still with a clean "-c some_dir" config dir.)
Regards, Nick
On 16 March 2010 00:41, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Mon, 15 Mar 2010 13:26:42 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Are the regex fields sensitive or not?
Yes, both.
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
I'll see your screenshot and raise you a working one :-), see attached, I set fieltype to XML and as you can see from the "xml" in filetype command 1, I can set and successfully save and restore settings.
I believe you, but can't replicate it.
(This is still with a clean "-c some_dir" config dir.)
I was actually wondering if an existing filedef was interfering, but as I said this is with a user with default config and no filedefs (until I successfully saved and restored xml settings) so unlikely.
I am going to have to ask you to have a look for it. Sensitivity for ft commands is set at the end of build_add_dialog_row.
-O2-Wall gives nothing
Cheers Lex
Regards, Nick
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
PS, all this is after an svn update and svn status shows no local mods
Cheers Lex
On 16 March 2010 10:59, Lex Trotman elextr@gmail.com wrote:
On 16 March 2010 00:41, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Mon, 15 Mar 2010 13:26:42 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Are the regex fields sensitive or not?
Yes, both.
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
I'll see your screenshot and raise you a working one :-), see attached, I set fieltype to XML and as you can see from the "xml" in filetype command 1, I can set and successfully save and restore settings.
I believe you, but can't replicate it.
(This is still with a clean "-c some_dir" config dir.)
I was actually wondering if an existing filedef was interfering, but as I said this is with a user with default config and no filedefs (until I successfully saved and restored xml settings) so unlikely.
I am going to have to ask you to have a look for it. Sensitivity for ft commands is set at the end of build_add_dialog_row.
-O2-Wall gives nothing
Cheers Lex
Regards, Nick
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 16 March 2010 11:17, Lex Trotman elextr@gmail.com wrote:
PS, all this is after an svn update and svn status shows no local mods
Cheers Lex
On 16 March 2010 10:59, Lex Trotman elextr@gmail.com wrote:
On 16 March 2010 00:41, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Mon, 15 Mar 2010 13:26:42 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
Are the regex fields sensitive or not?
Yes, both.
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
I'll see your screenshot and raise you a working one :-), see attached, I set fieltype to XML and as you can see from the "xml" in filetype command 1, I can set and successfully save and restore settings.
I believe you, but can't replicate it.
(This is still with a clean "-c some_dir" config dir.)
I was actually wondering if an existing filedef was interfering, but as I said this is with a user with default config and no filedefs (until I successfully saved and restored xml settings) so unlikely.
I am going to have to ask you to have a look for it. Sensitivity for ft commands is set at the end of build_add_dialog_row.
-O2-Wall gives nothing
Cheers Lex
Regards, Nick
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Nick,
Can you try this patch please, if it fixes it then it may need to be made elsewhere as well, sigh.
Cheers Lex
On Tue, 16 Mar 2010 11:31:22 +1100 Lex Trotman elextr@gmail.com wrote:
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
I'll see your screenshot and raise you a working one :-), see attached, I set fieltype to XML and as you can see from the "xml" in filetype command 1, I can set and successfully save and restore settings.
I believe you, but can't replicate it.
...
Can you try this patch please, if it fixes it then it may need to be made elsewhere as well, sigh.
Yes, this fixes it - both ft none and XML, thanks :)
Regards, Nick
On 16 March 2010 23:44, Nick Treleaven nick.treleaven@btinternet.comwrote:
On Tue, 16 Mar 2010 11:31:22 +1100 Lex Trotman elextr@gmail.com wrote:
See attached screenshot - I set the AUTHORS filetype to XML but it looks the same with filetype None too.
I'll see your screenshot and raise you a working one :-), see
attached, I
set fieltype to XML and as you can see from the "xml" in filetype
command
1, I can set and successfully save and restore settings.
I believe you, but can't replicate it.
...
Can you try this patch please, if it fixes it then it may need to be made elsewhere as well, sigh.
Yes, this fixes it - both ft none and XML, thanks :)
Ok, I'll commit it. And miraculously this seems to be the only place that I use the return value without testing the return status (that I can find by inspection :-).
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
