REPL aggressively uses wrong autocomplete on ENTER

[spazmodius]

Version

v16.13.0

Platform

Microsoft Windows NT 10.0.19044.0 x64

Subsystem

repl

What steps will reproduce the bug?

When typing into the REPL, autocomplete often predicts identifiers or keywords even when the typed characters are valid. When I hit ENTER (no TAB to accept), then the REPL chooses to use its prediction rather than what I actually typed.

For example, typing

then hitting ENTER

It's infuriating.

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

Always

What is the expected behavior?

I expect to be able to hit TAB to accept the prediction. If I continue to type something else then autocomplete should revise its prediction. If I hit enter, autocomplete should realize its services are no longer needed.

What do you see instead?

> var add = x => y => x+y

followed by ENTER results in

> var add = x => y => x+yield
...

Additional information

No response

[benjamingr]

I am able to reproduce this in both v16 latest and master. I think the ask here is reasonable and this isn't really a hard fix but I'm not sure if it's intentional.

@nodejs/repl @BridgeAR wdyt?

[benjamingr]

@meixg since you committed there in the past and it doesn't look like a hard fix, want to take a look at this too?

[meixg]

@meixg since you committed there in the past and it doesn't look like a hard fix, want to take a look at this too?

Yes, with pleasure :)

[meixg]

I made a PR may fix this: #42053

---

But there may be two more things we can improve:

1. The preview of var add = x => y => x+y should be just y, not yield . The problem here is that we currently implement autocomplete based on regular expressions, so the context information in var add = x => y => x+y is lost. Maybe we should use a parser repl: #41690 REPL gives wrong autocomplete on literals #41883 (comment).
2. There is a 500ms delay after pressing ESCAPE: https://github.com/nodejs/node/blob/master/lib/internal/readline/emitKeypressEvents.js#L67, if we press another key after ESCAPE within 500ms, the ESCAPE will be ignored.
   Visual feedback (PR above) can help a lot, but I wonder if we can find a way to remove this delay completely.

[spazmodius]

Thanks for working on this, @meixg . But I want to clarify that the issue I raise here is not related to "preview" (the advance evaluation of the line I'm still typing), but rather "autocomplete", particularly preferring it's own suggestion without confirmation from me.

I like autocomplete, when it doesn't get in my way.

Preview, however, is... uncompelling.

[meixg]

Thanks for working on this, @meixg . But I want to clarify that the issue I raise here is not related to "preview" (the advance evaluation of the line I'm still typing), but rather "autocomplete", particularly preferring it's own suggestion without confirmation from me.

I like autocomplete, when it doesn't get in my way.

Preview, however, is... uncompelling.

I know what you mean, see 80913e6, when you press ENTER, is actually the 'preview' part that is used.

With the PR above, it will behave more like the Chrome DevTools console.

[spazmodius]

I agree Chrome Devtools has a good usability model to emulate. I'll give this observation, then leave it in your capable hands:

In Devtools, when I'm at the point of having an outstanding suggestion, my first ENTER accepts the suggestion, and a second ENTER submits the line. In Node REPL, a single ENTER does both of these.

[meixg]

I agree Chrome Devtools has a good usability model to emulate. I'll give this observation, then leave it in your capable hands:

In Devtools, when I'm at the point of having an outstanding suggestion, my first ENTER accepts the suggestion, and a second ENTER submits the line. In Node REPL, a single ENTER does both of these.

Yeah, there is a different behavior too, I can try to improve that.