repl: uncomplete expression shouldn't be autocompleted.

[ZYSzys]

• Version: v14.4.0, maybe master
• Platform: macOS
• Subsystem: repl

What steps will reproduce the bug?

In repl:

> proc // then press `enter` key

How often does it reproduce? Is there a required condition?

Every time.

What is the expected behavior?

Throw Uncaught ReferenceError: proc is not defined.

What do you see instead?

Print the entire process object.

Additional information

This bug was introduced in recent release.

Maybe /cc @BridgeAR

[BridgeAR]

This is actually a feature. It was originally already planned to implement it like this but it required further thought and work and that is implemented now.

[BridgeAR]

It is possible to prevent this by pressing <ESC>. Do you have a case where it's not helpful to use the auto completed value?

[ZYSzys]

Print the entire process object.

I think it's more reasonable to autocomplete the input when press enter key(such as in Chrome devtool's console), but it shouldn't print the entire object directly right ?

[devsnek]

this is the behaviour I hate the most in browser devtools. I'm strongly in favour of removing it.

[BridgeAR]

I think it's more reasonable to autocomplete the input when press enter key

I actively decided to implement it like this due to the different UI. It is possible to move to the right or to press tab to auto complete the line.

this is the behaviour I hate the most in browser devtools

Which behavior? The feature to preview the auto completed input in general? Just the part about pressing enter uses the auto completed line? Something else?

[devsnek]

@BridgeAR how it automatically completes the input when you hit enter. if i wanted the completed input i would press tab and then enter.

[BridgeAR]

@devsnek the preview itself also uses the auto completed value. It would be confusing if pressing enter would result in an error in case the preview says something else.

[devsnek]

@BridgeAR I think it would be fine if the preview didn't autocomplete as well.

[BridgeAR]

I guess we could make it optional. I implemented it, since I was explicitly asked to do so.

[benjamingr]

For what it's worth what @devsnek is describing is the behavior in idle and the default Python repl (in Python).

[yseymour]

I want to +1 on this as a bug and not a feature, I actually trip over it quite often and find it quite irritating.

Consider:

> foobar = { get() { return { foo: 123 } } }

Now try to type:

> foobar.get().foo

The REPL always completes foo to foobar, even though that is incorrect. The behaviour of pressing Esc to cancel the completion is also unintuitive (it doesn't have any visual effect either until Enter is pressed).

I would prefer to have no completion at all until Tab is pressed, like other REPL environments. Alternatively, if the completion was less eager and didn't suggest foobar in my above example, that would be OK too.

[y21]

It's even worse when using functions that ignore V8 interrupts such as the BigInt constructor, since that can completely lock up the process without pressing enter, e.g. just typing BigInt('1'.repeat(1e8)) into the repl blocks it because it can't be properly terminated. The BigInt case was fixed in a recent V8 commit, but there's still a lot of other similar functions that can't be terminated by embedders either (e.g. typing Math.max(...Array(1e3).fill('1'.repeat(0x1ff00000))); blocks it for some time as well...).

[zhanzhenzhen]

Use case:
When I want to test if a variable is declared, or if a property has a value. For example, setTime or global.setTime.
Expected:
setTime -> Uncaught ReferenceError: setTime is not defined
global.setTime -> undefined
Actual:
setTime -> [Function: setTimeout]
global.setTime -> [Function: setTimeout]

But, the thing is not whether it's helpful or not. The thing is that it violates the rule that "what you type is what you get". Why we have to look at the screen when typing? We just look at the screen for the output after pressing Enter.

this is the behaviour I hate the most in browser devtools. I'm strongly in favour of removing it.

Me too. All "smart" features bring uncertainties. What surprises me is that most developers also like these uncertainties (at least while typing).