The current behavior of typed input in Rhino is to treat a space as Enter unless the space is in a quoted string. This becomes a problem for people who use the command line and have spaces in names, lengths (4’-1 1/2"). The need to quote the string is not easily discovered.
One solution would be to parse a single space as a space and a double space (tapping the space bar twice).
Pros: Command line users would be able to enter single spaces in the “obvious” way.
Cons:
Existing users who have been tapping the space bar for Enter need to be retrained.
Some new users will wonder why they could not get two spaces by tapping the space bar twice.
I’m bring this up now because I have some length parsing bugs on my V6 bug list. The bug http://mcneel.myjetbrains.com/youtrack/issue/RH-23095 is a good example. One issue that has come up is that string that is displayed on a dimension when feet-inches display or unit names are appended cannot be typed when specifying lengths or coordinates.
What do people think about trying
one space in command line input from the keyboard is treated as a space
two spaces in command line input from the keyboard is treated as Enter
this for Rhino 6?
I do like the idea. Would you be able to special case for when you are outside of a command and when you are inside of a command?
Specifically, I want to type L followed by space and immediately get the line command. When I’m inside the line command, it may be fine to work with double space (can’t tell how programmed my fingers are until I try it.)
I always felt that using a space as “Enter” was awkward. Not sure about using “double space”. I wonder if there is other symbol that can be used. It will be more obvious than a double space, I think.
I suppose that existing macros will also be impacted by this change?
Pros: If at any point we’re going to start accepting mathematical expressions in the command line, being able to use spaces with impunity would be vital. I very much want to be able to specify the width of a rectangle as 2050 - (2 * 18), and it just comes naturally to type spaces in expressions.
Cons: It will break every single RhinoScript and plugin which pumps text to the command line in order to run commands. Unless we treat strings that are passed in via RhinoApp()->RunScript() differently…
I use space much more often than enter typing on the command line. Its an unconscious habit and very convenient to me anyway. I don’t know how frustrating it might be to unlearn that. I agree that outside a command treating one space as terminator would be helpful.
Seems like for typing feet-inch dimensions, any use of a minus sign including as a delimiter between inch and fraction of an inch is confusing, meaning that its not compatible with describing subtraction arithmetic.
Is the difference between what you type on the command line and what is printed on a dimension a real problem? I don’t know of more than a very few complaints about it over the years.
I think this is going to be a major change to get used to, but I am also interested in trying it. I think it will be easier to get used to if the switch is to always hitting space twice.
I think having single-space start commands, as in "L " will be disorienting and frustrating. It means that:
"L " == line
"L B " == line both sides
Does that mean that:
"L " == line / cancel (like current behavior)
or
"L " == line / cancel
If I want to repeat a command, is it “” or “”?
It seems like having to remember would actually produce more cognitive load than always requiring me to hit space twice, making the learning process of double-space even harder.
The original complaint was about BoxEdit command. With units set to feet & inches it shows distances like 4’-2" in the edit boxes, but does not understand them when parsing. 4’-2" gets parsed into 4’-0" which is just plain wrong. As if formatting and parsing do not speak the same language.
As for Space, I vote for not changing it. Or at least make it context sensitive somehow. Like … IF the units are set to feet & inches, and IF the user has typed numbers without a decimal point optionally followed by ', THEN treat space as space and not enter.
I also use spacebar to fire off aliases- left hand on the keyboard, Letter>Spacebar = done. I suppose it’s possible to retrain but if you use a lot of aliases and it now needs two spacebars, or a reach over to Enter (much less convenient, for me at least) , this feels like it is likely to be a net loss in efficiency, even assuming I am trainable. But, I am certainly up for trying it, who knows, it might work OK.
I like the idea of making spaces ‘context-aware’ so that the current behavior as Enter does not need to change much, if at all.
Based on the three “accepted” rules, I think 1’-1-1/2" should be parsed as 13.5 inches. Lowell (and Jerry Hambly and probably other old-time ACAD users) felt it should be parsed as 12 - 1.5 = 10.5 inches. I want to resolve this issue.
The screen and printed display of 1foot+1.5inches = 1’1 1/2". If users expect to be able to type 4’-2" and part of the justification is that is what they see on the screen, I think it is reasonable to expect to be able to type 1’-1 1/2" because that they see on the screen.
I like your idea of simply making the space context sensitive. Since 1’1 is not a valid length, I could detect and allow
That leaves the issue of deciding what value to assign to
1'-1-1/2"
options include
13.5inches and stop parsing after the double quote
10.5inches and stop parsing after the double quote
12inches and stop parsing after the single quote
other ?
What option do you think makes the most sense (other than having the US use the metric system - we don’t want Liberia and Myanmar to feel lonely)?
…AutoCAD CAL command line calculator works the way you expect, it parses 1’-1-1/2" as 13.5 inches.
There’s even a warning and explanation to address the very issue of having minus symbol mean plus or minus with imperial units.
I missed / forgot the information in the link and have been wasting your time. This discussion did result in me realizing and can detect and accept a space when correctly embedded between feet and inches so what-you-see-in-display of dimensions can be typed as a length and not break any useful behavior.
I will make the Rhino parser work like the description in link and mark the bug fixed.