Fork me on GitHub
#parinfer
<
2016-01-23
>
snoe00:01:39

I've updated nvim-parinfer.js to use the new javascript lib. https://github.com/snoe/nvim-parinfer.js It's significantly faster (and has very little code) now, nice job @shaunlebron

shaunlebron02:01:03

I didn’t know you could use a js lib like that from cljs. I guess that’s what the new module-type option in foreign-libs is for

shaunlebron02:01:46

I was actually going to release a new version some time tonight, with a cljs wrapper to publish on clojars

shaunlebron02:01:36

I wonder if you still need externs

snoe03:01:58

Yeah, it was actually pretty painful as I was trying the cljsjs version, and the wrapper etc and getting nowhere. Lots of interacting systems and it was hard to know what was causing my problems.

shaunlebron04:01:47

@snoe I wonder what problems you were getting

snoe07:01:23

First, it took me awhile to figure out the :module-type and that cljsjs wasn't/didn't have the capability to set it. Basically, I'd see parinfer on js/module.exports but using multiple js libs would overwrite it. This was exacerbated by things seemingly working fine with :optimizations :none but not working with :simple. So, I tried for to get the plugin working with :none however both cljs and neovim-host are replacing node's require(...) and I suspect neovim-host is doing something bad with sandboxing modules. I ended up dropping that line since I couldn't get to the root of the problem. I went on to writing my own :foreign-libs and I found the :module-type option. That seemed to get me further with :simple but closure was throwing an error about redefining a const but not when using :none. I remembered looking at the :closure-warnings map previously and on a whim tried to :const :off and it finally compiled. So... I think cljsjs could improve with support for :module-type, I think either node-host or cljs w/node has a bug in their patched require, and I think cljs or closure should have that warning turned off with optimized compiles (or be able to catch the error when it's caused by the UMD rewriting).

meow13:01:41

@snoe: have you brought any of this to the attention of #C0E66E1H7?

dominicm17:01:26

@snoe I'm gonna update soon.

dominicm17:01:34

My team is trying to convert me to Emacs

shaunlebron19:01:33

@snoe: I also ran into the “cannot redefine const” error in closure, and posted it to the mailing list last week

shaunlebron19:01:26

It has to do with UMD style not recognizing that module.export can be defined inside an IIFE

shaunlebron20:01:42

@snoe, also parinfer-cljs (the cljs wrapper of parinfer.js I’m trying put out), I’ve confirmed it doesn’t work on Node

shaunlebron20:01:53

you were probably trying that

shaunlebron20:01:13

it’s interesting because requiring the cljsjs/parinfer library in cljs has different behavior depending on the environment

shaunlebron20:01:13

it seems useless in a Node environment, because I need to use require, but I don’t know how to “node require" a file that was prepended to the compiled output of the source that I’m inside of

meow23:01:28

on my todo list to try out Proton with Parinfer

shaunlebron23:01:15

hmm, that’d be neat, hadn’t heard of that

meow23:01:20

#C0GCNE3B3 is Atom-based spacemacs with parinfer and repl

meow23:01:21

looks like it is shaping up quite quickly

snoe23:01:49

Right on.

shaunlebron23:01:17

oh, I didn’t know it was integrated, neat!