TextMate - LSL Language definition file (For Mac users ;-))

You autocomplete using esc/shift esc (autocomplete works for custom variable names etc... not only for bundle-defined stuff!).

You can use/copy-modify goodies from other bundles (the source one is very useful, has things like insert a ;\n at the end of current line... and you can use its shortcuts while writing LSL code) so take a look to them too.

# Piero

Piero,
Thank you so much for doing this! Its Just Great!
Sterling

Ah, I don't really want to "steal the limelight" on TextMate, but... as said, I gave it a serious try. Piero's right: the strength of TextMate — like, perhaps, on the old Emacs — is the ability to "create your own features". Now this is very 1990-ish, when the rage was all about "creating your own extensible editor", and the "best" approach in these days was to develop a "bare-bones" editor, throw in a good programming language, and have people developing all the features they liked most. The more open the integration APIs were, the more flexible the language, the wider it would be adopted (I keep remembering Emacs in this context for some reason ).

TextMate seems to fulfill that role perfectly: it's cheap, it does the "bare bones", and it seems to unbounded in the ability to be extended. All good reasons for using it and paying the very reasonable licensing fee!

However, I would rather focus on developing things (LSL, PHP...) instead of developing the editor. After a few rounds of frustration for not being able to find some of the things that I consider essential — splitting a screen in the middle, converting to different character sets, quick find (ie. "inline find" like Emacs, Mozilla, and other tools do), eliminating "weird" CR/LF — as well as understanding that creating "projects" from remote folders (in order to get tabbed navigation, instead of "one separate window per file", and understanding that I had to develop all of these on my own, I reverted back to "old faithful" Smultron, which just got a new release this week that adds LSL support, being probably the first editor to do so on the standard distribution (although additional language support is actually very easy).

I'm afraid that TextMate won't be my mate after all The choice seems to be between TextWrangler and Smultron really; between both, although I can imagine that TextWrangler will always have better support (having a company behind it!), I'll stick with Smultron for a while longer, at least until it goes the way of many open source projects, ie. getting abandoned by its author...

Er... ehm... well...
I just dunno what to say... the things you say are VERY easily done and/or not missing in TM... and u seem to forget there are the free OSX programmer's tools to support, complement and ENHANCE TextMate possibilities in sinergy in a way you don't seem even to imagine... did u install/see them? (and did u see the screencasts on TM site? really? are you sure? no, you didn't! no! I don't believe you! you paid attention?! no, you fell asleep, say the truth! lol)
Without kidding, I think you probably took a "very quick look" to it...
I really can't compare it to Smultron... I am a programmmer so TM being so "programmable" makes it for me INFINITELY better, u don't even need to code to make useful macros, and it has wonderful premade bundles... and how can you say Smultron has "support for LSL" after seeing my bundle? Maybe I'm wrong and took a "very quick look" to Smultron, but I saw only a few words with a different color and a limited autocomplete not easy to expand (well, not so much if I use TextMate to edit it but that's a contradiction in terms)
I saw a wrong definition of block comments in LSL too...

# Piero

I enhanced the "check syntax show lslint" command: it now shows an HTML window with errors and warnings descriptions linked to their location on the source code.

Just for the fun of navigate it when you make a big mess.

# Piero

Today I'm having some problems with my provider (grrr) but this inspired me to make an "offline wiki" command to see the current word (function) description on the (limited and incomplete) lsl_guide.html document. I think and hope that many of ya friends may find it interesting: it uses some AppleScript hacks to make it ultra-fast even having a lot of text to parse...



# Piero

I noticed that some of the other language bundles have more complex regular expressions for their keywords. For instance, "e(ach|nd|xtract)" instead of "each|end|extract)".

With the large number of constants and functions, would the LSL bundle benefit from that kind of optimization? I haven't noticed any slowness, but I've only edited small scripts on a large machine.

Sorry folks I had connection probs but now back hackin online again!
I optimized the functions/constants/events definitions: TM support said it can improve speed a bit.

Added some other goodies too

The Link is always the same:
http://digilander.libero.it/usemac/tm.zip

HAPPY
NEW YEAR!

# Piero

ll autocomplete!!!
This means that after writing: ow
using the macro you get: llOwnerSay((string) text)
(1st letter is autocapitalized, and if not ok on 1st match you can continue autocomplete using esc)

When calling a global function (use autocomplete! ) you can now autocomplete even more with a macro that inserts the snippetized cast parameters.
This means that if you defined:
float Lag (integer NoobScripters, float SLupdates) {...
after writing: Lag
you get: Lag ((integer) NoobScripters, (float) SLupdates)
("insert-code-ready" like when you hit tab after autocompleting a ll* function)

Don't forget to indent (or use directly a cleanup macro if needed) before using my bundle

The Link is always the same:
http://digilander.libero.it/usemac/tm.zip



# Piero

Added some constants that were missing:
PARCEL_DETAILS_DESC, PAYMENT_INFO_ON_FILE, PAYMENT_INFO_USED

Did someone make some nice color theme?
The one in bundle is made to show what can be highlighted

# Piero

The bundle is great! Thanks for your work on it. It's a joy to work in TM instad of inside SL.

Would it be possible to make it so both bracketing styles work?

For example, this style works fine:

string foo(string param1, list param2) {
return "hi!";
}

But the way I prefer to format doesn't:
string foo(string param1, list param2)
{
return "hi!";
}

If I do it the second way, the bit that auto-detects functions so I can easily navigate with cmd-shift-T screws up.

Thanks!

Oh, also, with the old lslwiki down, the "look it up on the wiki" function doens't work anymore. Could the next version point to lslwiki.org?

I'm waiting for a decen... er... better version of the wiki to come up, but if u want to edit the link it is not hard to do... that's the spirit of TextMate: hack it! (I updated it: now uses lslwiki.org)

# Piero

A way to fix the functions autodetect using your bracketing is to add a space after:
string foo(string param1, list param2) <-- space here
... or changin LSL language definition:
name = 'meta.functions.global.declare.lsl';
begin = '^\b(\w+\b)*(\s\s+)*\s*(\w+\b)(\s\s+)*\s*(\()(?!$)';
end = '\)';
(changed end definition)
... but I suggest you to use the 1st alternative making a search/replace.

You made me doubt there was a syntax coloring error on return lines but was all ok so this post was re-edited for that lol



# Piero

Opens http://www.lslwiki.net/ now for help on current word.



# Piero

Great Bundle, thank you very much for sharing it.

what I don't really get: why do you think that empty lines or double spaces are "invalid"?

and there seems to be an error with indent for lines like
} else if (...) {

I like to have double spaces highlighted: if u dont like it u can make a new fonts&colors set...

Thats not a good indentation style IMHO and indent is done by textmate not my bundle

# Piero

ok. I use the "Mac Classic" color set and was wondering, why every empty line was marked dark red as error, which they are not. But looking at your color preferences, I understand that we have a very different understanding of what is clear/legible. No offense meant. I can change that myself, right.
(I still think it's not the best style to use the global root scope selector "invalid" to highlight things that are clearly not invalid, not even the slightest bit harmfull, like an empty line)



Another matter of taste, but clearly no reason to indent it wrong?


Hm, I think LSL.tmbundle/Preferences/indent.plist is responsible. Am I wrong?

Never mind. It wasn't my intention to criticise you. I thought you said to send you questions/suggestions/comments.

I made the example color scheme for you to have clearly visible what can be highlighted, so u can mod it!!!!
Better if u duplicate it and adjust than using mac classic scheme.........
I wanted to highlight "suspect" things like double spaces on the fly... it is VERY easy to mod it.... well I hope so for you... TM is wonderful cuz u can customize...
They r "categorized" as invalid.suspect.... NOT invalid... u can change their color with ease....
See next post to see how u can customize indent for your example indent correctly.

# Piero

solved swapping some definition priority... I'm almost sure there wasnt this prob some time ago... boh! (Remember: I always use cuttin edge version of TM)

for Soilent:
I realized I optimized indent rules for my cleanup macros, so it is not exactly like C stripped down for LSL, but u can try changing the decrease pattern in indent to something like this:

decreaseIndentPattern = '^\s*\}.*$';



# Piero

Hi piero,

thank you for the quick fix.

I was testing a bit with the patterns myself and now I see that it's hard -- if not impossible -- to write a single pattern that does it right for all possible styles.


For my personal stlye, I find these indention patterns work ok.
Lines like
} else if (t=="string" {
} else { // comment here
do work now and that's what I am using.

I know they do break some things for other styles/circumstances. Like "{" or "}" insidse a string or comment.
So everybody who wants to try these, do so at your own risk

{	decreaseIndentPattern = '(?x)
	    ^ (.*\*/)? \s* \} ( [^}{]* \{ )? [;\s]* (//.*)? $';
	increaseIndentPattern = '^.*\{[^}]*$';
	indentNextLinePattern = '^(?!.*[{};]\s*(//)).*[^\s;{}]\s*$';
	unIndentedLinePattern = '^\s*(//.*)?$';
}

(based on the c/c++ patterns)

After the new version of lslint came out, I updated the bundle to (L)SL 1.15.

Added:
PARCEL_FLAG_ALLOW_ALL_OBJECT_ENTRY
PARCEL_FLAG_ALLOW_GROUP_OBJECT_ENTRY
STRING_TRIM
STRING_TRIM_HEAD
STRING_TRIM_TAIL
llSetLinkPrimitiveParams(integer linknumber, list rules)
llSetLinkTexture(integer link_pos, string texture, integer face)
llStringTrim(string src, integer trim_type)

Other minor fixes:
syntax coloring (suspect minus in some instances)
"continue list with string" command (shortcut was not working on "incomplete lines"
improved indent (seems better than C for some special occurrences like { // or // {)

The Link is always the same:
http://digilander.libero.it/usemac/tm.zip

See it in action - old movie showing just SOME of the features -
http://digilander.libero.it/usemac/lsl.mov

Don't forget to write in terminal:
chmod +x ~/Library/Application\ Support/TextMate/lslint
(or use the command included in bundle)

HAVE FUN!

# Piero

Added llRegionSay

Fixed states not showing in list

Improved valid minus definition

Added a "force { indent" for rare cases when { is "between strings" and cleanup fails

#Piero

I realized http_response was missing after settin up (in 15 mins!!!) a web server that can make my Mac do almost anything from SL!!!

Thanks AppleScript!!!

# Piero

I'd LOVE to see a screencast of that, Piero!! Thanks for keeping the Textmate bundle up to date!! And thank you, Leon Ash, for putting it together in the first place.