1. An Experiment
I found that it is relatively easy to markup a Euphoria program in HTML,
without affecting the way it runs. (If only Rob would add block
comments...)
I have posted a short e file which reads and writes INI files at
this address: http://www.mindspring.com/~mountains/ini.e.htm
Please, if you have time, browse and download the file, EX it, and let
me know what you think. I'm not so much interested in what you think
of my poor code, but in how the markup works.
Especially, try to edit the file with whatever editor you like best.
The upload/download process seems to add extra linefeeds or something.
The idea behind this, in case you're wondering, is to simplify and
improve
the FAQ code postings.
Regards.
Irv
2. Re: An Experiment
Irv wrote:
> I found that it is relatively easy to markup a Euphoria program
> in HTML,
Your listings look good. Now all we need is for someone
to convert euphoria\bin\eprint.ex (or maybe just syncolor.e)
to output HTML codes for syntax coloring.
e.g.
<font face="Arial, Helvetica" color="#FF00A3" size=+2> ... </font>
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: An Experiment
Robert Craig wrote:
>
> Irv wrote:
> > I found that it is relatively easy to markup a Euphoria program
> > in HTML,
>
> Your listings look good. Now all we need is for someone
> to convert euphoria\bin\eprint.ex (or maybe just syncolor.e)
> to output HTML codes for syntax coloring.
> e.g.
> <font face="Arial, Helvetica" color="#FF00A3" size=+2> ... </font>
>
Thanks Rob,
If you tried printing the page from your browser, you'll see the real
advantage to this: it creates *very* nice looking documentation, and it
is
easy to add pictures to illustrate a point. Try documenting a sort
function with a couple of gif's - you'll like it!
Two things: I think a converter would be easy to write, but also, I was
trying to maintain a file format that would display in browsers and run
as
a Euphoria EX file without modification. While hopefully maintaining
readability in a Euphoria editor - ed or ee.
My scheme of putting straight HTML after the end of program (abort())
worked fine for an .EX file, but understandably gives errors if the file
is an
include .E file. So that's out. It's all gotta be in comments. Unless
you
could add a new directive: _ignore_ ( sort of the opposite of include ;)
If I try to color the syntax, I get code like:
--<font color=0000FF>
for --</font>
i = 1 to something --<font color=#0000FF>
do< --/font>
which sort of undermines the readability of the Euphorish, I think.
So my options are:
1. Copy the code, prepend it to the program as comments,
and mark that up - not ideal, as there would be twice as much code and a
lot
of garbage to wade thru getting to the real code.
2. Maintain two copies of each program. NG.
2. Invent an editor with an option to hide HTML. Not so good, unless
everybody
used the same editor.
3. Write markup- and markdown- programs to add and remove the html. I
think
that's my best bet. Anyone who wants can have a copy of the two
programs, and
run markdown.ex before .EX'ing the code.
Perhaps there is a better way?
Regards,
Irv
4. Re: An Experiment
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Aug 17, 1998
-
Last edited Aug 18, 1998
>Perhaps there is a better way?
Maybe the new version of Euphoria can ignore <..> html markups except inside
quotes.
Think about it, it will work.
And having an auto-format program bundled with Euphoria (in euphoria off
course) that removes & adds html format, tabs, spaces, comments, etc. Its
not hard to write, and a lot of customers would really appriciate such a
program to be bundled with euphoria, with documentation, etc.
Off course, the standard editor should (at least) know how to work with the
html color coding. It might even be preferrable to have an option in their
to 'format' the code (running that program).
I'm talking 'standard' with euphoria, because if only 3rd party editors and
programs (like David Cuny's excellent editor) offer such a thingie, it will
cause some problems with newcomers. Making more people aware of David Cuny's
editor can *really* increase the popularity of Euphoria. I do understand
Robert's logical choice for the simple and low-end ED which will also run
nicely on the slower machines and comes with far less complex code. (if you
look at EE.EX you first reaction would be: *thats a lot of code* not
considering the usability of every component of the GUI.
Yet, a GUI is also a crucial tool, that you will need for any program.
Robert should consider adding standard GUI include file, thats easy to use,
and a lot less OOP-ish. (a message box, open window, make window, make
button, and have an event () routine tell you what key was pressed, what
mouse action occured, or what button was pressed. (you first declare an
event) .. a sort of wait_event () routine, avoiding all the 'complex-to-use'
OO-approuches. Off course this last part of my message is a real stream of
thougts, it will do no harm trying to figure a way to add a simple to use
GUI to euphoria, and having a more 'heavier' editor that handles real
formats, with different font sizes, etc. with Euphoria. Or maybe just
something like this on the WIN32 front. Dont tell me you're not planning to
bundle some *real* win32 support with the next version of Euphoria, instead
of assuming every Euphoric user has net acces and time to find the 3rd
parties libraries you need to use for the most trivial things. Face it, the
Win32 part is Alpha stage if not less.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
5. Re: An Experiment
Ralf Nieuwenhuijsen wrote:
>...
> Making more people aware of David Cuny's
> editor can *really* increase the popularity of Euphoria. I do understand
> Robert's logical choice for the simple and low-end ED which will also run
> nicely on the slower machines and comes with far less complex code...
>
I have not said this before, because I didn't want to offend Rob, but
one of the things that Euphoria needs most (in my opinion) is to come
bundled
with Dave's editor. Maybe just the text gui version, to keep it smaller.
First impressions count, and I'm sorry to say that the ed. editor
doesn't make
a big impression compared to the IDE's that have come with other
languages
(Borland's, for example) since the 1980's. I do understand the reason
for the
easy-to-understand-and=modify editor, and would leave it in the package.
> Yet, a GUI is also a crucial tool, that you will need for any program.
> Robert should consider adding standard GUI include file, thats easy to use,
> and a lot less OOP-ish. (a message box, open window, make window, make
> button, and have an event () routine tell you what key was pressed, what
> mouse action occured, or what button was pressed. (you first declare an
> event) .. a sort of wait_event () routine, avoiding all the 'complex-to-use'
> OO-approuches. ....
The question is which GUI? I have tried every GUI package and library
that has
been mentioned on the listerver, except for OpenGL. Actually, I
downloaded
that too, but gave up after looking at the docs. I haven't found any yet
that
I could call easy to use, reasonably flexible, and fast.
Another decision is which platform? DOS or Win? Linux has it's own
GUI's,
which no doubt someone will adapt. Should Rob spend time on building a
simple
DOS gui, or designing a WinAPI wrapper? Tough choice.
>Or maybe just
> something like this on the WIN32 front. Dont tell me you're not planning to
> bundle some *real* win32 support with the next version of Euphoria, instead
> of assuming every Euphoric user has net acces and time to find the 3rd
> parties libraries you need to use for the most trivial things. Face it, the
> Win32 part is Alpha stage if not less.
>
Sadly, yes, despite the efforts of Dave Cuny, Jiri and others.
If it stays that way too long, a lot of potential Euphoria users
will be lost to other languages - that is no good for anyone,
especially Rob.
Hope this spurs further discussion.
Irv
6. Re: An Experiment
Ralf Nieuwenhuijsen (also) wrote:
>
...
> Yet, a GUI is also a crucial tool, that you will need for any program.
> Robert should consider adding standard GUI include file, thats easy to use,
> and a lot less OOP-ish. (a message box, open window, make window, make
> button, and have an event () routine tell you what key was pressed, what
> mouse action occured, or what button was pressed. (you first declare an
> event) .. a sort of wait_event () routine, avoiding all the 'complex-to-use'
> OO-approuches.
Ralf: I don't think a non-OOP approach to a GUI will be any more simple.
Consider this: if the "objects" on a screen do not "know" what to do
when they are clicked on, then the programmer will have to write
a lot of statements to handle the clicks. For example,
let's use a name and address entry screen with some non-oop code:
WINDOW = makeWindow(size and stuff here)
CLOSEBTN = makeButton(WINDOW,"Close")-- assuming automatic positioning
here
NAME = makeEditControl(WINDOW,"")
etc...
onClick[WINDOW] do Focus(Window)
onClick[TITLEBAR] do Drag(Window)
onClick[CLOSEBTN] do Close(Window)
onClick[NAME] do Edit(NAME)
onClick[ADDR] do ...
onClick[CITY] do ...
onClick[STATE] do...
onClick[SaveButton] do...
Next we write some onKey() handler code.....arrgh!
Note that all these *must* be declared, as a minimum. Otherwise, you'll
just
have a nice looking screen that does nothing.
Also consider that in each of these lines the programmer is only telling
the program to do what should come naturally. If you click on a close
button,
what else should it do but close the window? Likewise, an edit field
just
naturally wants to bw edited.
I think a set of pre-defined objects (all the standard ones for a GUI)
should
be added to Euphoria as an include. Everything should be callable with
one
line of code (all possible defaults in place).
(Not like writing to the Win API. No *&#$*@# handles, please!)
And by all means not forcing an OOP approach on the rest of the
programmer's code.
The main difficulty I see - difficult only because I am not very good at
planning things - is an easy method of getting data into and out of
controls.
Even tricker, a method of "linking" two controls so they respond to each
other.
Maybe someone can contribute those things?
Regards,
Irv
