* Andre Poenitz <[EMAIL PROTECTED]> [010502 10:28]:
> > Ok, before we serious start this kind of discussion on "Which scripting
> > language?" why don't we agree that the best thing is for scripting
> > language to be optional and let the user choose?
>
> Good point. If you leave out Python off the core, I won't argue.
>
> On the other hands there are a few tasks _within_ LyX that easily can be
> solved with scripting (like parsing certain configuration files or adding
> improved functionality for configuration files like if/then/else), so
> having _one_ language closer to the core might be sensible.
I went to read the past discussion and changed my mind. It
can and possibly is important to choose a language, in order to be able
to provide scripts to do various tasks outside the LyX core. I do not
have a concrete idea, I thought about uppercase character, but this
depends on locale and is probably best done in LyX with its future
unicode support (though Python has unicode strings ;-)
Currently every little function to be done is added to the LyX core (as
in the C++ code), having a blessed scripting language will allow us to
add functions without cluttering the core with things that are not
strictly necessary. This can avoid the MS Office bloat where every small
demand of some large customer is inflicted on the whole world.
> But I think that would be post 1.2 matter anyway...
Yes, but it doesn't mean we can't continue to fill the mailboxes of
everyone and the mailing list archive :-)
> > The basics of embedding a language is to have a way to call scripts of
> > this language: ExecutePythonScript(string const & filename)
> > And then we need to expose the lyx actions and queries to the scripting
> > language, this entails an extension to LyXFunc that can also query. We
> > need actions like "word-forward" (which we have now) and queries like
> > "character-get" (which we dont have).
>
> Right to the mark. We need some "low level lyxfunctions" in some
> consistent, simple-to-understand, well-documented style. Maybe that's the
> point where the effort should be spend...
For the Python embedding the "only" thing left now is to have these
actions available for the script. I have implemented the embedding, the
automatic configuration (stolen from glimmer) and added a manual
override for those who don't want the embedding even if they have python
installed.
The rest is empowering the scripts to do something usefull.
(Actually, I still need to implement the running of a script file,
currently you can run a script in a string... the difference is small
and the task is trivial).
> > It will be hard to quantify the "betterness" (for lack of the correct
> > word) of a language to implement some script.
>
> Not really. Take proponents of each choice and have a "shoot out", i.e.
> pose a (small) set of problems and have them solved by the proponents.
> Look at the result. If one needs 100 lines and the second only five, and
> the code of the second looks readable even to people who don't know that
> language, the second is "better".
>
> It works rather well if you really have people familiar with the languages.
Hmmm, ok. But one thing that raised in the former discussion is the fact
that we need to target the language at novices and those who are not
programmers, the example given there is Amirs Mom, I'm pretty sure she
groks Perl scripts, but most peoples probably don't know how to program
and so the language need to be a clear one and easy to learn for
non-programmers.
--
Baruch Even
http://baruch.ev-en.org/
