I’m sure I’m supposed to know this. When editing LSL, I sometimes type command B while reaching for command V. The results are that Sublime tries to build using some scheme and fills the window with diagnostics.
As far as I know, there’s no useful build system for LSL. I guess even if there is, I’d like just to disable the command B function in LSL, without breaking it for, say, Ruby.
Advise me, please. Thanks!
The first ways that come to mind for disabling the ability to build (there may be others) would be to:
Of these the first is invasive and not a good idea (unless you’re the one that created the build system in the first place, but it doesn’t sound like it) and the third way seems more clean. A new custom build in this case would still require the build system to be set to it (or automatically selected) before the build key binding would effectively do nothing, which leaves a margin for error that may catch you unawares.
An example of a key binding that would ensure that the default build key is disabled for plain text files would look like this:
{
"keys": ["super+b"],
"command": "noop",
"context": [
{ "key": "selector", "operator": "equal", "operand": "text.plain" },
]
},
Note that this assumes that you’re on a Mac (which it sounds like from your question). For Windows/Linux you would use the key ctrl+b instead to override the default build key for those platforms.
This is telling Sublime that in the specific instance of the current file being a plain text file (specifically the location of the cursor, to be more technical about it), run the noop command, which is a command that does not exist, hence the key does nothing at all. However since this binding gets selected for the key instead of the default one, it has the effect of blocking the build key.
For your purposes you would need to change text.plain to something more suitable for an LSL file. To do that, while you’re editing such a file, choose Tools > Developer > Show Scope Name from the menu (or press the associated key binding). That will show you a pop up of the complete scope of the current cursor location; you want just the first line of that (the more of the scope you put, the more specific you make your key binding).
I’m not familiar with LSL but I would guess that it would be one of text.lsl or source.lsl that you need here.
Super, thanks, I’ll see if I can do that. I do think disabling it makes the most sense in this case.
Thanks gain!
I assume you are using @makopo 's LSL package. As with any other Build system for Sublime Text, you should be able to just hit Esc following ⌘ CmdB which will hide the output panel. Also, as the Build doesn’t output any extra files, you wont have any unexpected side effects when aborting (should the Build process not be finished, yet).
On another note, should you be using ST3, I recommend SublimeLinter3 with SublimeLinter-contrib-lslint. That way you wont need the Build system provided by the LSL package, because the linter plug-in will do the same and highlight warnings and errors while you edit your code. If you are unfamiliar with linters, I suggest reading the linter plug-in’s README to get started. Also, be advised that this also works without you having saved the file contrary to the Build system.
Compare the following screencast where the linter plug-in shows warnings and errors from lslint output in the statusbar and/or by outlining the code. I’m hiding the panel with Esc as explained above:
Regarding @OdatNurd 's comment, the scope is source.lsl.
ST3 also has tooltip support, compare: https://github.com/Makopo/sublime-text-tooltip-lsl
Also compare the sublimetext/LSL subfolder on https://github.com/buildersbrewery/linden-scripting-language which has a slightly different setup.
Hi rppn, I did override command-B as suggested, using source.lsl and it did stop the build. I wasn’t getting a build window, however, I was getting interleaved comments that weren’t even germane to LSL. I forget now what they were, but things like var references and such, which are not used in LSL. It was like they were for some other language.
I’m sure I’d have tried escape to get rid of the diagnostics but can’t swear to it.
I can’t tell in your little video what you did to get rid of the in-line diagnostic, please advise on that.
The linter sounds interesting and maybe I’ll give it a try. If it’s not obtrusive it might save a compile pass.
I’ll try turning the thing back on and post a pic of what’s in there in case you or anyone gets more info out of it. I don’t believe I have whatever build tool @makopo calls installed, perhaps due to a need to replace the drive on this computer.
So, thanks. My status is that I overrode the command B but the linter sounds interesting and I suspect I have something else messed up.
(I love Sublime but rarely do any real mods other than installing packages, so I’m not facile with finding my way about. Thanks for help and patience!)
@ronjeffries If my previous comment wasn’t clear. I’d advise not to disable the build system but use Esc instead. That way you can still access the build system to fix errors via lslint.
You can set "show_errors_inline": false in your preferences to hide the in line errors on Build.
As to the output you get, that is from whatever Build system you are using instead of lslint now… see Tools > Build System and whatever is selected there instead of LSL. You have overriden the key binding for source.lsl, which kinda works but has the side effects you described.
If you have any other questions, just ask.
