On :print-limits session action and REPL state

[volrath]

There are two common scenarios in which a client might want to edit print limits (a.k.a. modify REPL state):

1. At init time, provided the client lets its user tweak certain aspects of the REPL connection.
2. As a one-off operation, where the client only needs to modify the REPL state for one loop (eval/print).

In any of those circumstances, the client might want to edit just one, or several, state variables.

Current implementation's pain-points:

• one-off operations entail possible callback-hell on the client side, there are at least two annidated callbacks to be executed that need to carry results from the initial operation. Example

-> send command to edit print limits to MAX_VALUE
   -> callback (carry the default print-limit values):
      send some action (i.e. "request docstring for symbol") that expects long lines not to be elided
      -> callback (carry the default print-limit values):
          revert print limits to default.

• There is no way to edit just one state variable. If a client wants to only edit *print-level*, it has to call the :print-limits action with all the other bindings. Furthermore, the client has no way to know what are those values the first time.

Proposal:

Improve api to handle REPL state variables by:

1. Adding initial state to :unrepl/hello.
2. Replacing :print-limits action for a more flexible version of it that can change a subset of variables at a time. Maybe also rename it to something more generic, in case more variables are added in the future.

--

Also, an idea I would like to bounce here: what about adding a function that handles one-offs state modifications internally, something like:

{:some/session-action (binding [*print-limit* Long/MAX_VALUE]
                        (foo/bar :unrepl/param :a-param))}

This would mean improving (ensure-ns) to recursively search for fully qualified 'function' symbols and requiring them, and to have another variable in the REPL's state that tracks reverting the binding.

--

If accepted, I could code the result of this conversation.

[cgrand]

Not addressing all points but:

:print-limits
Set print limits (pass nil to leave a limit unchanged). Returns a map of param names to original values.

So you can know the current values and you can also set only some values

[volrath]

Right I missed that, although I think that isn't enough.. with that approach, you can't set values to nil ever. A bit worse than that, in the current print-limits setup, both *print-level* and *print-length* are nil by default, so if you change them once, you will not be able to reset them to default.

This is my current solution to address temporary print limits binding: volrath/spiral@6391f99, I'm not in love with it, but it does the trick and it might be good enough for the problem.

[cgrand]

Setting both to a high value (e.g. Long/MAX_VALUE but smaller big values would be good too) is a workaround for nil.

The value you observe for *print-level* at the repl are not the values used at print times. Is this a bug?

[volrath]

huh, I thought It was weird that *print-level* was nil.. that's what comes from executing the :print-limits session actions, so it's basically the bak# backup. Seems like a bug.

This is what I get back from a first update:

[:eval {:unrepl.print/nesting-depth nil, :unrepl.print/coll-length nil, :unrepl.print/string-length 80} 1]

[volrath]

From slack:

• Currently it's not possible to edit settings (dynamic bindings) from one connection to another
• Because of this, the only way to change settings in "user" connection is to send action commands through it, which is a big NO-NO.
• One set of settings REPL wide is not enough, one per every print context (eval, log, ex, ...) is awkward.

[kommen]

Currently it's not possible to edit settings (dynamic bindings) from one connection to another

We just ran into this, as we assumed all :action can/should be sent to an aux repl. A clarifaction in the spec would be helpful, I guess.