I think there's a bug in MacVim that manifests when using its GUI form but not when one calls it in the console. This bug doesn't affect BramVim either. I have never seen this until Mavericks.
There is more than one way to reproduce it. I'm going to include at least two such ways because it might help shed light on the issue. ################## To reproduce, way #1: 0. Have some file (any file) already open in a MacVim window. 1. Navigate in the terminal to some file on your system that is owned by root and for which only root is allowed read-access. If you can't find one, do this: touch foo; sudo chown root:wheel foo; sudo chmod go-rwx foo. 2. Do 'sudo -K' to make sure you shouldn't be able to read foo. Do 'mvim -u NONE -U NONE foo', where 'foo' is that file. 3. Expected behavior: MacVim window appears with no contents but '"foo" [Permission Denied]' at the bottom of the window. The MacVim window that was already open remains untouched. 4. Actual behavior: MacVim instantly quits; all its windows are gone and the green diamond vanishes from the Dock. No opportunity to save unsaved documents is presented. 5. Observation: Console.app contains the following: p Vim[34269]: -[MMBackend(Private) connectionDidDie:]@2315: Main connection was lost before process had a chance to terminate; preserving swap files. 6. Observation #2: The "Expected Behavior" is exhibited by MacVim if one uses the console form (the Vim binary inside the app bundle, which I call by pointing an executable bash script at its path). It's also exhibited by BramVim. 7. Observation #4: I have never observed this kind of behavior on any OS prior to Mavericks. I will try to follow the above reproduction procedures on Tiger and Leopard and Lion later tonight. I predict, however, that I will see the Expected Behavior. I know I've seen "Permission Denied" in MacVim a million times before. 8. Observation #5: Occasionally the Expected Behavior will almost occur, if I keep doing step 2 over and over. By "almost" I mean that I get a MacVim window with "[Permission Denied]" down below, the other windows don't quit, but the terminal spews forth (and Console.app reports): MacVim[43957:303] Metadata.framework [Error]: void _MDItemMarkAsUsedForPath(CFStringRef): was called with a NULL path Quitting MacVim and starting fresh will restore the behavior of step 4. Step 0 is of course not necessary to generate the buggy behavior, but it helps for illustrative purposes. ################## To reproduce: way #2: 0. As before. 1. Create a symlink to a non-existent target: ln -s "fooblyfoobly dummy". 2. Navigate in the terminal to the workind dir. Then do "mvim -u NONE -U NONE dummy". 3. Expected behavior: New MacVim window with empty contents and '"dummy" [New File]' at the bottom. 4. Actual behavior: as in step 4 above. All other observations are the same. Observation: Doing "mvim" rather than double-clicking in the Finder is necessary to show the bug, because otherwise the Finder will detect that there's no underlying file and short-circuit things before handing off to MacVim. ################## I sure hope this has nothing to do with AppNap. I have been seeing strange delays in MacVim, only on Mavericks, only in GUI mode, that shouldn't be happening. I just can't even begin to reliably reproduce them for a report (which itself is some evidence that it's AppNap related). -- -- You received this message from the "vim_mac" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_mac" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_mac+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
