On 15 March 2010 23:21, Nick Treleaven
<nick.treleaven@btinternet.com> wrote:
On Sun, 14 Mar 2010 10:52:47 +1100
> > > 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:
> > >
> > > 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.
> >
> > 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.
I'm giving up for the night, if you have any sudden insight during your day let me know, otherwise tomorrow.
Cheers
Lex