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