Sure, I have a few useful parse transforms here, including erlpipe and listcomp, which I always felt constrained about not being able to execute them in the shell. Wouldn’t the following example (assuming pt loads a parse transform) be something nice to be able to do in the shell?
1> pt(erlpipe).
ok
2> abc / atom_to_list / length.
3
3> pt(listcomp).
ok
4> [S+I || S = 0, I <- [1,2,3].
6
This please. And #4337 (enter passwords from the console).
Ideally, fix the problem with insane TTY on MacOS after halting the BEAM with Ctrl+C / Ctrl + C (stty sane fixes the problem, but it’s not superconvenient)
Lot of things come to mind, but among other things, better support for colours, both on the expression syntax highlighting side but also possibly on the output side… True colours on output ? If people want to generate some TUI in the shell remotely that would be nice.
Someone should really try to fix zsh so that it does what bash does. We may have to introduce a new +B variant that disables the break handler, but makes sure to capture SIGINT and cleanup the terminal before exiting… No matter what we do, the terminal can always break if SIGKILL is sent to Erlang.
For true color support, I suppose one would want the colors to automatically degrade if the receiving terminal does not support that color? Or what support would you expect from the Erlang shell? An API module to create the correct ANSI escape sequences for colors/other things?
Erlang has had documentation helpers for module, functions, behaviours and types since Erlang 23 (tough I just realized that the behaviour help function is not documented…). Or was there some other type of helper you were thinking of?
As explained in the version documentation, getting the current version is not as trivial as it would seem. But maybe we can make something that works most of the time.
Yes, I was only having return values in my mind, or maybe some other shell built-ins, like flush/0 or bt/1 if you want to be extra fancy.
I wouldn’t expect any text getting to the terminal through io:format to be more than a blob of text.
But now that I start thinking about it, it may be possible to add {put_term, Term} to the I/O protocol, which would let the I/O device decide how to represent an Erlang term. Interactive or graphical devices may render the term as a collapsible widget then.
Hello, thanks for the work going into this. I have strong +1s for ctrl-L (to replace putting something like cls() -> io:format("\e[H\e[2J"). in every project), and somehow tidying up the multiple-line prompt-number-repeats so that it makes copy/paste possible (though I’m not really sure how that would best work!).
I’d also love to get syntax highlighting/colouring for terms returned as well as while typing, and in particular in error/crash messages, especially if there were some way to make it show nested structures - it’d really help to work out issues in deeply nested data quickly. And it would be amazing to have it integrated with record definitions imported with rr().
Completion of already bound variables .
Completion of function arguments depending argument types ( for instance functions using paths would benefit to have completion )
I love using ctrl+backslash (SIGQUIT) to get out of shell. If you can keep that, that would be super sweet.
Fred wrote the command history/search I believe. One snafu I had with it was when I use erl_pipe (with releases) and use the search history. A pattern that I typically use to get-out-of search mode is ctrl-d … this breaks the erl_pipe session … and I have done this 100 times. I wonder if it’s just me or what…
If I remember, the search history was based on a popular shell… and I believe ctrl+d was the normal way of breaking out of search in that inspiring shell. So to have the erlang shell close (when erl_pipe) on you, is a shame, at very least. This isn’t an issue for a standard erlang shell, or course.
Sorry I can’t suggest a solution. Not that there may be one that’s any good.
This would be super great too: if ctrl+] (which currently closes some brackets, braces, parenthesis) also closed double quotes, single quotes, and the trailing greater-than+greater-than for binaries ( <<“foo”>>, <<42>> ). Wow, that would be amazing.
I’m not sure about the internals and if I’m messing things up (please correct me if I’m wrong), but isn’t the screen clearing and history be handled by supporting Readline (or similar) integration? I think Ruby’s pry does that.