Hello. I am having trouble exiting rash on Mac OS X. I haven't debugged it too in-depth yet but here is what happens.

I open the shell. I hit ^D on my keyboard. I get this:

> ^Dput-preferences: some other process has the preference-file lock, as indicated by the existence of the lock file: #<path:/Users/griswold/Library/Preferences/.LOCKorg.racket-lang.prefs.rktd>
 context...:
 /Applications/Racket/collects/racket/private/more-scheme.rkt:163:2: select-handler/no-breaks
 /Applications/Racket/collects/racket/file.rkt:426:0: call-with-file-lock
 /Applications/Racket/share/pkgs/readline-lib/readline/pread.rkt:197:23

I tried both exiting back to zsh and exiting from an execd rash-repl. I've tried both rash-repl indirectly and manual racket -l rash/repl.

I don't know anything about the mac os x preference file lock, so i can't be of much help until i look into what is actually happening here. Exiting on my linux box is fine, so maybe people just haven't tested rash on os x yet, or maybe there is something wrong with my system. In any case, thought i would report so there is a log for anyone who runs into this to see.

Big Sur 11.3.1 (20E241)

In all shells i've used (zsh, bash, csh) sending a SIGINT clears the current line. I don't know how i got into the habit of using this to clear the line, maybe it is bad, but i use it all the time. I don't know what behavior is best for rash here, but SIGINT behavior for when no process is running seems like it might have a bug in any case.

Phase 1

This is the output i get in rash for <C-c> <C-c> <C-c> "echo hi" <RET>

3:02 /Users/griswold/
> #(struct:exn:break user break #<continuation-mark-set> #<procedure>)
3:02 /Users/griswold/
^C#(struct:exn:break user break #<continuation-mark-set> #<procedure>)
3:02 /Users/griswold/
^C#(struct:exn:break user break #<continuation-mark-set> #<procedure>)
3:02 /Users/griswold/
echo hi 
echo hi
hi
3:02 /Users/griswold/
> 

Note the command i entered (echo hi) is repeated back to me.

Phase 2

After this, further <C-c> presses generate nothing, but interestingly a little bracket suddenly appears to the left of my current prompt. It's very small and just to the left of the >, i have to zoom in to see it.

<img width="123" alt="image" src="https://user-images.githubusercontent.com/423758/119103979-5cc31100-b9e1-11eb-989a-199f85d15b81.png">

What is that bracket? Is that a feature?

Note: on my Linux box, there is no phase 1, everything is immediately phase 2. There is no exn:break user break

I am running Racket v8.1 [cs] on all systems.

Oops, i didn't look long enough and it seems this is mostly a duplicate of #78. Hm. I guess it should be merged. The only new information here is about the different behavior between darwin and linux.

Hm, this isn't really a rash issue, it's happening for me in regular racket v8.1 [cs], too.

This happens on Linux too. I'm also unsure what causes this, but it's a nuisance. It is due to use of the readline FFI library. At any rate, as with most other issues on the tracker, my ultimate solution will be to write a new racket-native line editor. Eventually...

Hmm, I'm not sure what's up with the bracket. What terminal emulator are you using? At any rate, I'll probably close this issue and just leave #78 open unless this bracket thing ends up being important. But it might be related to the terminal emulator and the way C-c works.

@willghatch the bracket thing happens for me in the regular racket repl, too, so it's more of a general issue.

The thing is that in terminals, C-c is weird. Unlike most key events where the process just gets characters written to its input, C-c is handled specially by the terminal. Instead of sending a byte through the file descriptor to the controlling process, the terminal basically sends a signal to the kernel, which then sends SIGINT to the process. (This is a bit hand-wavey, as I would have to check some reference material to remember the exact details.) Programs that do something other than exit when C-c is pressed do so by registering a handler for C-c that does something sensible.

Anyway, Racket's handling of C-c is essentially to raise an exn:break exception, and there's not currently a good way to change that.

My plan for how to deal with this situation in a Racket-native editor is to either just catch that exception in the editing loop and translate it into a key event to do whatever is bound to C-c or actually change the process signal handler to do something similar. In principle this could be done with a readline FFI layer, but the current wrapper library is pretty simplistic, and doesn't actually expose much of the actual readline interface. In particular, it provides no way to programmatically edit the buffer. This could be fixed with a better readline FFI library, perhaps with much less effort than writing a Racket-native line editor, but ultimately my planned racket-native editor will be much more powerful than readline in various ways that I care about (IE be much more fully like Emacs -- pervasively programmable).

Huh. It doesn't make any sense to me that it would be specific to ls. At any rate, I haven't been able to reproduce it. I don't really have time to dig into this right now, but I'll ask some more questions to hopefully narrow things down. No hurry to answer, but:

• What OS are you using?
• Is ls definitely not aliased? If you remove all rashrc and rashrc.rkt files from your $XDG_CONFIG_HOME and $XDG_CONFIG_DIRS does it still happen?
• What version of Racket? CS/BC?
• Is your version of Rash up to date?
• Sometimes issues with the readline library are due to the preference file that saves readline history. It also saves other things for other Racket programs, primarily Dr. Racket. Do you use other programs that change this file? (Once Rash uses a racket-native line editor, it will no longer touch this file...)
• If you delete your preference file (~/.racket/racket-prefs.rktd probably) does it fix the issue? (Maybe instead of deleting it, you could move it. If it's caused by a specific issue with the preference file, maybe you could even attach the offending preference file. Note that I'm not sure offhand what personal information might end up in that file, so... check before you post anything.)

Are you suggesting that the default prompt should change the terminal title bar to include the current directory?

If so, I'm interested. The most difficult part about this is that it's terminal-dependent. I think most terminal emulators support this feature, but there are multiple different codes for doing it. I think they all use OSC codes (IE \033]<some number>;<some text><string terminator>), but eg. xterm uses 0 for the OSC code while KDE Konsole (the main terminal emulator I use at the moment) uses 30 instead. I'm not sure what a good way to detect this is.

For the moment I don't think I'll put # as comment in the default rash language, and I don't think I want the repl language to diverge that much from the module language.

That said, I intend to make it easy to run alternative versions of Rash in the terminal. This is mostly planned as a feature of the line editor I intend to make. A big problem with Racket generally at the moment is that there is no good way to make a REPL for a custom #lang. So it is easy with many languages to make a variant of a language with a modified reader, or use meta languages like #lang at-reader racket that modify readers. But there is no way to do that with a repl. Or even an easy way to use a stock s-expression reader with different bindings at a repl. So when I write my line editor I intend to make an easy way to configure it to use arbitrary user-defined readers, bindings, etc. I'm not sure how closely this will resemble the #lang protocol, since #lang specifies the reader and binding set at once, and the module context (with a #%module-begin) is different than a repl context, so I can't “just” use the #lang protocol. (IE much of what a #lang means may be defined by its #%module-begin definitien, which a REPL can't use.) But it will allow for similar things.

Honestly, Racket's #lang protocol, while super awesome, is really only geared to code in modules, and there are currently only weak ways of making a language work in a repl at all, or defining what that would mean. Racket currently provides basically no way to do any of this in Racket's command-line REPL and some limited facilities for defining what to do for DrRacket's REPL. I intend to make a nice way of specifying this info for making REPLs with my line editor. Ultimately I intend for it to be the go-to way to make arbitrary REPLs for Racket languages, where Rash will essentially be the flagship example. What this will probably look like in the end is that you can write a module that defines a REPL as a reader, a set of core bindings, and some other info like a name for the language that can be introspected by the line editor to load any language-specific configuration that the user has, or info relating to programmable completion for the language, etc.

Unrelated to this repl stuff directly, but related to running modified versions of Rash, I also am (still...) working on some parsing stuff that I intend to use to replace Rash's parser implementation (or perhaps be the parser implementation for a Rash2 or something) that will also provide much more powerful (and much easier and declarative) ways of modifying the reader layer to do what you want.

Also I'll note that if you don't pass those keyword arguments on to old-prompt you will have a degraded experience, particularly when running Racket code (top level s-expressions or pipelines that end with something other than a subprocess). It's actually the prompt handler that prints results for those.

So, I have found that readline actually contains defaults to do what we want (https://tiswww.cwru.edu/php/chet/readline/readline.html#SEC44) but apparently the racket wrapper somehow overrides this and breaks even racket's own repl (https://github.com/racket/racket/issues/2432)