Feature request: reopen files on launch

[timkendrick]

I'm really enjoying using MacVim – however one feature that I really miss from Sublime Text is the ability for the editor to automatically reopen whatever files were open when it last exited. Do you know if there are any plans to add this behavior to MacVim?

I'm guessing the simplest way to achieve this would be to store the arglist of each active vim process (i.e. one arglist per GUI window) on quit, and then on startup you could automatically spawn a new GUI window for each of these stored arglists – but then again I'm quite new to Vim and I don't know anything about the internals of MacVim so this could be a terrible approach :)

N.B. I'm not talking about restoring the full session state (tabs/splits/etc), seeing as that can easily be accomplished with autocommand-triggered user scripts via :mksession and :source. The missing piece of the puzzle seems to be automatically spawning the vim instances with the correct arglist in the first place…

[chdiza]

This ought to be doable with vim sessions plus mvim.

[jpetrie]

It sounds like this is a subset of what sessions can do, so why aren't sessions appropriate for this? And further, how would you propose this feature interact with sessions?

[chdiza]

I think what @timkendrick wants is for double-clicking on MacVim.app to automatically reopen stuff. AFAIK double-clicking ignores session stuff (unless you put explicit session stuff in vimrc/gvimrc). But mvim, which is the appropriate way to do this, is equivalent to vim -g whatever-session-stuff-you-want.

OTOH now I think @timkendrick wants MacVim to amalgamate the different Vim instances into one stored arglist. I'm unsure whether vim sessions can handle multiple Vim instances. But whether it can or not, this is exactly the sort of thing I think we don't want to add as a uniquely MacVim feature. A request for such a feature should go to the Vim devs.

[timkendrick]

Hi guys – sorry to take a while to get back to you. Perhaps I made this sound more complicated than I intended by talking about sessions and the arglist. Essentially, this is the scenario I'm talking about:

---

1. User launches MacVim.app (and closes initial splash screen window)
2. User clicks File > Open... > selects ~/.vimrc file > OK
3. User clicks File > Open... > selects /etc/hosts file > OK
4. User clicks File > Open... > _selects ~/.bash_profile file_ > OK
5. User clicks MacVim > Quit

Note that there were 3 GUI windows open when the application quit: one containing ~/.vimrc, once containing /etc/hosts, and one containing ~/.bash_profile.

After doing this, the user reopens MacVim.app by double-clicking the application (or using Spotlight/Dock/etc).

Desired behavior: MacVim launches and automatically opens three GUI windows, one containing ~/.vimrc, one containing /etc/hosts, and one containing ~/.bash_profile (just as if the user had opened those files manually using the File > Open... menu).

Actual behavior: MacVim launches with one GUI window containing Bram Moolenaar splash screen. User has to reopen any files they want to edit.

---

Do you know if there's any way of achieving this behavior?

Sorry for causing all this confusion!

[timkendrick]

...also, if we're talking about sessions, I ran into problems when trying to autosave/autoload sessions from the .vimrc.

I'm assuming you'd do something like this to autosave sessions:

autocmd VimLeave * execute "mksession! ~/.vim/sessions/autoload/" . v:servername . ".vim"

... and then you can make a VimEnter autocommand that will autoload the saved sessions by checking whether there are any existing session files in the ~/.vim/sessions/autoload/ directory. If it finds any session files, it executes vim -g -S ~/.vim/sessions/autoload/SAVED_SESSION_NAME.vim (making sure to rename/delete the session file to prevent an infinite loop).

The trouble is with the VimLeave command. Within the command, it seems you have no way of knowing whether the user chose to explicitly close that window (File > Close Window), or whether the window was implicitly closed (MacVim > Quit). In the first case, you don't want the session to be saved, whereas in the second case you do want the session to be saved. I couldn't figure out how to solve this in a vimrc.

[jpetrie]

If you're only talking about window geometry associated with the files, this is maybe a thing MacVim could handle -- it does attempt to restore the geometry of the last closed window currently via user defaults, and window restoration is an OS API.

It may also be doable in a plugin, which I'll look at, but I have some doubts.

In this case what would be the expected behavior if you relaunched MacVim as 'mvim' or by double-clicking a file associated with it (essentially launching with no files on the command line)? What do other editors do in this case? Do we restore and show the new file? Do we only show the new file?

Either way this would probably need to be an opt-in feature since it still may have unforeseen conflicts with session-based restoration.

[timkendrick]

I would say that the expected behavior if you relaunched MacVim as 'mvim' or by double-clicking a file associated with it would be to restore and show the new file (like Sublime Text does). To me that seems very natural.

I agree that it would have to be an opt-in feature, similar to how the 'Open new window on launch' setting is custimizable in the preferences.

[timkendrick]

Sorry, just re-read the first part of your comment: I'm not talking about associating specific window geometry with a specific file.

I'm talking about the step before that, i.e. simply automatically opening the files that were open when MacVim was last quit.

[jpetrie]

But MacVim already tries to restore the last window to its prior location, so failing to do so for any additional windows it would re-open seems very odd?

Other kinks would involve handling "windows" (in the OS sense) with "windows" in the vim sense in them, or multiple tabs, et cetera, and this is where I guess it gets tricky to do this without polluting or otherwise getting our hands in the vim state :/

[timkendrick]

Well if that feature could be added as well that would be amazing! I'd be super-happy with just reopening files though :)

Thanks for all the help on this by the way, I really appreciate it!

[timkendrick]

Other kinks would involve handling "windows" (in the OS sense) with "windows" in the vim sense in them, or multiple tabs, et cetera, and this is where I guess it gets tricky to do this without polluting or otherwise getting our hands in the vim state :/

That's why I feel like it should be MacVim's responsibility just to open the files (and assign the same servername to the windows as they had before, if possible).

Once those vim processes have been spawned, it can be the responsibility of the vimrc user scripts to restore tabs etc, based on the arglist/servername.

[chdiza]

I would say that the expected behavior if you relaunched MacVim as 'mvim' or by double-clicking a file associated with it would be to restore and show the new file (like Sublime Text does). To me that seems very natural.

This is only expected if one is new to Vim. In particular mvim is supposed to just be essentially a shortcut for vim -g, and it is not expected behavior for vim -g to reopen all of your last open files, whether in separate Vim instances or not. Vim requires futzing around with sessions if you want things to be auto-reopened.

I would bet that one of the many session-related plugins on vim.org will get you close to what you want, perhaps in combination with a custom wrapper script and/or some custom vim commands to write session stuff (or not, as the case may be) before saving.

To the extent that what is desired should become built-in to anything at all (and I don't think it should), it should be built into plain Vim and then inherited by MacVim.

[timkendrick]

I see your point, however it seems to me that MacVim is a lot more than just a shortcut to vim -g – rather it is an attempt to integrate Vim into the OS X environment as much as possible. For instance, pressing Command-F within a Vim buffer will open a native OS X 'find' dialog, which seems like a very un-Vim-like behavior.

Similarly, I would have thought that applications reopening all their windows on startup is very much becoming the standard for OS X applications: all of Apple's built-in applications do it, Sublime Text does it, Chrome can be set to do it... it seems that the vast majority of applications from the last few years will have this behavior, either by default or as an optional preference. When an application doesn't have this feature, it begins to feel slightly less integrated with the OS X ecosystem (to me at least).

I think the specific issue here is entirely due to the fact that MacVim allows you to run multiple vim instances simultaneously in separate GUI windows. If there were only one single GUI window this wouldn't be an issue at all (you could just set your vimrc to autoload the previous session). I agree that multiple windows is a great feature to have, and very much in keeping with what you'd expect from an OS X application, but it seems to me that having multiple Vim instances running simultaneously (and exiting them all at the same time) is a large departure from how Vim is traditionally used in the terminal. I was suggesting that seeing as MacVim introduces this multiple-instance behavior in order to be more Mac-like, I would have thought that adding a feature to allow it to recreate those instances on startup would be in keeping with this goal.

I agree that you would never desire this kind of behavior when using Vim in the terminal. It only becomes an issue when there are multiple vim instances running simultaneously – a concept introduced by MacVim. For this reason, I disagree with your point that if anything it should be built into plain Vim rather than MacVim. To me it makes no sense for the vim executable to automatically spawn more vim instances on startup. The vim instance has no knowledge whatsoever of other vim instances – they're completely unrelated to each other. It's the MacVim executable that spawns these processes (e.g. in MMAppController), so I feel that the MacVim executable is in the best position to keep track of them.

For these reasons, and the MacVim-related reasons I mentioned in my comment above, I believe it's impossible to implement proper multiple-window-autoreopening behavior entirely with vim sessions (and would be extremely grateful to you if you could prove otherwise, seeing as I've spent about two days on this and the best I can come up with involves cycling through app windows using AppleScript). I've tried several different vim session plugins, and none of them were able to automatically reopen multiple GUI windows on startup. This is presumably because they were all made for plain Vim (or Gvim, where each instance of the application is self-contained and independent of the other instances) rather than MacVim.

Anyway, I do appreciate all the work you guys have put into MacVim, it's a really impressive project. This feature isn't particularly important, it's just something that I really miss from Sublime Text. Ultimately, it's just be a nice-to-have and I assumed it would be fairly easy to implement (but I could well be wrong about that). Apologies for writing such a long-winded message – I've said my bit so I'll back away now!

[chdiza]

it seems to me that MacVim is a lot more than just a shortcut to vim -g

Yes, MacVim is not just a shortcut to vim -g; MacVim is not a shortcut; MacVim is (one version of) vim -g on the Mac. But I was talking about mvim; mvim is and should be just a shortcut to vim -g.

it's impossible to implement proper multiple-window-autoreopening behavior

What I, and possibly others, are disputing is that in the Vim universe, what you call "proper multiple-window-autoreopening behavior" is in fact proper window-autoreopening behavior. In the Vim universe, what can be done with sessions is proper autoreopening behavior. The Vim universe includes gVim and MacVim. We don't want to make MacVim behave differently than gVim unless absolutely necessary to ensure a baseline level of Maclike experience.

applications reopening all their windows on startup is very much becoming the standard for OS X applications

This is a regrettable development. Lots of people turn off the Resume "feature" of OS X.

and the MacVim-related reasons I mentioned in my comment above

To the extent I understand the problem from that comment, it is solvable with custom "saving" and "closing" commands, perhaps ones which need to call a Vimscript function. When you want to close explicitly, your custom closing command will make sure that that window is not on the list of to-be-repopened windows (it will not call mksession, but might call something else to modify a session file). When you implicitly close via Cmd-Q, your autocommand means it will remain on that list. Then just bind Cmd-W to your custom closing command.

[timkendrick]

OK great – I think maybe it's my understanding of MacVim that was at fault.

I did take a look at overriding the default Cmd+W / Cmd+Shift+W bindings, but this doesn't cover edge cases – e.g. if the user clicks the red 'X' button in the top left of the window. I'm probably being too much of a UI perfectionist here though, you can easily become spoilt when you spend too long in the non-Vim universe :)

Thanks again for the help!

[eirnym]

This feature will be nice to be done automatically when MacVim suggests to upgrade.

[RichardDooling]

Take a look at Tim Pope's Obsession

https://github.com/tpope/vim-obsession

I use it from the command line but might be a way to make it work by double clicking. It's nice because it makes it automatic and you don't have to remember to do it before you exit.

Rick

[eirnym]

@timkendrick Does it still an issue for you?

[timkendrick]

@eirnym I haven’t actually used MacVim for the last couple of years years (switched to using VSCode - the Vim plugin’s pretty impressive and the whole app feels much more integrated with macOS around issues like this). I suspect I’m not the ideal target market for MacVim.

[eirnym]

I understand you and I don't use MacVim much for some languages as well. If it isn't an issue for you (the plugin was proposed), please, close the issue

[schveiguy]

I'd like to see this behavior for 2 specific cases: When macvim wants to upgrade, and when Macos needs to upgrade. I frequently put these off because I have 6 macvim windows open, each split with 2-5 buffers. I don't want to have to reopen all my buffers and window configuration just to upgrade (I don't care much about desktop position, just that the same buffers get reopened, and they are positioned how they were before).

I understand there may be plugins, external utilities, or "sessions" that could be used to kind of achieve this, and I can override specific keys to enable this behavior. Frankly, this isn't good enough, I shouldn't have to edit config files or install vim scripts or whatever. Every Mac app I use reopens all its windows to where I was when restarting if asked to do so. MacVim should do the same (with a switch in the preferences dialog).

[ychin]

I understand you and I don't use MacVim much for some languages as well. If it isn't an issue for you (the plugin was proposed), please, close the issue

We don't need to close this issue and it's fine to have feature requests remain open. However, there are some nuances to consider for implementation, so it may not be implemented in near future.

First, it's important to note that MacVim is a port of Vim, so it can mostly only do what Vim can do, unless we fork and add new functionality. Vim sessions is Vim's native way to handle this but because they are a little imperfect and have subtleties (they don't restore 100% of the state) I'm hesitant to roll it out as a MacVim-native restore feature, as it's not always clear what 'sessionoptions' to use to restore the state the user wants.

I shouldn't have to edit config files or install vim scripts or whatever

Vim generally is a hands-on editor. I don't think it's too much to just call :mksession /tmp/mvim_session.vim to save state and call :source /tmp/mvim_session.vim for now?

[schveiguy]

Vim generally is a hands-on editor. I don't think it's too much to just call :mksession /tmp/mvim_session.vim to save state and call :source /tmp/mvim_session.vim for now?

Yeah, I have been using vim for decades, so I have some experience with editing config files. The problem is, this is really not a vim thing but a Mac thing. Since switching to mac, I have come to fully expect all the apps I work with to just restart properly when I start back up. If sessions can be used to implement this, great! But I really think it would be more in-line with most Mac software to provide an option in the menu. Just "if you turn this on, I will restore all your windows/buffers". It doesn't have to necessarily deal with nuances (i.e. if I had set syntax highlighting off in one buffer, or changed the tab size in another away from the default, don't worry about it). But an easy way for someone to set this up is key.

I had not heard of sessions before this. I tried it, and... it only stores one window's session. I'm sure there are settings I can add to vimrc, and I can muddle through storing 5 or 6 sessions and restoring them all, but again, a switch in the menu == perfect UX.

Thanks for looking at it!

[ychin]

The problem is, this is really not a vim thing but a Mac thing

I mean, it's totally a Vim thing. In order to preserve Vim's state we necessarily need some mechanism to do so, which is sessions in Vim (it supports more than per-window states). I'll probably get to this but I'm not a big fan of half-measures built on top of Vim because eventually it's not going to work in some cases, and some users are going to want to extend it or get confused by the behavior. Also, to Vim's spirits, it's probably better to expose these in a Vim-like manner so they can be customized using existing knowledge of Vim functionality (learning one more thing and having to context shift is not as nice as reusing Vim's paradigm).

I imagine the implementation would likely be either exposing some AutoCmd or letting users set what sessionopt they want, and they would get invoked when this feature gets used.

[schveiguy]

Sorry, I mean the use case is based on the expectation of what a typical Mac app does. How it does it, sure, use vim sessions. I'm also OK if it does its own thing differently. But as a user, it doesn't matter how it gets done, it just should do what normal Mac apps do. I hope you can see where I'm coming from.

Like when I look at chrome settings for example, it has an "On Startup" section, and says "Continue where you left off". This means, when I quit chrome, and start it back up, all the tabs and windows I had open before are now reopened.

When I look at MacVim, it has options for launch to open an untitled window. I just want that extra choice in there, continue where I left off.

If there's a way to do this with the existing configuration system, then a document on how to do so would be most helpful. And it wouldn't hurt to have an option in preferences that does it for you.

Sorry if I seem ignorant on how this all works, I mainly don't write vim config files, I just use vim to write code (and love it).

[ychin]

I see where you are coming from and I understand the desire, but I'm just pointing out that MacVim is downstream of Vim, so the capabilities of it necessarily come from Vim itself. Preserving states is a bit more complicated than opening an untitled window that lives outside of Vim. I'm pointing out the difficulty in having a correct implementation, not whether this is a feature users want.

[schveiguy]

Sorry for one further note: I'm reading more about vim sessions, and it appears that this is going to be something that happens individually for each window, which doesn't help in my case as I have multiple windows open when I want to reboot/upgrade.

If MacVim could do the following, it would leave its hands clean and rely on vim and the user config to do the "right thing" for sessions, but still provide the functionality needed (when the appropriate switch is turned on in the preferences):

1. If using the cmd-q mechanism to quit VIM, then before quitting each window, execute :mksession ~/.mvim/sessX for each window, where X is a separate number.
2. When starting macvim, if any sessions exist that were saved, load them.
3. It's up to the user to configure what happens for the mksession command.

[ychin]

Yeah that's basically what I was thinking regarding sessions, and would likely be how it's implemented. It probably won't get implemented in near future but may come in a later update.

[bkmdev]

I hate to say this but I completely agree with @schveiguy 's initial set of comments. Unfortunately, Apple has stopped maintaining proper hibernation (deep sleep) support for their newer models and has now instead opted for application-supported session restore/resume. Irregardless of the actual implementation, the expectation now is one should be able to easily resume last state (which is an invaluable feature IMO).

I understand the difficulty in implementing such a feature, especially when vim already has a sessions feature and attempting to link it to the OS's native features, but when Mac Vim.app is the only app that doesn't support this, it makes it awkward to use after reboots (or crashes- which is my use case, which sadly are becoming more common with OSX) and results in flight (like with @timkendrick ) 😞 I have been trying to hold onto using MacVim because I love its simplicity, low overhead, and (almost 100%) native WindowManager integration but I may have to eventually do the same, despite my general dislike of VSCode's Electron-based forced "web GUI" 😕