Previously this appeared correct because once you clicked the minimum height of the pop-up menu set it to the correct height. Corrects an issue noted by @fatiotus in #728.
This is important when we wish to select or edit the URL (in the file browser) as URLs with different values for this flag will not compare as equal, and URL objects created before there is a file on disk will always have this flag set to NO.
Since we retained the SCM info in an asynchronous block, we would potentially extend the lifetime of the SCM info and thus the associated callback, so the callback could be invoked after its owner had been disposed.
This create a new file on disk and brings up the “rename” text field.
You can control the type/extension either in Preferences → New document type or by setting it in .tm_properties, e.g.:
[ attr.untitled ]
fileType = 'source.objc++'
New Document can be undone, but it is handled by deleting the file on disk and losing potential edits you have made since creating it.
Closes#161.
I am not sure what Apple’s thinking is here. We have swipeWithEvent: which worked on 10.7 but seems to no longer work, yet there is a global preference for configuring a swipe gesture and Safari supports that config option, but it appears other apps have to role their own implementation.
This allows us to use the same key for more than just directories. The notification name itself should indicate if the ‘path’ refers only to directories or files.
This mainly relates to the folder pop-up. By delaying creation of this menu till the user actually opens it, we avoid/delay having to create potentially expensive icons (icons are “expensive” since creating one may cause TextMate to hit the disk).
We use ⌘[ and ⌘] which is also used for Text → Shift Left/Right so we only set these keys for when the main text view is not active.
The main advantage is that you can now use these keys to move back and forth in history of HTML views (it also works in file browser, but due to a custom keyDown: overload, it also worked prior to this commit).
We now write what the actions will apply to. This isn’t done for all actions, which is somewhat consistent with Finder, though I don’t know why Finder doesn’t include such description for all items, perhaps it’s seen as redundant to state for every action (and just adds noise), so only items where user could be “confused” should explicitly state what they work on.
All of these will always have the same badge, so there’s no reason to show it (and it covers the alias badge, so there is some usability benefits beyond just the visuals).
- Accept two NSGradient objects instead of four colors.
- Call designated initializer on super instead of self since subclass is likely calling us from its designated initializer
- Make class public
Previously we kept the children which had been expanded, as these had an associated record for tracking file system changes and SCM info.
However, when expanding we weren’t actually re-using the item from the cached record, so not only was this wasteful, but it caused a problem because we effectively created a new item but used the old record with the old item, and while the two items would compare is equal when using isEqualTo:, they didn’t have the same memory address, so the outline view would not consider them equal, and would thus not react on reload requests when using the older item.
This is only to ensure everyone goes through the class method, which is easier to search for (constructing an FSItem from a URL is a little expensive so we wish to get rid of it where possible).
