eranif wrote:I am new to GitHub, but I suspect that we could try their "pull request" mechanism as a method for patching codelite (when the plugin is mature enough)

As i'm curious, I would like to try it also

eranif wrote:Does the plugin need the Lua libraries, if so, how are they obtained? (build them locally, download them etc)

Lua is very light, and I currently embed the source in the plugin. But I think that I will externlize it in the 3rd party lib, as a static lib (like sqlite). It will be easier to update the lua library if needed / wanted.

eranif wrote:Do you have access to a Linux / OSX machines where this plugin can be tested?, or are you going to focus only on Windows?

That's the point... I only have a win machine. I can try to use a linux virtual machine, but not very confident about this, sorry

eranif wrote:Does the plugin need the Lua libraries, if so, how are they obtained? (build them locally, download them etc)

Lua is very light, and I currently embed the source in the plugin. But I think that I will externlize it in the 3rd party lib, as a static lib (like sqlite). It will be easier to update the lua library if needed / wanted.

Whatever embeds Lua usually exports its symbol table so that 3rd party Lua libraries can bind to it without duplicating code.

People usually don't believe how light Lua is before seeing it: http://www.lua.org/download.html (don't blink while the LuaVM compiles because you might miss it ). The author's (Roberto Ierusalimschy) Lua reference manual is 100 pages, I often confuse it with K&R's ANSI C ref manual when I pull it out of my bookshelf

jfouche wrote:

eranif wrote:Do you have access to a Linux / OSX machines where this plugin can be tested?, or are you going to focus only on Windows?

That's the point... I only have a win machine. I can try to use a linux virtual machine, but not very confident about this, sorry

Don't worry I'll help. Actually I wrote my custom Debian installer in Lua (yes I'm a Lua freak), attached here. The Mac I have has been lent to me but I may get another one for future testing.

If your PC is powerful enough I can create a Qemu virtual machine container for you with Debian & Xfce, then convert it to a VDI that you can load into VirtualBox. You'd then just have to install Oracle's driver extensions.

cheers,

-- p

You do not have the required permissions to view the files attached to this post.

I read up on a bunch of different git features but none seemed to return a subpath like SVN would, i.e. not without downloading the entire remote repo so I just have a full copy of your repo next to Eran's, which is fine really.

I think if found 2 bugs my compiling with clang: lua_stack_dump() needs parentheses around

I spent a while trying to configure a CL build... then in the end saw Eran recommends a CMake . In general I use a bunch of env vars (system-wide, CL-wide, then project-wide in common settings -> environment) so I can redirect to my custom wx location, CL source and CL bin, also I guess I should move the hardcoded win path in OnRun() to an env var for testing?

I have to return to my day job project now, I guess it'll take a few ping-pongs to get win & linux targets building in harmony.

I finally succeded at managing "hook scripts". So, here is the current design :
- There are 2 kind of scripts : on-demand scripts and hook scripts
- The on-demand script are called by the user, on demand. Those scripts are stored in "codelite user data"/scripts directory.
- The hook scripts reacts to codelite events. Those scripts are stored in "codelite user data"/hooks directory.

local function do_something(event)
-- do what need
-- The codelite variable is available
end
codelite.Bind(wxEVT_FILE_SAVED, do_something)

Now, I need to implement the user interface to manage those scripts:
1 - A settings UI, which allow the user ta add/remove/edit hooks and on-demand scripts
2 - A mini frame that only shows the user the "on-demand" scripts. A double click on a script name should launch it.

If anybody have feedback on the design, and feature requests, tell me
Petah, I'm pretty sure you have lots of ideas and suggestions

half-way reading through your post I was getting ready to propose a single Lua table to define hooks, but actually I think your solution to explicitly bind hooks from Lua is even more elegant so... proceeding with humility:

- if editor:GetSelection() is empty I recommend returning nil (with lua_pushnil()) and if it can potentially return an error, push the error string as a 2nd argument. That would follow Lua convention.

- about [1], given that hooks are bound from Lua, the point is just to pass the UI state to Lua, which will then hook the appropriate function right? I'm thinking a generic 2D property table UI defined from a [name][type][widget][val] tuple/list, which on edit populates a codelite.config Lua table, then calls "OnConfigUpdated()" Lua hook would do the trick no?

The Lua script could then parse the table and rebind hooks, plus the UI property table could be used to customize anything really. F.ex remapping on-demand scripts (like a look-up table), set debug flags or other variables. You could even have the UI query Lua for the definition table before it's displayed by your plugin so the UI can be constructed conditionally.

On first invocation the UI shows only the debug checkbox, unchecked, upon checking the debug option it'll show the debug level spinCtrl too. Not the most useful example but you get the idea; it's a generic property editor that can solve different problems. The "integer" type is just to help the UI builder; obviously it's just a number to Lua.

- about [2] I would suggest a similar model: Lua returns a table of { "action_name", "action_function_name" } string pairs the UI shows in a listbox. Returning function names as strings vs the Lua functions themselves so prefs can be saved to disk.

- I'm not sure about [1]'s edit function, I'm guessing you can hardcode opening a CL window with the script.

- you'd ship standard/template Lua scripts to do all this, which most users would probably use as-is and never edit

- with all this low-level ping-pong you'd need solid Lua error checking, probably wrap arguments in a "return {...}" chunk you call luaL_dostring() on before it's passed between C++ and Lua contexts so on error it's caught & displayed immediately.