It doesn’t seem useful at least based on this screenshot. We should see if we can improve it
I set more appropriate defaults for “word-based” and “in function signature” autocompletion. They are both disabled by default in Rhino 8.9 SRC.
Persistent options added to the Language Options for change in behaviour:
Temporary toggles added to the Edit menu for changing behaviour:
Here is completing s.Extend:
For Reference:
RH-82473
4 Likes
Awesome! Thank you!
Can’t wait to test it.
I also brought these to the top of the list to fix/implement in 8.9. They are all marked as Stop-Ship so I will make sure they’re fixed before we release.
RH-81189 Script Editor Autocompletes In Comments
RH-77879 C# can not autocomplete ScriptInstance properties and their members
RH-81585 private members of Script_Instance are not in the editor so there is no autocompletion for them.
2 Likes
I ran my performance tests and noticed a drop. I logged this here for 8.9 and Stop-Ship:
RH-82474 New IronPython is much slower than legacy GHPython
Currently I do not have my performance tests in the list of automated tests since measuring that is a little complicated. I rely on manually running these and seems like I have missed a few runs.
1 Like
It still seems like it could be improved further.
m. should provide autocomplete, but the other case where you are just typing you shouldn’t get autocomplete until you at least type a character or possibly two. In other words, don’t add autocomplete suggestions if no characters have been entered yet.
int my_descriptive_variable_name = 10;
int x = Function(10, m
at the point of typing m, my_descriptive_variable_name should be provided as an autocomplete option.
I think suggestions / autocomplete / “IntelliSense” need some improvements.
This simple example shows already a few points:
- in general I think autocomplete should always drop down, never drop upwards. As a user I want to read what is written above, as my currently written line might depend on stuff from above.
- autocomplete should not suggest a brutal, senseless, endless, everything-in-collection. I would prefer to have some stuff missing but a well chosen collection offer a higher hit rate with the first 3 to 5 items. I don t want to see “AccessViolationException” all the time. Regarding the UI feeling, currently the drop-down list distracts a lot.
- I would love to see the signature / parameters of a function, even if I put the cursor inside the brackets a second time. the screenshot shows a simple scenario - if the user does not know, that
Intersection.LineLineneeds 2 double “out-parameters” - definingdouble tA,tBafter partially writting Line 40 - going back inside the brackets of the Function should show the the parameters again.
just a random drop-upwards - that happen often without clearly knowing why it is suddenly upward - instead of always drop down…
thanks for further improvements - kind regards -tom
2 Likes
A whitespace character has always been a trigger character for our autocompletion. (like visual studio and visual studio code). The window opens after a space:
and after you type the letter ‘m’:
continuing with ‘my’
That example was from visual studio. Our editor works the exact same way:
My argument has been not to get rid of that first window that appears after typing a space but to improve it. To come up with a sorting that follows some rules (1st-from local script, 2nd-RhinoCommon, 3rd-RestOfDotNet ?) that we’ve determined so the items that you’re most likely to choose will be at the top of the list.
Let’s say you’re linking to a new library that you don’t know well and you don’t have any idea what to call. Wouldn’t you want a list after you type a space? like so?
Having
AccessViolationException at the top of the list is probably the worst choice but the list itself, even though I can’t imagine ever doing anything with AccessViolationException, is what the compiler has deemed possible to call.So I think we should fix the sorting of the list and not get rid of it.
But if you really don’t want to see the list after typing a space, it’ll require a bit of retooling, but I will do that.
Thanks for the feedback Tom.
We are working on improving these points.
In the next build, typing a comma will reopen the signature help window (or typing shift+cmd+space) but I’m looking into more improvement options.
3 Likes
IF the “price” of having that list as a dropdown is to have the description of current method “dropup”, then the price is too high, it is not worth.
If no other ways are possible, I’ll gladly lose the suggestions list over having a more reliable presence of current method description.
Also, indeed too many elements in that list, but also the list is too long on-screen (12);
See how compact was the old editor:
the dropdown list appears while the method description is active, just 8 elements. Both are beneath the cursor, never above!
And it actually even displayed the description of a property of an object, something lost in current editor. Not needed, but old editor even did this, in a way that never bothered me: far to the right, almost never covering stuff i need to see.
My code editor windows usually are not very big, so having too many stuff covering your code is not good.
(Usually I have Rhino full screen and Grasshopper half screen. Easily the code editor is smaller than half screen, because you want to see part of grasshopper inputs/outputs and seeing the 3d geometry helps while studying your algorithm …)
So, please use the space in a wiser way.
Corrent editor:
that “dictionary” list is too much wide, and because it cannot go outside the window to the right, it is pushed to the left, un-aligning with the cursor (and also hiding completely beneath rows)
Edit: yeah, having that list including virtually everything, at least one element in the list will be extremely long (with many characters) and will force the whole dropdown list to be very large.
This is DUMB.
Have the dropdown list to never appear until the user typed at least 1/2 characters, filter the list with those, limit it to 8-ish rows on screen, and it will probably be very similar to the good old one.
You can resize it, but it will not remember on Rhino close, and that information is not shared cross-component. Any c# script will have its own temp sizes.
Having the element + the element class type in the same row result in too little space.
If the suggestion and/or the class type end up trimmed with a “…” the UI failed.
Never happened in old editor. Never seen “…” as far as I remember.
Old editor had the 2 things in separate small popup windows and it was excellent.
Solving the “we canno’t go outside current code window with child windows” could be handy for all of this.
1 Like
My guess is if our autocomplete algorithm returns more than 20 results it isn’t worth showing
Compact dropdown list.
Can go outside code window.
Show the description of that element.
If you ever plan to show again this kind of descriptions, current UI needs to have popup windows that can exit the parent code editor window.
only a subset of what is returned is shown.
show documentation is here
Sure, but if the entire set is a large number then we know we aren’t anywhere close to a match.
1 Like
The match is in the order. The most common things are immediately seen and the less common ones are in the list and will be shown once the user continues typing.
So far I haven’t seen or heard of any performance problems with the size of the list so then why is this a problem?
If a user wants this:
it’ll be in the list. Maybe at the top depending on how we define our rules or maybe not.
Users may want something like System.Uri for all we know, which could be somewhere in the list:
to maybe do:
In the previous example you could say that we need to fetch a new completion list from Rhino when the user types a ‘U’ but that would require redesigning how things work. And of course this could be necessary if there was a problem with performance with our current approach but there doesn’t seem to be a performance problem with the current list sizes.
That’s why I don’t see why we’d limit the list to 20. We can put a limit but I think it should be much higher.
1 Like
I’m not referring to performance issues. If a list of results is huge, it probably means we don’t have an inkling of confidence on what the suggestion should be. In this case it seems worse to show any list at all. This is only an idea of how to improve the feel for the system. It may be a completely foolish idea.
This didn’t make it to the 8.9 SRC today but will be in next weeks. Python 3 and C# components now autocomplete ScriptInstance members. IronPython is lagging behind since it doesn’t really have a language server like the other two.
3 Likes
Is this also the right topic for Script Editor - Design Feedback within Rhino and not Grasshopper?
I am missing a button and short cut to run a python script without debug mode. In the new editor I always have to delete all break points to be able to run the python script. All IDE’s I am using have the option to do so, even the old Rhino Editor had it. Is it possible to add this feature?