Generally we should always provide a base environment, since the scoped variables are format strings. The filtering scope selector is however optional, and we do not have one when executing commands outside an fi;e/editor context.
We return a variables map instead of updating a map passed in by reference. The previous API was mainly done because we couldn’t previously return non-POD from Objective-C methods. Returning a map with variables makes the API more exact, e.g. how to handle existing entries is no longer an issue (that is, the caller will have to chose the appropriate duplicate strategy).
Previously we relied on the delegate to set this, but a text view may not have a delegate. One could however argue that this is a “global” setting so should be set even when there is no text view.
We no longer pass the bundle item by const-reference because it is now used (delayed) in a block and const-references are not captured by blocks (i.e. the lifespan is not extended).
While it’s easier to execute bundle items from a text view, it doesn’t work when saving documents that are not in the current text view.
This is an intermediate refactoring step — handling should (likely) end up in the DocumentSaveHelper class, but we need to improve dealing with command execution first, and by having the callback piggyback on the normal performBundleItem: method, we (temporarily) limit the code which use the command execution API, making refactoring easier.
Apparently clang (now?) support transferring non-POD types from and to Objective-C++ methods, eliminating the need for doing this by passing a (const) reference.
These are now all prefixed with what they are obtaining variables for (scope, document, bundle, …) which makes it easier to analyze/refactor the code.
Also change document_t’s settings function to document_settings.
Based on crash reports this appears to happen for some users, though only reason I can imagine is if the images are not found in the application bundle (which would happen if the application is moved after launch, but that normally cause many things to fail).
Since saving is asynchronous the scoped refresh/undo helper would do “cleanup” before the command ran and potentially made document changes.
Commands executed at a lower level (i.e. by editor_t via macros) presently still has this issue. This should be fixed when macros are refactored (this isn’t the only issue related to macros).
Closes#450.
The fontSmoothing defaults key can now be set to:
0: Always disabled
1: Always enabled
2: Disabled for dark themes
3: Disabled for dark themes on high-DPI displays (default)
/cc issue #958.
If you wish to always have font smoothing enabled you can run:
defaults write com.macromates.TextMate.preview fontSmoothing 1
Setting the value to 0 causes it to always be disabled and deleting the key (or setting it to 2) has it disabled only for dark themes.
This is presently only settable via the ‘disableTypingPairs’ user defaults key:
defaults write com.macromates.TextMate.preview disableTypingPairs -bool YES
Closes#609.
Since auto-pairing can be adjusted via user customization we disable it for both macro recording and replay. Old macros will need to be updated (but this was already the case, as 2.0 never did pairing as part of replay).
A better solution is to record each implicit action of the auto-pairing in the macro. This can however be added later without breaking existing macros, as the macro player will remain the same.
Closes#130.
The implementation of kPaste seems to generate an exception for some users, but I don’t know exactly why, so this should provide some better diagnostics info.
This means we don’t need to know if there is a selection when creating the menu items and long-term it’ll be easier to introduce more complex updating, e.g. make the title a format string to allow referencing TM_DISPLAYNAME or disable the menu item if its requirements cannot be met.
Currently this is implemented in OakTextView which means that it doesn’t work for macros. Some refactoring is in order so that the implementation can be shared (lack of sharing has to do with how OakTextView reports status to Find dialog or via tool tips, and macros want none of that).
There is also no check to see if the current state of the editor is the result of a find operation, i.e. you can invoke “replace” regardless of wether or not “find” was the last action.
Finally, doing a multi-file search and using “find next” at the end of one document, which brings you to the first match of next document (part of the results), will not update “captures” from a potential regular expression search, meaning that if you then do “replace”, and your replacement string is a format string that references the match (via $1-n) then it will not be correctly expanded.
Closes#104.
Previously there was a single replace action and the options would indicate if it was a “replace all”, this mimics the “find” (which can be a “find all”) but since single match replacement is somewhat different than a “replace all”, as the former may need to know the captures from a previous find action, it makes sense to factor out these things as different actions.
