Why doesn't DrRacket use xrepl for the interactions pane? xrepl is really brilliant and the repl in DrRacket is, politely, less brilliant.
Nothing wrong with just using VS Code (or other) with xrepl in the integrated or a stand-alone terminal. Especially with VS Code extension Magic Racket.
Still, you'd think "they" would put their better foot forward...
I think "they" evaluate their dance partner before deciding which foot to put forward? 
Seriously my impression is that xrepl and the Dr Racket interactions pane have different use cases in mind.
Is there something specific from xrepl you think DrR should get?
Or is it the entire ,command style, and all those commands?
[If the latter, I wonder if Dr Racket maybe should get a brand new, alternative REPL pane more like xrepl -- as opposed to trying to shoehorn (no pun intended) too many xrepl ideas into the existing Interactions pane.]
Most conveniently, command history and better line editing.
Indeed. The DrRacket has two kinds of uses in mind:
experienced developers who understand that the original Lisp repl creates inconsistent states and don’t need the ability to interact with long-running computations at that level.
novice (student) programmers who should definitely not get bitten by the accidental inconsistencies of this repl.
If someone wants to submit a PR to drracket that allows programmers to switch to the old Lisp-style REPL, I am sure Robby would inspect it.
From: 1.6 The Interactions Window
To copy the previous expression to the current prompt, type ESC-p (i.e., type Escape and then type p). Type ESC-p multiple times to cycle back through old expressions. Type ESC-n to cycle forward through old expressions.
I believe there are more handy, platform specific shortcuts available too
(but esc-p works everywhere).
... better line editing.
Have you enabled Emacs-like keybindings in preferences?
In the terminal, it's Expeditor that handles the line editing. It uses features from the terminal, so it's not straightforward to use it in the DrRacket interaction window.
At least not until someone implements a terminal emulator in Racket.
FWIW, one can use the "Edit|Keybindings|Show Active Keybindings..." menu item to find keybindings. This one's name is (probably not the best!) "put-previous-sexp" and, on my machine is esc;p, as you say, but also control-up.
hth.
I've been wondering for a while why the default for "put-previous-sexp" is not simply "up" like it is in many other REPLs...
Instead, "up" moves around in the text of the window, but... why would you want to do that?
I feel like I must be missing something. 
I use "up" to move the cursor in the interactions editor often for copy/pasting — I rarely use the mouse.
Ah I see, I guess that's the main difference... Indeed, I nearly always use the mouse for such tasks.
Well, thankfully the shortcuts are configurable so either style of use can be done comfortably.
I believe the thinking is that the interactions window is an editor first and a REPL second and if we were to take over the arrow keys (which are very commonly used for navigation to people who are used to working in, say, google docs and whatnot) it would be very confusing to newcomers. So that's why the keystrokes are set up the way they are.
That is a bummer about control-up! I'm happy to add another keystroke if there's another free one we should be using or if there is precedent in some other well-established editor that shares DrRacket's goals/constraints. Or just if others have specific ideas for improvements?
I’ll look at the existing keymap and give it a try. As I said, xrepl in a terminal with Magic Racket in VS Code “ain’t bad.” Just did: In DrRacket, I tried ctrl-up; it works great, of course; and it's all I need. Solved.
As for whether any change might be beneficial--it's low priority. There must be better things to do given that the underlying functionality is all there (it was my mistake to not realize it was there all along...).
But, as a general matter I'll observe:
It seems more commonplace to use up-arrow to navigate through repl history. I think matching what nearly every terminal emulator does makes more sense. It seems fair to assume that most folks working with a REPL-based language are familiar with terminal emulators though I realize students (of any age) using DrRacket as an approachable way to get started may not have that familiarity.
Up arrow to move through the displayed lines is certainly expected behavior when navigating an editable canvas as in nano and nearly every editor in existence. But in a terminal/REPL, you generally cannot edit in place. You can only enter and edit on the entry line so returning prior inputs to the entry line is required. It's nice to make that as convenient as possible. Copy/paste is one way and so is riffling through recent entries. Generally, you are repeating something you did during the current session, either as is or with some changes--changes that can only be made on the entry line.
That said, it's hard to be insistent here. I generally hate keymaps and expect anything on OSX to match the os standards as being a "good citizen" app and meeting user expectations. Likewise for Windows users. Others can make a valid argument for cross-platform consistency (although consistent with what?).
As far as matching emacs, I pretty much despise emacs though I became briefly competent, though I needed a cheat sheet open at all times to do pretty much anything (and lots are very convenient if only I had accessible, reliable neurons to hold the keymap in my memory). Which must mean I really never did achieve competence--guilty.
That only lasted until I realized that SublimeText with the plugin SublimeRepl was every bit as good. And VS Code with send selection to terminal. To do this day I only know a handful of key commands (<= 10) and that includes the ones embossed on the key caps. I'll remember what I use over and over and no more.
Except for being able to modify emacs with elisp, I refuse to view emacs as magical--it was great in its day and remains the most functional terminal-based editor for editing content on remote servers--though VS Code and Sublime Text do so just as well (assuming you are using a desktop or laptop computer--does anyone actually use VT100 terminals any more?) when used in conjunction with a suitable ssh tool (embedded in most terminals and many file managers). Granted emacs appears as self-contained for such uses. I have to admit I use nano. I am not going to edit hundreds of lines for hours. I generally only need to change a small script or config file.
Please don't need slap me as a low-IQ slug for not bowing down to the genius of emacs (which generally seems to be the attitude of most emacs users/advocates). If you like it, it is wonderful--no one should contest that for you and no one will ever pry it from your cold dead fingers, as the expression goes. Only pointing out that equivalent capabilities exist in more approachable packages for people with different cold, dead fingers and neurons devoted to different skills and memories. In this amazing little corner of the world all of us can have our individual preferences honored. Hooray. Would that it were so in other realms.
To paraphrase William Gibson, the past is already here, its modifier keys are just not evenly distributed. 
Ctrl-Cmd-Up works on Mac.
Great post. There must be a huge market for emacs keyboards! Autographed by William Gibson for only an extra $2000! Order now!
