Ok, I make once again a video. 
Rhino WIP today is not working for me… i’ll stick with 8 for this example (it behaves the same as WIP for this matter)
Excuse me for my bad english. Hope you can understand what I say.
@maje90 you’re not alone:
I think there is still work to do in eliminating all those annoying little frictions. Personally, instead of an autoindentation working as I type (appreciated anyway, unless it becomes obnoxious), I prefer easy access to a “format code” (the greyed-out function in the menu) via keyboard shortcut (like CTRL+K CTRL+D in Visual Studio, for example).
Then again, I repeat my plea for implementing the ability to use an external IDE as an option (and no, current plugins, despite being somewhat helpful, just partially fill a void).
That’s not what I’m asking.
How Rhino 7 c# editor works (or any other IDE) is vastly superior.
Why can’t we have what we had? Why doing steps back?
Alessio Erioli mentioned that it was “like Visual Studio,” so I was replying to him.
Sorry for the confusion.
Damn, I wasn’t aware that the old/legacy C# editor got so borked in Rhino 8/9. GhPython has had issues too (one quite severe), but at least the general typing/coding experience is exactly that same as Rhino 7. We’re coming up on five years with the new scripting editors, and they’re arguably still not suitable for production 
It is pretty disappointing that after all these years Rhino/Grasshopper still does not have a solid, reliable script editor.
At this point I’m not sure it will ever really be treated as a priority, probably because only a small percentage of users actually code in C# inside GH. Even more so with the new AI tools… writing code is becoming more and more irrelevant.
Honestly, the most practical workflow might just be to write the code elsewhere and then paste it back into Grasshopper once it’s working.
Another option could be editing an external .cs file and having GH reload it on save. Not ideal, but probably less painful than fighting the internal editor.
Have you tried the WIP? I find it to be excellent for the work I’ve been doing. A massive improvement to Rhino 8. I’ve really enjoyed packaging up c#/py/gh into plugins that can be packaged for yak.
I couldn’t disagree more, AI doesn’t reduce code writing or running, it increases it. And the easier it is to vibe something out, the easier it is to try and edit those samples to make small changes and learn something more applicable to a user. The editor is very important to AI running code in Rhino.
You can disagree but it doesn’t take away the fact…
If improving the editors was not on McNeel’s priority list, much less will it be now with AI… and I don’t blame them.
I actually don’t use the editor at all, I just copy and paste code from AI and if I need a change I tell it to make the change and copy paste again.
No manual editing anymore. Just telling ai what I want.
It’s the future.
Edit: I agree people might start using code inside Rhino more because of AI. But this does not equal more demand for manual editing and thus a good editor. People will just keep copy pasting, like I do.
Can you please tell me what are you talking about?
The c# editor?
I think yes. In rhino 9 wip c# editor is improved. Format is working 
or not (today limited test)
I ll have to test more but I am not yet a rh9 frequent user!
While that might be somewhat true, Rhino 8 added c# scripts.
That feature alone should have been a reason to buy the upgrade… IF the editor was ready for work!
I’ve seen so few cases here of people sharing c# commands… the most obvious conclusion is very few people are using them.
But in my opinion this is survival bias. Nobody is using c# scripts, because the ones trying end up giving up.
Rhino 7 GH c# script editor seems it was made by someone who want to use it.
Rhino 8/WIP c# editor seems made (with nice ideas), to flag a check-list.
I’ve asked many times to devs if they are using themselves the new c# editor for something more than a bunch of rows of code… I never got a reply.
I’m writing every day dozens to hundreds of rows… the new editor is absolutely not even out of beta in my opinion!
I’ve hears other users admitting they stick to 7’s c# editor to quickly test code and later develop plugins even for 8.
Developers years ago offered quick solutions with 7’s c# components … today in comparison there is nothing.
7’s is awesome: compact, clear, useful, complete yet minimal:
8’s editor (which is the same as WIP), after years it doesn’t even have indentation! No types, no descriptions, the UI dies and you have to restart Rhino… but we have that useless list popping everytime disrupting any will to work (why it was spent time to even implement this??)
Any c# editor option change require full Rhino restart to apply.
How can this ^ happening while other devs are trying/testing it?
Either they are not testing it, or the do, but for some reasons refrain themselves to comment the situation.
imo I think it’s more likely if you can use C# fluently, you’re more likely to write a full on plugin, I will usually pick python myself even though I’m much better at C# for scripting because its very well suited to it.
Run the ScriptEditor command and what pops up there.
I’ve written the eto developer docs using the script editor. Python and C#, win/mac, although more heavily on mac. I’ve written hundreds of scripts and created C# projects in it to test this stuff out. Along the way I’ve filed lots of bugs for things that bothered me to help improve it.
I also use it to write integration tests for my projects so I can test the Rhino API’s among other things.
Admittedly not in Grasshopper which this thread seems to have a focus on.
This is not my experience at all, the WIP and 8 are vastly different, a lot of work went into improving scripting in the WIP. I find the WIP much nicer to use than 8 and can feel all that extra work that went in. If you haven’t you should try it out. Not every gripe in this thread is fixed in it, but it’s much faster and nicer to use.
Nope.
I have literally dozens of c# components in each .gh file, each with 50+ to hundreds of rows of code. No class is shared, each component have its own scope and function, and as the project grows, i need to constantly change and do maintenance.
This is absolutely NOT the context for making a plugin, it would make everything 10x slower and practically impossible to work on.
It’s the same editor of c# components in GH. Same problems.
Writing documentation with an IDE? You totally lost me here, no idea what you mean here, sorry, my fault.
Really? How much complex were those?
Sorry to ask this directly, but writing a bunch of lines of code is different to work all day in hundreds of rows of code, with no identation, no description, popups that jumps in front of the code, etc etc… I don’t know your standards, but I see HUGE difference from the 7’s editor and the 8/WIP’s , with the first being vastly superior to work with. You make me doubt we are using the same software.
That’s bad news!
From 7 to 8 backward compatibility was practically lost, considering GH is a programming language, each project written in 7 with c# components was and is a mess to use on 8/9, impossible, the “legacy” editor is a joke as much as the new one… you can only run the code but no longer edit it. backward compatibility lost. I can’t stress enough about this.
Now from 8 to WIP/9 you plan to repeat the same error!?
omg
People like me that learnt c# thanks to the editor being friendly. This didn’t happen in 8 and won’t happen until the editor is not fixed. You lost a “generation” of possible rhino users/developers.
Have you seen my video just above?
This one:
Can you please notice the difference from the 7 editor to the new one?
7’s helps you.
8 bother you with random features and lacks all the strong point 7 have.
@maje90 I do think you should test the WIP editor, it makes no sense to keep talking about 8 if there is a new editor already with some fixes in place. WIP editor will become the new editor with fixes anyways in 9.
1- I paid for 8, I almost never used it because of the problems it has. Problems i reported when it still was in WIP. I want 8 fixed. We were looking at the future and that failed, I don’t want to make the same mistake. I need to use 8. Today. Yesterday. Why push a “feature” if it’s broken and not complete? Why not leave 7 editor in 8? Why create fragmentation and kill backward compatibility without reason?
2- I AM trying WIP, it has the exact same problems. Basic problems. Who knows what are the deep new features!? It fails at the “abc”! I want it to at least try to be as good as the 7 one.
They killed the wonderful 7 c# editor and replaced it with a broken one! Why? No more! The 8 and 9 c# editor must be the same one! Everything about this is so wrong. Killing performance for what reason? Killing backward compatibility for what reason?
I need 8 c# editor fixed. Not now, 3 YEARS ago.
Same exact problems of THREE YEARS AGO!
I get your frustration and I agree with all your points… but 8 won’t be fixed in 8, it will be fixed in 9.
They say WIP is better than 8, so it might be less painful to work in WIP meanwhile.
Fixing takes time…
We had to switch to .NET Core at some point. The older editor was not made for .NET core and also did never worked on Mac.
We are still shipping service releases for Rhino 8 every month with bugfixes so I wouldn’t completely give up. The large scale updates made to the editor won’t be back ported to 8, but we can re-investigate some of the annoyances that Riccardo is pointing out and see if something can be done.
Thanks.
I tried to contact directly who i thought would be the main developer working on this, but I’ve received almost no answers in months.
I’m ready to re-write all over again the various points… this would be like the 7th or 8th time i do so. Is it needed?
Or even a live call or whatever, anytime.