Clojurians Log v2
unrepl
Should :set-source (optionally?) include the namespace?
should it evolve in something more general (eg set-env)
Maybe?
I need now five calls for eval. Set nspace. Set source. Eval. Revert nspace. Revert source.
That feels clunky.
and are youd doing the eval on the user connection?
Eval is now an operator compatible with vim-sexp.
Woohoo 🙂
The other flavours will go away.
@kotarak says >>> I need now five calls for eval. Set nspace. Set source. Eval. Revert nspace. Revert source.
all of that to evaluate a selection in a buffer
Evaluating from a buffer is different from the typical repl interaction because: 1/ it’s framed (I usually expect evaluation to fail if selection is malformed) 2/ it overrides most of the repl context
You got actually another point! Syntax check! So it would be actually six evals.
syntax check? Isn’t this what I mean in 1/?
Yes. I don't do it, yet. 😝
Should this happen on the user connection? why? why not?
For me it happens at the tooling connection. The user connection is never touched. Maybe the revert could be saved...
From a UX point of view, is it integrated with the repl buffer/transcript?
No.
Just to be clear: these questions are meant for all of us, not Meikel alone
Side-band transmission. Only user interaction is repl buffer relevant.
That's what I do and will do. It was not that it necessarily has to be that way. (Just to be clear. )
Now you get :read events for everything that is consumed
whitespace ✅ malformed code ✅
Malformed code? How can I resume? Eg. when a trailing paren is missing? I don't know in which state things are when the tooling repl evals some code (eg. a defn) on the users behalf. So I can't resume. The connection has to be reestablished.
For me the tooling connection is the master where everything is auxed from. So this would be rather annoying.
Trailing missing paren is not malformed it’s just waiting to be closed. (In a steaming context)
:read events should cover the entire input
also there’s a new :file key in the :read payload
Yes. So I still have to check the readability of the snippet.
@kotarak GOTO https://clojurians.slack.com/archives/C4C63FWP5/p1520351265000730
Goto considered harmful. ;-)
Read from string also has the problem of missing source info.
For now I do syntax check ( and report problems). Problem remaining is that only the last result is reported for several forms in one request. Similar for problems. So this is not really framing.
Urk. Not even the last, but only the first. 🤦 I have to implement read tracking. I will see how vim and :offset agree.
@kotarak all my commits since yesterday are baby steps towards an hopefully better solution.
I was syncing on prompt. But there might be newlines.....
How about allowing to set the id part of the responses? That way the clients could identify their frames without changing anything on stream input. Similar to set-source. So far the provided id is of no use to me... (unrepl/do (start-frame)) (form1)(form2) ... (formN) (unrepl/do (end-frame)) ... start-frame returns an id, which is used in the forms' responses. end-frame acts as an await to identify when all forms are done evaling.