'New Tab' menu item #172
'New Tab' menu item #172
Conversation
This is a naive implementation of this functionality. In the view controller, we intercept all calls to `openDocument:`, and check to see if our current document is empty. If it is, we save a reference to it in the app delegate. We check this reference when opening a document, and reuse existing windows if appropriate. This does not currently cover the 'recent documents' menu, which has a different implementation; it calls the application delegate's application:openFile: method.
This uses approximately the same trick used in c74a522 to reuse empty views, except in this case the global state is hidden as a property of the Document type, as opposed to the AppDelegate. If at some point in the future we write a document management model from scratch, this can all become much cleaner and we can pass creation params along with our new & open methods. For the time being, I think this is an acceptable approach. As of this change, we require macOS 10.12, to take advantage of the new tabbing APIs described in this document: https://developer.apple.com/library/content/releasenotes/AppKit/RN-AppKit/#10_12Window%20Tabbing
|
Generally seems fine. Regarding 10.12, my preference would be to allow one major version back. Would it be possible to use Happy to have you working on this stuff! Here's a partial wishlist of front-end things I'd like to see (arguably these should be issues, but I'll keep it lightweight for now):
|
|
Ok, I should be able to ifdef no problem. cmd-T won't work on 10.11. (I may be able to disable the menu item.) I'm also going to move the state storage for opening a new document (#171) into the Document type, to keep that stuff together. And I think I've found a bug where we incorrectly open a window when we expect a tab, so i'll update with these fixes shortly. happy to have some next steps, I'm enjoying myself. Some thoughts, while I'm typing, and you can let me know if any of my ideas have glaring problems:
As well, I'd love to hack on plugins a bit more, but I don't really have a sense of how far a way we are from having multiple plugin support with method lookup &c. It feels like a non-trivial problem. But I'd love to do a racer plugin (and maybe rust language server?); if I had racer & I had the I'm also day-dreaming about a simple fuzzy finder. This is a strange one because it firmly feels like plugin territory, but it's also largely a UI question. I think there's a good argument for having it managed in core, though. |
|
Thanks for this! I added some comments to the break-out issues, and we should continue those discussions there. I'll do word movement soon. Getting it unicode-aware is hard (see unicode-rs/unicode-segmentation#21 for thoughts on getting graphemes right), but it makes sense to do something that works for ASCII first. I suppose find could be a plugin, but it feels like it should be in the core; among other things, it's likely to want to access the entire buffer, which could be a lot of excess RPC. Again, this feels like something where we should get basic functionality in place first, then refine. I'm with you in feeling we're fairly close to having xi suitable for day-to-day programming. I've got to juggle a whole bunch of other responsibilities, but let's get there. |
|
Sounds good raph! I wasn't thinking of find as a plugin for searching in files, but rather a fuzzy-match file navigator, like sublime text's "goto anything" (⌘P) command or Xcode's 'open quickly'. And yea, I'm happy to keep plugging away at this. I had a very slow work week this week, so was able to get properly immersed in the codebase, but I won't be able to quite keep this pace up, though I should certainly have a few evenings free a week. I think I have some pretty clear next-steps, but it might be nice to put together a bare-bones roadmap sometime in the next few weeks, if only to have a sense of where to direct thinking? |
'New Tab' menu item
This builds on #171, and this diff includes a commit from that PR. I was assuming this would take longer. It'll be an easier read if that gets merged. ;)
This is a slightly fudgy way of getting tabbing working again, but it isn't a lot of code and I'm not aware of a better approach. I've tried to provide clear documentation inline.
This commit also bumps the SDK to 10.12, because it takes advantage of some tabbing-related APIs that become available then.
Assuming you're okay with this work, do you have any other frontend features you would like to have worked on? I'm enjoying hacking away, but would like to make sure I'm moving in a useful direction.
closes #168
closes #57