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