Codecov Report

❌ Patch coverage is 66.66667% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@27c8859). Learn more about missing BASE report.

@@           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.
📢 Have feedback on the report? Share it here.

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 multiline option, and have this be a default behaviour.

A question on the approach, why using \r instead of \n directly and skipping the replaceAll calls? (and, do you happen to know if \n by itself works on Windows' terminals?)

To your questions:

Where is ctrl set on Keypress? I want to add a shift

Inquirer uses the default Node.js keypress events on a stream. I have a small utility in the repo (node tools/keys.mjs to log keypresses.) Weirdly enough, it seems to ignore shift/ctrl/cmd when enter is pressed 🫤

When I try yarn dev I get this forever

I saw yarn dev was broken, but I forgot about it 🤦🏻. What I've done last is yarn tsc to build, then yarn demo. You do loose the rebuild watcher unfortunately.

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:

// no joy..
const readline = require("readline");
readline.emitKeypressEvents(process.stdin);
if (process.stdin.setRawMode != null) {
  process.stdin.setRawMode(true);
}
process.stdin.on("keypress", (str, key) => {
  console.log(key);
});

And:

process.stdin.setRawMode(true);
process.stdin.on('data', (key) => {
  if (key === '\u0003') process.exit(); // ctrl+c to exit
  console.log(key);
  if (key.toString() === '\r' && process.stdout.isShiftKeyDown) {
    console.log('Shift+Enter detected');
  }
});

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:

• https://github.com/tomzx/gkm
• https://github.com/KleoPetroff/node-global-key-listener

Both of these examples are bundled with a jar file and require java to be installed. I guess it might be possible with C, building for different distributions but it seems that'd be a lot of work and very brittle.

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 stdin and I don't know if we can identify that it is pasted content (if we can read all the content rather than byte by byte we could potentially at least handle newlines in the content at least up to the last one)

Interesting, ctrl-O doesn't work for me, but ctrl-j does. However when sending this key combination, Node detect is as an enter keypress - so looks like we couldn't catch it.

I'm not too sure where to go from now. My thinking starts going into a switch for multiline/single, like press ESC then we don't submit on enter. But that's pretty much copying vim keybindings, and at that point is there value versus yielding to the editor prompt 🤷🏻

(Side note, I figured out why yarn dev launched in an infinite loop - and it's fixed on latest main. Basically when I moved to tshy, it generates temporary files which were throwing off turborepo watcher.)

Great news on yarn dev! Yes I'm also at a loss - at the moment I pivot into the editor. Maybe one final thought - what about the down arrow? If we can catch this we could open a new line? And last question, when someone presses 'paste' - do we get the full bytestream of what is coming in (e.g. line one\nline two\nline three so that we can see that there are multiple lines and deal with them, or is it byte-by-byte (meaning ctrl+v will never work and maybe this is just not meant to be!)

(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.

Maybe one final thought - what about the down arrow?

My concern is it's unfortunately not very discoverable.

I don't know for certain about pasting. It sends a data event, but I don't know if it streams the pasted content if it's long or not 🤷🏻

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!