Externally triggered prompt redraw or write above the prompt

[flxo]

Hi,

I really struggled with the title for this issue - so let me describe what I need:

I want to write a console application that provide s some kind of command line that is always present at the bottom of the terminal. The text above this is updated from events happening somewhere else and have no influence on the prompt.

abc
def
>> asdf

abc
def
ghi
>> asdf

Currently the readline blocks and I haven't found a way to kind of interrupt that and print some lines and resume the input operation. Is that possible with rustyline?

I got this working with linefeed that allows to clone a handle to the prompter that implements write and internally synchronises writing to stdout. A example is here.

For sure this topics gets complicated when it comes to paged display of the history etc...
Did this topic already raise in the past and if yes - what's the conclusion?

Thanks,

flxo

[gwenn]

I don't know how to do this!
I should investigate how python-prompt-toolkit or linefeed do this.
I will look at your example.

[gwenn]

See similar topics:

• Moving the cursor wipes out next lines #48
• Integration with termion (or any other terminal abstraction) #199
• Add an async interface #126

Async/non-blocking input but sync/coherent output.

[neonphog]

+1 I need this too. Looks like https://github.com/Dhole/rustylinez is trying to add this functionality, but didn't compile for me

[gwenn]

Just for reference:

• haskeline getExternalPrint
• python prompt toolkit patch_stdout (example)
• replxx print (example)
• linefeed write_fmt (example)

I am not sure but I guess we should give priority to user input for example while doing completion/listing completion candidates.

[gwenn]

Could you please give #235 a try ?

[flxo]

@gwenn Thanks. I will try that!

[gwenn]

Should work on windows now.
Only tested with:

$ wineconsole --backend=curses target/x86_64-pc-windows-gnu/debug/examples/external_print.exe

[tailhook]

I've just got a very similar issue: I want asynchronous completion. I don't think that waiting on <tab> for too long makes sense as well as putting completion in front of the user if they already don't expect it.

So what I think I'm going to do is:

1. Wait 100ms in completion handler, if it's not ready put -- loading completions to the hint
2. Fetch completions in background
3. Change the hint to -- completions loaded (user can now press tab and that will work)

The problem is to update hint on (3). While #235 helps there if I also print a line into the external printer that line will bother users.

We can probably apply #235 which sets up some async infrastructure, and then add another pipe to signal refresh.

Alternatively, we can introduce some simple signal to refresh instead of #235, and use that as a basis for the external printer.

[vi]

Are there any updates on async and/or printing while readlining?

[JanBeh]

Are there any updates on async and/or printing while readlining?

In the master branch, there has been support added for printing while reading, see example.

On my terminal, this appears to be buggy yet, so I filed a bug report.

A longer thread on URLO: Text-mode (terminal) application with asynchronous input/output.

[gwenn]

Version 10.0.0 released.