> 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.
But I think that would be post 1.2 matter anyway...
> 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...
> 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.
Andre'
--
André Pönitz ............................................. [EMAIL PROTECTED]
