On 23 February 2010 18:18, Noli Sicad
<nsicad@gmail.com> wrote:
Hi Lex,
Thanks you for taking the time in answering my question.
> I'm not sure that my point was clear enough.
I think your point is clear enough.
> Geany has a unified model of a file type. When a file is loaded, its type
> is determined (or it is set by Document->Set Filetype ->...). This type
> controls the text highlighting and the filetype dependent build menu
> commands.
Probably if GLPK is created in the 50's the address the needs of the
time, then there is no problem, it would a fit into the mold classic
c/c++ compiler.
compiler = glpsol --mps mylinearprogramingmodel.mps
run_cmd = glpsol -mps mylinearprogrammingmodle.mps.
BTW, the MPS is created by IBM in the 50. MPS is mathmatical
programming system
On line doc
http://projects.gnome.org/gnumeric/doc/file-format-mps.shtml
Then followed by the LP format
LP format doc
http://www.gurobi.com/html/doc/refman/node386.html
> Scite (and apparently TextAdept) does not have a unified model, the commands
> have to be specified separately by extension as your post showed. I am not
> saying one model is better than another, they are just different. In this
> case Scite can be more flexible, but the Geany model has other advantages
> and AFAIK this is the first time this problem has occurred.
As I mentioned, SciTE is the father of all scintilla base editors.
Since the developer of TextAdept is author of SciTE cloned
(SciTe-tools - scintilla lua dynamic lexer). He knows exactly why
SciTE has 56 languages and scripts and does not fit into "unified
model", the classic c compier, I suppose.
Actually the C compiler is the one that is most likely to require different handling of .h and .c files if your compiler produces pre-compiled headers. So the "traditional" is not the best example but I know what you mean :-)
> I am about to start more changes to the Geany build system that will further
> improve its flexibility. But providing separate commands for different
> extensions within a single filetype is not in the plan because as I said,
> its never been needed before. Without that capability Glpk can still be
> supported in two ways:
> 1. each of the extensions is a separate filetype, but using the same
> highlighting (BTW what lexer do you use with Scite because AFAIK it doesn't
> support GLPK) this is supported now in SVN with custom filetypes
The problem is we will have 5 (mps, lp(cplex), fps(freemps),
mod(mathprog), glp(glpk)) separates filetypes. What name should we use
? Probably, glpk_mps, glpk_lp, glpk_fmps, glpk_mathprog, and glpk_glp,
it might work but messy. Aside from this, glpsol has ability to
translate/convert one format to another. Most of the solvers use mps
format. GLPK is one of the best in the area and this is the reason why
I am promoting GLPK to the Geany users.
I know its messy but it is available NOW. All other options require development and will therefore take time.
In GUSEK IDE, we use, c, sql and asm lexers to create the glmp.properties.
In TextAdept, I adopted c lexer and modified it to create glpk.lua
lexer. TextAdept use the lua dynamic lexer loading.
Oh, Ok you have your own lexer, which you would need to add to Geany anyway.
> 2. a plugin is added which modifies the command for GLPK files depending on
> the extension, this requires the re-make to be available (and the plugin to
> be written) but might be considered to be cleaner
I think this is the best option.
> To use method 1 all you need to do is to copy your current filetypes file so
> you have one per extension, set the compile (or whatever) command in the
> [build-menu] section for each, and edit filetype_extensions.conf to
> reference them.
I think this is the hack (method 1) and probably use just use - glpk1,
glpk2, glpk3, glpk4, glpk5
I hope Geany developers that address this issue.
Right now, windows users can use GUSEK IDE and TextAdept, for Mac OS X
users TextAdept and for linux users TextAdept and classic editors.
As I said option 1 its a way of using Geany until alternative means is supported, or use these alternatives instead.
Cheers
Lex
Lex, thanks again.
Regards, Noli