script plugin

[jfouche]

Hello,

I'm currently working on script plugin.
The main goal of this plugin is to allow users to extends CodeLite with simple functionnalities without having to create a c++ plugin. It's based on the lua langage.
Currently, this plugin doesn't react to CodeLite events, but in the futur, if needed, I can add this functionnality

Here is a very small sample of a script, which append a comment at the end of the current file :

Code: Select all

editor = cl_manager:GetActiveEditor()
if editor then
   content = editor:GetEditorText()
   content = content .. "\n//end file"
   editor:SetEditorText(content)
end

Let me know if somebody may be interrested by this plugin.

[petah]

I would be very interested in this plugin, assuming it has rich hooks into CL. F.ex. when opening new files I'd like to insert the tabs in a predetermined order so headers appear before cpp files, etc.

cheers,

-- p

[jfouche]

Hello Petah,

Here is my current roadmap :

1 - Implement lua bindings for codelite interfaces. This works is the proof of concept, and it's done for some interfaces (some IManager and IEditor methods).
2 - Find a pretty user interface. I'm currently thinking of a toolbar with a single button, which show/hide a floatable pane that shows all available scripts. Double clicking on a script run it. This pane also should contains a way to add a script, and to edit an existing one.
3 - Add a way to allow a script to bind a function to a CL event. This task requires to have 2 kind of scripts : runnable by the user, or registered ones (which are always loaded, and react to CL events).It probably need a UI update to differenciate those 2 kind of scripts, as you can't run a register plugin. An interrestin'g think should be to automatically recognize if script is a runnable one, or a hook one. Don't know how to do this today...

If you have ideas on items 2 and 3, I would be very happy to share comments

[petah]

Salut Jeremie,

in my opinion the UI is completely unnecessary - Eran already takes care of that. I've embedded Lua in almost every app I wrote but when I tried adding a UI for the bindings it always turned to crap. The main point is to be able to script CL so I would focus on glue code and making sure you keep up with Eran's API.

I think you could probably have an API that's 100% even based, i.e. reacts to CL's events, even the init script could be something like OnCLInstanceLoaded(), then OnCLWorkspaceLoaded(), etc., i.e. keep it simple and focus on the meat

For example VideoLan supports various script engines with zero UI, just place an init script in a given folder and that's it. It's not the best example because their documentation absolutely sucks and trawling through their humongous source code too, but other than that it does its job.

a+

-- p

[petah]

some more thoughts (qui vallent ce qu'ils vallent et t'en feras ce que tu voudras:):

- If your plugin exports the Lua VM symbols then it'd be possible to dynamically import other Lua libraries like luasocket, luasqlite (maybe to read from the ctags dbase), Bam (lua's make-style build system), luaposix, luaGL (for overlays), luagraphviz (for callgraphs), whatever

- in general if you keep your bindings modular it'd be easier for you and others to add functionality. I.e the CL plugin would be just the core Lua VM, and your CL bindings are separate Lua modules loaded with require(). If someone absolutely wants a UI they could write it with wxLua, say (though IMHO it's a monster)

- maybe you can use one global CLevents Lua table to hook into, that'd save you having to add individual event functions and keep the API smaller

- if you don't know it, check out Lua FFI http://luajit.org/ext_ffi.html, it's from the LuaJIT team. I never used it but the idea to bind Lua directly to binaries seems promising, it may save you some time.

- it'd be great if you could bundle the makefiles for the plugin & libraries, that way it's easy for others (like me) to contribute, say if I wanted to quickly add a binding to a new CL event.

Eran - can we pls already have a LuaCL plugin forum so we can move our conversation there and stop making noise here?

thx & cheers,

-- p

ps: sorry if I come off over-excited, I told you I'd be very interested

[petah]

btw I wrote this simple lua debugger a while back, I should be able to contribute it to your plugin if there's interest. It's 100% C++ & wxWidgets, nothing else, so it's very light compared to other debuggers out there with wxLua and luasocket bindings:

ddt1.png

a+

-- p

[jfouche]

Hi Petah

Thanks a lot for your interret and feedback (et t’inquiètes, ça vaux, et je prends )

Here is my 1st needs : I wanted simple way to replace the current selection with some text (transform ascii to hexa representation, for example) and I don't think there is a way to do this without a UI to select wich operation I want to apply to the selected text.

but... your idea, even if it's harder to implement, may be the good way to do.

So : My first step will be to implement what I want, and upload a repository on github. This way, you can help me to make this plugin evolve to match both needs.
I'll do it this week end, as I'm very busy this week

edit I think you need a UI to manage scripts (add / remove a script, event if it's a hook plugin)... no ?

[petah]

I wanted simple way to replace the current selection with some text (transform ascii to hexa representation, for example) and I don't think there is a way to do this without a UI to select wich operation I want to apply to the selected text.

I see. I was thinking mostly automation but you're absolutely right in that case some UI is needed to be practical and triggering a Lua function for text manipulation would be awesome given Lua's regex.

Maybe you can have a Lua function to dynamically add submenus to the plugin UI. It's a bit cumbersome for repeat operations but a good start. Maybe you can query CL for unused kbd shortcuts, then add those to your command.

So : My first step will be to implement what I want, and upload a repository on github. This way, you can help me to make this plugin evolve to match both needs. I'll do it this week end, as I'm very busy this week

No hurry, I'm neck-deep in a project myself.

edit I think you need a UI to manage scripts (add / remove a script, event if it's a hook plugin)... no ?

Yes it would be more user-friendly, but a simple checklist would probably be enough. What I meant is that from personal experience, UI and scripts are orthogonal concepts and trying to embed them too deeply will limit the scripts' power and frustrate UI-only users.

I think your plan to implement the features you want is sound, you'll find when/if you require UI as needed.

salut,

-- p

[jfouche]

Hi,

I'm ready to upload the 1st version of the plugin. I was very happy to see that the editor recognize the lua extension, and shows a pretty synthax highlight

Eran, I just wondering what is the may you prefere for source code managment :
- I fork the codelite repo, and add the plugin to codelite ?
- I create a plugin out of codelite repo ? I'll use a environment variable to define the codelite source directory in the project settings.

[eranif]

Hi,

I think that the best practice to create plugins is to create them inside codelite's source dir

- I fork the codelite repo, and add the plugin to codelite ?

Given the above, this looks like the best option.

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)

Some questions:
- Does the plugin need the Lua libraries, if so, how are they obtained? (build them locally, download them etc)
- Do you have access to a Linux / OSX machines where this plugin can be tested?, or are you going to focus only on Windows?

Eran