Unified build system like Sublime Text (partly because a different shortcut key for every build system is ridiculous)?


#1

Is there one?

Being able to set the command run by e.g. CTRL-B based on grammar/extension (like ST) works really well - you first look at the current file type, and then decide what to do.

What I see atm is that every package which provides some kind of build capability uses its own shortcuts, which usually step on the shortcuts used by some other build package (because everyone seems to want some variation on CTRL-B).

The actual support in ST is pretty minimal - you create a .sublime-build file and optional entries on the Tools menu, and then there’s the default shortcut. It’s completely language-agnostic - there is no other functionality/no other defaults except for what one finds in the various language-support packages.


#2

You don’t have to have a different shortcut key for every build system. If you have three different packages, one for Ruby, one for Python and one for Go … I’m pretty certain you can map them all to Ctrl+B like so:

'.editor .source.ruby':
  'ctrl-b': 'ruby-build:build'
'.editor .source.python':
  'ctrl-b': 'python-build:build'
'.editor .source.go':
  'ctrl-b': 'go-build:go'     # Just because I like the sound of that :laughing:

Of course, the key would only work when an editor window is focused, not when say the Tree View is focused … but meh :grinning:


#3

Brilliant! Assuming it works :wink:

The .source.* selector was the missing piece for me.

I’m not really feeling the need to run files from the tree view either :g:.


#4

The thing that I like about this system is that it can offer features that are more customized to whatever build system is appropriate for that language. For example, I would love to have a Ruby build package that looks into my Rakefile and when I press Ctrl+B it would build the default target, but if I press Ctrl+Shift+B it would pop up a list of build targets for me to select from.

The part where this system breaks down is that it keys off the language of the active editor, so if I was in, say, an HTML file in my current Ruby project … the keymapping wouldn’t do what I want.

But I think this will work until someone makes a more language-agnostic build package like you’re asking for.


#5

Not so much.

Key Binding Resolver shows the mappings from ~/.atom, but the winner is “fuzzy-finder:toggle-buffer-finder” from “.platform-win32”

Although removing .source.blah makes it run…


#6

Interesting, perhaps my theory was incorrect :confused: I’ll have to look at it a little later …


#7

The grammar scope classes are applied to lines and words (tokens), and key bindings don’t trigger that deep into the hierarchy. I’m guessing they trigger at the view level.


#8

Maybe we should fix that so that the scope of the associated grammar is associated with the editor view? This might not be the only situation where this kind of redundant keybinding would be useful.


#9

That would break the scenario where you have e.g. an ERB file which consists of a mix of Ruby and HTML. I guess that could be solved by only yanking the main scope? Or do we yank all of it and cram it in?


#10

Only the scope that is associated with the currently selected grammar: editor.getGrammar().scopeName


#11

I’ve opened a pull request and begun working on this. Still heaps of work left to be done; only works upon triggering a grammar change, there are no tests, and there’s no support for the React based editor view.


#12

I reckon the primary goal of the pull request is done. Still needs tests, documentation and what not.