Assign other Lua editor

[josjojo]

I would like to use an other Lua editor than the integrated one.

Ron, can you make an option to assign an other editor (executable) for Lua?

[Ron]

no.

I'm working on the editor though. What is the problem with it ?

[josjojo]

I'm missing some things. Like:

- syntax colouring
- multi-line indent
- automatic saving after x min.

Perhaps I want too much, but would be possible with an external application.

[Malversán]

Although Josjojo's ideas are great, I think it's not enough effort to copy and paste code from an external editor to the Girder LUA window to justify providing Girder with IDE functionalities. I think Girder's LUA is intended just as one of the multiple powerful extensions of Girder, not one of its main features.

And I've read that Ron is working in syntax highlighting, in fact. But, as a programmer, I won't be tempted to make his life harder asking for the Moon ("la Lua", in portuguese ;-) ) just for comfort (not functional) issues. I know very well how much this "little requirements" cost in time. ;-)

Just my opinion. Sincerely, I'm very glad to see Ron's working day by day and I hope Girder's development will be useful for him in still more important fronts than the tons of learning and friends he's making. I'm sure of it.

The same applies to all plugin developers (but I think Ron carries the hardest job). Thanks for all. :-)

[Ron]

1 syntax colouring
2 multi-line indent
3 automatic saving after x min.


1. implemented 3.2.6pre1
2. implemented 3.2.6pre1
3. easy to implement.

[Mark F]

...
3 automatic saving after x min.
...
3. easy to implement.

I'm a bit confused about how this will be easy. If a plugin is using the script editor, what will be the new behavioral model of the interface?

[Ron]

I might have been a little quick there, I was thinking of saving the GML file. Indeed its a little tricky when it comes to the lua script. Maybe I can do something like a file to which Girder writes the currently edited script and when girder crashes it could restore from this file.

[Marsupial]

OK, I don'T use Lua yet (conversion issue)

BUT... when I work under girder, I don't exactly want to "auto-save"...

the fact is that I do modifications, and saves when it works. It'S not like I'm to programm other lua things under girder, only my girder things... therefore I don't intend to work for hours without having significant changes.

Maybe I'm fool... but I don't see the purpose of auto-save for SCRIPTING.

Highlight, that's great! :D
multi-tab: great also :D

do you have a java compiler and a C++ editor in there ? ;)
plus a VB editing property... ;)
Oh, yeah, and a file browser with integreted winzip. :P
(see the point?)

[Ron]

Indeed an GML file autosave would not be usefull, however what I was suggesting was a autosave that only saved the current script in a separate temporary file. But I do not consider this a critical feature. I'd rather fix bugs that are causing the need for the auto-save ( as in remove the cause not fix the symptoms )

[josjojo]

Ok, I think that an autosave function for the Lua script editor is a bit overflowing, but an autosave function to save the GML-file is very useful. When your computer crashes the GML-file is not saved and all your newly added commands are gone.

Maybe you can implement this:
Autosave the GML-file to a backup-file (e.g. file.bak or ~file.gml).
When Girder is closed correctly the backup-file can be removed.
But when Girder or the computer crashes, the next time Girder starts you can ask the user is he wants the backup file to be loaded.