By default, scrollbars are hidden on macOS when using a trackpad, but for mouse users, or people with scrollbars set to always visible, this is probably preferable (all other scrollviews in TextMate use autohiding scrollbars).
This is only when the default application is not TextMate.
Ideally the regular “Open” item would change to “Open With «application»” when the selected items are not text documents, and there is an application to handle them, but the code changes required for this are non-trivial because what the item does, is not decided until the user triggers it, and it may not treat all selected items the same.
The API expose a few more implementation details and require the user retains the delegate for the duration of the menu’s lifecycle.
The upside is that we avoid the global singleton and it is now possible to examine and use the information gathered by the Open With menu delegate.
Due to the high priority menus have in the responder chain, we effectively cannot have context menus with key equivalents, if these menu items have explicit targets.
We need the explicit targets so that the context menu works when the application is not the active application.
The warning only appears when the anonymous enum is used in a conditional, hence why we do not need this change for all calls to NSFileTypeForHFSTypeCode.
This problem started after f1a1e1920f (handling key equivalents in performKeyEquivalent: instead of keyDown:).
It does however not appear that it is necessary to manually handle the return key to activate editing, therefore we have removed handling of this key.
Most likely it was required before view-based table views.
Some of the items require the key equivalent to be set as “inactive” as menu item keys are “global” and thus need to be unique, and can be triggered even when the view containing the context menu is not active.
Previously “Paste Next” in the Edit → Paste submenu could have its title updated to “Move Item Here”, which would never be restored back to “Paste Next”, similarly for regular paste.
This commit also drops the wrappers for the cut:, copy:, paste:, and delete: methods, as these wrappers resulted in a bit of redundancy related to menu item validation.
This is called before the main menu acts on keys, and thus allows us to catch keys that are otherwise assigned to menu items.
We only do this when the file browser is first responder, so it should be acceptable to have a few menu keys change behavior in that case.
This was required when we linked each framework as its own thing, which we do not do anymore, and if we do go back to this system, we can simply have symbols public by default.
It appears that NSURL’s algorithm for “delete last path component” is to first append ‘../’ and then “normalize” the result, but the latter step can fail for some file URLs, for example with “file://localhost/path/to/https://macromates.com/” it will be stuck at the two slashes (continuing to append ‘../’).
Such malformed (file) URL can be created by running ‘mate https://macromates.com/’.
This is simpler than having to proxy the action (and target) for the button.
Previously the button was created on demand, but now that we always create it (and hide it when not required), we might as well have users set action and target directly on the button instance.
Minor downside is that labels for open and closed files are no longer aligned.
It would be nice to find a solution for that, but without dropping the stack view, as it saves us > 100 lines of code.
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.
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.
While in theory just a wrapper for VNODE events, there are some edge cases:
- Observe missing file: Report when created (observe all ancestors to know).
- Rename ancestor: Treat as rename (observe all ancestors to know).
- Move observed file to trash: Treat as delete (reported as rename).
- Rename file with symbolic link in path (e.g. /tmp): Preserve symbolic path.
- Delete observed file and write new one: Treat as a write (reported as delete).
- Rename observed file and write new one: Treat as a write (reported as rename).
- Change case of file: Tricky on case-insensitive but preserving file systems because newPath != oldPath but both exist, so it looks the same as “rename and write new file” (previous case) that should be reported as write.
There is also an issue observing a symbolic link, here we should really observe both the link itself (does it get renamed or deleted) but also the resolved path (does this file get updated).
Currently though this is NOT implemented.
Previously some status bars could be compressed vertically because the dividers did not have a fixed height, so they were sized based on their intrinsic height.
With a fixed height the intrinsic height is redundant and previously it was simply hiding an issue with an under-constrained layout, so better just remove them.
This makes the color of the separator bar better adapt to the color of the status bar and should make things more consistent, as we already have separators inside visual effect views in various places.
Also adjust height of the vertical separators in status bars to only be 15 pixels so that we have equal padding above and below.
