Extremely cool idea! Some questions

[dieggsy]

First of all, I love this - it's like emacs' eshell but for a real terminal, and more scheme-y, which is great. I just had some general thoughts - I understand this is unstable and feature requests are the last thing on your mind, but I just wanted to pick your brain on a couple things:

More immediate:

• Do you plan to define some standard interface to addons/goodies? (something like rash/infix would feel neater than rash/demo/infix)
• Would bee cool to expose the currently implemented prompts/git stuff as an addon module (unless there's already a way to do this and I'm just blind)

Way lower priority:

• Is it possible to get bracket auto-insertion so that when ( is typed, ) is inserted, with the cursor remaining between the two? In general, a hackable prompt would be neat (text substitution and snippets, autoinsertion, autosuggestions, but I understand this might be a limitation of the readline library? unsure).
• Key bindings?
• Would it be possible to get fish/zsh-like completion, where completions appear as a sort of 'pop-up' in which you can cycle through completions, and completion doesn't emit a new prompt?

I mostly have experience with chicken scheme, and only just recently started diving into racket, but I'd love to help your project however I can.

[zlee-personal]

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.

[willghatch]

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. :)

[willghatch]

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.

[willghatch]

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.

[zlee-personal]

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?

[willghatch]

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.

[zlee-personal]

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.

[willghatch]

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.

[zlee-personal]

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?

[willghatch]

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.

[bpstahlman]

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.

[willghatch]

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.

[bpstahlman]

Excellent! I've used evil-mode as well, and nearly switched to emacs a few times, but have always ended up coming back to Vim - partly because I'm heavily invested in several Vim plugins, but also because, as nice as evil-mode itself is, I found myself spending an inordinate amount of time and energy "evilifying" the various packages I wanted to use, and getting them all to play nicely together…

At any rate, I'm excited about rash, and it's comforting to know that it's author is not at all hostile to the modal editing paradigm…

Thanks, Brett S.

On Tue, Oct 2, 2018, 4:34 PM William G Hatch notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/willghatch/racket-rash/issues/17#issuecomment-426438541, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7pQH_MGWXkCXqyFz4bOiKjweryhTLQks5ug9v0gaJpZM4VDKpE .

[willghatch]

Out of curiousity, what types of things do you find yourself "evilifying"? I've had this problem as well, but I find the problems primarily come down to 2 things: keybinding conventions and command-mode cursor position. Keybinding conventions I struggle with always because I customize them sometimes far from both emacs and vim. But the command-mode cursor position problem I find really annoying and largely pointless. For instance, I made the on-parens emacs package to fix the problem for smartparens. What I mean by the cursor position problem is that in command/normal-mode/state, the cursor is viewed as being ON a character rather than BETWEEN characters (thus you can't move past the last character on a line and have i and a as two different ways of switching to input-mode). I think that's largely unhelpful, and I occasionally think about using a modal editing scheme where the cursor is always viewed as being between characters. I haven't yet due to inertia, but some day I think I will.

On Tue, Oct 02, 2018 at 03:32:22PM -0700, Brett Stahlman wrote:

Excellent! I've used evil-mode as well, and nearly switched to emacs a few times, but have always ended up coming back to Vim - partly because I'm heavily invested in several Vim plugins, but also because, as nice as evil-mode itself is, I found myself spending an inordinate amount of time and energy "evilifying" the various packages I wanted to use, and getting them all to play nicely together…

At any rate, I'm excited about rash, and it's comforting to know that it's author is not at all hostile to the modal editing paradigm…

Thanks, Brett S.

On Tue, Oct 2, 2018, 4:34 PM William G Hatch notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/willghatch/racket-rash/issues/17#issuecomment-426438541, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7pQH_MGWXkCXqyFz4bOiKjweryhTLQks5ug9v0gaJpZM4VDKpE .

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/willghatch/racket-rash/issues/17#issuecomment-426452618

[bpstahlman]

If I recall correctly, a few of the popular packages had evil counterparts, but for those that didn't, I invariably had to spend time thinking through a sensible set of bindings that didn't conflict with anything. Although this sort of ground-up customization isn't necessarily a bad thing, it can be a source of unwelcome inertia that slows the adoption of new packages. I found myself picking what seemed like a set of sensible mappings, only to run into a conflict of some sort that forced me back to the drawing board. Whereas a non-evil emacs user might freely "test drive" a package to get a feel for the advantages it provided, such test drives were rarely free for me, as I couldn't fully appreciate the benefits of the plugin without spending some time getting it set up for use with evil mode. Nothing insurmountable, but it just seemed as though I was spending a lot of time tweaking and re-tweaking my settings while trying to get to a stable configuration. One of the reasons I prefer vim over emacs is that, whereas both allow you to customize just about anything, default vim just feels more useful to me than default emacs. I realize, of course, that no one forces me to use either editor in its default configuration, though there have been times when I needed to log onto remote systems for non-recurring work, and for those scenarios at least, I prefer that text editing, at least, remain basically unchanged. (Incidentally, this is also the reason I never switched to one of the more efficient keyboard layouts). I considered using Spacemacs, as I assumed it would provide evil defaults for just about everything, but at the time, the packages I wanted to use weren't all supported IIRC... Actually, as attached as I am to modal editing, I think the orthogonality of operators and motions may be one of the most powerful features of Vim. I was really excited when I discovered that the "composable" package brought this concept to emacs, but I could never decide on the best way to use it: i.e., whether to try to use it in conjunction with evil, or as a means of obviating the need for evil...

As for cursor positioning... Yes. The mismatch between the Vim and Emacs approach can definitely complicate evil mode packages. Although I haven't generally considered it to be a problem in Vim itself, the inability to position cursor past the last char on a line does occasionally complicate plugin logic. Something I've found helpful with plugin code is setting virtualedit=all,onemore, which allows the cursor to go just past EOL in all modes. I'll take a look at "on-parens". I looked into smartparens et al when I was trying to find the best lisp editing solution in emacs. I eventually settled on "lispy" in conjunction with "lispyville". Ironically, despite drawing some of its inspiration from Vim, lispy didn't work well with evil out of the box: hence, the need for lispyville. I was just starting to get comfortable with the combination when I reverted to Vim... (doh) Ah well, I haven't ruled out a switch back at some point...

On Tue, Oct 2, 2018 at 6:35 PM William G Hatch notifications@github.com wrote:

Out of curiousity, what types of things do you find yourself "evilifying"? I've had this problem as well, but I find the problems primarily come down to 2 things: keybinding conventions and command-mode cursor position. Keybinding conventions I struggle with always because I customize them sometimes far from both emacs and vim. But the command-mode cursor position problem I find really annoying and largely pointless. For instance, I made the on-parens emacs package to fix the problem for smartparens. What I mean by the cursor position problem is that in command/normal-mode/state, the cursor is viewed as being ON a character rather than BETWEEN characters (thus you can't move past the last character on a line and have i and a as two different ways of switching to input-mode). I think that's largely unhelpful, and I occasionally think about using a modal editing scheme where the cursor is always viewed as being between characters. I haven't yet due to inertia, but some day I think I will.

On Tue, Oct 02, 2018 at 03:32:22PM -0700, Brett Stahlman wrote:

Excellent! I've used evil-mode as well, and nearly switched to emacs a few times, but have always ended up coming back to Vim - partly because I'm heavily invested in several Vim plugins, but also because, as nice as evil-mode itself is, I found myself spending an inordinate amount of time and energy "evilifying" the various packages I wanted to use, and getting them all to play nicely together…

At any rate, I'm excited about rash, and it's comforting to know that it's author is not at all hostile to the modal editing paradigm…

Thanks, Brett S.

On Tue, Oct 2, 2018, 4:34 PM William G Hatch notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/willghatch/racket-rash/issues/17#issuecomment-426438541 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AC7pQH_MGWXkCXqyFz4bOiKjweryhTLQks5ug9v0gaJpZM4VDKpE

.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub:

https://github.com/willghatch/racket-rash/issues/17#issuecomment-426452618

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/willghatch/racket-rash/issues/17#issuecomment-426465128, or mute the thread https://github.com/notifications/unsubscribe-auth/AC7pQMZwlFcjoNcvM7McYu9CVfknZ3bQks5ug_hYgaJpZM4VDKpE .

[vyp]

@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.

[bpstahlman]

This looks intriguing. I plan to read through it in more detail when I get time. Would love to find a way to reconcile Vi(m) and Emacs in order to get the best of both worlds... Thanks for the tip! Brett S.

On Tue, Oct 22, 2019 at 11:10 PM vyp notifications@github.com wrote:

@bpstahlman https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/willghatch/racket-rash/issues/17?email_source=notifications&email_token=AAXOSQB46TAZWCJLG355FXLQP7FCLA5CNFSM4FIMVJCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB77MMA#issuecomment-545257008, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXOSQFU4KPT5CN35XQWI2TQP7FCLANCNFSM4FIMVJCA .