…so that it is easy possible to define keybindings in the syntax specific configfile.
e.g.
in php specific:
{ “keys”: [“ctrl+space”], “command”: “expand_function_from_a_php_plugin” },
in D specific:
{ “keys”: [“ctrl+space”], “command”: “expand_function_from_a_D_plugin” },
i cannot belive how stupid this is solved right now!
My colleagues are laughing about me like “wow… you have a $80 Notepad++” - the deeper I dig, the more i feel that they might be right
I bet they will laugh some more about your lack of empathy and the inabilitily to RTFM. But jokes aside – with an attitude like that, do you expect people to be willing to help? Keep your frustration to yourself!
http://docs.sublimetext.info/en/latest/reference/key_bindings.html
Example:
[
{
"keys": [
"alt+shift+x"
],
"command": "your_javascript_command",
"context": [
{
"key": "selector",
"operator": "equal",
"operand": "source.js"
}
]
},
{
"keys": [
"alt+shift+x"
],
"command": "your_coffeescript_command",
"context": [
{
"key": "selector",
"operator": "equal",
"operand": "source.coffee"
}
]
}
]
Have a great day!
I know this and this is exactly what i am talking about.
My keymap-config file looks already like hell because of this.
I am angry because i paid 80 f* $ for this in a blind expectation that its better then a free solution. And don´t tell me to RTFM! I did this - The “Sublime Text Unofficial Documentation” - are you kidding me? So is this a open software project or what? 80$ and no helpful official documentation? No productive working without an installation of at least 5 plugins? Which has it´s issues by the way - You know what? - yeah this is absoultly not my attitude and not how i work day to day.
To be clear: this is not a question for help. This is a request for doing it better.
…even more off-topic: Don´t get me wrong - I like how efficient and quick ST3 is, while nothing comes in my way. That fact has indeed some weight which is why i am still holding on to ST3.
Sublime Text has a free unlimited evaluation and you are supposed to evaluate it instead of buying it based on your blind expectations. Why would you buy an editor without even checking its documentation? (It also has an official by the way, but the unofficial is more extensive.)
Nonetheless you can get a refund within the first 30 days https://www.sublimetext.com/sales_faq
It would be helpful if you’d at least specify how you think it could be “better”? What’s bad with the current design? How do you expect it to work?
How i think it would be better are the first 6 lines of this topic.
Whats bad about the current design should be very clear IMHO. At least i think so as fresh flesh in here. So for the routine-blinded:
If i want to define a keybind for a specific syntax, i expect it to be made in the configuration file for the specific syntax.
The good thing about this would be, that it makes configuration more distinct and the general keymap file would be not that blown up.
implementing this would be something like: if keybind definition encountered in syntax specific file on reading, then extend it internally with the corresponding context. - i quess the costs to implement this would be under $80 
I think keybinding management is a problematic aspect of ST, but only because possibilities are endless. I have a keybinding manager in my works in progress but it’s not nearly usable yet. Just to say that making keybindings more manageable is possible and it’s a matter of time for a solution to come out.
no doubt. Since sublime text seems to be very plugin oriented and a plugin comes usually with a set of keybindings, this should be addressed by the core developers.
…Saying so - are core developers around here? How to identify those in the forum?
This is something that can be done entirely through plugins, and the developers are surely busy with core features and things that cannot be done otherwise.
Nope, i don´t see that. To avoid conflicts between plugins can only be done through a general platform solution.
Martinus, it sounds like you’re suggesting that the keybinds in a syntax-specific keymap should automatically be restricted to that syntax. This could make sense in simple cases, but there are complications that would make such a feature narrower than it might seem.
First, a keymap or other configuration file is not necessarily associated with a particular syntax. A given keymap may contain bindings that pertain to a single syntax, to multiple related syntaxes, to multiple unrelated syntaxes, or to no syntax in particular. For example, my User keymap contains syntax-specific bindings for Markdown, CFML, Oracle, JavaScript, and more, as well as general bindings that apply to all files. Or a JavaScript-specific keymap may also contain binds that apply to JSON files. There is no sensible default in many common cases.
Second, there is no way to specify a syntax generally for a keymap file. The structure of that file is simply an array of bindings, and adding an explicit keymap-wide syntax would complicate that structure. Deriving the syntax from the file’s name or location could be problematic as well, not to mention potentially surprising.
Third, even if a given set of keybinds pertained to a single syntax, and the keymap file had some way to indicate that unambiguously, it is common for some bindings to be even more specific, applying only in a certain subscope. You would still need to manually specify a context in such cases.
Fourth, any kind of implicit restriction on keymap bindings could make it more difficult to create and customize bindings. Right now, if a binding is restricted to a particular syntax or scope, that is explicitly specified in the binding. This makes it easy to understand in what circumstances the binding will apply, even if you’re not familiar with that particular keymap file. It also makes it easy to override the default behavior. If bindings in a keymap file were implicitly restricted to a single syntax, and you wanted to broaden or narrow the scope of a binding, then you would have to either remove that binding from the file and put it in a new keymap or change the implicit syntax restriction for the entire file and possibly change all of the other bindings as well.
I understand that you find the current syntax to be overly verbose, but I hope that you can understand that the current system attempts to strike a balance between power and simplicity. Adding implicit syntax restrictions might make some simple cases simpler, but it could make a lot of cases more complicated without adding power. Therefore, I don’t think that the developers are likely to add such restrictions.
If you often find yourself editing keymaps, I recommend the PackageDev package, which adds better syntax highlighting and completions to keymap files.
If nothing else, it made me take a look at my own package keybinds and I realized that I needed to add several context selectors for langauge just to be a good package developer citizen. It’s a nicety that I didn’t think of when I was starting fresh.
Okay while this is topic is a little charged, and dated, and I actually really like Sublime Text and think it was worth every penny, I do have a small problem in exactly this area. I’m new to ST3 so perhaps I’m just missing something basic. Here’s my problem…
I am both a developer and a writer. While coding I like the default paragraph style, which I think is determined here:
`{ “keys”: [“enter”], “command”: “auto_indent_tag”, “context”:
[
{ “key”: “setting.auto_indent”, “operator”: “equal”, “operand”: true },
{ “key”: “selection_empty”, “operator”: “equal”, “operand”: true, “match_all”: true },
{ “key”: “selector”, “operator”: “equal”, “operand”: “punctuation.definition.tag.begin”, “match_all”: true },
{ “key”: “preceding_text”, “operator”: “regex_contains”, “operand”: “>$”, “match_all”: true },
{ “key”: “following_text”, “operator”: “regex_contains”, “operand”: “^</”, “match_all”: true },
]
}
But when I write in markdown or plain text this is really irritating. I want a binding that indents the beginning of a paragraph only. Which, by experimenting with the above settings maybe I can arrive at.
But even so, I’m left with a bad choice half the time. Is there some way to a least group some key binding overrides that can be easily swapped?
Okay, I found it, and it was really simple. In case there’s someone else out there as new to this editor as me, just put this in your multimarkdown.sublime-settings file, assuming your using that package.
“indent_subsequent_lines”: false,
Done and dusted.
