Fork me on GitHub
#unrepl
<
2018-03-30
>
cgrand08:03:33

@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)

cgrand08:03:05

I fear it’s going to look like the Homermobile

volrath08:03:18

I feel it's not needed in unrepl. this type of thing fits better in something like orchard

cgrand08:03:13

My hope was to define the contract (action) not necessarily the impl.

cgrand08:03:24

maybe I should stop worrying

kotarak09:03:29

@cgrand I agree with @volrath that such a thing should be in some separate library.

kotarak09:03:24

I'm also not sure that defining the action is actually the right thing todo.

kotarak09:03:11

Maybe. I could live with the transforming the input on the client side into the required vim format.

kotarak09:03:44

However that would be slower and bans me from adding possibly not contained information.

kotarak09:03:01

(There is always a feature you can add to the Homermobile. 😛 )

kotarak09:03:21

So I'd rather have a small wrapper around the library which does the heavy-lifting.

kotarak09:03:07

Whether this is hidden behind a commonly defined action or whether it's my own doesn't really matter, does it?

kotarak09:03:41

Having a common action would then mean, however, that only what goes in would be specified. The output would obviously differ.

cgrand09:03:34

the output would be specified but in a human readable form only

kotarak09:03:45

How can you do that?

cgrand09:03:19

By writing a document 🙂 and having you to read and implement it 🙂

kotarak09:03:23

Vim needs a map contain this and that key. Emacs requires a list. IntelliJ takes ......

kotarak09:03:37

How do you describe that?

kotarak09:03:52

You can specify only the inner heavy-lifting part.

kotarak09:03:12

Is defining the action worthwile?

kotarak09:03:28

Now that we expect to send the blob for kick-off?

kotarak09:03:50

No one ever sees the action except the connection counter-part.

cgrand09:03:01

actions were meant for one client to support multiple blobs

kotarak09:03:58

Is this a relic of "we connect to a unrepl server"?

kotarak09:03:26

The client is obviously in full control of the blob it sends.

kotarak09:03:48

For me the actions mainly take care of versioning and shading.

cgrand09:03:04

hey, you are the one developing just-in-time shading of user-provided actions!

kotarak09:03:14

And whether I have a local action mapping system or the one we have at the unrepl side now doesn't really matter.

kotarak09:03:27

Except for connection specific things like auxing.

cgrand09:03:51

you’ll have to support one blob per target (ok now there’s only one)

kotarak09:03:52

Not user provided! Extension provided!

kotarak09:03:00

They are not dynamic for a given connection!

kotarak09:03:16

Once you start up vim you are static.

cgrand09:03:52

I know there’s no way to quit

kotarak09:03:18

No. Indeed not.

kotarak09:03:30

I tried emacs, IntelliJ, Eclipse.

kotarak09:03:46

But my Vim kept running, so I thought I might as well use it. 😉

cgrand09:03:34

Real mensch write their own editor 😉

kotarak09:03:04

Harharhar. Only creatures of the night do that! 😉

cgrand09:03:05

How is The-Project-Previously-Known-As-Pinky going?

kotarak09:03:23

Öh. Waiting for me to finish working on Vimpire at the moment.

kotarak09:03:32

dummdidumm

kotarak09:03:24

But you can extend things.

kotarak09:03:32

Even with multiple targets, you are fully in charge of the resp. blob, aren't you.

cgrand09:03:07

yeah but my hope was that tools author would have basic intreaction ok without having to write custom actions for each taregt

kotarak09:03:50

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.

kotarak09:03:53

(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.)

kotarak09:03:29

(And async also not even being a unrepl problem, but a vim one.)

cgrand11:03:14

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))
The prefix gets shaded instead of the full namespaces

kotarak15:03:42

(... and caused by @kotarak. 😐 )

dominicm20:03:53

I'm not sure if this was noticed amongst the spec conversation: https://github.com/athos/spectrace/blob/master/README.md