Recognizing more `ctrl-` keys in Iex

dogweather

I really miss ctrl-l to clear the screen and ctrl-d to exit like other REPLs provide. Since ctrl-d is ignored, I would chose to alias it to one of the two “break” codes: ctrl-c or ctrl-g.

I’ve read through the Iex source code and don’t see how to extend the code. The closest thing I’ve found is the tab completion handler. It seems to work via a plug-in strategy as this section implies:

  @doc """
  Provides one helper function that is injected into connecting
  remote nodes to properly handle autocompletion.
  """
  def remsh(node) do
    fn e ->
      case :rpc.call(node, IEx.Autocomplete, :expand, [e]) do
        {:badrpc, _} -> {:no, '', []}
        r -> r
      end
    end
  end

But I still can’t figure out how the tab character is specified for this “hook” (if it even is a hook).

Are “special” characters like tab and ctrl-c handled exclusively by an Erlang server, and somehow Iex’s current architecture rules out adding new key combinations?

7 comments

#iex #cli

4 2559 7

2019-10-18 14:51:03 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

OvermindDL1

They are handled via the erlang shell framework in OTP itself, you’d look there for how to extend it (and they’d probably accept PR’s to make it easier).

Post #1

dogweather

Thanks - I discovered that. I created an AutoKey config as a workaround, submitted a ticket to OTP, and found this continuing conversation about it.

It looks like no improvements are going to be accepted, unfortunately. The discussion seems to get bogged down in all the different use cases for the shell, and the semantics of exiting it.

IMO, ctrl-d should be supported as a “least dangerous” way to exit, which is users’ expectations. I.e., probably corresponding with ctrl-c ctrl-c. It’s what we teach beginners. But then the discussion seemed to get derailed by a comment that this is actually a bad thing to teach as the default way to exit. I don’t know.

Post #2

OvermindDL1

That can bring down a node depending on how you are connected, not really the suggested way. I try to use Ctrl+g, q by default as it’s a safe way to quit without bringing down remote nodes if you are connected directly to them. Good habit to get in to.

Post #3

christhekeele

That’s great to learn, and really supports @dogweather’s point:

It seems like we would be secure by default by supporting dev expectations in the unfamiliar realm of live prod node VM connections, otherwise we’ve built a footgun when someone connects to a production node to diagnose a critical issue for the first time.

Post #4

Nicd

Please elaborate. I always use double ctrl+c and now I’m worried I will wreck my instance some day.

Post #5

sweeneydavidj

There’s an interesting note about this type of thing here…
https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-daemon-mode-unix-like

Post #6

OvermindDL1

Yep, what @sweeneydavidj linked to is a quick summary of the reason.

Essentially think of this, you make a release, you make a daemon, you get a foreground shell in to it, you want to exit the shell but keep the daemon up, well Ctrl+C twice will kill the daemon (since you are sending the kill signal to the whole process), Ctrl+G then q will quit the shell but leave the daemon running.

As the doc says, a remote shell is generally better, it starts a ‘new’ BEAM instance and just connects to the daemon remotely, that way you can kill the local instance without issue to the daemon.

I think Ctrl+D as the ‘end-of-input’ to do an implicit Ctrl+g, q in the shell would be very useful, it definitely should be suggested and/or PR’d to the OTP proper.

Post #7

— All posts loaded —