multiline-input

[mirek190]

I'm testing newest build.
I have a stupid question as I added --multiline-input as parameter .
How to end of my input now?
Pressing enter just invoking a new line.

Also without that parameter I can invoke answer but arrows up and down are not working so I can not see my history questions.
Arrows left and right also not working so I can not correct my spelling mistakes .

All those things were working fine earlier.

[DannyDaemonic]

The directions will change depending on if you use --multiline-input or not.

Without it:

== Running in interactive mode. ==
 - Press Ctrl+C to interject at any time.
 - Press Return to return control to LLaMa.
 - To return control without starting a new line, end your input with '/'.
 - If you want to submit another line, end your input with '\'.

With it on

== Running in interactive mode. ==
 - Press Ctrl+C to interject at any time.
 - To return control to LLaMa, end your input with '\'.
 - To return control without starting a new line, end your input with '/'.

So if you are on --multiline-mode, you should be able to end your input with \ to return control:

This is what it would look like\

Also without that parameter I can invoke answer but arrows up and down are not working so I can not see my history questions.
Arrows left and right also not working so I can not correct my spelling mistakes .

What platform are you on?

[mirek190]

Windows

Tested with CMD and Power shell .

[DannyDaemonic]

Ah, this is a feature of Window Terminal I wasn't aware of (and isn't tied to either the Command Prompt or PowerShell directly). The arrow keys I can fix. The history is a bit harder. Do you use the history feature?

[mirek190]

Of course I use the history why I wouldn't?
Do you not use a history of your inputs by up / down arrows?
Earlier arrows up /down were works perfectly.

In terninal , cmd or power shell is a very important feature. :)

[DannyDaemonic]

I use the history feature on the shell, it is very useful there, but I've never seen it used inside a program before.

[mirek190]

Your newest fix master-e6a46b0 not helped at all. :-/
Anything changed.

[DannyDaemonic]

No, nothing has changed. You can use f9a6364 in the meantime.

[mirek190]

I tested when that happened.
After this commit :

master-41654ef
Interface improvements and --multiline-input (previously `--author-…

…mode`) (#1040)

• Interface improvements
• Multiline input
• Track character width
• Works with all characters and control codes + Windows console fixes

[DannyDaemonic]

Yes, thank you. f9a6364 is the one right before 41654ef. So that's the latest one without the arrow keys. You can use that one in the meantime if you want the arrow keys. I'll drop an update here once the arrow keys are working.

This was a feature specific to Windows Terminal (I believe Windows 11) only. When I add the arrows back in, it will work for everyone, but it could take a day or so with everything else that's going on right now.

[maddes8cht]

Regarding multiline input:

Can't we simply use Shift-Return for having a new line without sending control back to Llama?
This would be kind of standard behaviour.
Doing shift-return to submit a new line without submitting a command is pretty common.
It works that way in the ChatGPT Web interface and it's easy discoverable if you are familiar with keyboard standards.
I think it's the best way to handle multiline input.

[DannyDaemonic]

@maddes8cht I would love to make it use Shift-Enter! It seems in a terminal/console, Enter comes across as \n whether or not you're holding shift. There might be some hacks we could use to accomplish this but we'd probably have to implement it separately on Windows, macOS, and Windows. I'll have to think on it and see if I can come up with something, but don't hold your breath.

For what it's worth, \ is fairly typical in terminal/console apps.

[maddes8cht]

I know basic c/c++, and the main.cpp doesn't look really complicated at first sight (except for the fact that everything is in a rather unstructured queue). However, I find it surprisingly difficult (but I haven't tried too hard) to find the place where the distinction of multiline input is processed, and finally the input of enter should be processed somewhere there as well.

So I ask myself why it doesn't boil down to a simple query of the last two values. If at the end there is a combination of 0/13 or 224/13, then it was shift enter, if it is an alphanum and 13, then it was enter.
Am I seeing this wrong, or is there a reason why this cannot be implemented in the existing main.cpp?

[patrakov]

I think that we need a better UI than ending the line with a \, because this makes discussions of multi-line C macros impossible. Strawman proposal: double- or even triple-Enter, unless inside a MarkDown block.

[DannyDaemonic]

@patrakov Finding two \n in a row is also extremely common in code. Even in this project it happens in every source file. Three is probably safer, but it's also somewhat common. Three does seem a bit much.

Also, I'm not saying it's the best solution, but it's not impossible to input C macros; you can just add a space to the end of any line that would otherwise end with \ (or depending on the mode, end with \\). If you're using --color it will light up to let you know it's about to do something, which might be enough of a reminder to append an extra space?

The \ symbol was already used before --multi-line input, so that's why I kept that character. Perhaps there's a less common character we could use for multi-line mode. I'd say we could let you pass in the character, but there's already so many command line switches that I'd hate to add another for something niche sounding. If that's something you think would be useful, you could open a feature request and if there some interest there I would be happy to implement such a feature.

I know people have asked about Shift-Enter but in a terminal environment, the terminal typically only sends the sequences of characters you type back to your program, not raw key presses. So Shift-Enter looks the same as just Enter.

One solution that is probably within reach is to just change it to Ctrl-D, but I believe the Windows equivalent is Ctrl-Z unless you're in the new Windows terminal then it's Ctrl-D. Might be hard to explain to the user unless we can just make Ctrl-D work across platforms. Windows does allow us to read direct key presses in a terminal environment so it's not entirely out of reach but would require special code in Windows. I wonder if that'd be too advanced for people. I also wonder how all these Ctrl-KEY combos effect mobile users who don't have Ctrl on their devices.

[patrakov]

@DannyDaemonic That's why the "unless inside the MarkDown block" suggestion.

[DannyDaemonic]

I would imagine it's also not uncommon to have two enters in a row outside of a code block as well. (If you're manually using an alpaca instruct model, it happens all the time.) The other issue is tracking if you're in a code block. Right now each line is stateless. Since you can intermix your generated text with your own text, I feel tracking something like that could get complicated. And again, I don't know how niche it is.

[mirek190]

I think the best will be fast double enter.
Shall we say 0.1 second between second enter pressed.

[DannyDaemonic]

Hmm, interesting approach, but it will trigger when someone pastes text into the terminal. Two Enters would happen almost instantly.

I'm softening on the Ctrl-D idea but I still wonder how mobile users are effected by control keys. I also wonder if there are systems where it closes the stream permanently.

[mirek190]

"almost instantly" is different than pressed twice enter by human. I think the proper code could recognize it easily ;)
Something like press between 10 ms to 100 ms between first and second press only.
Pasted text will be "press enter" faster than 1 ms I presume....

[mirek190]

Yes, thank you. f9a6364 is the one right before 41654ef. So that's the latest one without the arrow keys. You can use that one in the meantime if you want the arrow keys. I'll drop an update here once the arrow keys are working.

This was a feature specific to Windows Terminal (I believe Windows 11) only. When I add the arrows back in, it will work for everyone, but it could take a day or so with everything else that's going on right now.

Few days past .. are you going to fix it?

I will be appreciate

[DannyDaemonic]

Yeah, sorry. I caught COVID. I'm not dying or anything but it takes a lot out of me.

It's still in my plans though. So don't worry, I haven't forgotten!

[mirek190]

Ok no problem ;P

I had covid few mounts ago I know feeling ....

[mirek190]

2 weeks passed .
Soooo can you fix it maybe a bit .... ;)
Would be nice multi line input plus working arrows at the same time

[DannyDaemonic]

Sorry, there's a not on github but it probably didn't go to your email. You can try out the patch at #1558. If you're only using the precompiled versions you'll have to wait for it to be reviewed and merged.

[mirek190]

Would be nice multi line input plus working arrows at the same time ... I just saying :P

[DannyDaemonic]

You can combine multiline with --simple-io, but you loose the cleaness of the look. It will work though.

I also have a future PR that adds the arrows/controls back in along with some other additional features. If you do compile it yourself, I can probably post the PR as a draft for you to try out.

[mirek190]

Downloaded newest build binaries run main.exe with --simple-io <-- such parameter not exist ...

[DannyDaemonic]

Yeah, it has to be approved first. There's a bit of a process involved.

[mirek190]

Any improvements?
I still waiting for fix it ;)

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.