Clojurians Log v2

<@U3Y18N0UC> i think i can describe what leads to the config option not appearing -- and how to make it appear. i don't understand the details, but: 1. when i symlink atom-chlorine's clone repository under ~/.atom/packages, i typically have been doing: `cd ~/.atom/packages &amp;&amp; ln -s ~/src/atom-chlorine` -- this creates a symlink with name "atom-chlorine" -- this leads to the settings button not appearing for me in manjaro linux, ubuntu, and macos 2. if instead i do: `cd ~/src/atom-chlorine &amp;&amp; apm link` a symlink is created in ~/.atom/packages with the name "chlorine" -- the settings button appears now -- at least in manjaro linux and ubuntu (haven't tested macos yet)

i thought it used to work with method number 1 -- but in any case, if method 2 really does work for others, perhaps the instructions at: https://github.com/mauricioszabo/atom-chlorine/blob/master/docs/developing.md can be updated (happy to draft some text)

the current text reads: > If you symlink your directory on ~/.atom/packages, you can use it while developing itself!

as an experiment, i changed the value for the "name" key in package.json to "atom-chlorine" and named the symlink to match (i.e. atom-chlorine) -- now the settings button appears. perhaps the displaying (functioning?) of the settings button is dependent on this sort of correspondence.

That's certainly what I would have I expected. The name in package.json should correspond to the directory name in ~/.atom/packages

the repository is currently named "atom-chlorine", the value in package.json for the "name" key is "chlorine"

fwiw, apm link does this i guess: https://github.com/atom/apm/blob/master/src/link.coffee#L35_L52

Exactly. They need to match

The README could (should) be clearer about this but I thought it was obvious.

which README are you referring to?

The developing link you posted above I guess.

Sorry, I think of that as the readme for developers 🙂

i don't know why the names matching is considered obvious

I don't know why anyone would think they could be different 🙂

when you make a symlink, one of the common ways is to not specify the name of the target, no?

When you install Chlorine, it creates ~/.atom/packages/chlorine so if you symlink it instead, it must match.

if you start with developing and not the package, you wouldn't know this 🙂

I never do a symlink without specifying the target. It would never occur to me.

I actually didn't know you could omit the target! So TIL!

well, much til for me too 🙂

It's really hard to write documentation. I think that's the number one thing I've learned. Because everyone has different backgrounds and different expectations.

to be clear, i am not accusing anyone of anything 🙂

I just answered a question about next.jdbc on the Clojure mailing list -- I had to read it several times to even understand what the OP was asking (and even now I'm not sure)... Their question was so at odds with my understanding/expectation of how you write Clojure.

this is not an uncommon experience for me -- i find a fair bit of what i read to be difficult to interpret

I just sort of assume anyone trying to hack on Chlorine would have installed it directly first -- and seen the package name was chlorine -- and only later tried to symlink the repo into that folder so they'd have known the name. Which clearly is not a universal assumption.

So you've brought a very valid and different perspective to the table which indicates the documentation really does need to be updated.

It always amazes me the stuff folks ask me to document or explain on the projects I maintain -- even after nearly 30 years of maintaining OSS projects! I'm terrible at documentation!

i don't think you're terrible at docs -- i've been helped by them on more than one occasion. i find them to be on the clearer side, fwiw.

Well, thank you. I aspire to better docs but I'm realistic about my background/thought processes not being in the right place to create introductory material a lot of the time... 😞

https://github.com/mauricioszabo/atom-chlorine/pull/113

thanks for the pr!

Wow, thanks for the investigation of this issue!

Just merged the PR. Thanks @seancorfield. And yes, writing good documentation is really hard 😄