dvcrn / proton Goto Github PK

Another oversight when I implemented this feature.

Besides themes getting applied, I noticed that proton also force-activates packages that layers want to be disabled. As a test, just disable "relativeLineNumbers" inside .proton. The layer deactivates it but proton core activates it again.

We need to find a solution in which we force-activate all packages that are needed but still allow layers to disable packages

:keybindings inside .proton is currently unused.

Before tackling this, we should check if we can somehow call a :fx callback from there. This might be a bit tricky because edn != clojure.

Needs further investigation

On first installation and small screens, I had it a few times that the "installing xxx" messages out-scrolled the screen.

Needs some css tweaking

I'm not sure why or when this happens but I had it twice that when a lot of packages are due to be installed, it only installs a few of them, reports 'success' and on the next start installs the rest. Maybe we have a timeout somewhere?

Either vim-mode or vim-mode-plus.

I'm using vim-mode and when I press SPC to enter the chain I see that vim-mode:move-right is being called as the chain starts.

Should we just un-map this?

The options for pane management in atom (especially the default ones) are less than stellar.

A great feature from spacemacs is the numbered panes that allow you to easily navigate between open files with spc # where # is the pane number.

Something like this in proton would be amazing!

This was an idea from a discussion on discuss.atom.io.

Proton has a few things that could stand on it's own for people that don't want to use everything at the same time.

• dotfile loader: This would probably the easiest part, a package that just loads a specific file (maybe ~/.atom by default), loads it and puts it into the atom object. (edn? cson? json?)
• dotfile mode: Leverages above plugin but sets / removes config keys. The wipe and install mechanism that proton currently uses, just as a standalone thing.
• chain mode: The proton prefix tree. User can specify keybindings and summon the chain overlay (what proton does when you hit space). When hitting a leaf, execute the editor action.

Proton itself is then requiring these packages, adds its layer system on top and glues everything together.

Definitely a must.

#23

Currently, the iex package is impossible to use since you can't type spaces without pulling up the proton keymap menu.

We should copy the default template to ~/.proton if the user doesn't have it yet.

Maybe specify a opt-in before proton activates in case he just installed it randomly so we don't wipe his entire settings by accident.

When I think about proton, I'm more thinking about a complete package: Something that you install that makes your editor instantly better while getting rid of annoying things. Similar to nuclide.

We should go over all settings atom provides and check which ones are useful by default and which ones don't make sense. Plus maybe adding toggles for them inside the core layer.

I think including themes / fonts could also fall under this category. A beginning would be to ship Hack / Source Code Pro with proton and install a fresh template by default (thinking about https://atom.io/themes/atom-material-ui).

What are thoughts on keeping the keybindings close to what spacemacs has already done? It seems possible that someone may want to occasionally switch between using proton and spacemacs. Keeping the keybindings similar could keep the transition smoother.

That being said, not all of spacemac's bindings are necessarily ideal either.

Right now the user can deactivate packages which could mess up how proton works. Plus once a package is disabled, it no longer shows up inside the atom API and is invisible to proton.

One problem we have with this is, that when proton uninstalls a package, it adds it to disabledPackages. If the user enables the layer again, proton installs the package again but it is still disabled.

I think we should add a logic that force-activates all packages that all layers need to operate.

Maybe something like this:

1. Take package list
2. If under 5, install all in parallel
3. If over 5, take 5, install parallel and repeat

Right now it installs sequentially. I tried the all parallel approach before but that didn't end so well.

In my config I have things like:

".coffee.source":
  editor:
    tabLength: 2
".bibtex.text":
  editor:
    tabLength: 2
".julia.source":
  editor:
    tabLength: 2
  "multi-wrap-guide":
    columns: [
      72
      80
      92
    ]

If I try to add something like [".julia.source.editor.tabLength" 2] in my ~/.proton I get

  "":
    julia:
      source:
        editor:
          tabLength: 2

I think we just need to special case a leading . in the config string when parsing configs

Hi @dvcrn, do you use figwheel during development? I've succeed on figwheel activation and got hot code reload and another nice features, but it's a bit hacky. Could you please share your dev workflow with figwheel? Thanks.

Propose to add linters support within :tools/linters or :tools/error-check.

I'm trying to apply the theme/syntax highlighting I had in my atom config from within proton and am having problems.

I've added the proper packages to the :additional-packages section and in :configuration I have included

    ["core.themes" ["isotope-ui"
                    "tomorrow-night-eighties-syntax"]]

When I launch a new atom (proton) window the console tells me

Setting core.themes to ["isotope-ui" "tomorrow-night-eighties-syntax"]

But then when I do cat ~/.atom/config.cson I see core: {}

Is there supposed to be another way to do this?

Not sure how that happened but I can't manage to navigate with these anymore

I recently discovered this project through a Spacemacs tweet and I have to say it looks very promising. I'm an Emacs (and Vim) fanatic but I would also like to move into more modern software, specially for a text editor, so I'll see what I can do to help out with this project.

Anyways, after looking through Atom packages I found atomatigit which seems to be a form of git integration based on magit, being proton heavily influenced by spacemacs, I thought it would be a good choice 👍

Why did you choose the GPL3 license? Most of the Atom ecosystem is MIT, so this choice limits sharing options. As an example, I'll avoid looking at your code for fear of "tainting" other packages.

SPC + Tab should always jump to the previously opened buffer / tab in a MRU fashion. Executing this multiple times should always cycle between 2 tabs.

I noticed these warnings during compile:

WARN: WARNINGS: proton/lib/keymap.cljs (4)
WARN: Use of undeclared Var proton.lib.mode/get-current-editor-mode at line 8
WARN: Use of undeclared Var proton.lib.mode/get-current-editor-mode at line 8
WARN: Use of undeclared Var proton.core/mode-keys at line 34
WARN: Use of undeclared Var proton.core/mode-keys at line 34

pinging @geksilla. That is something you worked on I think

We should allow layers to extend keybindings defined in core or other layers.

Here's an example layer that could utilize this:

(ns proton.layers.pomodoro.core
  (:use [proton.layers.base :only [init-layer! get-initial-config get-keybindings get-packages get-keymaps]]))

(defmethod get-initial-config :pomodoro
  []
  [])

(defmethod init-layer! :pomodoro
  [_ config]
  (println "init pomodoro"))

(defmethod get-keybindings :pomodoro
  []
  {:t {:category "toggles"}
     :p {:category "pomodoro"
         :s {:action "pomodoro:start"
             :title "Start Timer"}
         :a {:action "pomodoro:abort"
             :title "Abort Timer"}}})

(defmethod get-packages :pomodoro
  []
  [:pomodoro])

(defmethod get-keymaps :pomodoro
  []
  [])

What I am going for here is to add another category under the t chain defined in core so that I can toggle my pomodoro timer. So what I'd like to see is that SPC t has all the existing options, but now has one more option for pomodoro that will drop me one layer lower in the chain and have options for a and s.

Right now, this is now what I'm seeing. Here are some screenshots to demonstrate the problem:

When I do just SPC I get this:

When I do SPC t it appears that everything was wiped out:

It also appears that SPC p has replaced the "project" section from core with my pomodoro section defined here:

The existence of proton convinced me to give Atom a try, I just downloaded the latest atom, and tried to install proton. I receive the following error report any time I try to start atom. It looks to me like some part of proton's config process is failing, but I'm not sure where to start debugging.

Atom Version: 1.3.2
System: Microsoft Windows 10 Enterprise
Thrown From: proton-mode package, v0.3.0

Stack Trace

Uncaught Error: EPERM: operation not permitted, write

At C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2132

Error: EPERM: operation not permitted, write
    at Error (native)
    at Object.fs.writeSync (fs.js:663:20)
    at SyncWriteStream.write (fs.js:1981:6)
    at Object.execSync (child_process.js:491:20)
    at Object.proton.lib.proton.create_default_config_BANG_ (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2003:284)
    at Object.proton.lib.proton.load_config (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2004:114)
    at C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2610:410
    at d (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2608:164)
    at b (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2609:17)
    at Object.cljs.core.async.impl.ioc_helpers.run_state_machine (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2131:198)
    at Object.cljs.core.async.impl.ioc_helpers.run_state_machine_wrapped (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2132:116)
    at C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2635:153
    at Immediate.cljs.core.async.impl.dispatch.process_messages [as _onImmediate] (C:\Users\awh\.atom\packages\proton-mode\lib\proton.js:2088:298)
    at processImmediate [as _immediateCallback] (timers.js:374:17)

Commands

Config

{
  "core": {
    "themes": [
      "atom-dark-ui",
      "solarized-dark-syntax"
    ]
  }
}

Installed Packages

# User
proton-mode, v0.3.0

# Dev
No dev packages

This idea got sparked by a conversation on slack. It would be ideal if we could just generate READMEs for each layer.

With the changes we made inside the doc-helper branch, we can already generate a list of options and keybindings

So to summarize:

• Keybindings: We can generate
• Options: We can generate as well
• Package list: Should be no problem. Just construct the URL with atom.io/packages/{{package-name}}
• Install instructions is a no brainer

We need to add a description to each layer and a script for re-generating all READMEs

http://nuclide.io/blog/2016/01/13/Nuclide-v0.111.0-The-Unified-Package/

Right now we do something like this:

  :layers
  [
    :core
    :git
    :clojure
    :python
  ]

To set config we do

    ;; stuff for proton
    ["proton.core.showTabBar" false]
    ["proton.core.relativeLineNumbers" true]

Maybe we should think about going the spacemacs way and doing something like

  :layers
  [
    :core
    :git
    :clojure
    [:python {"showTabBar" false
              "relativeLineNumbers" true}
  ]

instead. This would make it more clear that a config is for a layer only. 

Perhaps when the user presses SPC + ? it pulls up the command palette (default CTRL + SHIFT + P) search bar. The other part would be to list the proton keybindings in the command palette instead of the atom provided keybindings.

I have a django project with a module named "data". Not the best name for a module, but it shouldn't be ignored by default when searching project folders

Not sure how that happens but every time proton proceeds to install nuclide-quick-open, all packages after won't install. Need to restart the editor to continue package installations

I thinks we can add some terminal package to core layer and bind it to SPC `. I found few interesting packages:

https://atom.io/packages/terminal-panel
https://atom.io/packages/atom-terminal-panel
https://atom.io/packages/terminal-plus
https://atom.io/packages/term2
https://atom.io/packages/term3

I've tried all of them. And for now my choice is terminal-plus.

Feel free to propose another one and share your experience.

In Spacemacs these pane:focus keys are simply preceded with a w for a window category (SPC w h for 'focus left pane'.

There's an interesting problem right now with Proton in that you have to try and think ahead with categorizing so that you aren't having to change shortcuts all the time, messing with people who have learned them.

It would be great if categories could be planned out somewhat. For example - Spacemacs uses SPC x as the category for all text manipulation commands. I want to add a feature to sort lines of text so I was considering the following options:

1. SPC x l s (leader => text manipulation => lines => sort)
   This matches Spacemacs, but feels slightly weird at this point since there is nothing else in the lines category or even the text manipulation category.
2. SPC l s (leader => lines => sort)
   This makes a little more sense I think at this point, but SPC l is currently used for pane:focus

Maybe coming up with a future keybinding categories guide or something would be worthwhile so that keybindings don't end up getting changed as more features are added?

Right now we have 10 entries (for 0 to 9) for pane movement. We should squash this into a single entry [0-9].

I think that this should be more doable now given the work in #80

Refs #65 #72

OS: Ubuntu 15.10

Proton is like the first thing everyone thinks of when they try to name a atom extension. Need something more creative :)

(Most of the stuff in this list just comes from random words from wikipedia)

• etom (emacs atom)
• spacetom (spacemacs atom)
• helium / proton / neutron / {{something else atom related}}
• quantum-mode
• exotic-mode
• ???

We might need a new name first since proton is already taken. Plus we need to check how we can submit a compiled version.

On a fresh atom if I execute apm install proton-mode and then launch atom, I get the following error:

Uncaught Error: ENOENT: no such file or directory, lstat '/Users/dave/.proton'

One of the really cool things about spacemacs is that some keybindings (in their case <spc> m or ,) change according to what the current syntax is like.

<spc> m = in python executes yapf while in js executes js-beautify.

We should think about porting this to proton as well

One of the plugins we integrate is probably hooking on the save event. Right now, the first save on a new file takes around 1-2s. Saves after the first one are back to instant.

Currently we cannot set scopeSelector and source options via proton.lib.atom.set-config! see Config::set for details.

Proton should have some :)

Possibly utilize PR and issue templates - for instance a checklist of steps to take before submitting an issue, and what information to include in an issue
For example:

• Have you tried running proton with a minimal .proton file, and if so, what are the minimal settings required to reproduce the issue?

On a similar train of thought, I highly recommend using something like git-flow.

It would be great to visually number panes so users know which one they are jumping to. Refs #65 #72

This comment has potential suggestions for where to put the numbers

Hi,

I am getting this error when atom starts:

TypeError: Cannot read property 'addBottomPanel' of null
at Object. (/Users/raguay/Documents/proton/plugin/lib/proton.js:1806:80)
at Module._compile (module.js:428:26)
at Object.defineProperty.value as .js
at Module.load (module.js:353:32)
at Function.Module._load (module.js:308:12)
at Module.require (module.js:363:17)
at require (module.js:382:17)
at Package.module.exports.Package.requireMainModule (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:761:34)
at /Applications/Atom.app/Contents/Resources/app.asar/src/package.js:192:28
at Package.module.exports.Package.measure (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:169:15)

Not sure what's going on - now getting this error on every launch, gets stuck with the Proton modal up at "Initializing proton... Just a moment!"

Atom Version: 1.5.3
System: Mac OS X 10.11.3
Thrown From: proton-mode package, v0.8.0

Stack Trace

Uncaught TypeError: Cannot read property '0' of null

At /Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2008

TypeError: Cannot read property '0' of null
    at cljs.reader.read_keyword (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2575:161)
    at Object.cljs.reader.read_delimited_list (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2563:74)
    at cljs.reader.read_map (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2567:142)
    at Object.cljs.reader.read_delimited_list (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2563:74)
    at cljs.reader.read_map (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2567:142)
    at Object.cljs.reader.read [as read] (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2584:72)
    at Object.cljs.reader.read_string (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2584:368)
    at Object.proton.lib.proton.load_config (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2612:163)
    at /Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2975:21
    at d (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2972:199)
    at b (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2973:17)
    at Object.cljs.core.async.impl.ioc_helpers.run_state_machine (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2007:198)
    at Object.cljs.core.async.impl.ioc_helpers.run_state_machine_wrapped (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:2008:116)
    at /Users/Jesse/.atom/packages/proton-mode/lib/proton.js:3002:408
    at Immediate.cljs.core.async.impl.dispatch.process_messages [as _onImmediate] (/Users/Jesse/.atom/packages/proton-mode/lib/proton.js:1964:298)
    at processImmediate [as _immediateCallback] (timers.js:374:17)

Commands

Config

{
  "core": {
    "audioBeep": false,
    "destroyEmptyPanes": false,
    "disabledPackages": [
      "linter-jshint",
      "vim-mode-plus",
      "atom-alignment",
      "tabs"
    ],
    "themes": [
      "isotope-ui",
      "chester-atom-syntax"
    ]
  }
}

Installed Packages

# User
Parinfer, v1.11.0
aligner, v0.19.1
atom-ternjs, v0.13.2
atomatigit, v1.5.5
autoclose-html, v0.21.0
autocomplete-elixir, v1.5.13
autocomplete-html-entities, v0.1.0
autocomplete-modules, v1.4.1
autocomplete-paths, v1.0.2
autocomplete-sass, v0.1.0
autoupdate-packages, v1.3.1
chester-atom-syntax, v0.1.1
css-snippets, v0.9.0
docblockr, v0.7.3
easy-motion-redux, v1.0.0
emmet, v2.4.1
environment, v1.1.1
file-icons, v1.6.14
highlight-line, v0.11.1
iex, v0.9.27
indent-guide-improved, v1.4.5
isotope-ui, v2.7.1
javascript-snippets, v1.2.1
language-diff, v0.4.0
language-elixir, v0.11.1
language-haml, v0.23.15
language-slim, v0.5.0
linter, v1.11.3
linter-bootlint, v1.0.0
linter-clojure, v1.1.2
linter-csslint, v1.3.1
linter-elixirc, v1.1.5
linter-eslint, v6.0.0
linter-haml, v1.1.0
linter-rubocop, v0.4.7
linter-sass-lint, v1.1.0
linter-slim, v1.0.0
linter-xmllint, v1.3.3
markdown-scroll-sync, v2.1.2
minimap, v4.19.0
pigments, v0.24.1
project-manager, v2.7.6
proton-mode, v0.8.0
react, v0.14.1
react-snippets, v0.3.0
recent-files-fuzzy-finder, v0.2.4
relative-numbers, v0.5.0
release-notes, v0.53.0
terminal-plus, v0.14.5
vim-mode, v0.64.0
vim-surround, v0.8.1
zentabs, v0.8.7

# Dev
No dev packages

Spacemacs style :) https://github.com/syl20bnr/spacemacs/tree/master/layers/%2Blang/html