It now matches the width of the other preference panes, so the preferences window will only change height when changing preferences panes (unless the user has manually resized any of the resizable preference panes).
The goal is to have the window resize as little as possible when switching to another preference pane, therefore we aim for at least making the width the same for all panes.
The MGScopeBar class uses deprecated API, doesn’t support dark mode, and doesn’t seem to be maintained, therefore it’s better to switch to OakScopeBarViewController, although it doesn’t support “collapsing” into a pop-up menu.
This commit does change the category filter to work as a radio button, so if one category is selected, others will be deselected, which I do think makes more sense than the previous behavior of allowing multiple categories to be selected, and using the union of these when filtering.
This commit also retires the xib file. The long-term goal is to eliminate all xib files, as being explicit (in code) is preferred. The xib files only exist because in the past we did not have auto-layout.
Ideally this would be a view property, but the view controller only expose the content view, which is an NSView instance that does not support the property by default, so we would have to introduce a subclass for this.
This fixes problems with symbolic links, for example file browser may show contents of /private/tmp when we ask to select /tmp/foo.txt. Comparing file path URLs will fail even though /tmp is a symbolic link for /private/tmp.
Note that this fix only works for when the current document is already part of the items in the file browser, as we still store pending URLs to select as file path URLs.
This is for multi-selecting items in the pasteboard chooser and they are stored as auto-generated items and with their history identifiers, so that we can treat them as multiple items.
Previously we stored discontinuous selections as a newline-delimited string, and therefore the individual fragments could not contain any newlines.
Now that we use NSPasteboard’s multi-string support, we no longer have this limitation.
I was using the clipboard history as a testbed for CoreData but my conclusion is that it was not a good fit, and with the API we used now being deprecated, and the clipboard history needing various improvements, it’s easier just to replace the CoreData backend with sqlite3 and offers us more flexibility going forward.
With this re-implementation there is now support for storing multiple strings on the clipboard and the check to see if other applications changed the clipboard should work better (it appears that if an application is changing the clipboard while TextMate is active, sometimes the NSPasteboard’s changeCount is not updated).
It now also stores the history item’s row ID on the pasteboard, so if we select the non-latest history item and relaunch TextMate, it will no longer treat the current item on the pasteboard as a new item.
Incase of a file reference URL, moving an item will have the URL resolve to the new file path, therefore such URL cannot be used for storing the old location/path of the item.
This is currently not a problem with TextMate, as all URLs are file path URLs, but as we are moving to using readObjectsForClasses: with NSURL, we will be receiving file reference URLs from Finder.
Terminal.app is peculiar about what it expects to be on the clipboard. If we only write URLs like this:
[pboard clearContents];
[pboard writeObjects:urls];
Then it will not paste anything. There *must* be string fallbacks for it to support paste. But if we also write an array of strings like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard writeObjects:[urls valueForKeyPath:@"path.lastPathComponent"]];
Then it will paste both the URLs and the strings, but where the URLs will be space-separated, the strings will not. If instead we write a single string fallback only for the first item, like this:
[pboard clearContents];
[pboard writeObjects:urls];
[pboard setString:@"whatever" forType:NSPasteboardTypeString];
Then it will paste the URLs and ignore the string fallback for the first URL.
There are no subclasses of this type, so no need to make them virtual, and going forward, we will be refactoring how this API works and subclassing will not be supported.
Currently this just moves constructing the options and LF-separating the strings into the clipboard_t::entry_t, but going forward, we will be able to utilize NSPasteboard’s native support for multiple strings (and avoid storing the “fragments” count).
When CommonAncestor is called with only a single directory then it returns that directory, which meant that searching a selected folder and selecting File Browser → Enclosing Folder would not go up a level (only on second use of this action, would it ascend to the parent folder).
As the CommonAncestor function is used in several places, I didn’t want to change its behavior, but it appears that there are multiple checks in the code to see if “file browser items” only contain a single item, and we just added a new one, so grounds for refactoring.
The reason we were doing a fetch was because it may provide better performance, furthermore, the count returned by the array controller is count of filtered objects, so this change is a slight regression, should be addressed later.
