Thanks for the feedback.
- The Build => Upload => Script entry shouldn't be there, I'll correct the code. It's a follow up project, which I haven't completed yet.
- Saving only works after editing. This is normal behaviour for scripts, I was doubtful of doing it this way, but did so to maintain consistency. If there is a consensus to alter this behaviour I would happily agree to do so.
- Hmm, .lsl should be added by default, I'll look into this.

Unless opening the script from file automatically saves (uploads and compiles) the script then it makes more sense for the save button to be enabled as soon as the script is loaded. No need to wait for an edit to enable the save.

@Kelly. No it doesn't upload and save, that would be the job for the Build => Upload => Script entry that I'm also working on separately. So far as my own testing, uploading a file into the window does automatically enable the save to inventory button. The saving that Lance mentioned is for saving to disc, which is not automatically enabled, currently, unless the script's state is not clean.

This is mostly a Window's feature, at this time. The .lsl filter is part of a Window's only code path, there exists a Darwin code-path too, but I haven't done any work in that yet (no Mac to develop with). As far as I can see, there is no Linux specific code-path for the dialogues, so I'm not sure what can be done there.

Incidentally, I'd be interested to know how a Linux build handles exporting images. Does it add the suffix automatically?

I'm not familiar with lslforge, but I'll look into it. Are you sure they're valid tabs? I ask because it handles tabs from LSL Editor without a problem.

Looks like this is a bug I've introduced recently, as it is also affecting my LSL Editor created files now. :-(
Trying to track it down, as soon as I can work out how to go back to a specific revision in Hg.

Damn.  SL's text editing windows do not like tabs. When copy/pasting the tabs are converted to spaces, but not when inserting text. I'll look at finding a way around this.

I don't remember any in-viewer text input ever liking \t particulary. It might be best, or at least easier or safer, to just convert them to spaces on import.

I use an external editor now for all my scripting (TextWrangler) and I have set it to use only tabs for all indentation.  The viewer accepts it just fine, and will even regurgitate the tabs when I open the same script in the external editor sometime later.  However, if I try to edit the text using the in-world editor it will mangle the tabs every time.  So my suggestion is this: don't worry about tabs when saving or loading scripts - leave the text as-is.  If it's too annoying (which I think it is) than a JIRA entry should be made, unless there is one already, to request that the SL text editor support real tabs (\t) in the text.  That's where the real problem domain is, not here, IMHO.

@Kadah, @Cron. Guys, tabs are now handled as noted it the last diff (below). Are you suggesting I should remove the conversion?
Personally I like using tabs in my external editors, but hate the boxes in SL's editor.

@Cron. What editor is that? I've only tried live editing externally with LSL Editor, set to use UTF-8 and only indent with tabs, but the tabs only show as boxes in SL which I find defeats the purpose of clear indentation (and ugly too).

I had the mistaken impression from my experience that part of that issue was at least the fault of more than just the UI text editor controls. I was only making the point cause the tab issue and the fact that most external editors use \t for tabs, is likely going to lead to "I uploaded a script and now I can't edit it properly in-viewer, thus the uploader is broken". 
I'd like \t to be preserved on the uploads and simple have a jira regarding the text editor's poor handling of \t linked to STORM-1708, then get that fixed separately.

@Ima: WRT to the conversion, I suspect controversy here.  Personally I'd go for leaving the file the way I intended it - with tabs, or any number of spaces, depending on how my external editor is configured.  To me, since I use ExternalEditor, this Save/Load functionality is more a way of doing backup and restore, but having it mangle my files doesn't sound good to me.  Maybe a debug setting for the conversion, but most likely not: the real fix is to fix the in-world editor to display the tabs correctly.  Like I said in the OSDev list, I don't see the squares: the tabs render as something akin to spaces.

As to the editor, it's just a nice advanced editor for Mac OS that's free.  Its big brother is BBEdit.  I had to go find a syntax highlighter module for LSL.  In Windows I use Programmer's Notepad, again with a highlighter plugin.  On Linux, since I use KDE, I set up Kate as my editor.  All three are very similar.

@Kadah: Agreed.

@Cron: I think whichever way tabs are handled will cause controversy.
Some will regard, and already have, the non-printing characters being displayed to be an error of the import process and not that of the editor display. This is understandable as they will never have encountered it before in SL. Others, and I count myself here, would simply like the editor to leave the file alone and display tabs as tab-stops.
Either way, someone will not be happy. I think, that this is a decision for the product owner to make. ;-) Incidentally, I filed a JIRA for external editing not dealing with tabs. We can see what is desired from how that is handled.