In elvish I need to request an autocomplete— in fish I get a suggestion in a light font which is usually a good one.
Another nice thing in fish is that valid file names get automatically underlined. It’s another subtle but useful feature.
So I think you know what is coming. A feature request :-):
Please make Elvish prompt autocomplete/suggestions more like fish. I wouldn’t be surprised if this has not been requested already !
I can't promise anything, but I'm undertaking a major refactoring of Elvish's TUI and that should make it much easier to implement this feature in the near future.
I'm not keen on trading bashisms for elvishisms though :-) A somewhat random example from looking at the docs, where you have this example:
~> curl -s https://dl.elv.sh/$platform:os'-'$platform:arch/elvish-HEAD....
Quoting '-' instead of using (bash-style) "${platform:os}-${platform:arch}" seems really counterintuitive to me. After all, '-' is simply itself (a plain dash), it's the variable name that is special here and deserves quoting. Any thoughts on this?
~> curl -s https://dl.elv.sh/{$platform:os}-{$platform:arch}/elvish-HEA.......
It's more verbose than quoting the dash so I opted to the latter.
You seem to use "elvishism" in a negative way, and this particular example is one of the more quirky ones, but the whole reason you would use Elvish is that it's different from other shells! :)
So I'll definitely do more testing with Elvish and see what the overall experience is like. Coming from Solaris, we still have a ton of ksh scripts in our shop (with people working on them who have very different backgrounds and scripting skill levels). Something with less pitfalls than bash would be great... Thanks for putting in your time and effort!
Is that doable?
Related: is there a comprehensive list of hotkeys floating around? I didn't see it in the docs. Things like Alt-Enter and Alt-, are mentioned in the Quick Start, but I couldn't find them elsewhere.
It has the characteristics of a really great idea: seems obvious in retrospect, doesn’t look too difficult to implement, but somehow everybody seems to have… just missed it?
These days browsers will often suggest results from search engines but back then (at least in Firefox?) it was just history and bookmarks.
Bash will be dethroned some day. As general purpose languages like Rust, Julia, Python etc have risen, Fortran, pascal etc have declined. And so that will eventually happen with bash. Not “if” but “when” !
Re the cost of switching: on the one hand, I'd say that "switching" is really the wrong mentality, because you can always still use bash! You can "switch" to Elvish as your interactive shell and still use bash for scripting. Or you can "switch" to Elvish for some new scripts and still use bash as your interactive shell (and your existing scripts). If you want to give Elvish a try, you can just do it without giving up everything you do with bash today, and reap the incremental benefits of using a better shell.
On the other hand, the mental barrier of adopting "a new thing" is definitely real, even after you overcome the more irrational fears. We only want so much software in our lives anyway. To that I'd say Elvish needs to be more compelling than what it is today. Elvish today, with its nice interactive features and a real programming language, is perhaps 2x to 4x better than traditional shells on its own (if we ignore the whole ecosystem issue), but it needs to be more than that to stand out to people as something radically better. I'm still trying to figure out how to do that, but two ideas I'm exploring are:
- Make it super easy to build TUIs in Elvish - we've had a "renaissance" of TUI tools in recently years, but if you want to build a TUI from scratch it's still surprisingly complicated. Much simpler than building GUIs, but still much more complex than just building a CLI. I feel Elvish as a shell language is a really good place to have a nice TUI framework in.
- Make it super easy to manage a simple homelab or build farm in Elvish - this is traditionally a strength of shells and people still cobble together shell scripts for this purpose, but traditional shell languages are clumsy and you can't easily expose a nice UI from shell scripts. It would be very nice if you can compose some Elvish scripts together and have a nice TUI or a web UI for management at a very low extra cost.
I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
P.S. I am aware that Elvish has a built in LSP. It’s somewhat basic though IIRC.
That's interesting, because I have the same starting point as you (optimise hacked-up script experience) but a lot of the time as my script grows I really wish there's a nice little TUI for it. For example, rather than finding my invocation of the script from my command history and edit the CLI arguments, can I just have a little "pop-up menu" for my workflows, where I can probably add some string argument? Or allow me to see the outputs of the script in a slightly more fancy way than a stream of text - like a Miller column view, which Elvish already has implemented in its file manager? Ideally, these should be "ready-made" UI components that you can take advantage of from your hacked-up script with just one or two lines of code.
I'm also coming from the viewpoint of implementation - I've built Elvish's TUI using some very generic building blocks but they are only used for very specialized builtin features of Elvish, so I'm really keen on exposing the capability for shell scripts to use.
I guess we're thinking of different things when we say "TUI" - perhaps you are thinking of full blown TUI applications, like an editor? I'd agree that a more [1] general-purpose language is more suitable and Elvish is not in the business of being a good language to implement the next TUI editor :) Maybe I should coin a new term for what I have in mind, which should be something you can hack up as easily as a CLI. "TUIlet" maybe?
> I would spend time building a top notch LSP for Elvish. Shell scripting languages tend to be highly untyped and flexible so building a good LSP will be tough here. But if you were able to build one that works really well you would have another really compelling reason to use Elvish.
Definitely! It's not what I'm working on in the immediate future, but good editor integration is a must to make the experience of writing scripts much better than more traditional shells.
1. Emphasis on "more", because Elvish is a general-purpose language itself, just not the most general-purpose :)
Also when I started Elvish 10 years ago (!) PowerShell wasn't ported to non-Windows operating systems yet, so it wasn't even viable for most people.
(This is a really neat tool, great work!)
Elvish visibly leans into this to try to have a consistent syntax. Sometimes the similarities go deeper, too; IIRC, its number types are inspired by Scheme, for example.
Yes! Similarity to Lisp is very much a deliberate design choice and I feel happy every time a Lisper picks that up :)
I believe Elvish has also contributed a novel solution to the Lisp-1/Lisp-2 divide by making the space of command names equivalent to the subspace of variable names with a suffix - the command "foo" is equivalent to the variable "$foo~" and vice versa. (There's a bit more twist than that - the command "foo" can also resolve to the external command named "foo", but then that's represented by the "$e:foo~" variable.)
Powershell is not true FP, but, if you stretch terminology:
- the unit of feature delivery is the function - you can pass functions as values (but it's not idiomatic or elegant) - objects tend to look more like anonymous records than OOP classes with methods - pattern matching is supported (sort of)
1) Maybe link at the top of the ref page to the learn page? I started looking at ref but some stuff I needed to know was much better explained under learn and it took me a while to notice that it was there also (I'm guessing the existance of ref would be more obvious from the learn page).
2) Local documentation is vital for a shell, if there is a way to generate a man page from the available documentation that would be quite helpful (at least instaling the website would be good, but that looks like a package issue that should be easy to do).
3) If I want the equivalent of fd -X but being able to use aliases (functions in elvish) there is from-terminated and (all) but despite the long command line lengths these days it can overflow. A builtin simplified version of xargs that works with elvish lists and aggregates arguments while breaking into acceptable length command lines would be great.
4) There seems to be no way to execute code from a different file in the current context? For bash to get aliases in fd -X you can use a complicated fd ... -X bash -ic '<alias> "$@"' 'fd bash', however it seems that elvish both doesn't have -i and has no way to even source the rc file from elvish -c? Or to split rc files into multiple files without using modules?
5) &> and to a lesser extent |& are handy in bash to simplify combining stderr and stdout. Hopefully elvish doesn't have the 2>&1 placement issues that posix shells do but even if not I'd consider a shorthand worthwhile.
6) Some type of cooperative locking would be helpful along the lines of Debian's lockfile-progs but built in to make it easy to avoid scripts that break if you accidently run it twice at the same time (ideally compatible with lockfile-progs unless there is a good reason not to be).
7) Beyond that, some type of built in concurrency managed database based on elivish data types might be worth considering to simplify sharing state between independent execution of related utilities (or multiple execution of a single utility).
8) I like your idea of exposing more TUI abilities. In addition to what you said, being able to create a status line or two while preserving the scrolling history of other commands would be helpful (and this would be potentially interesting in an interactive shell also). I like your rprompt.
Overall, I like the look of elvish and for some reason it seems more approachable to me (not a big fan of lisp) than the PowerShell style shells.