Fork me on GitHub
#chlorine-clover
<
2020-10-27
>
sparkofreason15:10:11

More of an atom question, but hoping perhaps it's related to the typical clojure/chlorine setup in atom. When editing non-clojure files, like JSON, the auto-indent behavior inside of any brackets is broken, defaulting to indent to the space after the previous opening bracket when inserting a newline. I've tried toggling the obvious things like Auto Indent in the editor and language-specific settings, nothing seems to have an effect. Has anybody else seen this?

seancorfield16:10:53

@dave.dixon Sounds like your default binding for enter is to lisp-paredit: newline (which I have in my keymap to deal with other quirks I don't like). shift-enter should give you a plain newline I believe.

sparkofreason16:10:10

Thanks, that was it. I'll see if I can scope that binding to Clojure files.

sparkofreason16:10:56

Separating the newline definition into its own block like this seems to work. Curious if there's some reason you don't do that (i.e., where is it going to bite me?)

'atom-text-editor[data-grammar="clojure"]':
  # paredit:
  'enter':          'lisp-paredit:newline'

seancorfield16:10:33

I can't remember the problems I ran into -- it was a long time ago -- but I should probably do that too and see if I bump into anything odd. I always knew it was a bad idea to blank route enter to paredit 🙂

3
seancorfield17:10:36

So far, so good. Will ping back here with anything I run into...

mauricio.szabo17:10:09

By the way, this conversation is the reason that I don't register keybindings for Chlorine. Atom keybindings are quite confusing, and there was a time when I had to register "enter" and "tab" for some specific parts of connection to work - then, if someone wanted to disable all keybindings, he would not be able to connect for example. (and, disabling specific keybindings for a specific package is quite difficult)

seancorfield17:10:09

Yeah, it's a very flexible system and also easy to shoot yourself in the foot with it 😐

Mattias18:10:47

Wise choice. A common annoyance is shortcuts that assume a certain regional keyboard - a bunch of standard keys on US keyboards require special switches on many European keyboards. Ugh.

mauricio.szabo17:10:09

By the way, this conversation is the reason that I don't register keybindings for Chlorine. Atom keybindings are quite confusing, and there was a time when I had to register "enter" and "tab" for some specific parts of connection to work - then, if someone wanted to disable all keybindings, he would not be able to connect for example. (and, disabling specific keybindings for a specific package is quite difficult)

sparkofreason19:10:55

One thing I've noticed recently is that if I interact with the inline results from evaluating forms, the editor pane ignores keyboard input, or maybe redirects it so you can interact with the output (ENTER seems to open/close maps, for example). That's probably by design, but is there some command to escape back to the editor? I can click on the text, but wondering if there's some key-binding I could use/make.

mauricio.szabo19:10:02

Well, it's not really by design... it's because the focus gets redirected to the inline result. I don't know if there's a workaround, to be honest... but it also bugs me 😞

seancorfield19:10:16

It's partly why I like working with Reveal alongside Atom/Chlorine. I can alt-tab to Reveal when I want to interact with results and then alt-tab back to the editor. I almost never interact with the inline results (except, occasionally, to click into exceptions/stacktraces to expand them... and I'm thinking of changing my eval shortcuts so those get caught and tap>'d into Reveal...

seancorfield19:10:48

(I can't catch all exceptions that way -- e.g., load-file failures -- but it would handle most evaluations I do)