This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
@sogaiu Could you elaborate on that? What has made Atom harder to debug than Emacs when something goes wrong?
finding relevant error output - sometimes the dev tools console and other locations do not show anything upon failures. here is an example situation: https://github.com/atom/symbols-view/issues/159#issuecomment-544118286
Interesting. A feature I didn't know existed and have never used. Chlorine's go-to definition works flawlessly for me so I've never looked to see whether Atom had anything similar (and I'm not a vim user so this sort of thing wouldn't have occurred to me).
i have generated tags files (https://github.com/sogaiu/alc.index-defs) for clojure projects that cover symbols that are within dependencies. having this feature not function well makes using atom for reading code (particularly other people's) much less appealing to me compared to emacs, vim, or vscode, where i had luck getting it to work.
i find it greatly helps me in reading source -- to be able to reach a definition quickly is invaluable for me.
guessing that you might be suggesting using the repl (sorry if i'm off on that)... i don't always have a running jvm or js runtime when reading source. there are a number reasons for this: * i don't necessarily want to run other people's code without being somewhat familiar with it * it's sometimes not trivial to get other folks' code running so it can be an impediment to rely on a running process just to read code * it doesn't seem worth starting up a runtime to do some reading sometimes
You don't need to run the code to be able to use the REPL, just compile it. I always have a REPL running and can always compile code into it. I rely on REBL quite heavily for understanding code structure (browsing namespaces and var use graphs). Interesting to hear about such a different approach tho'...
I was even thinking on migrating clojure-lsp to run in ClojureScript, so I could add some syntatical analysis to Chlorine