Clojurians Log v2

:thumbsup:

@jessejanderson: I'm trying to merge your pane PR but it doesn't even compile for me

I'll take a closer look later but if you're faster than me, please let me know

theme comparison. material+material-dark vs nucleus+atom-fusion

wow

proton handles handlebars beautifying better than spacemacs

@dvcrn: can the errors only show for the given buffer?

@robbyoconnor: need to check that!

yes there is

[linter.statusIconScope "File"] should do that. Gonna put that as default for the next release

It's not a biggy

it also annoyed me. Just never got around to check it

Question: what does it use for beautification?

we started adding https://atom.io/packages/atom-beautify but not sure no the exact state

I think @geksilla started with it

and stuff that isn't supported by it, we just add whatever is available

(ruby is for example done with rubocop format)

I use rubocop to format my ruby

just updated my proton install

@dvcrn I would like to set default theme nucleus + atom-material-syntax.

nucleus is the one of the best themes, because it's adaptive and looks awesome with any syntax theme.

also we can pre set some default profiles with theme-switch

btw fusion theme also awesome )

@geksilla: I think we should integrate your surround keymap by default

ok

I will send PR. @robbyoconnor did you start to wok on it?

work on what?

@geksilla: I gave up -- i pulled your keymap and keybindings in

ok, thought you want to send PR. I will add it.

for vim-mode we can use vim-surround package. https://atom.io/packages/vim-surround

I dont wanna send a PR -- I'm already spread thin with OSS

contributions

sent PR regarding surround support.

How does it work for vim-mode

as far as I can see that works for vim-mode-plus only... :X

@robbyoconnor, vim-mode-plus enabled by default and has built in support for surround

vim-mode is developed by atom core team and has no support for surround

for vim-mode there is a plugin https://atom.io/packages/vim-surround

so for vim-mode-plus we need to add appropriate key maps to trigger surround actions

but for vim-mode package we need to install additional package vim-surround

ah ok

❤️

to me the power of vim is the fact i can copy/paste without using my mouse

I'm not interested in an editor war -- so long as I have modal editing im happy

cute plugin https://atom.io/packages/git-time-machine

spacemacs had something like that in the minibuffer

we need this! https://atom.io/packages/nyancat

lol

I had this plugin enabled for spacemacs )

We need more fun layers 😄

https://atom.io/packages/typewriter-sounds

That was my favorite

nice, will try it

sadly doesn’t work that great with vim mode

hm

seems like people really like “spaceatom"

typewriter + power-mode + nyan-cat and my coworkers will never take me serious again lol

))))))))))))

@dvcrn what is the status of doc_helper branch?

just wondering what features missed

putting everything together and writing it into a README file

need to think how to run it properly. We can’t use shadow-build or leiningen (ping @thheller) to collect all the things because of cljs artifacts. I think it would fail right away. I saw that better cljs repl support is coming in the next version though

alternatively, maybe planck for mac can help us with 1-time off scripts (for generation)

For now we can try to use it for key bindings discovery.

Similar to spacemacs when you can hit Ctrl-h during which-key buffer

For layer and other docs we can just copy all readme files to some directory for released build

For example you type SPC h l will start dialog with list of available layers

on selected item will open appropriate readme

nyancat needs to go in the colors

let's model spacemacs

:simple_smile:

They're doing stuff right

We should slowly aim to match the layers of spacemacs

nyan cat isn’t really a color tho 😛

it’s a fun package that’s toggle-able. It seems obvious to me where to put it 😉

layer -> fun/nyan-cat keybinding -> SPC t f n (toggle -> fun -> nyan cat)

@dvcrn: what's up?

@thheller sooo

each layer is exposing keybindings and readme fragments over multimethods. Within proton / cljs we just collect that and generate the prefix tree with that. Now we want to use that information to generate README files. We need a solution to execute all of the cljs code and writes out files

any thoughts on this? I was thinking of just compiling everything down to javascript and load it inside node with calling it’s exposed commonjs functions

uhm I don't quite follow

you have a bunch of cljs CODE that you want as data?

do you have an example?

each layer’s multimethod is returning a hash (or vector of vectors) that defines the keybindings and settings each layer needs to operate

that information is what we show inside READMEs as well but right now that’s very manual

the part where I was wondering if you have some ideas is how to execute a one off cljs runner that just calls all these multimethods, collects each layers settings and writes out a bunch of README files

is there a way to do this with shadow-build or is the node / browser REPL the only real way to achieving this?

again I don't quite follow

where can I find one of those multi-methods?

sec

here for example https://github.com/dvcrn/proton/blob/master/src/cljs/proton/layers/lang/ruby/core.cljs#L21-L59

or here for required settings https://github.com/dvcrn/proton/blob/master/src/cljs/proton/layers/lang/ruby/core.cljs#L10-L12

and this is how a readme looks like https://github.com/dvcrn/proton/tree/master/src/cljs/proton/layers/lang/ruby

why are those not actual "config" files?

nope, pure cljs trees :simple_smile:

@thheller: you never saw spacemacs? The fact this is done in clojurescript is kinda epic 😄

😄

again: why is it code?

it would be the exact same structure if it was edn?

@thheller: why not?

Sometimes there's logic that needs to be run

sometimes we need to react on user config and dynamically adjust packages / settings/ etc

yah

that is not logic that runs

that is static data

just trying to understand it, not saying it is wrong or anything

aaanyway

the part we want to do next is to collect all of that and spit out readmes for each layer

though my cljs knowledge is still a bit limited in what the best way for this is

I bullshitted my elisp for the past 6 months

suppose you have a config file like this

https://gist.github.com/thheller/594357dbae686e01f1c9

wouldn't that yield the same thing?

but since its pure data, not code

you can access it simply without executing it?

you can even write a simple shadow-build importer

that generates the desired code from it

if it really has to be code?

but .. if you are fixed on the idea of code

yes you can use shadow-build to generate a launcher/util for you and node to execute it

I’m not sure how edn deals with anonymous nested functions, for example https://github.com/dvcrn/proton/blob/master/src/cljs/proton/layers/core/keybindings.cljs#L93-L104

same thing just a whole lot more complicated

don't make it an anonymous function

big smell if you repeat something like that 4 times

:target that-package.util/helper-fn

yah 😅 we started doing that for other things

in anyway, how would that look in edn?

it wouldn't

if I parse the edn file, does it resolve to the namespaces?

ah

I think it will be simple list in edn

well yeah if would be a simple list

but not very useable and you would need to load configs via macros so the correct cljs code can be generated

not very pretty

I had an idea to use bootstrapped repl to compile some parts, like these functions in edn

but really don't know is it make sense at all

I was able to compile simple function in bootstrapped cljs repl

but didn't try to require that compiled code

if you want to stick with the code

write a "main" namespace that does what you want

compile it

execute it to dump the data

I assume you have something like that already?

Like a one off thing that just dumps everything into READMEs and execute that

what is edn

im too lazy to google

@robbyoconnor: clojure is a superset of edn. It's a data notation https://github.com/edn-format/edn

The .proton file for example is pure edn

@dvcrn, I'll try to make some demo branch with readme features on top of doc_helper branch.

I think using shadow build to compile a different main namespace and execute that with node might work quite good

Getting late here. I'll check back tomorrow morning :)

@thheller I got one issue when trying to write another atom plugin with shadow-build. Thrown error: 'shadow_umd_helper' already provided

I think this is because of proton plugin already define it

you can only have one umd module per build

yes, I got it

also compiled source with advanced compilation will prevent it I guess

since it's mangle strings

no one mangles strings?

yes, proton uses simple optimization for release

I was trying switch to advanced but got errors

yes forget about advanced

not worth the effort

you'd need externs for all of atom

every package you are using

and node itself

unlikely that will happen

@dvcrn: looked into it a bit ... getting an executable for the docs will be quite hard ... something does require("atom") which node doesn't know

Hmm we could stub that dependency