This content has been marked as final. Show 23 replies
You may want to check out this page:
Not sure about Windows, but on Mac, TextWrangler (http://barebones.com/products/textwrangler/download.shtml) does a nice job with Lua syntax coloring.
Also BBEdit (Text Wrangler's Big Brother) and TextMate support Lua
Good call Eric.. Free is always good.
I'd been using Taco HTML Edit, because it runs as projects and will open .lrwebengine files on Mac (i hate renaming them, just to open them)
I've mailed the link to Matthew Campagna to..
Thanks also the Jeffrey Friedl for the ./luac hint.. Sheesh.
Remember you can do one of 3 things. 1) Right-click > Open With. 2) Drag the file onto the Dock icon 3) Get Info on the file type and change which App it (or all of them) open with by default.
For TextMate you will have to grab the Lua "bundle" from their Subversion server. Once you do that it works a treat.
There is an Eclipse plugin for lua that is good too for those already using Eclipse. Check it out:
If you download the lua installer for Windows, it includes the SciTE editor as part of the package. Its basic but it doesn't use much memory. What more do you need?
The package also includes the lua documentation and compiler. Download the Lightroom SDK, DebugView ( technet.microsoft.com/en-us/sysinternals/bb896647.aspx ) and you have a functional development environment.
I can vouch that the emacs lua-mode works well.
I am using a combination of LuaScript editor, Eclipse and Ant(am a java develper, so I have SVN, Eclipse and Ant). This way, it is easy for me to run the ant tool after I make a change to my code and it will create my xxx.lrdevplugin directory for me and copies it over to my deployment direcotry. What is even better is that I have two different builds for Mac and PC, and the build takes that hasle even one step further away.
I'm writing with Coda which does have SVN built in, but I'm not currently using it. Should I investigate this further?
If your question is 'should you use eclipse', I would say it depends. If your situation needs automatic(or easy) builds, the answer is yes. I have had some problems with Elise's Lua editor, but I still can lunch the files in the Lua Sript Editor. The rest is just easy to build with the ant support.
If I am not being clear, let me know...
As I'm compiling some of my code, I'm more concerned that in a moment of weakness that I don't throw away the uncompiled code. It's happened once, but I was able to recode the changes as they were fresh, I don't want it to happen again..
I think this is relevant to this thread: I haven't seen info on how to compile my Lua code, how LR treats that differently if at all, etc. Do I use a stock Lua compiler or is there anything special I need to know because of the LR environment?
I am using an ant build file that automatically calls lua copiler on my lua files. I issue:
C:/Program Files/Lua/5.1/luac.exe -o "somepath/fileName.lua" "sourcepath/fileName.lua"
That way, I am only distributing the compiled code and at the same time, I am working on my uncompiled code and neve have to worry about losing it, nor do I worry about distributing my un-compiled code.
I never noticed any problem when compiling my lua code and put it in my plugin folder. As you can see above, I am using the standard lua compiler. I used the compiler It seems they are not diffirent as they should not be.
I had those same concerns and in a similar vein to Kamal I've written a wrapper script to avoid the issue (see http://thephotogeek.com/download/scripts/luac-lr.cmd ). Place a shortcut to it in the parent directory for my source file and call it using a syntax similar to:
and it compiles code from export-backup.lrdevplugin to export-backup.lrplugin. Minimises chances for me to kill my code.
From memory you are a Mac user so you would need to convert it to bourne shell script but that wouldn't be hard.
I'll peek at that soon.
Currently I just back up the script as I'm only compiling the galleryInfo.lrweb and manifest.lrweb files for Web Engines. I could actually automate this, which I hadn't considered until your note!
Actually after peeking through the script, I could easily modify it for .lrweb files using no extension for the dev version and the .lrwebengine extension for the compiled version.
Here's what I did:
cp -R $DIR $DIR".lrwebengine"
luac -o galleryInfo.lrweb galleryInfo.lrweb
luac -o manifest.lrweb manifest.lrweb
Bear in mind this is probably the first shell script I've written since college, but it seems to work.
I have luac in /usr/bin already..
I could work this so that I'm not even working in Web Galleries anymore.
I could be in Docs and have the compiled version go to Web Galleries.
That way the version in Lightroom is always compiled when I test it.
Edit.. if I could read spaces in file paths in a shell script that is.. Sigh
I've been using NTFS junctions in Windows (think symbolic links in UNIX) to hook my source code and compiled code directories directly into the Modules directory LR2 automatically checks at startup. I only ever compile my code when I'm getting ready to release a package and do my final testing.
Advantage of this approach is LR2 already knows these two are the same plugin (they have the same identifier) so when you enable one it automatically disables the other. That way I can be merrily coding/testing away, receive a report of an error and swap to the publicly released version of the plugin to troubleshoot, then switch back to the development version once I know what the issue is. An elegant feature the Adobe crew built into the Plugin Manager.
The Plugin manager is for Export plugins only Matt, doesn't work with Web engines. (I'm including post process and metadata stuff in Export)
Lightroom will only allow one of the plugins to work, but I'm not sure what the criteria for choosing which one it is.
Haven't developed a web engine before so hadn't thought about that issue.
Alternative for you - modify your new script, or write another script instead, to allow the released and development versions of a gallery to run in parallel. Either add something into the development version's galleryInfo.lrweb file and strip it out before compiling, or add something in before compiling.
e.g. the former option would look like this
Dev galleryInfo.lrweb file would include:
title = "Web Sample (Dev)",
id = "com.adobe.lightroom.wpg.templates.sdk.luawebsample.dev",
Source for compiled galleryInfo.lrweb file would include:
title = "Web Sample",
id = "com.adobe.lightroom.wpg.templates.sdk.luawebsample",
I'm guessing that would be enough to allow LR2 to distinguish between the two versions, and you to know whether you were using the released version of the one still in development. Adding a sed call to your script should easily be able to make this change for you.
This is a bit of a kludge but should work.