medley
medley copied to clipboard
Interlisp
TTYINPROMPTFORWORD does BKSYSBUF if terminated with mid-string CR
TTYINPROMPTFORWORD is advertised as a nice way of allowing mouse-based editing for simple user inputs, a la TTYIN. TEdit uses it (via TEDIT.GETINPUT) when asking for file names, search targets, etc. in the prompt window.
If the call to TTYINPROMPTFORWORD can include a list of terminating characters. When any of those characters is entered, the editing session ends and the string in the buffer is returned.
However, if CR is one of the terminating characters and the session is terminated with CR, the result may not be as intended. It depends on where the caret is when the CR is entered.
If the CR is at the end of the string, the whole string visible in the buffer is returned, as expected. However, if the caret is somewhere earlier in the string, then the return value is only the prefix in front of the caret. But the characters after the buffer are not thrown away, instead they are stuffed into the TTY buffer and show up in the current TTY stream.
For example: if the string is foofum with the caret between after foo, the value is "foo" and "fum" appears as input somewhere else.
For TTYIN in the exec, the CR goes to a new line, and the suffix characters then appear at the beginning of that line, which makes sense--the editing session continues in place.
But in the Tedit (and maybe other cases), the effect for the Find operation is that the search string is just the prefix...and the suffix is silently inserted in the text at the position of the caret, presumably corrupting the document. The effect when trying to get a filename is that you only get the prefix as a name, and again the suffix may be inserted somewhere.
A solution for Tedit is to disable CR as a way out, require perhaps only something like ^X as a terminator following the TTYIN convention.
Or to somehow fix TTYIN so that CR as a specified-terminator takes precedence over CR as a new-line insertion. (Although, again in the TEDIT case, you might want to be able to search with a string containing CR.)
Just to reinforce the point, the rename command in the file browser also demonstrates undesired behavior. If you aren't careful to move the caret to the end before you hit CR, you end up with a truncated filename--a pain to recover from.
I think we might consider changing TTYIN to treat a user press Enter when the caret is in the middle of the line as a "move to end" first.
Re: CR as "submit" versus CR as "new line" is a pretty common issue in various web apps. One pretty common solution is to have CR be "submit" and CTRL-CR (or maybe Meta-CR) be "new line".
But the current behavior might be correct for the Exec, when you might want to type an EOL into a string. So move-to-end first has to be parameterized in some way.
If move-to-end is specified, then some way of escaping a CR would allow it to be inserted in the string if that’s what you wanted. TTYIN seems to respect % as an escape for parentheses, that doesn’t seem to work for CR.
On Feb 27, 2024, at 11:07 AM, Larry Masinter @.***> wrote:
I think we might consider changing TTYIN to treat a user press Enter when the caret is in the middle of the line as a "move to end" first.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1560#issuecomment-1967412960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJMQ34NGQSVGFBDPI3LYVYVHXAVCNFSM6AAAAABD4P37JGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGQYTEOJWGA. You are receiving this because you authored the thread.
<ctrl>-V<CR> when the caret is at the end of the line is an escaped <CR> embedded in the string (rather than terminating the input), but you can't <ctrl>-V<CR> when the caret is between characters you've already typed.
(you'll need to read that last note via the web interface -- it won't come through as intended in the e-mail version)
BTW, SEDIT search also uses TTYINPROMPTFORWORD, has the same issue.
On Feb 27, 2024, at 12:19 PM, Nick Briggs @.***> wrote:
Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1560#issuecomment-1967523939, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJIXDQSAVVN4ZJAOO3YVY5UNAVCNFSM6AAAAABD4P37JGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGUZDGOJTHE.
PR #1565 is a brute force attempt to fix the really bad behavior: if the new argument SINGLELINE is true in the call to TTYIN (which it now is in the call from TTYINPROMPTFORWORD), then CR causes it simply to terminate with the complete buffer. As if the caret had first been moved to the end.
I still don't see any way of escaping a CR that you want to appear in the middle of the output string. ^VCR in the middle of a line seems merely to flash the screen.
I'll also note that TTYINPROMPTFORWORD is a little odd. It basically decides whether to call the original (non-editable) PROMPTFORWORD or TTYIN, based on some of the arguments. But the TERMINCHARS.LST argument is only relevant if the other arguments result in old PROMPTFORWORD. The terminating character list for TTYIN appears to be built in.
See what happens with the new code if you type the ^VCR when the cursor is at the end of the line (and then continue typing something else). You can't go back and insert the CR (you get the visual bell flash), but you can currently type it as you go.
You have to enlarge the promptwindow in Tedit or Sedit to see it. But after you have typed the ^VCR and go back, you do get the flash. But instead of doing the ^VCR you just do an earlier CR by itself, it goes to the beginning of the line with the characters you typed after the CR that you had escaped. It just moves the caret, without terminating. If you have also entered a second escaped CR, then a raw CR will bumb forward to that one. If you are in the part of the string after the last escaped CR, then a CR will terminate with everything that you see, including the EOL’s.
So it seems that
- ^V only escapes CR’s at the end of the buffer. With or without the code fix, verywhere else it just flashes the screen.
- With the code fix, if the caret is before a CR that was entered by escaping at an end, then a raw CR moves to the beginning of the line that resulted from the end escaped CR, whether or not additional characters. were added.
- A raw CR only terminates if there are no escaped CR’s ahead of it.
I don’t know if this can be unscrambled without understanding the innards of TTYIN, which I personally am afraid of getting into. Escaping a CR (maybe with something other than go-to-the-next-line ^V) should just dump a CR in the buffer, unescaped CR should just terminate with whatever’s there, no matter where the caret happens to be located. (And then the various prompt windows should be set up to enlarge or scroll.)
But the brute-force code change at least seems to get rid of the most commonly encountered gotcha.
On Feb 29, 2024, at 11:12 AM, Nick Briggs @.***> wrote:
See what happens with the new code if you type the ^VCR when the cursor is at the end of the line (and then continue typing something else). You can't go back and insert the CR (you get the visual bell flash), but you can currently type it as you go.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1560#issuecomment-1971794771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJLKRQABUDXFQR3CVFLYV56SBAVCNFSM6AAAAABD4P37JGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZRG44TINZXGE. You are receiving this because you authored the thread.
I don’t know if this can be unscrambled without understanding the innards of XXXXX ... But the brute-force code change at least seems to get rid of the most commonly encountered gotcha.
Many of the various "it's a mess" problems we've seen are the application of this principle. I suppose it's a problem of any piece of software that is in development for a long time with multiple generations of contributors. I don't think the modern world is immune to these kind of problems, but still... I think understanding TTYIN is a prerequisite for addressing our keyboard problem and possibly font problems too. And the problem with MODERNIZE not being able to move the Exec.