Extremely cool idea! Some questions about racket-rash HOT 17 OPEN

Yeah, I've thought about using an emacs mode, eg. running inside term-mode or something. But that doesn't really get me what I want. I want a bottom-of-the-terminal editor, like readline or Zsh's ZLE. This is important to be able to use a shell/terminal normally -- the modes embedded in emacs don't handle TUI interfaces (made outside of emacs) well. I want to be able to customize the editor, keyboard shortcuts, hooks, etc in Racket and not emacs lisp, and I don't want to go through some FFI or comunicate over a socket for Racket and another language (eg. elisp) to cooperate. So I really think I want a bottom-of-the-terminal mode for one of the emacs-in-racket projects, and then build a REPL around that. It would benefit other Racket projects too -- if the line-editor mode for the emacs-in-racket is generic enough, it could support repls in many languages besides Rash.

from racket-rash.

I'm not the author, but in the Todo file he mentions plans to make the line editor into a sort of configurable, extensible "emacs in racket".

In terms of add-on modules, when you create a racket package, you can specify it to be under the rash collection, and do things like (require rash/git) where rash/git is your own package. I'd assume racket packages would be the standard add-on method.

from racket-rash.

I'm glad you are interested!

• I do plan to have standard interfaces to things eventually, but aside from core language infrastructure there are a lot of things that I know I want but don't know exactly how I want them. The demo directory is full of a lot of half-baked experiments. But I definitely want them to mature into things I provide by default.
• The current prompt stuff is garbage, and I plan to re-implement it “soon”. But yes, I want to have a suite of functions that you can easily add/remove from a prompt to get the info you want. The existing prompt stuff I wrote quite a while before any of Rash above the bottom pipelining layer was anything I thought I would be keeping, but I was testing it out enough to want a semi-interesting prompt. I plan to rewrite it soon with the main benefit of having some timeouts to not hang when I cd into a git repo with a lot of history.
• It is probably not possible to get really good editing stuff with libreadline. But as @vityou mentioned, I want to have an emacs-style extensible line editor. I am considering making a bottom-of-the-terminal display mode for either rmacs or remacs, and making the Rash REPL basically be embedded inside a full editor.
• Key bindings will come with a better editor.
• Completion, editor extensibility, separate "I'm typing now" and "this command is now part of the history" prompts/display, super powers with custom keystrokes, etc, available and programmable in Racket as soon as there is an emacs-in-racket-as-a-line-editor.

When will this line editor thing happen? Who knows. I've been thinking about making time for it this summer, maybe in August. But I would probably make something really basic to start out. Lately I've been focusing on an academic paper I've been writing about Rash, and then I have some other obligations as well. But I really want Rash to be a usable and good shell/scripting language.

Any hacking you want to contribute would be great. :)

from racket-rash.

And I don't mean that I want to limit contributions to hacking -- I'm also very interested in design feedback, bug reports, documentation improvements, testing, etc. So I'm glad to be having these discussions.

from racket-rash.

And yes, as @vityou mentions you can make your own packages that add thing to the rash collection. But unless something is really specific to Rash it may make more sense to just put it in a collection with a name related to what it's doing. You can use any Racket library written in any #lang you want in Rash or in any customization of it.

from racket-rash.

Just to confirm that I have the right idea about collections, something like rash/prompts or rash/oh-my-rash are what you mean by specific to rash right? Or would they go in a different collection? People can write their own scripts to require in rash, but if someone wanted to make an oh-my-zsh for rash, I'd assume it would be a package and be under the rash collection, correct?

from racket-rash.

Yeah, those would be under the rash collection, and anybody could make them. But I also want the out-of-the-box prompt and such to be good, so I would like a lot of that stuff to just be in the rash package itself.

from racket-rash.

If you wan't to have smart parens, custom keybindings, and other emacs stuff with the repl, you can run it in normal emacs. I have racket mode installed for emacs, and if you open a repl and type (require rash/repl), it works fine. Tab completion doesn't work, but you get syntax hilighting for racket code, smart parens and all of emacs.

from racket-rash.

Would it be a mode in one of the racket emacs you mentioned, or were you thinking of redesigning the project to make it more specific to rash? And just to clarify what you mean by bottom of the terminal, do you mean like there's a permanent fixture at the bottom of the window which you type into and the results get displayed at the top, like m-x in emacs kind of, or do you mean something different?

from racket-rash.

Basically I want it to be like readline or other line editors -- at the bottom of your shell session you have a prompt and you type, and you have editing functions and customizable keyboard shortcuts while you are typing. But it would be extensible in Racket, and the editing functions and the way to customize it would be in the style of emacs, but in Racket, and would be the same functions as in the emacs-in-racket project. Basically this would be achieved by making the editor something you can require as a library, and making a different UI for the text buffer so that it sits at the bottom of your session when its active and goes away completely while a command is running.

from racket-rash.

Would be really nice if the line editor didn't exclude inveterate vi(m) users... ;) Readline has its limitations, but it's pretty ubiquitous, and does provide a large productivity boost to both emacs and vi users with a minimum of configuration. I would be fine with a solution that provided basic emacs/vi editing capability, even if all the lispy extras (e.g., convolute, wrap, slurp, barf, etc...) were provided only in emacs mode. (Though I'd love to have them, I suspect that those extras provide less value in a command line context than they would in lisp file editing, where a vim user would presumably have access to something like vim-sexp or paredit). I suppose it's possible that something like rlwrap could provide the basic editing functionality, even without explicit rash support.

from racket-rash.

Yes, you can currently run rash-repl with or without readline support, and you can also wrap non-readlined rash-repl with rlwrap. I used vim for a few years before switching to emacs, and I use evil-mode in emacs to get vim-style modality. So some vim stuff is definitely on my radar for supporting in a line-editor (modality as a priority, then text objects, and I would want everything else to be possible [although some parts of vim I think are more historical accident than good design]).

Even when there is a better line editor, I think it will be easy to support multiple options -- no line editing, readline, and the new emacs-in-racket with line-editor mode.

from racket-rash.

from racket-rash.

from racket-rash.

from racket-rash.

@bpstahlman By "running into a conflict" with keybindings I guess you mean your custom keybindings getting overwritten? I've had similar issues with evil mode but I wonder if you have seen https://github.com/noctuid/evil-guide ? Because it's by same author of lispyville. After following https://github.com/noctuid/evil-guide#preventing-certain-keys-from-being-overridden issue was solved.

If you ever try emacs + evil again, I'd recommend reading most of that guide if you haven't already. It's not 'official' evil mode documentation but personally it's made it lot easier for me to understand how to use evil mode everywhere in emacs. Overhead of having to configure your own evil keybindings vs normal emacs users not needing to is still there of course, valid point, but consider using/looking into evil-collection as mentioned in the guide.

You can read it incrementally as you configure evil, skipping parts you are not interested in or don't understand until later.

from racket-rash.

from racket-rash.