When working with Erlang, the shell is central to a lot of the work that we do. It is where most of us started out when learning Erlang and it is where we have spent countless hours trying to debug issues in production.
For Erlang/OTP 26, we are going to take a close look at the shell and see what we can improve in there. There are already a lot of issues[1] at the Erlang/OTP github tracker related to problems with the shell and we intend to address as many of those as we can. However, we do not only want to look at fixing current bugs, but also expand what the shell does today.
Having support for the very common Control-L shortcut to clear the terminal while in the shell would be incredibly beneficial to clear the mess after several commands.
I would probably configure the default Erlang build to have history turned on by default, along with Unicode auto conversion in at first.
Multi line editing would be good for sure.
I would have liked it if the shell parsing structure was amenable to getting vi mode implementable but I donāt imagine this would be easy nor popular.
Iād like for remote shells to keep working
Syntax highlighting would be great, along with better autocomplete.
The kernel application allows configuration of a shell history. You can enable it using erl -kernel shell_history enabled, or setting ERL_FLAGS=-kernel shell_history enabled. Is this what you mean, or something different?
Ctrl+L today in the shell redraws the current line, which is a feature I find very handy when logger/dbg is printing things to stdout as I type. I would not like it if that feature went away.
Btw, Ctrl+L in my shell sets the cursor to be at the top left, while clear clears that history buffer as well. I assume you would like Ctrl+L to do the first option, but thought I would double-check to make sure.
Itās tricky, but essentially would require modal editing (hence why I donāt think it would be realistic to expect it).
So instead of pressing ctrl+a to go to the beginning of the line or ctrl+e to go to the end, I switch from insert mode to edit mode and press 0 or $.
Common commands in edit mode include things such as ct" which means āchange the content from the current cursor until the next "ā and switches back to insert mode.
I frankly have no idea how the same shell code can be made to switch from one to the other; I just know that I looked at how it was handled in the current one and it was very much impossible. I also know pretty much nobody uses that sort of shortcuts, so I wouldnāt be mad not to see it, thatās the usual.
Yeah, I think that the āas I typeā mode is the most useful one, particularly around things like whether Iām still stuck in a string (or quoted atom), and in some cases matching on closing parens or brackets.
Suggestions for function arguments are probably the trickiest one, possibly based on type names if that is carried.
And yes, Ctrl+L clears the terminal and insert a new prompt. This behaviour is incredibly common for all shells ā system or language ā I ever used. Some advanced shells such as zsh even keep what was currently typed in the current prompt line.
Not having it means the only way to clear the mess is to exit and re-start the Erlang shell. This is a constant annoyance.
If filename is specified, the file is edited; after the editor exits, the fileās content is copied into the current query buffer. If no filename is given, the current query buffer is copied to a temporary file which is then edited in the same fashion. Or, if the current query buffer is empty, the most recently executed query is copied to a temporary file and edited in the same fashion.
If we could implement this you could get something close, but since it would open up a new vi session you would not be able to view the current content of the terminal at the same time. Unless you set EDITOR=āxterm viāā¦ not sure how useful something like that would be.
bash and zsh kind of does this, but only when you use arrow-up to get the history. i.e.
> a="a
> b
> c"
## Arrow-up
> a="a
b
c"
I think I would prefer it to be the bash/zsh way, though I have no better reason than āthat is what bash and zsh doesā.
For anything returned to the shell through a command this might be possible, but for things that are printed by the application (i.e. logging, dbg, io:format etc) it would be very hard to do.
Would only having it from return values in the shell still be useful, or is it dbg/logger/io:format where the largest benefit would come?
wowā¦ I was looking for this feature for years and gave up anywhenā¦
Thanks for the hint!
That is sometimes the problem with ERLANG:
many gems but hard, or should I say hardly, to find.
I tend to agree with @dszoboszlay, copy and paste is a great argument.
However, if we decided not to have any prompt
1> mod:fun(mod:fun2()
1>
compared to
1> mod:fun(mod:fun2())
Its difficult to tell if the function is stuck/executing or if I forgot to complete the expression with ā.ā.
Some kind of indication is necessary (IMO) to help new adopters to make that distinction.
Can probably be solved by cleverly using colors.
What Iād like to see in the shell is that it would be possible to apply parse transforms to the typed commands. Maybe something similar to how records are handled, where you read records with rr() and the shell remembers the record definitions, in the same vein, youād be able to specify which parse transforms youād like the shell to invoke on the typed input. The later should be also configurable through given user_default or shell_default modules.