I knew I was being daft!
@dominicm, I'm curious, are you working on something based on unrepl?
pesterhazy: not actively. But I'm in the hammock over it. I'd like to build a vim client eventually. My participation here mostly centers around me wanting to repeat cool things the Nrepl allows in the "new world"
I have a general interest in tooling too which helps
a vim client would be great, even a simple one
I guess one obstacle would be an edn parser?
@kotarak got one I believe
an edn parser in vimscript??
Yeah.
It exists
he mentioned something like this to me yes
beautiful 🙂
Speaking of :set-source
, there’s the open question of knowing reliably when it starts to apply. Scenario; the user submitted three benchmark forms at once, the 1st form is being evaluated, the other two are waiting to be read. Meanwhile the user wants to evaluate some form from a file (with corresponding source info set).
This raise at least one edge cases and several questions:
• if :set-source
occurs on a separate connection it shouldn’t apply bafore the 2 pending forms are evaluated
• evaluating from file also require to set the ns, should eval from file and repl share the same session?
• if :set-source
is async how do we know when it applies (or when to apply it)?
Yup. I have one. Untested. Ugly. Probably slooooow. It's viml after all. 😊
Currently I’m leaning towards adding an extra param to :set-source
: the offset where it must become active. Still unconvinced
Yeah. I had wondered about the async and multi form versions of that. This, I suppose, is another part of the trade off of not "wrapping" input forms in a special way.
wrapping on the “aux” connection is acceptable
It’s a related concern but there’s something that bugs me with eval-form-from-file
after some time the lines/cols are all wrong, ideally the editor should version files at each eval-form and makes the version id part of the file path
Back to my question on :set-source
, should “eval-form-from-file” happen on the repl connection? Should it alter *1
and friends? Should it be concurrent? In my experience (I’d like to know yours) the only integration I care about is having it appears in the repl logs so as to be able to review the log more easily. This may be a pure client feature
I use *1 and *e for things evaluated from a file
From a tooling perspective *e is invaluable for formatting exceptions
True, most of the time it’s only defstuff but when it fails *e is useful (would a nice exception browser meets this need?)
@cgrand perhaps. I hear Cider's is really good (you can click on lines and stuff).
@dominicm yeah but it asks too much of the client
@cgrand indeed. I'm starting to look at how vim can even have something close (although, it is based on a generic exception viewer I think, not dived in yet)
so new small change, the :prompt
message lists :column
and :offset
.
This si interesting for two reasons: the client can keep track of the progress of evaluation without counting chars itself
By checking if last :echo
‘s :offset
+ :len
is equal to current prompt :offset
the second reason is that you can easily spot when :set-source
applies (you don’t have control over when it applies yet)
dominicm: no no you don't click in cider 😁
I mean, you'd use some kind of keybinding 🙂