Fork me on GitHub
#chlorine-clover
<
2020-11-10
>
jlmr09:11:19

@seancorfield I’m trying out your vscode setup now (in VSCodium). Are you using Parinfer and if so how did you get it working?

seancorfield15:11:41

I have Parinfer installed but it definitely doesn't work "properly". I'm thinking of uninstalling it today and seeing how I get on with just Paredit (which does seem to work). Right now, I can't tell how much of my woes are Parinfer being "broken", i.e., making editing worse, vs just "not working", i.e., just not doing what I expect.

mauricio.szabo12:11:42

@jlmr when I tried VSCodium with vim-mode, parinfer and paredit, they kept conflicting with each other. I don't really know if parinfer works in this setup, I imagine it needs some tweaks.

mauricio.szabo12:11:04

I was even seeing if I could port my parinfer-plus from Atom to VSCodium

jlmr12:11:23

So far I only tried parinfer and no other tools, but its not working correctly (ie parens not moved/added where you would expect them). Could be something with the parinfer package, I was hoping someone else had already found a solution

pez15:11:25

Parinfer is not working all that well in VS Code. From what I’ve picked up in the #parinfer channel, Smartmode isn’t even possible.

mauricio.szabo20:11:40

I'm quite amazed on what you did on Calva, considering all the VSCode limitations and buggy APIs... I was trying to wrap up some observers as "pre-formatters" for parinfer and only format when VSCode lets me, but they all misbehave in some peculiar and bizarre ways...

mauricio.szabo20:11:15

Callbacks that say they will fire after an specific event are firing before, rows/cols that don't change, etc...

pez21:11:06

It's like I depicted it once 😃

pez21:11:00

It helps regarding oneself as the hero, haha.

mauricio.szabo15:11:25

I'm trying to find a "hacky way" to make it work. But I'm not expecting that much, really... VSCode really limits the way you can adjust text after an edit (and not "any edit" but only the ones they allow you to intercept) For example, I haven't found a way to trigger a "reformat" when you press backspace

borkdude15:11:24

@mauricio.szabo Do you also support the custom rendering using sci in vscode? ;)

mauricio.szabo15:11:14

@borkdude Yes, I do! 🙂. The only limitation is that you can't use external JS libraries like you could in Atom

🎉 1
mauricio.szabo15:11:29

For example, this code works if you paste on the config file:

(defn create-a-counter []
  (p/let [pos (editor/get-block)
          code '{:html [:div [:button {:on-click '?inc}
                              "clicked " '?state " times"]]
                 :state 0
                 :fns {:inc '(fn [_ state] (inc state))}}]
    (editor/eval-interactive (assoc pos :text
                                    (pr-str code)))))

mauricio.szabo15:11:58

It evaluates the inc function on the Clojure side, and everything else on sci

mauricio.szabo15:11:26

For example, this is the "custom command" that I use to run tests: https://gist.github.com/mauricioszabo/c2a756d5f5e363f6539cdad212815df1 It renders clickable stacktraces in case of exceptions, and makes it clear when something failed or not (instead of just printing on the console)

pez15:11:27

@mauricio.szabo the way Calva does a reformat after backspace is to register backspace as a keyboard shortcut. Then make the command for it perform both the backspace and the reformat.

mauricio.szabo15:11:05

Ah, right! That explains why it does not reformat when I use vim-mode 😄

pez15:11:27

vim-mode binds backspace?

mauricio.szabo15:11:05

Not really, but some commands do not trigger a backspace like "delete word". So while I was editing text, things were reformatting but when I changed to "command/normal mode" and tried to use vim commands, sometimes it did sometime didn't.

pez15:11:07

Thinking about it, I think Calva does not reformat on backspace, but on many other paredit commands it does. Should probably add reformatting, there…

mauricio.szabo15:11:49

I imagine that's when I triggered some "delete" commands on the vim side

seancorfield18:11:18

Re: Parinfer -- I uninstalled it and now I miss what things it was doing, so I've installed it again!

sparkofreason20:11:01

I starting to wonder if there isn't a place for a "parinfer light". I shut it off for awhile in Atom, found I mainly missed things like the maintenance of format when tabbing a form. I don't know that I actually use the "infer" part too much, and it usually seems to be the trouble-maker, often actively avoid it, such as when pasting in forms.

mauricio.szabo20:11:10

@U066LQXPZ are you using parinfer on Atom, or parinfer-plus?

mauricio.szabo20:11:29

(parinfer-plus should be considered less mature than parinfer, to be honest, but it addresses some of these issues)

sparkofreason21:11:24

I'll try parinfer-plus.

mauricio.szabo21:11:54

Please let me know if you find any issues with parinfer-plus 🙂.

1
seancorfield03:11:55

@mauricio.szabo Maybe you should port parinfer-plus to VS Code? 😉

mauricio.szabo13:11:01

@seancorfield I'm trying really :rolling_on_the_floor_laughing:. But the API is so limited and sometimes even buggy that my first experiments got me unpredictable results :(

sparkofreason15:11:12

Which maybe goes back to my original thought. Is there some subset of effective parinfer features that is useful and more easily implemented?

mauricio.szabo17:11:33

parinfer-rust is simply and easily implemented to be honest. You just have to get the state before the change and the state after the change, and then change the document with what parinfer-rust returns

sparkofreason20:11:39

That sounds workable.

mauricio.szabo21:11:30

Yes, but the problem is that VSCode API does not have 1. A way to capture the state before and after a change 2. A way to change current text 3. The only way to change text is by a FormattingEditProvider that only allows you to capture some changes - no backspace, for example, nor delete 4. onDidChangeTextDocument fires before the change is perceived by the TextEditor, so you can't know for example what's the current cursor position. Also, after FormattingEditProvider fires, if you issue changes to the document it'll fire "didChangeTextDocument" can fire again, so you have to catch this. 5. VSCode does not provide lots of APIs to, for example, by a "changes" object patch a text into another (also, there are at least 2 "changes" object, and they are incompatible between each other) These maybe are all workable in some way, but it's incredibly fragile. For example, you could hook onDidChange and run parinfer, accumulate the result, then apply then on edit provider, but there's still the case of multiple backspaces / deletions that will not fire the edit provider (and both smart-mode and paren-mode depends a lot on backspace)

sogaiu01:11:35

(fwiw, iiuc, other folks who've worked on parinfer also discovered that various editors lacked apis. i think there was some discussion of this in: https://www.therepl.net/episodes/17/ )

sparkofreason15:11:54

The tyranny of character streams. I wonder if there are any existing text editors that allow you to plug in at higher abstraction levels than individual keypresses.

mauricio.szabo15:11:10

@U066LQXPZ what kind of abstraction do you have in mind?

sparkofreason19:11:15

@mauricio.szabo It's an interesting question. I think the ideal for editing code is that the entity being edited is the AST or similar representation of the code, rather than the text representation. The textual representation would just be a transformation against that, perhaps combined with a bit of metadata around how the user wants to see it formatted (thus ending formatting wars in dev teams).

sparkofreason15:11:51

In something like Clojure, this is "easy", in some sense, as you only need to type one or two characters to establish the AST node type to be inserted. For other languages, I think you'd need something more like "snippets".