Since we do not load documents before the user selects them, e.g. after session restore or when opening multiple documents, it makes sense to have both an isOpen and isLoaded property, the former means “is shown somewhere in the UI” and would make it appear (e.g. in file browser) with close button etc., whereas the latter means that data has been loaded from disk, and we can safely access the buffer.
If the user starts typing the focus is moved to the search field, so the only potential disadvantage is the discoverability.
The advantage is that with the table view as initial first responder we can support forward and backward delete to remove items, where previously we required ⌘⌫, which would work when editing text, and thus could cause data loss for a user expecting this key to instead delete to the beginning of the line (text field).
The table view (currently) refuse first responder, but this will change, hence why it is important that our remove button refuses (for proper key view loop).
We have been detecting plug-in crashes for about two years, and we offer the user to remove crashing plug-ins, nonetheless we are still getting a significant number of crash reports from loading the Emmet plug-in.
Commit 8c19532531 broke it so that a digest would only be stored if one was already there, meaning that new users (since November 2015) would not see release notes after update.
The reason is that if there are no bundles, we will extract the default set to Application Support, and in doing so, we call tar which implicitly sets up the command environment, which is re-used for all successive commands.
The problem is that loading a plug-in may add to the environment (e.g. setting the DIALOG environment variable), so if plug-ins are loaded after the call to tar (as would be the case for on a clean system), the DIALOG variable will be missing from the environment.
Kudos to René Schwaiger for discovering this issue.
The semantic class must be of the form: `theme.«group»[.«whatever»]*`.
If a theme lacks a semantic class, or the semantic class does not have a `theme.` prefix then the theme gets into the “unspecified” group.
In theory we could analyze the themes for dark/bright background, but manually classifying themes seems more flexible, for example some themes have a transparent background, which we could put into their own group.
This sets '' (empty identifier) in Global.tmProperties that switches to system
specified spelling language (usually Automatic by Default which is OS X
default). It serves as a way back to the default when user picks any other
language than default from the menu for current buffer (effectively for
documents's directory).
The problem is that when we change user defaults a notification is posted, and this runs on the thread that did the change, so our own “user defaults did change” notification callbacks are executed on a background thread.
