This scenario is very similar to the InvokePrompt scenario where somebody explicitly wants to call their prompt function to update some status or whatever - and after that, the cursor may have moved.

In the InvokePrompt scenario, we render the entire command line (all lines) because either the cursor moved or we erased the previous prompt.

I think this scenario is equivalent, and if I'm correct, I think the code from InvokePrompt should be extracted into a function so it can be shared.

The code in question is:

            _singleton._initialX = console.CursorLeft;
            _singleton._initialY = console.CursorTop;
            _singleton._previousRender = _initialPrevRender;

            _singleton.Render();

@lzybkr Yes this scenario is very similar to the InvokePrompt. Both may change the cursor position. And for the tab Completion case, if a user do get<tab>, the cursor is expected to set back to right after get, right? This means _initialX has no change. If we update _singleton._initialX = console.CursorLeft, we get getGet back.

Agreed, _initialX shouldn't change in your scenario, so now I'm just wondering if you might need the other 2 lines to render properly.

Can you test all the ways GetCompletions is called - I can think of 4 - Complete, TabCompleteNext, PossibleCompletions, and MenuComplete. I would test all of those with the completion on the first line, and again with the completion on a second line (multi-line input), and also where the completion is near the end of the line.

If the display is fine in all of those scenarios without calling Render (in other words, exactly how the code is now), then we can call it good.

Thanks. The multi-line case does not work. It becomes something like this. Any advices?

Updated the code and tested on Windows and Linux with the following cases:
Complete, PossibleCompletions, MenuComplete, TabCompletNext, multipleline such as start-job{..}, close to end of the line. Works as expected now.