Script Inspector 3 - World's Fastest IDE for Unity

hey flipbookee great program and it's saving me a lot of time...

just curious - is there any sort of manual for SI 2? i haven't found so much as a single help file as to how to configure things. i'm most interested atm in changing font size. there was a few choices in version 2.1 but in 2.1.1 but that seems to be gone now. what gives? is there currently a way to customize font types and sizes (for fonts that support dynamic sizing)?

scott

 

Cool! Thanks!

There's still option to choose the font from the wrench menu, except when a script is shown in the Inspector. You can scale the size up and down with Ctrl (command on Mac) + mouse wheel, or Ctrl+Plus (or Ctrl+Equals on some keyboards) and Ctrl+Minus. Note that the Si2 editor view has to be in focus for these to work. Also Pinch/Magnify gestures should work on a laptop for example.

The included readme.txt covers all of the existing features, and it has a list of shortcuts near the end. Check that, or just let me know what are you looking for exactly.

 

Finally put up a review Flipbookee. Thanks for the great tool :-D

 

WOOT! Another 5 stars review? 19 x 5 = 95 stars, almost unlocked an achievement

Thanks a lot Eric!!!

 

Ah Cleroth, my dear, I'm so sorry to see you so disappointed. With all due respect to your opinion and how the Si2 feels to you, let me just clarify each of your points in your updated review:

1. Indentation helpers will be available in the upcoming version 2.2. The reason that wasn't implemented so far (besides that I only have two hands) is because such feature depends on the parser used in Script Inspector 2, which up until now was still the old one from the initial version that was only useful for syntax highlighting. The main feature of version 2.2 is the new parser that will be capable to do much more than the old one...

2. Go to definition is another new feature that depends on that new parser which I'm working on right now, and this will be one of the first features that will come out with it.

3. Please, don't blame Si2 for the Undo shortcut being different than Ctrl+Z. There's one simple reasons why it's like that - it is impossible to handle Ctrl+Z (and a couple of other shortcuts) in the Unity Editor, and there's nothing I can do about that... If someone has to be blamed, blame UT for not allowing extensions to override all key bindings. Giving Si2 lower star rating because of that is not correct, even though your point that it might be difficult to get used to that new shortcut is still valid. But see, this is the closest you can get right now. Once UT gets that fixed I'll submit an update within minutes!

Regarding the Undo shortcut, it might be worth mentioning that I was considering a hack similar to how it's done in UnIDE, even before UnIDE got announced or released, but I dropped that idea quickly after realising that code editing needs separate undo/redo buffers from the one in Unity, and even more, each script has to have one for itself. That's why Si2 doesn't require to first undo all changes made in your Scene and Project done after editing a script, to undo that change in that script. Similarly, undoing changes in one script doesn't require first to undo all changes in other scripts made afterwards.

 

I just thought I'll write a little bit about the progress so far with the new parser I mentioned in my previous post... Ignore this post if you don't care about the technical details, or if words like parser, lexer, grammar, or syntax tree make you feel sick

Before I started working on this new parser I did a lot of homework, researching various parsing techniques, algorithms, popular implementations, alternatives and existing libraries. None of the existing libraries I checked seemed to be fitting my needs, so I decided to go with my own implementation from scratch. And everything seemed fine until I read Eric Lippert's post on http://stackoverflow.com/a/9556530 answering how dificult it would be to implement a feature like intellisense, because according to him it should take some good 20 years of full time work and studying for a single person to do all that!!! I was shocked for a day and I was almost ready to look for some other existing libraries again. But then I realized his answer there was biassed towards turning people to opt for using Roslyn instead of trying to implement something similar by themselves. Reading his answer more carefully again I found some tips he was giving on how such library should work, and all of them were things I actually thought about earlier for my own implementation, and seeing this from another perspective was only a strong assertion that I was in fact on the right way. So I thought to myself, if the experts in this field seem to agree with my approach there's no reason to get scared and it should motivate me even more! After checking what Roslyn project is capable of, and comparing that with what I need for the code completion feature, it seems like I'd only need a very small percentage of Roslyn's features, so I tried to focus on that part only.

Within a week I did my own implementation of a parser modelled after TextMate's and Sublime Text's parser, with similar data only defined grammars, and even with similar limitations. But the performance were disappointing... So I had to look for another solution that would still be simple enough to be implemented in some reasonable time...

The reason I'm posting this is to inform you that I finally found a very promising solution, which is going to build up on top of the existing parser. Btw, the existing parser is not really a parser, but only a lexer, a.k.a. tokenizer, used to classify tokens into categories for the syntax highlighting, and it's really fast in doing that! My new parser is going to use that sequence of already recognized tokens, and even not all of them but only those which are needed for code completion. I found an algorithm for building a sparse syntax tree out of that sequence in a really fast way, that's also progressive and incremental, to make it possible to parse only the parts which are needed on request and between keystrokes so that it doesn't affect the performance. Well, that's still not implemented, I only started working on that a few days ago, but everything seems smooth and simple so far. Looks like it will be ready in about a week from now... Exciting times!!! Can't wait to finish it and say "take that now, Eric"!

 

Very good read man.

Im happy you dont got caught on the trap of "cant be done by you alone... use ours". There are sometimes when a reality check is required by projects that become too big for ourselves (ie: lone indie trying to compete on game content against an AAA studio), but many other times there are just external interests polluting your intentions of making something by your own. IMO, is the corporate version of the drug dealer in front of a school. And their greatest fear is that you discover (or remember) that you can do it by yourself, and even better than them.

Go for it! Keep it up!

 

Ah, cool! I was afraid no one is going to read that ... Thanks for your support!

 

Thanks for sharing with us your struggle and discoveries These insights are invaluble towards building a better software and gives us better clarity on how you approach your solution.

About the search algorithm - (pardon my very rudimentary understanding of the subject) - if all the "terms" (keywords) are known sets - would it be easier to just put them all into a Hash function for quicker look up? Also since all terms are known would it be easier to use Binary tree / Binary tree search (sort of like binary space partition) to search quickly to find the right term? There is also "Bayesian search theory" I heard about would that be applicable?

 

Hey, I am da bawss, thanks for reading!

The Bayesian search theory is interesting and new to me, but not really applicable to these kind of problems. That's more for estimating probability and cost when searching for missing objects in real life situations. I always wondered how people can say that chances to find any survivors from a disaster after let's say 10 days are less than 3% for example...

Yes, all the keywords make a known set, and that's what some lexers use to classify tokens as keyword or something else. After extracting a word delimited with white-spaces or punctuation characters those kind of lexers search for that word into their tables of predefined keywords. Si2 does that too using the binary search algorithm over sorted arrays, or using the HashSet collection class introduced with .Net 3.5. Both methods give amazing performance and seem to be superior compared to using the Regex class for example.

 

Just bought it, and loving it so far.

One question, and I apologise if this has already been discussed and / or resolved. I notice that if I have my scripts open in a separate tab (on a second monitor, for instance), I can have an object selected at the same time that the script is in focus. This means that as I type script, whenever I hit a hotkey associated with the selected object, stuff happens.

So, for instance, if I type the letters W, E or R in my script, I can see the gizmo changing on my selected object between move, rotate and scale.

Is this intended behavior? I don't know all the Unity hotkeys, but i'd hate to think i'm altering my scene by accident while I type code. I guess a good solution would be to unselect all objects when the si2 tab becomes active?

Regardless, I think it's really good and I can't wait to really get stuck into it.

Thanks!

 

Hey mickyg, I'm so glad you're loving Si2 so far!

Don't worry about those hotkeys, it's just a small imperfection of the Unity Editor and it's harmless for your scene objects and assets. In fact all windows in the Unity Editor are affected by that, including Unity's built-in ones. Same happens while editing asset names or typing something inside the search field of the Project window for example.

Enjoy!!!

 

Hey folks, could you please tell me how many of you guys would use Si2 for editing shaders? I just realized MonoDevelop doesn't have auto-completion for that, and since ShaderLab syntax is pretty simple I thought maybe to release that feature first, some time during the next week, and get some initial feedback from you guys?

 

Can I get intellisense first pweeze?

 

You mean for scripts first? Sure, I wanted to check what's more preferred, scripts or shaders first. For scripts it would take a little bit longer than for the shaders, and there aren't many alternative editors for shaders... Most of the code will be shared anyway, but each grammar has to be specific to particular language. That's why I asked...

 

Scripts

 

Yeah... That's the expected answer ... C# is on the way already, and it's coming soon...

 

+1 Scripts!

 

+1 scripts i guess

 

I use it for editing shaders!

 

WOAH!!! My new C# parser is like 10 times faster now!

I was logging the time (in milliseconds) both parsers take for every line... See the difference



Yet, it produces more detailed info!

 

That was suspiciously fast, so I had to check am I doing something wrong. I replaced the old parser for syntax highlighting with the new one and it works great! Takes about 20 milliseconds only to process and highlight a larger .cs file of 1000 lines!

 

Outstanding! Go Flip!

 

Thanks man!

Time to use this now for something more than just syntax highlighting. Extracting symbol definitions is the next step, then "go to definition" feature, with a new document outline window later on...

 

Could you tell why do we need 2 console tabs open?!

 

Yep, sure! In short, that's because the SI Console tab doesn't do its own GUI rendering, or mouse and keyboard events handling, and it doesn't maintain its own list of console log items, or anything else we see in the original Console tab. Instead it acts as a proxy window and uses the original Console tab data and code for all that! Obviously, the Console tab has to be visible to work as it's been designed.

So, the SI Console doesn't know anything about the GUI content displayed in it! It only handles the OnGUI events and passes them to the OnGUI method of the original Console, which then renders the whole content and handles all the events. What you see in the SI Console tab is the same as what's shown in the Console tab, only the window size and position might be different, so SI Console has to take care of that and it sets the original Console window size and position over itself, then it passes the OnGUI call to the original code, and then restores the Console window to the real position and size.

Just before calling the original OnGUI code the SI Console has a chance to inspect the current event and alter it eventually to modify the default behavior of the Console, which otherwise would be impossible to be done since Unity API doesn't support that. So, just before the default processing of the double-click or right-click mouse events, or the Enter/Return key events, the SI Console catches the event and does its own behavior instead of the default one! And it works like a charm... Isn't that brilliant?

This programming technique is known as Aspect-Oriented Programing, or AOP (see https://en.wikipedia.org/wiki/Aspect-oriented_programming for more info) and Si2 is the first editor extension for Unity that does anything like that, or at least I haven't found or heard of any other extension doing something even close to that... I've been looking for a solution to implement this kind of functionality from time to time over a couple of months before the initial release of Si2, I've read all about known and existing techniques to simulate AOP in .NET (unfortunately AOP doesn't come out of the box in .NET), I've learned about code injection, AOT and JIT, runtime code generation, and other cool things... Finally I came up with this idea just before the first release of Si2, and implemented the core of it in only a few hours...

This seemed to be so cool that I wanted to do this post and share the technique with all of you long time ago, but I forgot... Thanks Bruno for reminding me!

Anyway, in case your question was more like "Why don't we get rid of one of these and keep only one console tab?" then there are two or three reasons for that. First, this way the SI Console tab will look and work the same as the Console tab in all future versions of Unity, as it was the case now with the improved functionality of the Console tab in Unity 4.1. SI Console tab inherited all the improvements without any code changes (well almost, there were some changes required but not related to AOP). Second reason is that this way you can always choose how to navigate to the source code of log entries - use the original Console to open the scripts in external editor, or use the SI Console to open them inside Unity.

 

I see, my last monster post scared you ... Sorry about that, I just thought someone may find it useful while trying to do something that seems to be impossible in Unity. I'll try to keep my replies less technical in the future

A quick WIP update: I'm still trying to use the new parser to extract symbol definitions. For now there's only a quick-and-dirty implementation to prove the concept, and now I'm restructuring it to fit the existing pipeline. The biggest challenge there is to update the data stored in parser structures in runtime as you type and edit the code without the need to reparse the whole file but only the minimum block of text as required. I have a promising solution but I'll need a couple of days to get it working... I'll keep you posted

 

Some of us enjoy your technical replies

 

Cool, I'm glad to hear that! Here's another one then

Just in case this isn't obvious, I'd like to explain why am I bugging with implementing a new parser... Well, a parser is needed to recognize the code you're editing in order to implement the code completion. Code completion needs to know the context in which the editing happens in order to offer valid completions. With auto completion the script is not seen as a plain text anymore but as a meaningful structure with strict grammar rules which can only be recognized by a parser. The second reason is that code completion needs to know the type of the expression in front of the dot in order to list accessible members of that type within the current context as valid completions. Similarly it needs to know the method signatures for parameter hinting, etc...

Now you might know that implementing a parser is not a trivial task, so you might be wondering why am I bothering to implement my own parser when there are already parsers for all languages supported in Unity? That's because of one simple reason - all those parsers are non-incremental since they were made for the compiler and not for code editing! They work on entire files which means whenever a single character is modified they have to parse the entire script file which leads to lagginess, something that I was always trying to avoid in Si2. There are ways to mitigate that effects by taking snapshots of the entire text buffer and parsing it in another thread, or stripping out the inaccessible parts of the code before passing it to the parser, solutions which are memory and processing power hungry so I didn't like that. This approach has already been tried in UnIDE and it didn't work very well, so there's no point of trying to do the same again.

 

Hey, any chance of a trial version? I already bought the UnIDE and i don't like it to much, i don't want to make the same mistake again

 

Hey badawe, I don't really have a trial version but I'll send you a PM with the full version so you can test it and see the difference. I'll be sending you version 2.1.2 which I've submitted just now to Asset Store. It's the same as v2.1.1 which is currently available without any limitation, but with two hot-fixes: one for the missing shortcuts Ctrl+[ and Ctrl+], and another one for processing some of the Cmd-combined shortcuts on OS X which were incorrectly handled.

Note that this version doesn't have automatic code completion yet or any of the new improvements I'm currently working on. Still, I hope you'll like it and I'd love to hear what you think about it...

Enjoy!

 

The Asset Store team at UT was awesome yesterday and they accepted my update in another record-breaking time of only a couple of hours! Version v2.1.2 of Script Inspector 2 is already available on Asset Store now and it fixes two issues:

- missing alternative keyboard shortcut handlers for indent and outdent - Ctrl+[ and Ctrl+] on PC or Cmd-[ and Cmd-] on Mac; and,
- on Mac only, some Cmd-combined keyboard shortcuts were processed incorrectly so that if you for example press Cmd-K to toggle the comments Si2 would after doing that also replace your selection with a 'k'. :-\​

Both are fixed now, thanks to Little Angel for reporting these! I'm normally working on a PC, so I was unaware of these issues. If you guys notice anything else feel free to let me know and I'll make sure things get sorted out quickly...

I'm continuing now to work on the major update with the automatic code completion and the new parser with incremental parsing feature. I've developed my own algorithm to achieve incrementality and I have that half implemented in code. I've been trying to find some resources online about how that part is working in other code editors, but seems like this is not something that many people talk about. Resources on this topic are scarce and not easy to find... But I've found one paper published by the ex-director of Visual Studio Tools at Microsoft Tim Wagner, which I'm currently using as a reference to fill up the holes in my algorithm besides that it proved that 80%-90% of the assumptions in my algorithm were correct ... I'm hoping to get the parser finished this weekend so I can move on with other things missing to complete the next release.

 

Horray! Thanks and looking forward to the auto-completion update

 

Yeah, me too... Seems like I'll need about two weeks to finish that...

In meantime I had to submit another minor update, v2.1.3 will be available soon. This is really a tiny one and it should only help people who are still using MonoDevelop - I've removed all the default parameter values in my code to avoid MonoDevelop's complains about that. Though, I'm not sure why is MD complaining about that!

BTW, all code changes and even the readme.txt update were done in Si2 within only a couple of minutes, same as with the previous two minor version updates! That feels so... Magical! Open Unity, open Si2 code in Si2 tabs, edit the code, save the changes, test, and a new minor version update is ready to be submitted! All that without even leaving the Unity Editor!!!

 

Script Inspector 2 - v2.1.3 is available now!

Enjoy!

 

WOW. THAT.IS.FAST.
Asset Store team are blazing fast lately.

 

I'm getting this error sometimes when I'm using ScriptInspector2:
GUI Error: You are pushing more GUIClips than you are popping. Make sure they are balanced)
Unfortunately I can't reproduce it. Fortunately it doesn't break anything. I'm using the latest ScriptInspector2.

Could you add functionality to select the whole row when triple clicking (like in notepad++ and monodevelop etc). I've used to delete rows that way.

Thanks. Great editor.

 

I've seen that too, but I don't have a repro too... I didn't spend time to investigate that yet, and it's pretty low on my todo list since it doesn't do any harm. I think it's related to only some versions of Unity. Thanks for reporting that! It may help to know what is your version of Unity.

Yeah, that should be easy.

Thanks man!

 

Speaking of tiny things...

I have a wacom tablet, which I use as my primary pointing device.

What I'm finding is if I double click a word, I must double click and make sure a lift the pen off of the surface, or SI2 detects the resting pointer as a selection.

Tap (lift) Tap (lift)


Tap (lift) Tap


And - (getting greedy here)

There is not-uncommon functionality when double tapping and dragging to move to whole word select, which is great when selecting larger volumes of text.

(^_^)

Still great, still use it on all my personal projects.

 

Is there auto completion ???
If not, when update?
thanks

 

Ok, I see the problem... You tried to explain this earlier but I didn't get you really, so yeah, I'll fix that.

Great to hear that! It makes me wish to have a "Made with Script Inspector 2" list of Unity projects somewhere, either on my website or just here on these forums, somewhere in the WIP or Showcase threads...

 

No, not yet. I'm still working on that feature... It all depends on availability of my free time, and the last couple of weeks were pretty bad in that. I should have much more time from now on, so I expect to have the initial screenshots next week, followed by a beta version shortly after that to make sure everything works fine before the official release.

 

I have the latest, 4.1.2f1 Pro

 

Ok, thanks! I'll keep an eye on this...

Regarding your triple-click request, I forgot to mention that you can select full lines even now by clicking on the line numbers area and dragging! I know that's not the same but it's very close.

 

Any thoughts so far?

 

Exciting news! More exciting for me than for you guys as this is still only one part of what I'm trying to do, and not enough to complete a new version release yet... For the last two weeks I was working on implementing a new fully blown parser and I had no visible results until now because it had to be completed in order to compile and run. So I just finished that and it not only compiles but it also recognizes the input as structured language strictly defined by grammar rules. It's a generic parser that takes grammars of type LL(1) represented as EBNF which is defined as data structures and then uses those definitions to process the input. It runs in linear time without backtracking which is required for fast processing of the scripts as you type. It can also verify automatically the grammar to make sure it conforms to LL(1) requirements...

You probably know that parser code can easily be generated using some tools like Antlr, Irony, and such, but that approach doesn't work in my case because I want to be able to expand the parser with support for incremental parsing. That's the first reason, and the second is that I'm not only going to parse a single language but at least 3 different scripting languages and also ShaderLab and hopefully CG and GLSL one day, so if I had to adapt all those auto-generated parsers to support incremental parsing that would take ages. Then also integrating all those various parsers in the pipeline may complicate the things even more... So my solution was to implement the parser code once and make it work with different grammars defined as data structures. This makes integration with the rest of the code a much simpler task, once integrated any language for which a grammar is defined will be supported. And defining the grammar is pretty simple when the formal grammar is already existing in some other form... This approach also makes it simple to extend the supported languages in the future to XML, YAML, JSON, SQL, or whatever else you'll wish to have too!

 

Awesome man! Can't wait to see this working!!

 

Hnnngh...stop teasing and get to releasing...

 

Ok sir!

 

But! Don't release a rushed product!

I'm waiting for the next release, but, I'm also content to wait until it works properly.

-

Say, I can't remember if anyone has requested a hotkey lookup for terms in the documentation like they have in MD?