Clojurians Log v2
unrepl
@kotarak @volrath @pesterhazy is there any sense to define a common complete action then? (yes I can take the union of what all of us are doing)
I fear it’s going to look like the Homermobile
I feel it's not needed in unrepl. this type of thing fits better in something like orchard
My hope was to define the contract (action) not necessarily the impl.
maybe I should stop worrying
I'm also not sure that defining the action is actually the right thing todo.
Maybe. I could live with the transforming the input on the client side into the required vim format.
However that would be slower and bans me from adding possibly not contained information.
(There is always a feature you can add to the Homermobile. 😛 )
So I'd rather have a small wrapper around the library which does the heavy-lifting.
Whether this is hidden behind a commonly defined action or whether it's my own doesn't really matter, does it?
Having a common action would then mean, however, that only what goes in would be specified. The output would obviously differ.
the output would be specified but in a human readable form only
How can you do that?
By writing a document 🙂 and having you to read and implement it 🙂
Vim needs a map contain this and that key. Emacs requires a list. IntelliJ takes ......
How do you describe that?
You can specify only the inner heavy-lifting part.
Is defining the action worthwile?
Now that we expect to send the blob for kick-off?
No one ever sees the action except the connection counter-part.
actions were meant for one client to support multiple blobs
Is this a relic of "we connect to a unrepl server"?
no
The client is obviously in full control of the blob it sends.
For me the actions mainly take care of versioning and shading.
hey, you are the one developing just-in-time shading of user-provided actions!
And whether I have a local action mapping system or the one we have at the unrepl side now doesn't really matter.
Except for connection specific things like auxing.
you’ll have to support one blob per target (ok now there’s only one)
Not user provided! Extension provided!
They are not dynamic for a given connection!
Once you start up vim you are static.
But you can extend things.
I know there’s no way to quit
😄
No. Indeed not.
I tried emacs, IntelliJ, Eclipse.
But my Vim kept running, so I thought I might as well use it. 😉
Even with multiple targets, you are fully in charge of the resp. blob, aren't you.
Real mensch write their own editor 😉
Harharhar. Only creatures of the night do that! 😉
How is The-Project-Previously-Known-As-Pinky going?
Öh. Waiting for me to finish working on Vimpire at the moment.
dummdidumm
yeah but my hope was that tools author would have basic intreaction ok without having to write custom actions for each taregt
Hmm.. Since I have no clue about ClojureScript, that was not my concern. I see the problem more on the client side. That each client has its own requirements and interfaces.
(Eg. the completion in vimpire is actually voodoo. Normally the interface is syncronuous. And they do some black magic to make it asyncronuous. Otherwise I wouldn't be able to provide completion, because the connection is async.)
(And async also not even being a unrepl problem, but a vim one.)
Shading with find & replace failure:
(ns compliment.core$lGKpTGw5kbRXJ4kBA9SDwnNAxCE
"Core namespace. Most interactions with Compliment should happen
through functions defined here."
(:require (compliment.sources$p8UbKISrPlDh$sMwHBsmdzBLjpU ns-mappings
namespaces-and-classes
class-members
keywords
special-forms
local-bindings
resources)
[compliment.sources$p8UbKISrPlDh$sMwHBsmdzBLjpU :refer [all-sources]]
[compliment.context$50K5FJhtgeO$CW7edfPjhgFPlr8 :refer [cache-context]]
[compliment.utils$YmBUUrJwullK9KE0yVCYElF$2Xk :refer [*extra-metadata*]]
[clojure.string :refer [join]])
(:import java.util.Comparator))(... and caused by @kotarak. 😐 )
I'm not sure if this was noticed amongst the spec conversation: https://github.com/athos/spectrace/blob/master/README.md