The rendering doesn’t mimic the system 100%, for example the key equivalents are not centered on the split between modifiers and the key, nor are F-keys rendered using a smaller font / menu glyph.
On the plus side though, now all keys are rendered. Previously keys shared with other (non bundle) menu items would only be shown for one of the items sharing the key, and some keys would simply not be shown (e.g. ⌃#).
Also, bundle menu items no longer “eclipse” regular menu items, which could previously happen even when the bundle menu item wouldn’t fire (as it was scoped for something else than the current context).
Fixes#894.
Previously shifting text left/right would ignore blank lines (as noted in issue #419).
When shifting left though it does make sense to delete whitespace, especially as the same code is used to re-indent when pasting.
Fixes#810.
This will give the matched lines zero indent but without affecting the following lines.
Probably the only use-case for this is C preprocessor directives.
This solves the problem where we need to estimate the current line’s indent, but the lines above it is a multi-line block comment. Previously we would fetch indent patterns based on the current scope, then find the first line above caret, for which the patterns can be used to estimate the indent. The problem is that the commented lines without comment markers would be treated as code, and used for the indent.
With the new approach, we can set different patterns for ‘comment.block’ (the C bundle already does this), which basically ignore all the lines, which will cause TextMate to use the code above the comment to estimate indent.
This commit closestextmate/c.tmbundle#3 and also closestextmate/php.tmbundle#24.
The first time the browser is toggled, we’ll save the current frame so that we can restore it if the user toggles again (the calculated frame won’t match when window is moved or width is “truncated”).
Additionally when file browser is on the left side, we reframe the window so that the text view remains in the same place on the screen.
Closes#827.
These variables are mainly for use in the window title. Not all variables make sense across SCM drivers, hence why it is now completely up to the driver, what variables it provides.
Instead of passing the file descriptor to the child, and have the child close it, we set FD_CLOEXEC on the file descriptor in the parent process.
While it limits the window in which another thread can fork() and cause the file descriptor to be “leaked”, it doesn’t eliminate the problem.
The Find object is assigned to a variable with (guarded) static storage, so the initializer of the Find object will run with a lock on the guarded variable, which turns out to be shared with all other guarded variables.
When setting up the window controller, from the Find object’s initializer, we create a “recent folders” menu which hold icons with SCM badges.
When creating these SCM icons, blocks are scheduled (asynchronously) to “fetch status”. These asynchronous blocks will need to lock the same mutex as we currently have locked (because we haven’t yet left the initializer).
The issue is that we also schedule synchronous blocks on the same queue, and that’s why we get a deadlock, because those can’t run before the asynchronous blocks have finished, yet those are waiting on the global lock that our main thread has currently obtained.
Fixes#874.
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.
This is work in progress but I don’t think any functionality is missing compared to previous commit, although some functionality might be less polished, e.g. the action buttons don’t properly enable/disable and the height of the results list gets lost when hiding it.
Some of the stuff that has changed / improved:
* The find/replace text fields adjust their height to encompass the content (closes#94). Presently though the initial height of the ontrols is one line regardless of content (but they should adjust on first edit).
* You can use Save All (⌥⌘S) to save affected files after Replace All (closes#558).
* The key equivalents / actions available in the Find dialog is now easier to find via the action pop-up, which also has enables accessibility.
* Using Next (⌘G) or Previous (⇧⌘G) with search results will move selection up/down.
* Using Find All with ‘in’ set to ‘Selection’ will find and select all matches in the current document, which fixes#425, though it might be more desirable to show the results in the find dialog (like Find All does for a document or folder).
