Fork me on GitHub

Is there any way to hook saving file and call chlorine:clear-inline-results after that?


I believe you can do it using the init.js script. You can listen to text editors, listen to some callbacks, and so on. You probably want atom.workspace.observeTextEditors:


or you include an option that "Clean evaluates after save"


are you going to replace init.js after update?


init.js (or is a file that's user-specific


oh , sorry init.js is for atom not chlorine


Yes, the atom specific 🙂


something like

atom.workspace.observeTextEditors (editor) ->
    editor.onDidSave () -> atom.commands.dispatch(atom.views.getView(editor), 'chlorine:clear-inline-results')


I think a workflow based on actions-on-save is flawed. I work without saving code a lot. I evaluate code as I write it and change it. I run tests too without saving changes. I clear inline results when I want. I save when I want -- and don't want any magic happening at that point.


I think people need to get away from save-watch-run style workflows.


But I'm very opinionated about workflow 🙂


(luckily with Atom you can customize this any way you want but...)


Yes, but once you evaluate, evaluate, evaluate it become very anoying and messy


in Cider you only press ESC and done


so, this is adapt that guy from Emacs


I find it very helpful to keep all those inline results around until I decide to get rid of them. I'd hate them all to vanish if I accidentally saved a file in the middle of some work! :rolling_on_the_floor_laughing:


I used Emacs for years (technically decades). I've never looked back since I switched to Atom tho' ...


I´m in transition of it !!! 🙂 Cider is very very good


and the best tool for Clojure is clj-refactor


have you ever used it?


I think we can implement any kind of functions inside it in Atom


like you did in sean:... to use with rebl


I've never felt a need for any automated refactoring tools.


I think people rely too heavily on "tool support".


Watch Stu Halloway's talks on "Running with Scissors" and "REPL-Driven Development". Watch Eric Normand's excellent course on REPL-Driven Development.


It's the "Java disease" where people rely so heavily on IDE support that they no longer know how to write code in a plain editor.


I think in the way that the tool (IDE, editor, refactor ...) gives you support to do things that you think less to be more productive


I disagree -- I believe that "thinking less" is a mistake. Fully understanding your (basic) tools is important. IDEs and refactoring tools lead to more "magic" and less "understanding". People who rely on them stop being able to do those actions without tooling support. Digital amnesia


I remember one job in Clojure where people used mostly Intelij. The editor hide imports, adds and removes then at will, and also adds aliases for you. Some files imported 80 namespaces, and lots of test files had syntax errors (load file didn't work, but for some reason running tests worked fine). Also, some aliases were completely impossible to decipher - things like a-tx-inc-ml were common


As most people had a tool that organized these things automatically, people were used to not look at the namespace declaration and think "maybe we're importing too much..."


I hate IDEs for that exact reason 😞


(it's more widespread than just smartphones)


but if you think like clj-refactor helping me to organize :require stuffs that I included and clean that I do not use is very useful for me, that´s the way I mean about "thinking less" or "left using manual stuffs"


like you said "(luckily with Atom you can customize this any way you want but...)", in this case doing stuffs that can help me to be more productive, and the tool can be anything that you been conformtable


There are some feature that I'm planning to support from cider. In order of my personal preference are orchard extensions for documentation and goto var definition, hotload dependencies, organize ns, debugger and refactor. But the thing with Chlorine is: it'll never inject anything on the classpath. So, it'll use these features if they are present. If not, there will always be a "default option"


What I do use is a real-time linter (`clj-kondo`) that prevents me from making a lot of mistakes that would need to be refactored later 🙂

👍 4

I´ve never used linter


i hadn't used a linter much until clj-kondo, but it's near real-time capability completely changed my opinion of the worth of such a thing. to be informed while context is still fresh in one's mind is invaluable imo.


I'd been using Joker for ages and found it useful enough, but clj-kondo is a game-changer.


ah, that's interesting to hear. is there somewhere i might read up on some of those details?


What do you mean?


Joker only does a small subset of what clj-kondo does.


ah ok -- i had never used joker, so i didn't know. so perhaps part of it is that clj-kondo manages to overcome a certain threshold of usefulness for enough people.


Joker does basic unused requires and unused bindings stuff and local arity checking. Useful enough to be worthwhile.


But until recently I had no idea how much stuff clj-kondo did.


I finally decided to try it out... and switched immediately... and committed a .clj-kondo/config.edn to the repo at work! 🙂


great! i found it a bit overwhelming to configure, so i haven't tuned it -- except for one case where i was using it programmatically and needed to turn off all of the linting.


I only used Joker so far, mostly because it was already installed (because it is also an interpreter with socket-repl support), but I'll try clj-kondo after this thread 😄

👍 4

There's a linter-kondo package to wire up Atom to the command line clj-kondo command. Works well. Pity it only supports warning/error levels, not info.


I just double-checked the source code and linter-kondo isn't at fault here -- clj-kondo itself only produces a non-zero exit code for warning/error levels and that's what triggers the linter to decode/display the summary results.


i'd like to add a point to the refactoring discussion -- i have heard these types of discussions multiple times, but have always left feeling they tended to remain abstract. i think if concrete cases were discussed it would be much more enlightening to all parties involved. especially in the realm of cs / it, people seem to have very different notions of terms.


Ohhhh 😀


I like that I can configure clj-kondo a lot: I've made unsorted requires an error 🙂


And Borkdude is so responsive and works so hard to make it better all the time.


indeed, those are definitely important points!


Part of why I'm so passionate about Chlorine is because @mauricio.szabo is so responsive and proactive. The same is now applying to clj-kondo too.

😄 4

i agree, @mauricio.szabo has been (and continues to be) great! it would be nice if this were true of more projects, but it is not so easy.

😄 4

As someone who maintains a bunch of projects, yeah, it's definitely hard to be that responsive and that proactive!


i often wonder if it wouldn't be helpful if there were a "successor" or "co-maintainer" in training. kind of like what the romans used to do 🙂


For some projects, that naturally happens. I'm the third maintainer of tools.cli, the second for java.jdbc, the second for and core.cache and core.memoize. The third for honeysql too I think? Maybe also clj-time. I was the second or third maintainer for congomongo and handed that off to someone else.

parrot 4

Not all projects deserve to live. Important projects always get new maintainers. If a project dies for lack of a maintainer, then it wasn't important enough to live.


it's nice when it works out, but i don't think it does all of the time.