LuaEclipse 2.0 -- feature design

["Luís Eduardo Jason Santos" <jasonsantos@...>]

Hi, people

For those interested in discussing the design of some
features in the next release of LuaEclipse, I am posting here a message
originally posted in the LuaEclipse mailing list that I believe might
interest some of you.

Any feedback will be appreciated. If you would like to further
discuss this topic or any other concerning the LuaEclipse IDE, I
suggest entering the LuaEclipse List on LuaForge.

---------- original message ----------

Hi, people

We are heavily involved into the preliminary steps to develop LuaEclipse 2.0

Our main goals are: to add Remdebug support and to move into a DLTK-based architecture.

We are currently attacking two fronts:
* trying to use LEG as the code parser for code highlight and AST building
* improving RemDebug to support all the features needed by Eclipse Debug API

There are some decisions I would like to discuss with you all before running to implement.

Right now, we have been considering four kinds of scripts would have to be supported by LuaEclipse:
(a) - Scripts that can be run by any Lua interpreter;
(b) - Scripts that must be run by the system default Lua interpreter (or an interpreter closely integrated on the system, i.e. by sharing the same runtime with shared libraries on PATH);
(d) - Scripts that must be run by a custom launcher that accepts the script as a parameter;
(e) - Scripts that must be run by a custom launcher that decides which script to run by its own logic;

As you can see, although we are flexible enought today to cover all these situations, some of them are a little difficult to cope with when we come to debugging.

There are a number of means we could put Remdebug to work with all those scenarios, but some of those solutions smell really bad:
[1] We can use a built-in interpreter for (a) that already has the Debug engine started in its LuaState.
[2] We can generate a pre-launch script that starts the engine and then 'loadfiles' the given script -- works for (a) and most times for (b) -- unless (b) assumes a given starting path (if it does, It would have problems with today's implementation of the launcher)
[3] We can generate in runtime a temporary script that is the current launch script with the commands to start the debug engine right before it starts. Works for (a) and for (b) -- and perhaps for (c) -- but would have to inject remdebug dependecies -- what could become a problem to debug scripts out-of-the box in some scenarios of (b) and (c) -- or even (a). That would be easy for remdebug itself, but could be really troublesome in the case of luasocket, due to runtime or library compatibility issues.
[4] We can replace the current script by its 'debug engine start prepended' copy temporarily prior to launch.. that would fool even the launcher in (d) but can be really messy and risky. Besides it should face the same library requirement problems we face in [3].

As I see, there is no single solution that covers everything. So, maybe we could implement solutions [1] and [3] to cover most cases.. but then we still can't cover case (d). I am uncertain about adopting any form of solution [4] -- and would rather delegate for end users to start the debug engine manually on their scripts for case (d) -- or to forsake support for debugging completely in the (d) scenario.

I would like to hear some opinions and personal experiences that could point to new options, increase or decrease our constraints, etc.

Does anyone have thoughts in that matter?
--
Luís Eduardo Jason Santos