Fork me on GitHub
#proton
<
2016-02-08
>
dvcrn01:02:23

@jessejanderson: you need to start atom from the terminal to correct the path to iex

dvcrn01:02:36

that's a problem with atom sadly

dvcrn06:02:41

@geksilla: really like that golden ratio plugin simple_smile

lucien.knechtli14:02:59

@dvcrn: I'll try to compile a list if it's helpful.

lucien.knechtli14:02:13

to be fair, a number of the issues I've come across are limitations of the packages available on atom vs the ones on emacs, not specifically proton itself

katy15:02:43

do I have to upgrade Atom manually while using Proton? what about individual packages?

lucien.knechtli16:02:14

If I want to disable pep8 and use flake8 instead, how do I go about doing so in .proton?

lucien.knechtli16:02:11

the second part is easy - just add the package, but I'm not sure how to disable pep8 checks

austincrft16:02:17

Maybe ["core.disabledPackages" ["linter-pep8"]]

austincrft16:02:47

Oh, maybe not based on @dvcrn's comments on how disabledPackages works

austincrft16:02:44

So the linter-pep8 package has an ignoreErrorCodes array. You could add all the error codes to it.

austincrft16:02:52

Doesn't seem like a very good solution, but it'd work

austincrft16:02:14

Of course, it'd still be running in the background, which is also annoying

lucien.knechtli16:02:33

yea, I'd rather avoid it being called at all by proton

austincrft16:02:47

@dvcrn: So there is no way to disable core packages?

jessejanderson17:02:10

So for package settings - Iā€™m supposed to do those in my dotfile, right? And ignore the normal Atom Package Settings section?

jessejanderson17:02:03

Is there an obvious place to find what options are available for a package?

katy17:02:41

My workflow is currently to set the package settings in the GUI as you're used to doing, then look at my Atom generated config file

katy17:02:00

you can also go to the console and type atom.packages.config.defaultSettings

katy17:02:18

(credit to austincrft simple_smile )

jessejanderson17:02:52

ahhhh, nice! Thanks.

lucien.knechtli17:02:57

@austincrft: ended up changing the path that linter-pep8 looks at for pep8 to /bin/true. Still tries to run it, but a least its a simple solution

austincrft17:02:59

That also seems hacky, but it's better than writing all the error codes.

lucien.knechtli17:02:55

it'll work until dvcrn tells us the right way / makes a right way simple_smile

lucien.knechtli17:02:57

is there a right way to specify multiple settings in a single expression? like

["a.b.c" 
    ["d.e" "val"
     "f.g" "val2"]]

austincrft17:02:28

In that instance, a.b.c is a package name?

austincrft18:02:20

This doesn't seem to work for me

;; appearance
    ["editor" [["fontFamily" "Source Code Pro"]
               ["showIndentGuide" true]
               ["showInvisibles" true]
               ["fontSize" 12]
               ["softWrap" true]]

austincrft18:02:32

But I think that's what you were getting at

lucien.knechtli18:02:35

thats what was getting at

lucien.knechtli18:02:14

on another note - atom seems to keep its process running hogging as much cpu as possible if you start it in a terminal and later close it

lucien.knechtli18:02:30

not sure if that's proton or atom though

austincrft18:02:06

I'd argue that it isn't much better, though. The .proton file seems to be modeled in a way that you don't have to be familiar with clojure to modify it

lucien.knechtli18:02:23

that's true, but it's a nice-to-have simple_smile

austincrft18:02:53

Which is also (I assume) why parinfer is disabled in the .proton by default. It would mess with the formatting.

austincrft18:02:46

Yeah, I think it'd look better from a clojure standpoint, but the current formatting is more straightforward

austincrft18:02:17

Now that I think about it, I have this line in my dotfile: ["minimap.plugins" [["git-diff" true] ["pigments" true]]]. I'd be willing to bet that this isn't working. šŸ˜›

austincrft18:02:09

Yeah, changing it to

["minimap.plugins.git-diff" true]
["minimap.plugins.pigments" true]
made it work. I'm surprised I didn't notice it wasn't working. šŸ˜›

lucien.knechtli18:02:21

wow that's really weird. when I start atom from term, I get 100% cpu usage for as long as that term is open. Closing it fixes it, and has no effect on atom...

austincrft18:02:15

That does seem pretty strange. I'm not experiencing that at all. What OS are you on?

lucien.knechtli18:02:40

ubuntu 15.10, using zsh.

austincrft18:02:27

Hm. I don't have a linux machine next to me right now to test, but I don't experience that on Windows or OSX

lucien.knechtli18:02:57

it may be zsh specific

austincrft18:02:25

That's possible. Mine sits at 0% and only spikes to about 0.5% when typign

lucien.knechtli18:02:21

so when I run xterm bash then run atom inside it, it seems fine

austincrft18:02:57

Hm. I'd be interested in what zsh is doing with the process.

lucien.knechtli18:02:15

not sure how to test that - maybe whatever atom uses to start the gui from the command line has an issue with zsh?

austincrft18:02:14

It's basically just running a modified version of chromium

lucien.knechtli18:02:19

that I get - i'm not sure how to check what zsh is doing differently that bash when it starts stuff though

austincrft18:02:52

You could try running the chromium executable from zsh to see if it's specifically an incompatibility with Atom

austincrft18:02:26

If it's an Atom thing, I'd report it to the Atom repo. If not, report to the zsh repo if there is one?

austincrft18:02:46

I know admittedly nothing about zsh other than it's a shell alternative. šŸ˜›

lucien.knechtli18:02:02

I'll look into it more tonight. Not really worth stressing over it atm since I have work to do šŸ˜›