Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1673 +/- ##
=======================================
Coverage ? 97.97%
=======================================
Files ? 39
Lines ? 2467
Branches ? 658
=======================================
Hits ? 2417
Misses ? 43
Partials ? 7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Hi, I think this is a great idea and approach to this problem. It's also been requested fairly often, and so is definitively a handy addition to the core! All in all, I would prefer not to add a A question on the approach, why using To your questions:
Inquirer uses the default Node.js keypress events on a stream. I have a small utility in the repo (
I saw |
|
Thanks for the response and glad you like the idea? I might have stumbled onto a challenge (which currently seems insurmountable) though - it looks like it is potentially not possible in NodeJS to detect whether the shift key is pressed when 'Enter' is pressed. Combinations of the following haven't worked: And: Some googling suggested it might not be possible and that it could be terminal/os specific. I'm scratching my head as to what to do - unforunately it doesn't seem to even be possible to read the OS state of the keyboard, at least without using another language: Both of these examples are bundled with a Any thoughts? It might just be that this won't work (I can't think of any REPLs or terminal apps that handle Shft+Enter either). |
|
(note: looking at this comment it seems that at least on iTerm2 on MacOS 'Ctrl+o' seems to open a newline (works on my mac). I wonder if we could just inform the user and use Ctrl+o (and then something similar to the implementation above? However I don't know if we would be able to handle a clipboard paste as it may just stream the content into |
|
Interesting, I'm not too sure where to go from now. My thinking starts going into a switch for multiline/single, like press |
|
(Side note, I figured out why |
|
Great news on (FYI I'm playing with both of these ideas in my fork now will let you know!) |
|
Sorry for the slow cycles here, I've been under water the last 2 weeks.
My concern is it's unfortunately not very discoverable. I don't know for certain about pasting. It sends a |
|
Yes it seems problematic - I have seen a very good implementation here: https://github.com/sigoden/aichat/wiki/Chat-REPL-Guide However as it is using Rust they are likely hooking in directly at the level of APIs that are harder to access via NodeJS. I would expect at this stage that the work would be considerable; I might come back to this in the future. I'll take a look at the paste multiline option and get back to this issue shortly and suggest closing if it doesnt make sense! |
|
However - Ctrl+O to change from a single line input to opening the buffer in the editor is a cool idea, that's what they do in this project! |
Hi! I'd love to get your thoughts on this. Essentially this should allow for multi-line input. The use case is an application like mine, where a user may want to "Shift+Enter" to start a newline in an input prompt, or paste content that contains newlines. For example, in my
aiapp I want to write a message, "Shift+Enter" to put in a newline, then Paste from my clipboard a code sample. You can roughly see the app in use here: https://github.com/dwmkerr/terminal-ai?tab=readme-ov-file#terminal-aiThe methodology is:
\rcharacter.\ris rendered as\n\ris rendered as\nHowever I'm having a few issues with the PR:
ctrlset onKeypress? I want to add ashiftyarn devI get this forever:Finally, my use case is that hitting 'paste' when in the input would have some kind of event I can listen to so that in multiline mode I can transform the
\nto\r. I'm not sure if this is possible.Before I continue I'd love to know if this seems like a useful feature, if possible a hint on the
yarn devissue and a couple of pointers. Thanks in advanceI'm more than happy to take on the work for this just need a couple of hints!
Alternatives
Potential Limitations
\rcharacters will not be handled properly, as they essentially become a placeholder for a 'non-input ending newline'Related Issues