Hi Nick, Enrico,
I've got a question about how your custom filetype functionality will work when its available, specifically if it will do the following:
For the builders WAF and SCONS the config files are actually pieces of python so they need to:
- detect the custom filetype from the filename (not extension) (SConstruct and SConscript for SCONS and wscript for WAF) - use python lexers and highlighting - load tags for the functions provided by SCONS or WAF so tooltips work - since the config files are not a complete python program they should not have python compile and run commands, but at least SCONS could have a compile that is "scons --dry_run" and I'm sure WAF has a similar option. This will automatically work with the new build system so long as the custom filetype functionality creates a separate GeanyFiletype for the custom type and there is a suitable config file.
Cheers Lex
On Mon, 12 Oct 2009 18:59:24 +1100, Lex wrote:
Hi Nick, Enrico,
I've got a question about how your custom filetype functionality will work when its available, specifically if it will do the following:
For the builders WAF and SCONS the config files are actually pieces of python so they need to:
Why do they *need* to do the things listed below? I don't get the point what's this about.
- detect the custom filetype from the filename (not extension)
(SConstruct and SConscript for SCONS and wscript for WAF)
- use python lexers and highlighting
the first point is already being done by reading shebang lines if available, the second point is done implicitly if the first has succeeded.
- load tags for the functions provided by SCONS or WAF so tooltips work
Which? Why?
- since the config files are not a complete python program they should
not have python compile and run commands, but at least SCONS could have a compile that is "scons --dry_run" and I'm sure WAF has a similar option. This will automatically work with the new build system so long as the custom filetype functionality creates a separate GeanyFiletype for the custom type and there is a suitable config file.
Are you talking about something like a pendant to the Make commands in the build system?
Regards, Enrico
2009/10/13 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 12 Oct 2009 18:59:24 +1100, Lex wrote:
Hi Nick, Enrico,
I've got a question about how your custom filetype functionality will work when its available, specifically if it will do the following:
For the builders WAF and SCONS the config files are actually pieces of python so they need to:
Why do they *need* to do the things listed below? I don't get the point what's this about.
I use scons, I only had a quick look at waf and you are an expert (well you can build Geany with it, thats an expert) so where I said anything wrong about waf please ignore it.
- detect the custom filetype from the filename (not extension)
(SConstruct and SConscript for SCONS and wscript for WAF)
- use python lexers and highlighting
the first point is already being done by reading shebang lines if available, the second point is done implicitly if the first has succeeded.
Ok, wscript is a python program, but scons files are *not* complete programs, no shebang only the filename for identification
- load tags for the functions provided by SCONS or WAF so tooltips work
Again maybe I was wrong about waf, but scons makes a lot of functions available for use in the script, having tooltips would be useful. Creating the tags files isn't Geanys problem, just loading them for the script.
- since the config files are not a complete python program they should
not have python compile and run commands, but at least SCONS could have a compile that is "scons --dry_run" and I'm sure WAF has a similar option. This will automatically work with the new build system so long as the custom filetype functionality creates a separate GeanyFiletype for the custom type and there is a suitable config file.
Are you talking about something like a pendant to the Make commands in the build system?
What I'm talking about is when I am working away on my program, have lots of the C++ files open and the build script which I am editing trying out something too complicated again (thats the temptation when its just Python :-).
So I want to see if the script is acceptable to the builder and that it does the right thing, but without actually doing anything in case it has a problem. Hence my suggestion that I want to do a dry-run which prints rather than executes the commands it would run. That means I don't want to use the 'make' commands since they have been configured to run the commands to build the program.
I was suggesting that if the custom filetypes functioned like a real filetype then I could have a filetype compile command which did the dry-run when the current document is the script
It seems to me that detecting the build script, using a lexer, loading specific tags files and having specific compile commands looks really like a new filetype.
I guess really I have no idea what you intend custom filetypes to do but I was hoping that it would be easy to add a filetype without having to edit Geany, thats why I'm asking :-)
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 13 Oct 2009 08:40:52 +1100 Lex Trotman elextr@gmail.com wrote:
I was suggesting that if the custom filetypes functioned like a real filetype then I could have a filetype compile command which did the dry-run when the current document is the script
It seems to me that detecting the build script, using a lexer, loading specific tags files and having specific compile commands looks really like a new filetype.
I guess really I have no idea what you intend custom filetypes to do but I was hoping that it would be easy to add a filetype without having to edit Geany, thats why I'm asking :-)
I would like this to be possible, but not sure if I'll work on it much.
Regards, Nick
On Tue, 13 Oct 2009 08:40:52 +1100, Lex wrote:
2009/10/13 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 12 Oct 2009 18:59:24 +1100, Lex wrote:
Hi Nick, Enrico,
I've got a question about how your custom filetype functionality will work when its available, specifically if it will do the following:
For the builders WAF and SCONS the config files are actually pieces of python so they need to:
Why do they *need* to do the things listed below? I don't get the point what's this about.
I use scons, I only had a quick look at waf and you are an expert (well you can build Geany with it, thats an expert) so where I said
I'm by no means a Waf expert. Building Geany with Waf is very easy, much easier than fighting with autotools. ./waf configure ./waf ./waf install
Anyway, that's not really what you have asked :).
- detect the custom filetype from the filename (not extension)
(SConstruct and SConscript for SCONS and wscript for WAF)
- use python lexers and highlighting
the first point is already being done by reading shebang lines if available, the second point is done implicitly if the first has succeeded.
Ok, wscript is a python program, but scons files are *not* complete programs, no shebang only the filename for identification
Actually, wscript's are no programs and also actually don't need a shebang. Not sure why Geany's has one, probably because I copied&pasted it from somewhere else :). Anyway, for filetype detection can also be done easily use ~/.config/geany/filetype_extensions.conf, e.g. in my personal config, part of the setting for Python files is ";wscript;SCons*;".
- load tags for the functions provided by SCONS or WAF so tooltips
work
Again maybe I was wrong about waf, but scons makes a lot of functions available for use in the script, having tooltips would be useful. Creating the tags files isn't Geanys problem, just loading them for the script.
IMO this is and should stay filetype dependant.
- since the config files are not a complete python program they
should not have python compile and run commands, but at least SCONS could have a compile that is "scons --dry_run" and I'm sure WAF has a similar option. This will automatically work with the new build system so long as the custom filetype functionality creates a separate GeanyFiletype for the custom type and there is a suitable config file.
Are you talking about something like a pendant to the Make commands in the build system?
What I'm talking about is when I am working away on my program, have lots of the C++ files open and the build script which I am editing trying out something too complicated again (thats the temptation when its just Python :-).
So I want to see if the script is acceptable to the builder and that it does the right thing, but without actually doing anything in case it has a problem. Hence my suggestion that I want to do a dry-run which prints rather than executes the commands it would run. That means I don't want to use the 'make' commands since they have been configured to run the commands to build the program.
I was suggesting that if the custom filetypes functioned like a real filetype then I could have a filetype compile command which did the dry-run when the current document is the script
It seems to me that detecting the build script, using a lexer, loading specific tags files and having specific compile commands looks really like a new filetype.
IMHO this is far beyond Geany's scope especially because this seems to be a very special use case to me. Generally, I'd say either we make the filetype system more flexible what Nick has already begun (wow!) or maybe your use case could be made into a plugin, not sure.
Unfortunately, I don't have as much time as I would like to have to read, discuss and even actually code as much as I wish...but you know the game, real life...
Regards, Enrico
2009/10/16 Enrico Tröger enrico.troeger@uvena.de:
On Tue, 13 Oct 2009 08:40:52 +1100, Lex wrote:
2009/10/13 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 12 Oct 2009 18:59:24 +1100, Lex wrote:
Hi Nick, Enrico,
I've got a question about how your custom filetype functionality will work when its available, specifically if it will do the following:
For the builders WAF and SCONS the config files are actually pieces of python so they need to:
Why do they *need* to do the things listed below? I don't get the point what's this about.
I use scons, I only had a quick look at waf and you are an expert (well you can build Geany with it, thats an expert) so where I said
I'm by no means a Waf expert. Building Geany with Waf is very easy, much easier than fighting with autotools.
AKA autofools but don't tell them ;-)
./waf configure ./waf ./waf install
Anyway, that's not really what you have asked :).
I didn't mean you know how to run it, I meant you can write a wscript to build Geany, even *I* can run it :-D
- detect the custom filetype from the filename (not extension)
(SConstruct and SConscript for SCONS and wscript for WAF)
- use python lexers and highlighting
the first point is already being done by reading shebang lines if available, the second point is done implicitly if the first has succeeded.
Ok, wscript is a python program, but scons files are *not* complete programs, no shebang only the filename for identification
Actually, wscript's are no programs and also actually don't need a shebang. Not sure why Geany's has one, probably because I copied&pasted it from somewhere else :). Anyway, for filetype detection can also be done easily use ~/.config/geany/filetype_extensions.conf, e.g. in my personal config, part of the setting for Python files is ";wscript;SCons*;".
Ach, I forgot about patterns in the extension file, sure, but of course it makes them python, see below for why that has problems.
- load tags for the functions provided by SCONS or WAF so tooltips
work
Again maybe I was wrong about waf, but scons makes a lot of functions available for use in the script, having tooltips would be useful. Creating the tags files isn't Geanys problem, just loading them for the script.
IMO this is and should stay filetype dependant.
Indeed it should be, but as we have made wscript/scons files python we would have to load these extra tags files for every python source file.
- since the config files are not a complete python program they
should not have python compile and run commands, but at least SCONS could have a compile that is "scons --dry_run" and I'm sure WAF has a similar option. This will automatically work with the new build system so long as the custom filetype functionality creates a separate GeanyFiletype for the custom type and there is a suitable config file.
Are you talking about something like a pendant to the Make commands in the build system?
What I'm talking about is when I am working away on my program, have lots of the C++ files open and the build script which I am editing trying out something too complicated again (thats the temptation when its just Python :-).
So I want to see if the script is acceptable to the builder and that it does the right thing, but without actually doing anything in case it has a problem. Hence my suggestion that I want to do a dry-run which prints rather than executes the commands it would run. That means I don't want to use the 'make' commands since they have been configured to run the commands to build the program.
I was suggesting that if the custom filetypes functioned like a real filetype then I could have a filetype compile command which did the dry-run when the current document is the script
Similar to the above, by making the wscript/scons python the commands are general for all python, not way/scons specific
It seems to me that detecting the build script, using a lexer, loading specific tags files and having specific compile commands looks really like a new filetype.
IMHO this is far beyond Geany's scope especially because this seems to be a very special use case to me.
It isn't a general case, but it is relevant for all the systems that use an existing language as their extension language. These almost always provide a large library of functions available to the extension programmer. Python, Ruby and Lua are all partly targeted at that use and there are many web systems etc that use them for extension or application programming and which provide more than the standard language functions and are executed by different commands to standard python/ruby/lua. Yes it isn't everyday, but I wouldn't call it unusual, and its probably going to grow.
Generally, I'd say either we make the filetype system more flexible what Nick has already begun (wow!)
@Nick, you replied previously that you didn't expect to implement a fully extendible filetype system (except as a dream :-) but how far are you planning to go? For example using an existing lexer/tag parser so no programming is needed, could it make enough of a separate filetype to do the things I've listed above?
or maybe your use case could be made
into a plugin, not sure.
Unfortunately, I don't have as much time as I would like to have to read, discuss and even actually code as much as I wish...but you know the game, real life...
Thats ok, this is long term stuff, fast responses not required.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 17 Oct 2009 16:30:12 +1100 Lex Trotman elextr@gmail.com wrote:
Generally, I'd say either we make the filetype system more flexible what Nick has already begun (wow!)
@Nick, you replied previously that you didn't expect to implement a fully extendible filetype system (except as a dream :-) but how far are you planning to go? For example using an existing lexer/tag parser so no programming is needed, could it make enough of a separate filetype to do the things I've listed above?
I think using an existing lexer (even with separate custom-FT styles) and using an existing tag parser seems fairly straightforward to implement, I might look at it soon.
Perhaps other things can be implemented gradually, but only if it makes sense for the codebase - I don't think that we should add a lot of code to support anything. But adding a little/replacing existing code to be more flexible seems OK IMO.
Regards, Nick
On Sat, 17 Oct 2009 12:37:08 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
@Nick, you replied previously that you didn't expect to implement a fully extendible filetype system (except as a dream :-) but how far are you planning to go? For example using an existing lexer/tag parser so no programming is needed, could it make enough of a separate filetype to do the things I've listed above?
I think using an existing lexer (even with separate custom-FT styles) and using an existing tag parser seems fairly straightforward to implement, I might look at it soon.
Implemented (without separate custom-FT lexer styles). I added "lexer_filetype" and "tag_parser" [settings] keys, explained (briefly) in the 'Filetype definition files' section of the manual.
Regards, Nick
On Mon, 19 Oct 2009 16:08:03 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
@Nick, you replied previously that you didn't expect to implement a fully extendible filetype system (except as a dream :-) but how far are you planning to go? For example using an existing lexer/tag parser so no programming is needed, could it make enough of a separate filetype to do the things I've listed above?
I think using an existing lexer (even with separate custom-FT styles) and using an existing tag parser seems fairly straightforward to implement, I might look at it soon.
Implemented (without separate custom-FT lexer styles). I added "lexer_filetype" and "tag_parser" [settings] keys, explained (briefly) in the 'Filetype definition files' section of the manual.
(Hmm, the web devel version of the manual doesn't seem to have the latest changes...)
Just implemented loading global tags files for custom filetypes, but they will share the tagmanager tag type. E.g. if a custom filetype Foo has tag_parser=Perl:
* Using Foo filetype will load any *.[foo_extensions].tags files. * Then using Perl filetype will load any *.[perl_extensions].tags files, and tags from both of these will now be used for both Foo and Perl filetypes. * If only using one of the filetypes in a Geany instance, the other filetype's tags files are not loaded.
Regards, Nick
Wow, looks pretty much all that is needed :-) I'll try it out after I stop hurting my head on build system dialogs.
Cheers Lex
2009/10/20 Nick Treleaven nick.treleaven@btinternet.com:
On Mon, 19 Oct 2009 16:08:03 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
@Nick, you replied previously that you didn't expect to implement a fully extendible filetype system (except as a dream :-) but how far are you planning to go? For example using an existing lexer/tag parser so no programming is needed, could it make enough of a separate filetype to do the things I've listed above?
I think using an existing lexer (even with separate custom-FT styles) and using an existing tag parser seems fairly straightforward to implement, I might look at it soon.
Implemented (without separate custom-FT lexer styles). I added "lexer_filetype" and "tag_parser" [settings] keys, explained (briefly) in the 'Filetype definition files' section of the manual.
(Hmm, the web devel version of the manual doesn't seem to have the latest changes...)
Just implemented loading global tags files for custom filetypes, but they will share the tagmanager tag type. E.g. if a custom filetype Foo has tag_parser=Perl:
- Using Foo filetype will load any *.[foo_extensions].tags files.
- Then using Perl filetype will load any *.[perl_extensions].tags files,
and tags from both of these will now be used for both Foo and Perl filetypes.
- If only using one of the filetypes in a Geany instance, the other
filetype's tags files are not loaded.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel