This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # architecture (20)
- # aws (22)
- # babashka (41)
- # beginners (191)
- # chlorine-clover (66)
- # cider (19)
- # clj-kondo (54)
- # cljs-dev (15)
- # cljsrn (78)
- # clojars (1)
- # clojure (148)
- # clojure-android (4)
- # clojure-europe (7)
- # clojure-gamedev (15)
- # clojure-germany (6)
- # clojure-losangeles (46)
- # clojure-nl (23)
- # clojure-survey (3)
- # clojure-uk (46)
- # clojurescript (24)
- # conjure (21)
- # crux (37)
- # cursive (21)
- # data-science (11)
- # datomic (5)
- # events (2)
- # fulcro (28)
- # garden (32)
- # joker (2)
- # kaocha (6)
- # lambdaisland (4)
- # mount (2)
- # off-topic (11)
- # pathom (10)
- # pedestal (13)
- # re-frame (7)
- # shadow-cljs (15)
- # spacemacs (21)
- # specmonstah (1)
- # wasm (1)
- # windows (1)
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
And when this calls back, you register another callback: https://flight-manual.atom.io/api/v1.45.0/TextEditor/#instance-onDidSave
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 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' ...
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 http://amnesia.kaspersky.com/
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..."
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 🙂
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?
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.
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 😄
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.
I like that I can configure
clj-kondo a lot: I've made unsorted requires an error 🙂
Part of why I'm so passionate about Chlorine is because @mauricio.szabo is so responsive and proactive. The same is now applying to
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.
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
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.
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.