ESET (nitpicking)
- Thread starter vefatica
- Start date
- May
- 15,047
- 271
Let me rephrase for accuracy.
At the command line or in ESET, pressing Ctrl-C places "^C" at the current cursor location and the new prompt appears on the line following that cursor location. If the text to be edited extends beyond one line and the cursor is not in the last line when Ctrl-C is pressed that will lead to the new prompt appearing mixed in with inappropriate text (as in the image in post #1).
At the command line or in ESET, pressing Ctrl-C places "^C" at the current cursor location and the new prompt appears on the line following that cursor location. If the text to be edited extends beyond one line and the cursor is not in the last line when Ctrl-C is pressed that will lead to the new prompt appearing mixed in with inappropriate text (as in the image in post #1).
- Jun
- 1,092
- 48
That's the same kind of thing I'm seeing with ConPTY sessions of TCC in TCMD when I've scrolled the buffer and then press ESC. Any new command input just writes over the contents of the screen buffer. In non-ConPTY sessions, the cursor gets moved to the bottom of the buffer. I think that's what one would want to happen when bailing out of ESET.
rconn
Administrator
- May
- 14,987
- 375
Staff member
I know what you're saying. It's also 20+ year old behavior, and I am not inclined to introduce breaking changes during a beta.
rconn
Administrator
- May
- 14,987
- 375
Staff member
Well -- not remotely the same kind of thing. You're talking about an Esc in a ConPTY session when you've scrolled back in the buffer, and you want it to autoscroll back to the insertion point. Vince is talking about a Ctrl-C when editing a wrapped line in any kind of session (for the last 20+ years), and he wants the exception handler to automagically determine what he was doing at the time of the ^C, and if it was editing a long line, go to the end of that line and do a CR/LF.