[Geany-devel] Build, Compile, Execute [Built Setting] for various filenanetypes extension
elextr at xxxxx
Tue Feb 23 08:55:47 UTC 2010
On 23 February 2010 18:18, Noli Sicad <nsicad at 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
> > 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
> Then followed by the LP format
> LP format doc
> > Scite (and apparently TextAdept) does not have a unified model, the
> > have to be specified separately by extension as your post showed. I am
> > saying one model is better than another, they are just different. In
> > 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
> > 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
> > 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
> > the extension, this requires the re-make to be available (and the plugin
> > 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
> > 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.
> Lex, thanks again.
> Regards, Noli
> Geany-devel mailing list
> Geany-devel at uvena.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel