Thanks for testing. This below is in 8.7RC.
Hi all.
I’m back! 
Rhino 8.7.24107.13001, 2024-04-16.
Strictly talking about the new c# code editor, of the c# component.
(but I guess is the same for the new Rhino c# “scripts”?)
Strictly talking about the difference and worsening of the current Rhino 8 c# code editor compared to the old c# code editor for c# scripts in grasshopper in Rhino 7.
Probably more, but after attempting again a “one-liner” script and still seeing all of this, I stopped here.
I’ve never developed any plugin, but I can say I’ve achieved decent results using c# scripts in Gh, in R7. I’ve LEARNT c# thanks to c# scripts!
Rhino aims to be a “platform” for developers, rhinocommon etc… right?
Now we can even code directly in c# to make “c# scripts” in Rhino 8!
This matter should really be important. Developers can attempt quick and simple tests, if code editor is good. Or even attract not-developers into diving into this world (like me).
But, this code editor is still not good!
I’d like to try new “Rhino” tab in grasshopper, even if I see some bugs are reported sometime.
But I rely too much on c# scripts in my .gh definitions to “survive” in Rhino 8!
What’s worse: if Rh7 .gh files are opened by Rh8 grasshopper, the c# components works, but the pseudo-editor is completely unusable for any edits of code! Was this made by purpose? Bad idea!
It would be just perfect if you just let users use THE. OLD. EDITOR.
Instead, because it is not, I just drop Rhino 8 completely and, willingly or not, I have to tell all my other colleagues and clients that I’m not using 8 at all. We are all still with 7.
Instead helping to code, it is creating more problems and bothering the user!
This is obviously just my opinion.
As time pass, the improvements are few, and many bug I’ve reported months ago are still there, I have no more ideas of what to do, to report, to ask… So I’ll try echoing my feedback by asking the opinion of some others that I know to code in c# directly in gh:
@eirannejad @Alain @DavidRutten @stevebaer @DanielPiker @laurent_delrieu @PeterFotiadis @gankeyu @Michael_Pryor @TomTom @Petras_Vestartas @Mahdiyar
Are you using the new c# editor in Rhino 8?
What are your opinions about it, compared to the 7 one?
Feel free to tell me I’m the stupid one, if it is so.
Thanks for your time. Sorry for the textwall.
Well … as far I’m concerned … I use (quite rarely) R5 thus I have no idea about the new things. That said the days of the R/GH combo are numbered since I switch 100% towards CATIA/AECOSim/Generative Components.
Hi. We do appreciate the feedback. I’ll address some of these points.
5, 6, & 7 - private members of Script_Instance are not in the editor so there is no autocompletion for them RH-81585
8, 9, 10 - For what it’s worth, the way that the signature help and completions windows show up is very similar to how they do in vscode. The signature help window is usually above to make space for completions window which is usually below. I can understand why most users would prefer that the windows shows up below the line. vscode users complain about it too.
Create an option for the signature help to show up below the line if possible RH-81584
“Please let the floating tooltips go outside the current code editor window, without shrinking them.”
Unfortunabely this is not possible: same limitation as vscode.
11 - it’s normal that the arrow keys cycle thourgh the completion window at this point. You can still cycle through the method signature help window with the alt/option + up/down arrow. The completion list is not useless. We can try to improve it instead of getting rid of it.
12 - The signature help window can be reopened with shift + cmd/control + space. Close it with the escape key.
13 - completion suggestions for this. is not always correct RH-81587
I think (hope) the key bindings help in managing these windows but they don’t work properly on all keyboard layouts. We need to document these better. Summary:
ctrl/cmd + space, close: escapeshift + ctrl/cmd + space, close: escapeup/down arrowalt/option + up/down arrowI think having to remember “cheat codes” with shift/ctrl/alt keys is a failure in the UI.
Please, look again how good Rhino 7 c# code editor works: that should be your target.
What about points 1-4? Particularly point 3!
9 - “Unfortunabely this is not possible: same limitation as vscode.” It’s 2024. Make it possible please.
This ^ is a “Sorry we forgot to assemble the wheels of your car, so we put them in your backseat instead”
It is absolutely normal to code up-down and reaching the bottom of the code editor window while coding. Indeed, my current row of code is 99% of the times the bottom one, near the window border. This should not be an unexpected scenario.
Showing the popup tooltip dropUP means the coder will mostly see only the bottom code row all the time. (unless he constatly add white spaces benheat and scroll mid-way to let the popup accomodate… TOO TRICKY!
If it is not possible to go outside the window, then call again the developer of Rhino 7 code editor and ask him how he did so.
Sorry to be salty, but this is what I think. Is this another limitation of ETO?
14 - Chained methods:
Instead, give it full-priority to ALWAYS display the currently-being-compiled method description to show up. all. the. times. Do not make the UI “forget” about it. Close it only if the user press escape key.
15 - I thought, “Maybe devs expect the code editor is always big-enough that it will let tooltips show up without touching the windows borders?” so I made a very big code editor window, but after I lost focus once and went back to rhino:
Wouldn’t it be a easier and quicker solution to just re-use the old editor?
Apart from some method description messed up sometime, it was A+ perfect compared to this.
The old editor was a dead end and we can’t use it for reasons I’m not going to get into.
Even though in some ways it doesn’t look like it yet this editor is more flexible and has way more potential.
We are aware of points 1-4 but appreciate you pointing them out.
Code editor preferences are very personal so even after we fix these problems not everyone will be pleased.
For that reason we will try to make it configurable when practical.
If you don’t like to see completion suggestions while the signature help is open we’ll provide an option to turn it off. RH-81607
But by default we’ll improve the content of that list instead of getting rid of it.
About having the completion window extend beyond the borders of the main window, I regret saying “not possible” because we can find other ways (RH-80471) to solve the problem for those who can’t live with that.
Even though the technology we are using (same as vscode) gives us great flexibility, one limitation is that everything has to be drawn within the borders of the main window. That limitation has nothing to do with ETO.
point 14: RH-81591
Thanks.
point 15: Yes, we do expect most users to have the editor window be large enough. If that’s a bad assumption we want to hear about it. The problem you’re reporting: RH-81605
We appreciate your feedback and take your frustrations seriously. I assure you that we are working hard on these problems.
xbim测试.gh (13.0 KB)
Package management is a feature that I think is very handy in the new version of the script editor, but in version 8.7, there still seem to be some minor problems with the installation of nuget packages, and here is the buggy package Xbim.Essentials 6.0.445
See this ticket please. I’ll prioritize and will get it fixed:
RH-78722 NuGet package processor does not include dlls from package dependencies in the build
Some of these NuGet packages are basically empty shells with a bunch of dependencies, to easily reference multiple packages at once. A current workaround is to reference the dependencies explicitly in your code (NuGet Gallery | Xbim.Essentials 6.0.445)
Hello 
I have a couple of questions about file handling within the new editor.
File>SaveAs? I’m able to SaveAs from the (Ctrl+Shift+P) Command Palette.It’s very useful if you’re editing a file from a repository in another IDE and would like to take advantage of the Script Editor’s file watching capabilities. LoadFrom was also a nice feature from the legacy editor that would be great to have in this new editor as well.
import pathlib
print(pathlib.Path(__file__).parent.absolute())
C:\ProgramData\McNeel\Rhinoceros\7.0\Plug-ins\rhinocode:\grasshopper\1\af8c3421-4519-4076-9711-2a9d623c552cThanks!
@bfrederick Your example is from a script that is embedded inside a Grasshopper component and not a file so:
SaveAs doesn’t really mean anything since it would have to create a new script component. The component right-click menu has Export Script if you just want to save the script to a file. I can add this to the save menu as well.
RH-81628 Add SaveAs/ExportScript To Grasshopper component save menu
Script is embedded in a Grasshopper component and not a external file so __file__ contains and internal path to Grasshopper that points to this component
Thank you for considering the Export Script feature.
I would say something is definitely happening when I SaveAs then use Ctrl+S in VSCode because as you can see it will update in the Grasshopper component (sometimes it doesn’t work as shown at 0:18):
Oh! I see. This sounds like a bug! I’ll look into it. The scripts should not be connected!
RH-81629 Exported script overrides GH component storage
@bfrederick Thanks for finding and reporting this. Such a weird bug. I pushed a fix for next 8.7 build
@eirannejad I have a problem with ScripEditor exploding somewhere into outer space. Is there a way to force it back near the component/view?
If I select the ScriptEditor window from Windows taskbar, I cannot move it using Win+arrows or anything. I have no idea how to get it back to where it’s supposed to be.
I’m running Rhino (8.7.24101.10001, 2024-04-10)
@TuomasLehtonen Is this repeatable? Would you be able to give me steps to repeat the bug?
I did try a bunch of stuff, but here’s the short-version:
Copying the script component to a new GH file does not help
But if I copy it to a new GH canvas using Ctrl+Shift+V (to place it where the focus is) I can fix it. The screenshot below shows the positions on the canvas where it works and where it doesn’t. It even seems to get exponentially worse when going towards the lower right corner.
Based on this, it seems like the placement of the window is dependent on the position of the component on the Canvas and somehow it goes haywire.
And actually to add on top of that: just moving the component to a new (more top-left) position on the Canvas does not help. It has to be Ctrl+Shift+V’ed there.
I don’t know where this problem actually originated from, but I was having old legacy C#-components copied from Rhino 7 Grasshopper to Rhino 8 GH. So maybe it has something to do with that, because I have never experienced this before.
@TuomasLehtonen This has come up before and I put a fix for in in 8.7. Would you mind trying the latest 8.7 RC (8.7.24128.07001) to see if this is still repeatable?
Please see this. Hard to see the selection in this situation.
See my reply:
Hi @eirannejad, apologies for not reporting the issues I had promised (e.g. syntax highlighting issues). I have not really had time for further testing lately, but hopefully I will soon. This topic has, understandably, snowballed quite a bit outside the original intention, which was to provide feedback on the visual design of the script editor (e.g. its structure, layout, menus, elements, styling, fonts) and not so much its performance and functionality. So I thought I’d just quickly recap the design issues I’ve reported that appear not to be YouTracked, are still open, or have been closed but where the issue still persists:
4: Syntax Highlighting (my primary reason for not using the new editor)
5: Duplicate Highlighting
6: Font Sizing Using Mouse Wheel (+ Terminal)
7: Simpler Unified Icons (super low priority)
8: Superfluous Layout Elements (mostly resolved)
9: Slow Printing to Console (not design issue, but another primary showstopper for me)
10: Missing Font Variations
11: Border and Background Width/Color
12: Top Menu Structure and Verbosity (especially Window having Toggle start all items)
13: Grasshopper Menu Point Placement (this one really bothers me for some reason 
)
14: Top and Bottom Bar Information
I don’t know if you can comment on the roadmap for the editor or any of these items individually? Also, if we should start new topics when reporting issues, suggestions etc.?
