[ZeroBrane Studio] Re: couple of questions
- From: Paul K <paul@xxxxxxxxxxxxx>
- To: zerobrane@xxxxxxxxxxxxx
- Date: Thu, 7 Nov 2013 18:11:59 -0800
Hi Geoff,
> Yes removing Lua 5.1 was a big problem for us, so much so that I stopped
> using ZBS and switched to a different IDE. We are using it to write scripts
> for a embedded system that is 5.1 and unlikely to change to 5.2 and will
> never be Lua Jit.
Sorry to hear that; I wish you'd told me that when you first
encountered that error. This is only the second time I hear about
possible incompatibilities and the first one was related to the use of
"goto" as a variable name.
> The first script I loaded into V0.39 that was fine in earlier versions
> produced an error for me. I cant recall what it was now as I did this a few
> weeks back, but it was due to some small but significant incompatibility
> between versions
I'd love to know what the error was as my assumption was that using
LuaJIT would provide a smooth transition path to those who want to
switch to Lua 5.2 and also would allow to stay compatible with Lua
5.1. So far I have only came across two issues: missing math.mod (can
be replaced with %) and tbl.goto not allow as goto is a keyword.
The current version of LuaJIT is compiled with
LUAJIT_ENABLE_LUA52COMPAT switch, which is a bit less compatible with
Lua 5.1 (http://luajit.org/extensions.html). I'm considering
recompiling LuaJIT without that switch, especially if it's causing
compatibility issues as the ones you see.
> It would be great to have it back in as a future option please ? Thanks for
> the note on how to put it back, I will try that tomorrow.
That was my original plan, but it turned out to be too complex because
of dynamic library dependencies (especially on windows). I tried to
find a way to make Lua 5.1, LuaJIT and Lua 5.2 to co-exist, but there
was just no clean option to package them all, so I decide to go with
LuaJIT and Lua 5.2. You should still be able to use Lua5.1 dll (as I
suggested earlier), but my preference would be to figure out what
exactly is causing the issue for you.
Using LuaJIT has some other advantages even for those who don't use
LuaJIT as I plan to integrate profiling and some other features that
are not available in Lua 5.1.
> My other question missed a detail I should have mentioned. The other language
> for syntax colouring was an oddball language that wouldn't be in Scintilla as
> an existing lexer. so I guess to implement that I would have to implement it
> first in Scintilla then build that as a custom object and then hook it up to
> ZBS. That sounds pretty tough to figure out and get working.
It is possible. I've done something similar with styling I use for
Markdown formatting. Roughly, the logic is this: you set Lexer to the
value of SCLEX_CONTAINER, which will make Scintilla to trigger
StyleNeeded events when it needs to style a text fragment. You can
then style the fragment any way you need.
Some of the resources that can be helpful:
1. Scintilla styling docs: http://www.scintilla.org/ScintillaDoc.html#Styling
2. How to write a lexer; it's in C, but all the calls can be mapped
with wxlua calls: http://www.scintilla.org/Lexer.txt
3. Simple lexer in a container:
http://sphere.sourceforge.net/flik/docs/scintilla-container_lexer.html
4. Markdown styling used in ZeroBrane Studio:
https://github.com/pkulchenko/ZeroBraneStudio/blob/master/src/editor/markup.lua#L151-L210;
it's called from UPDATEUI event, but it can also be called from
STYLENEEDED even and will work exactly the same way, but STYLENEEDED
is only generated when lexer is set to CONTAINER (which is your case)
and not LUA (which is my case).
You can still use something similar to what I sent you in
spec/cpp.lua, but instead of wxstc.wxSTC_LEX_CPP you will have
wxstc.wxSTC_LEX_CONTAINER and your own constants instead of
wxstc.wxSTC_C_*. When you parse your file format, you will apply those
styles to specific fragments of your code, which will automatically
apply whatever colors/attributes you configured for those styles.
Paul.
On Thu, Nov 7, 2013 at 4:49 PM, Geoff smith <luadataviz@xxxxxxxxxxxxx> wrote:
> Hello Paul
>
> Yes removing Lua 5.1 was a big problem for us, so much so that I stopped
> using ZBS and switched to a different IDE.
>
> We are using it to write scripts for a embedded system that is 5.1 and
> unlikely to change to 5.2 and will never be Lua Jit.
>
> The first script I loaded into V0.39 that was fine in earlier versions
> produced an error for me. I cant recall what it was now as I did this a few
> weeks back, but it was due to some small but significant incompatibility
> between versions
>
> It would be great to have it back in as a future option please ? Thanks for
> the note on how to put it back, I will try that tomorrow.
>
> My other question missed a detail I should have mentioned. The other
> language for syntax colouring was an oddball language that wouldn't be in
> Scintilla as an existing lexer. so I guess to implement that I would have to
> implement it first in Scintilla then build that as a custom object and then
> hook it up to ZBS.
>
> That sounds pretty tough to figure out and get working.
>
> Regards Geoff
>
>
>
>> Date: Tue, 5 Nov 2013 17:07:42 -0800
>> Subject: [ZeroBrane Studio] Re: couple of questions
>> From: paul@xxxxxxxxxxxxx
>> To: zerobrane@xxxxxxxxxxxxx
>
>>
>> Hi Geoff,
>>
>> > I was a bit shocked to discover you had removed the standard Lua 5.1
>> > Interpreter :(
>>
>> It has been replaced by LuaJIT, which is fully ABI compatible with Lua
>> 5.1 while also providing some level of language compatibility with Lua
>> 5.2. May I ask what you are missing in the current setup?
>>
>> > Could you point me at some instructions as to how I add that back in
>> > please ?
>>
>> You have several options. One would be to get the old
>> library/executable and use it instead of the current one. You can get
>> all the binaries from one of the older versions of ZBS
>>
>> (https://github.com/pkulchenko/ZeroBraneStudio/tree/115924d56797f9d1f3a43df453a1cef8e9a1a581/bin).
>> You can also install Lua interpreter to some other folder and
>> configure ZBS to use it with path.lua setting
>>
>> (http://studio.zerobrane.com/doc-general-preferences.html#interpreter_path)
>>
>> My assumption was that users are not losing anything with this switch,
>> but maybe I missed something.
>>
>> > A second more wacky question for you. How easy or difficult would it be
>> > to modify ZBS so that its syntax colour highlighting was for a different
>> > language other than Lua ? I am guessing this might be hidden away inside
>> > the
>> > Scintilla edit component you are using, so therefore would be very awkward
>> > to change ?
>>
>> Yes, it should be possible to get access to other lexers inside
>> Scintilla. It should be a matter of connecting spec identifiers that
>> ZBS recognizes with those defined in Scintilla lexers. I recently did
>> something similar for c/cpp that you may use as a starting point
>> (spec/cpp.lua).
>>
>> If you open .cpp file you should see that highlighting if you enable
>> loading of spec files by adding this to the config file:
>> load.specs(function(file) return file:find('spec[/\\]cpp%.lua$') end).
>> I should probably change this to allow new specs to be loaded by
>> default.
>>
>> You should still be able to use all the color themes and everything
>> else color related.
>>
>> If you want to distribute this, you can wrap this into a plugin that
>> uses ide:AddSpec and ide:RemoveSpec calls. This may be easier option
>> as it eliminates the need to modify the config file and to provide
>> multiple files. Let me know if you need an example on how this can be
>> done.
>>
>> Paul.
>>
Other related posts:
