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.

[nopeless]

Link for feedback would be a bit weird. I like to visit the repositories myself and make issues talking about the features I want, but you are the project owner and I think this is under your discretion. I would appreciate it if there was an option to disable the feedback prompt though.

[kardolus]

I was thinking, we can be more iterative by starting with just EOF being the new "enter" in multiline mode. Then later we can make that configurable with number of enters and enter frequency counting for pasting.

For me personally a double enter doesn't feel intuitive. I would rather just use 'EOF'. Can make that configurable if users submit Issues.

Anyway, I am struggling with the prompt. I think this looks ugly. What do you think? Would it bother you to see the prompt printed like this?

edit: I guess the prompt is configurable, so maybe it's not a big deal

 2024-10-13 09:38:53 ⌚ (☸️ |kind:N/A) Guillermos-MacBook-Pro in ~/workspace/chatgpt-cli
± |main {6} U:2 ✗| → ./bin/chatgpt --interactive --multiline --auto-create-new-thread
Entering interactive mode. Using thread 'int_30f7'. Type 'clear' to clear the screen, 'exit' to quit, or press Ctrl+C.

Multiline mode enabled. Type 'EOF' on a new line to submit your query.
[2024-10-13 09:39:08] [Q1] what
[2024-10-13 09:39:08] [Q1] is
[2024-10-13 09:39:08] [Q1] the
[2024-10-13 09:39:08] [Q1] capital
[2024-10-13 09:39:08] [Q1] of
[2024-10-13 09:39:08] [Q1] france
[2024-10-13 09:39:08] [Q1] EOF
The capital of France is Paris.

Multiline mode enabled. Type 'EOF' on a new line to submit your query.
[2024-10-13 09:39:30] [Q2]

[kardolus]

Here's a new branch for multiline support: https://github.com/kardolus/chatgpt-cli/tree/multiline

Note that I am still force pushing to that latest commit and it can change quickly.

[kardolus]

PS it is really cool to be able to paste. I just pasted the prompt called create_git_diff_commit.md followed by the git show HEAD and it worked perfectly.

[kardolus]

@drone1 feel free to jump in btw. Sorry for hijacking.

[nopeless]

@kardolus tested the branch out. i see you also added backspace support but unfortunately there are two small issues that I think might just be windows ™️ stuff

• Backspace support doesn't work in vscode integrated terminal
• In Terminal, it works but it is slightly buggy. Hard to describe but it might be an issue with Terminal itself.

EOF works well but I would still prefer double new lines

[kardolus]

Thank you so much for testing! Ugh. I am bummed that it's buggy. I will do some research on vscode integrated terminal. May end up spinning up a box on GCP and use remote desktop.

[nopeless]

Honestly having it disabled on windows might be a good compromise for now. I personally don't see why I would use backspace when I already have entered a newline but it was refreshing to see the idea itself.

[kardolus]

Thank you so much for testing. I will go ahead and merge it in then. Let's keep iterating though.

[kardolus]

Commit: 86684f7
Release: https://github.com/kardolus/chatgpt-cli/releases/tag/v1.7.3