[ANNOUNCE] IF Builder 1.0
Cryptonomic
Interactive Fiction. The difference here is that I am releasing the full
source code, which is something that many people do not do. You can get the
software at http://ifbuilder.cjb.net.
It is written (currently) in Visual Basic and it uses the CodeSense control
for the syntax coloring. IF Builder does allow you to custom build the
language you want it to color-syntax. In other words, nothing about the
language is hard-coded in so you can specify your own languages or changes
to existing languages. This will probably lead to trade-offs at some point.
You can also set up compilers and interpreters for the story formats you
want to compile and interpret.
It is not a perfect program by any stretch. I still do not have all of the
IntelliSense features in there yet. (The CodeSense control allows for all
the things that traditional IDEs allow.) I would also eventually like to
think about porting this to Java so that it at least has a chance of running
on Unix/Linux machines. There is a lot of room for improvement, not all of
which I am probably capable of making. That is why this is released as open
source. I have plans to add a plug-in set of functionality as well so that
tool-specific features can be added by people if they want. I would also
like to add a "project mapper" kind of thing, sort of like what IF IDE has
or even like what Imaginate has. Problem is: I have no idea how to go about
it. I would also eventually like to add some mapping routines (perhaps
similar to Plugh) but, again, I have no idea of how to go about it. And,
again, the eventual goal would be a conversion to Java.
I have tested it on Windows 2000, Windows 98 SE, Windows NT, and Windows
Millennium. I had no problems installing or uninstalling it and I had no
corruption problems or anything like that. It only minimally touches the
Windows registry (to write some setting information). It does require
current Visual Basic runtimes, Microsoft common controls, and two
third-party controls. (Doing a full installation will handle all of this, of
course. The uninstall will not remove any of your system files.)
I welcome any and all criticisms of the software and I highly encourage
anyone to modify it to make it better. The basic goal here was not really to
provide a better mousetrap. Rather it was to provide an open source solution
for writing an editor that people can take and run with to whatever degree
they want and hopefully modify and make better. I also want to encourage
other people to release their source code for stuff like this, even when the
product is not "perfect." IF Builder is far from perfect, but I am still
releasing it more for the benefit of those who might like to write editors.
David A. Cornelson
news:Zks1a.48638$vm2.26498@rwcrnsc54...
This is probably the best implementation of an IF-centric text editor that I
have scene. If the author does indeed get Intellisense functioning properly,
I would consider that a (insert sports euphamism here to indicate huge win),
and may start using this tool.
Jarb
Cryptonomic
message news:TpSdnd126rb...@speakeasy.net...
> "Cryptonomic" <cryptonom...@hotmail.com> wrote in message
> news:Zks1a.48638$vm2.26498@rwcrnsc54...
>
I
> have scene. If the author does indeed get Intellisense functioning
properly,
> I would consider that a (insert sports euphamism here to indicate huge
win),
> and may start using this tool.
David: Thank you for your comments.
The tool definitely needs a little work. The IntelliSense would not be so
much hard to program as I am not sure what overall way to program it to make
it effective. I mean, I can flag functions that should have IntelliSense but
right now the big thing would be to gather all those functions and determine
what should show up. The best way I could see to do that would be similar to
how I set up the language files: have the application read in some "Function
File" that is specific to each language. That function file is what allows
the user to specify what function choices should appear. The idea being that
once these are built up they can be re-used by anybody. What I need to do, I
guess, is sit with the manuals for each language and look at the various
functions they allow and see what is the best way to format the file and
then a form that allows the user to modify those files. (Those files would
be modified and created similar to how the language files are currently
created via the Language Editor form.)
A few problems that are immediately obvious that I need to fix:
Multiple extensions is a pain. I can set it up so that *.h works along with
*.inf in the language file. You can just specify that in your language file
without a problem and the Open dialog will filter appropritely. (The Save
filter will always default to the first.) The problem is that, in this case,
when opening any file with a .h extension, the application will not know how
to color syntax the file. This is due to how g_sColorString is currently
being parsed out in the mLanguage routine.
The other problem with multiple extensions is compiling to different
extensions. For example, with Inform compiling to .z5 or .z8. The problem is
that when you set the interpreter, you might set up z5 as the file to read.
That is fine but if the person compiles to z8 in the switches, the
application currently would not know to look for that. It would seem that
the solution here is to allow the interpreter form and logic to recognize
multiple extensions.
Also, if you choose Compile and Run but the story file does not actually
compile, the application bombs out. There has to be a check for that. The
problem is how. The only way I can see is to check if the filename +
extension was actually generated. But then that ties into the above problem:
I have to check for each allowable extension.
===========
The trade-off with all of this has been making a tool that tries to be
non-language specific. That necessitates that the compile and interpret
forms (among a few other things) be as general as possible. But that, I am
finding, makes coding a nightmare in some cases when you do want to allow
for some specifics. The good thing (maybe) about the core IF Builder setup
is that you could rip out that core (the syntax coloring engine and the
basic overall functionality) and just slap on a specific compile/interpreter
screen that would be specific for the language of your choice. Hence you
have a ready made HugoBuilder, InformBuilder, TADSBuilder, etc.
Also: if anyone knows code to make good mapping type routines, that might be
helpful. Again, the problems would be with programming such a routine in a
general way. But, at the very least, it might be nice to allow for some sort
of visual-based creation scheme for rooms, even if it only starts out very
general and then builds from there. I simply have no idea how to go about
building that in Visual Basic. (I looked at one open source flowcharting
tool for some ideas but it used a slew of third-party controls that were
extremely resource intensive and not themselves open source or free.)
Richard Northedge
> anyone to modify it to make it better. The basic goal here was not really
to
> provide a better mousetrap. Rather it was to provide an open source
solution
> for writing an editor that people can take and run with to whatever degree
> they want and hopefully modify and make better. I also want to encourage
> other people to release their source code for stuff like this, even when
the
> product is not "perfect." IF Builder is far from perfect, but I am still
> releasing it more for the benefit of those who might like to write
editors.
>
Imaginate, my Windows-based IF code editor, uses very similar architecture
to IF Builder - CodeMax control, docking windows, etc. Imaginate's
architecture is designed to support multiple IF languages, even though it
only supports two (TADS 2 and Alan) at the moment (more on this below). The
main reason Imaginate is not open source is because the whole open source
thing is way off my radar and I haven't had time to assess whether it would
be a good thing or not. In principle I'm not opposed to releasing Imaginate
code (again, it's written in VB6 like IF Builder) and it's certainly not
inconceivable that one could merge IF Builder and Imaginate to create a
"best of both worlds" type solution - presumably by merging Imaginate code
into your GPL'd source. The only reason I hesitate to do this is the fact
that I don't understand how open source works, and how source code control
etc. would be handled. Can anyone enlighten me?
>I would also
> like to add a "project mapper" kind of thing, sort of like what IF IDE has
> or even like what Imaginate has. Problem is: I have no idea how to go
about
> it. I would also eventually like to add some mapping routines (perhaps
> similar to Plugh) but, again, I have no idea of how to go about it. And,
> again, the eventual goal would be a conversion to Java.
You mention further down the thread about the trade-offs caused by making a
non-language specific editor. I originally took the same approach to
languages as IF Builder, by putting language specific details into external
files (it was originally all in the settings.xml file that Imaginate uses).
I eventually realised that it would be impossible to continue this approach
and handle all the issues you talk about re compiler options, project
explorer features etc. So I ended up keeping the language settings but
moving them inside the EXE, and then creating an interface plus
language-specific classes that implement that interface, to handle
language-specific functions like compilation, source code parsing, etc. I
have a development version of Imaginate that runs other languages beyond
TADS2 and Alan, because as you know it's easy to feed settings into the
CodeMax control and away you go with a new language. But it's these
language-specific details that eat up the time and are the reason why the
published release of Imaginate only supports TADS 2 and Alan so far.
An aside about the CodeMax/CodeSense control - others may not know that this
is a syntax highlighting text edit control originally developed as freeware
by WinMain software. The C++ source is available and others have extended
it with Intellisense features (CodeSense, which I haven't got round to
incorporating in Imaginate yet). CodeMax is a great general edit control,
but it doesn't cope that well with some idosyncracies of popular IF
languages. I'm not fluent enough in C++ to modify the source, but if any
C++ programmer is interested in extending CodeMax in IF-language-specific
ways, I would certainly love to hear from them, and I bet IF Builder would
benefit too.
Richard
Cryptonomic
news:%Mb2a.1825$Vx2.148746@wards...
> into your GPL'd source. The only reason I hesitate to do this is the fact
> that I don't understand how open source works, and how source code control
> etc. would be handled. Can anyone enlighten me?
Honestly, I am not sure of all the details. Personally, I really never
cared. I read the GPL license and it was fine for my purposes and "my
purposes" were really not many. I want people to take the code and make it
better and I am not terribly concerned about how much or how little credit I
get for the original. After all, what I have worked on is really not all
that original to begin with. Visual Inform, IF IDE, Informer, Plugh, and
your own Imaginate are testament to a long line of work on this same exact
kind of application. I certainly blazed no new trails. Also, to my mind, it
is not likely that some Interactive Fiction code editor is all the sudden
going to become the rage in terms of a commercial venture. What really
motivated me is that I was tired of seeing so many people work on editors or
claim to work on them and all of them (myself included) were really doing
the exact same things. It makes much more sense (to me) to just provide some
general application that people can modify. I certainly do not claim that
other people *should* do this. If they are against it, that is fine. I just
feel that if they are *not* against it and are just not releasing the source
because they never thought about it, perhaps releasing IF Builder as pure
open source would give the impetus to think about it.
You are right about versioning and source control. For that you can often
set up something on SourceForge or even agree to have a central distribution
Web site for all updates since I find SourceForge somewhat cryptic although
I have not devoted much time to setting up IF Builder on it. It is
definitely good to have some way to control things, of course. If that was
the case, I would rather see a requirements specification drawn up (somewhat
informally perhaps, but done in some fashion) so that the IF community could
participate in creation of some sort of general purpose tool. And then
design could take place relative to that specification. (I come from a
Quality Assurance background so some parts of that stick with me.) Perhaps,
as I said, a general purpose tool would not be best. The core of IF Builder
(and I suspect the core of Imaginate) can be ripped out and immediately be
made into a simple HugoBuilder, InformBuilder, etc. That may be another way
to go. Again, creating the sort of general framework and then allowing
concerted development based on that framework.
> You mention further down the thread about the trade-offs caused by making
a
> non-language specific editor. I originally took the same approach to
> languages as IF Builder, by putting language specific details into
external
> files (it was originally all in the settings.xml file that Imaginate
uses).
> I eventually realised that it would be impossible to continue this
approach
> and handle all the issues you talk about re compiler options, project
> explorer features etc. So I ended up keeping the language settings but
Actually, it is not impossible. I have done it for quite a few elements if
IF Builder but I certainly grant you that it is difficult; sometimes very
difficult. Then again, I expected that going in and I know that I personally
prefer code editors that I can modify as much as possible without having to
worry about it being out of date because of someone's lack of maintenance or
interest. You can also write up a plug-in framework to offset that. (Similar
to what programs like WebEditor and cEdit, also Visual Basic open source
did, or similar to what Jext and Jedit do, again, both of which are open
source, although written in Java.) Even the project explorer features would
not necessarily be all that difficult in the general sense because once you
have a "mapping" of how a given language is structured, you can "parse"
through the source code (based on the language selected) and write that
structure to a treeview. (My problem is I have not worked with treeviews at
all yet and I am just getting started on that.)
> CodeMax control and away you go with a new language. But it's these
> language-specific details that eat up the time and are the reason why the
> published release of Imaginate only supports TADS 2 and Alan so far.
Definitely true on the language-specific details. My compilation and
interpret forms are general in that sense but I still have error-handling
logic to add that would be specific to compilers. I would also like to add
something similar to what IF IDE does when it compiles to the output window:
clickable error lines. That, again, is language-specific because you have to
parse the output. Not impossible, but difficult. I truly do think it is
worth it though for a general purpose tool. I also like to have a general
tool that other tools can utilize. (For example, I am trying to make IF
Builder extensible in the sense that other tools might be able to "hook"
into it. At the simplest level this means something like TADS Workbench can
easily use it as the default editor rather than Notepad. At a more difficult
level it means allowing a sort of Open Framework approach to to the tool.)
> by WinMain software. The C++ source is available and others have extended
> it with Intellisense features (CodeSense, which I haven't got round to
> incorporating in Imaginate yet). CodeMax is a great general edit control,
> but it doesn't cope that well with some idosyncracies of popular IF
> languages. I'm not fluent enough in C++ to modify the source, but if any
> C++ programmer is interested in extending CodeMax in IF-language-specific
> ways, I would certainly love to hear from them, and I bet IF Builder would
> benefit too.
I agree with everything here. I basically "re-wrote" the CodeSense options
and color settings screens by creating new forms in VB and just overriding
everything CodeSense did. (This is because I did not want to refer to things
as "Tag Entities", as just one example, like CodeMax/CodeSense does.) I also
had to handle how the languages are read in slightly differently than how
CodeSense does things. I have looked at abstracting out the main elements of
CodeMax/CodeSense in terms of the syntax coloring so I am not dependent upon
the control. It is possible but a little problematic. Plus if I port to
Java, this has already really been done. There are color syntax "engines"
that are the basis of Jext, Jedit, and a few others where much of that work
has been done.
Morgul
"Cryptonomic" <cryptonom...@hotmail.com> wrote:
>Yes, this is just what it sounds like: yet another code-editor for
>Interactive Fiction. The difference here is that I am releasing the full
>source code, which is something that many people do not do. You can get the
>software at http://ifbuilder.cjb.net.
>
>It is written (currently) in Visual Basic and it uses the CodeSense control
>for the syntax coloring. IF Builder does allow you to custom build the
>language you want it to color-syntax. In other words, nothing about the
>language is hard-coded in so you can specify your own languages or changes
>to existing languages. This will probably lead to trade-offs at some point.
>You can also set up compilers and interpreters for the story formats you
>want to compile and interpret.
This is a very good new! I'll tell you what I would like to do with it: Take
its source code and examine the syntax coloring part. Then, if I like it, I'll
use it for the next version of Visual Sintac (I think it will become 1.2 Rev
0). Of course, if I find any bug in that code or make any improvement to it,
I'll notify and send it to its author.
Thank you.
Regards,
Morgul
-=-=-=-=-*#*-=-=-=-=-
Miembro del Club Español de Aventuras AD (CAAD): http://caad.mine.nu
Página web personal aventurera http://www.geocities.com/jmfo1982
Usuario registrado de Linux nº 196150 en http://counter.li.org
Doherty
> Interactive Fiction. The difference here is that I am releasing the full
> source code, which is something that many people do not do. You can get
the
> software at http://ifbuilder.cjb.net.
This looks really good. I like the 'general' approach for the configuration.
What you should probably consider is adding to that so that you can have
more specific stuff. This is definitely a good effort though. I like the
source code being released even though I've gotta admit I won't be much help
on it but I think I like the idea of building upon a 'core' of some sort.
I'm not sure a 'plug-in' approach like you've mentioned before would be the
way to go. My experience with VB apps (unless you're doing a VBIDE plug-in)
is that it's too much trouble for too little ROI. But I like the look and
feel of IF Builder. I would recommend adding 'hot-tracking' to the windows
you have (main screen, output window).
Other things you might consider: hook into the debugs. For Inform this is
really nothing at all because that's just compiler settings. But with Tads
you could hook into the Tads Debugger which is a separate executable. Hugo
also has a separate debugger you could hook into. You might also hook into
specific features of the languages. Example: with Tads you can use a
separate program to generate executable files of games. You might also
consider something plugh's mapping routines. Or better yet try to add in
something like GUEMap. That'd be cool. Then you can have the person design a
map and then generate code from that map. Good start here. I'd at least like
to see one person make a generally robust IF tool, even if it doesn't have
all the bells and whistles right away.
Morgul
jof...@inf.upv.es (Morgul) wrote:
>In article <Zks1a.48638$vm2.26498@rwcrnsc54>,
> "Cryptonomic" <cryptonom...@hotmail.com> wrote:
>>Yes, this is just what it sounds like: yet another code-editor for
>>Interactive Fiction. The difference here is that I am releasing the full
>>source code, which is something that many people do not do. You can get the
>>software at http://ifbuilder.cjb.net.
>>
>>It is written (currently) in Visual Basic and it uses the CodeSense control
>>for the syntax coloring. IF Builder does allow you to custom build the
>>language you want it to color-syntax. In other words, nothing about the
>>language is hard-coded in so you can specify your own languages or changes
>>to existing languages. This will probably lead to trade-offs at some point.
>>You can also set up compilers and interpreters for the story formats you
>>want to compile and interpret.
>
>This is a very good new! I'll tell you what I would like to do with it: Take
>its source code and examine the syntax coloring part. Then, if I like it,
>I'll use it for the next version of Visual Sintac (I think it will become 1.2
>Rev 0). Of course, if I find any bug in that code or make any improvement to
>it, I'll notify and send it to its author.
Hmmm... where is the CodeSense control?
Cryptonomic
news:b2qf37$qnh$1...@polaris.cc.upv.es...
>
> Hmmm... where is the CodeSense control?
It is an ActiveX control, so it is included as a component within the Visual
Basic project. I then hook into that control with the API that it provides.
This is done in the MDIParent and MDIChild forms. But the modules also hook
into the API. For example, the mLanguage basic file handles much of the
language-reading abilities that the control supports. Note that one of the
first things I do is unregister all of the default languages of the
CodeSense control as well as most of its default settings. I then set them
up in a manner more conducive to the application. Also I do not use the
default "Settings" screen of the CodeSense control.
If you mean "Where can I get the CodeSense control", then check out the
following:
http://www.ticz.com/homes/users/nlewis/Menu.htm
Look under the "Programming" tab and you will see a section for "CodeMax"
and "CodeSense".
Cryptonomic
news:Oof3a.112884$be.79263@rwcrnsc53...
>
> This looks really good. I like the 'general' approach for the
configuration.
Thank you for the comments.
I agree about the plug-ins. I have looked at a couple of "framework"
approaches to this and they really leave quite a bit to be desired. What I
am doing now (for version 1.5, I guess I can call it) is to have a routine
in my "InitializeApp" routine that checks what languages were added in. If
the routine recognizes the name ("Inform", "Glulx", "TADS2", "Hugo", or
whatever) it is going to make a previously invisible menu visible. That menu
will be specific to the tool. If you opt to make settings in the
tool-specific options, those will always override the general options that
you can currently set. I am also making some general fixes that people who
have used the application have asked for. (Most of it is just stuff that I
should have caught the first time through and simply missed.) I am also
adding some FTP routines in there as well since that has been requested by
many people. I would also like to add a better file compare utility. (I
realize this is not even really necessary since so many tools already do
this. I guess I just threw this in there because .... well, hmmm, I am not
sure now that I think about it.)
The debugging thing you mention is interesting. I will look into that.
Interestingly, CodeSense also contains an internal debugger that you can use
for any sort of language but I have a feeling that this would be a very
bare-bones sort of thing and it would probably be better (and easier on my
sanity) just to hook into existing debuggers. Part of the problem is that I
really do not know the languages all that well yet. I am still going through
the manuals of the languages. For example, right now I am trying to make
sure I get all the necessary differences between Glulx and Classic Inform so
that I can determine if the settings for what amounts to the same overall
language should just go on one compiler/interpreter form. I am also
concerned about that with any differences (major or minor) between TADS2 and
TADS3 in terms of selecting compilers, using compilation switches, and
choosing interpreters.
As far as the GUEMap-like functionality, believe me I wish I knew how to do
it. If I did, you can bet that would be one of my immediate priorities for
inclusion. As it is, I have to learn how to even build something like that.
Generating code from that map, however, is even a step beyond that. I guess
you could make it so that it just builds the basic shell of the locations
from the map. That starts to get into a sort of "Visual" based environment,
which I suppose might be sort of nifty.
Two things I would really like to get working are: (1) a tree-view of some
sort to map out source files. This should be capable of recognizing the file
type being used (which I can determine by the file extension saved as or the
language setting someone chose) and then creating a simple tree listing. (2)
An output window that is a little more ... well, just a little more. I would
like to color code errors and warnings. I would also like to do what IF-IDE
does, which is allow for clicking on the line in question and being taken to
that line in the source code. The only thing preventing both options from
being in there right this very moment is my programming skills. (Sigh)
Of course what really keeps hammering at me is two things: (1) I am not
thrilled with writing in Visual Basic; I would rather port to Java or
something; (2) I do not like being even as dependent as I am on the
CodeSense control. While I have abstracted out a lot from it, I am still
more dependent than I would like.
Robin Munn
[snip]
>
> Of course what really keeps hammering at me is two things: (1) I am not
> thrilled with writing in Visual Basic; I would rather port to Java or
> something;
Have you considered Python (http://www.python.org/)? It's cross-platform,
easy to write in, and with the wxPython GUI your can write GUI code that
will run on any platform that wxWindows has been ported to (currently
Windows, Unix (dozens of flavors including all the common ones like Linux
and *BSD), MacOS, MGL, and OS/2). A co-worker introduced me to Python a
couple of years ago and I fell in love with its clean syntax, high-level
power, and easy data manipulation.
Yikes, this is starting to sound like language advocacy! I'll stop here,
except to say that if you do decide to give Python a try, check out the
"Python for Beginners" links off of the main Python site. I recommend two
online books to start with: _Dive Into Python_
(http://diveintopython.org/) and _How to Think Like a Computer Scientist:
Learning with Python_ (http://www.ibiblio.org/obp/thinkCSpy/). The latter
is a bit more beginner-oriented, while the former is more oriented at
people experienced with other languages who want to quickly get a feel
for Python. Besides online sources, the comp.lang.python newsgroup is a
good place to get more information.
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
Cryptonomic
news:slrnb5436f...@localhost.localdomain...
> Have you considered Python (http://www.python.org/)? It's cross-platform,
Actually, I had not previously considered Python. I have certainly heard of
the language but, to be honest, had never really investigated it. Your
message here, however, has certainly got me interested so I am going to be
taking a look at that. It sounds like that might be something even more
readily amenable than Java. Thanks for the tip.
Ferlin Scarborough
to have Python installed on your system in order to run programs written in
Python?
I may be wrong, but the ONE Python program I downloaded told me I HAD to
install Python in order to run it. I'm from the OLD school and like an
executable or script that I can just run, with out first having to install a
bunch of stuff, taken up precious addiontal drive space.
By The Way, Love the IF Builder, I even added another language to it, and
it only took a few minutes to do so, and works like a charm.
Nice Job, keep up the good work.
--
Ferlin Scarborough
----------------------------------------------------------
Please Visit My Web Site
http://shadetree.freeservers.com
Home of S.T.A.G.E
Shadetree Text Adventure Game Engine
"Robin Munn" <rm...@pobox.com> wrote in message
news:slrnb5436f...@localhost.localdomain...
Richard Bos
> I may be wrong, but the ONE Python program I downloaded told me I HAD to
> install Python in order to run it. I'm from the OLD school and like an
> executable or script that I can just run, with out first having to install a
> bunch of stuff, taken up precious addiontal drive space.
I take it you don't like Perl, dynamically-linked C, C++, and similar,
Java, or ZCode either, then?
(No, I don't like Python, either. But not for that reason.)
[ Massive bottom-quote snipped ]
Richard
Robin Munn
> I was under the impression that Python was interpretive, therefore you HAD
> to have Python installed on your system in order to run programs written in
> Python?
>
> I may be wrong, but the ONE Python program I downloaded told me I HAD to
> install Python in order to run it. I'm from the OLD school and like an
> executable or script that I can just run, with out first having to install a
> bunch of stuff, taken up precious addiontal drive space.
Yes, Python is interpreted, but you don't necessarily have to install
Python to run a Python script. py2exe (http://sourceforge.net/projects/py2exe/)
or Gordon McMillan's Installer (http://www.mcmillan-inc.com/install1.html)
can distribute a Python program as a single package that the user can
install. In the case of py2exe, you can create a single .EXE file that
includes a Python interpreter and your script, runnable by anyone
without their having to download anything else. I haven't played around
with McMillan's Installer yet, but I've heard that it's even better than
py2exe because Installer, unlike py2exe, isn't Windows-only.
David Cornelson
I would consider your choice of language from an accessibility or
popularity basis as well. It sounds like your primary goal is
cross-platformness. I think interpreted and virtual machine based
languages are mostly your choice, so then you want (my opinion) want
to narrow it down to which syntax is easiest, then which platform has
the best GUI extensibility.
Python may very well be the best, but I would also consider all of the
other platforms mentioned in this thread.
Jarb
Cryptonomic
news:86f8fbe6.03021...@posting.google.com...
> I would consider your choice of language from an accessibility or
> popularity basis as well. It sounds like your primary goal is
> cross-platformness. I think interpreted and virtual machine based
> languages are mostly your choice, so then you want (my opinion) want
> to narrow it down to which syntax is easiest, then which platform has
> the best GUI extensibility.
I agree the choice is not easy. Obviously Visual Basic proper is not it, at
least long-term, but right now it can probably serve as proof-of-concept
and, if nothing else, port to .NET, which may or may not have some bearing
on how it ports (or does not port) to something like Mono. I have also
gotten many suggestions via e-mail regarding what languages to use or not
use, Java being one brought up the most often. Others have brought up just
using portable C while still others bring up things like Qt (from
TrollTech), Scintilla, Eclipse and, now, Python. Right now the problem is
that I am drowning in potential choices, trying to weigh pros and cons.
Another thing is perhaps having some sort of "core" that is cross-platform
but that can be supplemented with front-ends in various languages. (Hmmm.
Where have I heard that before? ;) I am not sure how much abstraction makes
sense for an "editor component" along with an "IDE component". To that
extent, what is the "best solution" is probably really choosing what is a
"good solution in context". It is deciding what that context actually is
that becomes a little difficult.
In looking at the various ideas for enhancements that people have posted
here and more specifically sent to me via e-mail, the one thing everyone
seems to agree on is as much extensibility and configurability as possible.
Yet still allow many language-specific options here and there. So there is
that balancing act between accomodating the "general usage" and the
"specific usage" and making a framework that can robustely accomodate that
but also be future-mobile.