Multi-line interactive mode?

[drone1]

Hello. Love this, but in interactive mode I'm not able to paste multi-line code, from what I can tell? Did I miss something? Super cool! Thanks.

[nopeless]

I was going to suggest this as well. There is no way to detect things such as ctrl+enter though so it would be detecting double newlines. I want to to talk about this before it gets implemented though

[nopeless]

specifically because I would use this feature a lot

but here are some extra specs I would appreciate

• in code blocks (triple back ticks), the newline enter should be disabled entirely
• the terminal should "detect" paste by checking how fast the newlines are entered

[kardolus]

@nopeless I have played around with trying to detect "shift+enter" but I couldn't figure it out. I can play with other key combinations though. Control + enter perhaps? It would be a little odd.

The mac keyboard just only sends the outcome to the go program. Like it won't send "shift+s", it will send "S". The outcome of "shift+enter" is "enter" so that's what the program receives.

Haven't looked into backticks or enter-frequency.

You can always cat files or use pbpaste to pipe data into the CLI though.

Like

cat README.md | chatgpt --prompt summarize.md

Or

echo $(pbpaste) | chatgpt what are some action items for me in this slack thread?

[nopeless]

@kardolus yea, there is no difference between shift enter vs ctrl enter vs enter. The protocol is simply not there. I am aware of the -p flag as well, I was considering copying my code into terminal directly while im in interactive

[kardolus]

Perplexity (with Claude) provided some context:

The difference in detecting Shift+Enter between your browser and Go program is due to how input events are handled at different levels of the software stack. Let's break this down:

Browser Behavior

Browsers are designed to handle complex user interactions, including modifier keys like Shift, Ctrl, and Alt. When you press Shift+Enter in a browser:

1. The browser captures the keypress event.
2. It recognizes both the Enter key and the Shift modifier.
3. JavaScript running in the browser can access this detailed event information[1][4].

For example, in JavaScript, you can detect Shift+Enter like this:

document.addEventListener('keydown', function(event) {
  if (event.key === 'Enter' && event.shiftKey) {
    console.log('Shift+Enter pressed');
  }
});

Go Program Behavior

Your Go program, on the other hand, is likely receiving input through a more basic input stream, which typically doesn't include information about modifier keys:

1. The operating system handles the keypress.
2. It sends only the resulting character to your Go program.
3. The Go program sees just the Enter key (newline character) without any information about the Shift key[5].

Why the Difference?

1. Input Level: Browsers operate at a higher level of input processing, with direct access to keyboard events. Go programs often work with standard input, which is a lower-level, simplified input stream.

2. Event Processing: Browsers have sophisticated event handling systems designed for rich user interfaces. Standard console input in Go is more basic, focused on character input rather than complex key combinations.

3. Operating System Interaction: Browsers interact more directly with the operating system's input systems, while console applications often receive pre-processed input.

To detect Shift+Enter in a Go program, you would need to use a library or system-specific code that can access raw keyboard input, which is more complex and less portable than standard console input.

If you need this functionality in your Go program, consider using a library like termbox-go or gocui, which provide more advanced terminal input handling capabilities.

[kardolus]

@nopeless Sorry for being this verbose today; but here's a library we could look into: https://pkg.go.dev/syscall

[nopeless]

I won't advocate for detecting shift pressed using syscalls. cross platform compatibility might be an issue. To add a bit more to Claude's response, it's not really about the operating system or go, but the terminals responsibility to encode the modifier keys (usually you can configure behavior in terminal as well)

[nopeless]

with that being said microsoft/terminal#16511 I may be wrong on the protocol (PowerShell). last time I tried doing smth similar I gave up I might look into it again

[kardolus]

Thanks for providing the additional context. I was not aware of that.

Instead of a shift+enter, what would you think of something like this: when a user types <<EOF we start "multiline" mode. Once the user types "EOF" we end the multiline mode and the content between the two is submitted?

<<EOF
your
multiline
input
query
here
EOF

Totally open to other suggestions.

[nopeless]

@kardolus I honestly think all interactive sessions should be multi-line with the user being required to enter two newlines for the prompt to accept the query, with these extra specs

• in code blocks (triple back ticks), the newline enter should be disabled entirely
• the terminal should "detect" paste by checking how fast the newlines are entered

[kardolus]

I can look into the enter frequency first. That would be a none breaking change. The double enter should I suppose be an opt-in somehow, just so we don't break folks who don't want that or don't expect that.

I wish I had a better feel for how folks use the interactive mode.

edit: maybe I should start posting google forms once in a while for feedback (?)

[nopeless]

I guess the conventional way to approach this would to just make an option so everything is opt-in and changing defaults when you release another major version. I don't like the idea of sending google forms for this or adding telemetry. I personally don't mind if I have to add another flag e.g. -m to enable multi-line mode, but because I am biased I would like the double enter should be the default for everyone.

[kardolus]

Oh yeah, I would def not add telemetry. But you know how the gcp cli sends out a link for feedback once in a while? I think that could be an option. edit: it could work as long it is very infrequent.

But maybe the new "Discussions" tab in github catches on someday. That could be a good spot for it too. It's just hard to do proper project management if you don't know how people are using your product.

I like the idea of a -m flag. I could make it configurable so you can make it your own default.