Hi Björn, On 2009-01-11, at 01:03, björn wrote:
>> With 4, I've tried to hack my way through getting scrollbind to work >> when scrolling unfocussed windows (the one not containing the >> cursor). > > This patch has to go to the vim_dev list for Bram to look at since the > changes are to the Vim source code only. Thanks, I'll send it there. >> Patch 3 is a one-liner that I'm not completely comfortable with. It >> makes a call to read the viminfo when a preloaded Vim instance is >> taken and run. > > I understand what the problem is and I think the best way to deal with > it is the same way I deal with [g]vimrc files. All you have to do is > to add a couple of lines to -[MMAppController rcFilesModificationDate] > (it should be completely straightforward so please send me a patch > that you have tested yourself). Good idea, I've done this. The viminfo file is written on exit (although luckily not when exiting by being cleared from the preload cache), so this will invalidate preloaded processes more often. I added a check for this on close, though, so a new process can be prepared in advance. src/MacVim/MMAppController.m | 97 +++++++++++++++++++++++ +------------------ 1 files changed, 55 insertions(+), 42 deletions(-) --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_mac" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
0001-Treat-viminfo-as-an-rc-file-that-can-invalidate-prel.patch
Description: Binary data
>> The reason I'm unhappy about this patch is because it raises two >> issues. First, should this be folded into a more general hook that's >> called when an instance is about to be used? And second, should we >> attempt to unify the viminfo across instances? I could imagine that >> when an instance is deactivated (i.e. when it's no longer the active >> window), it writes its viminfo, and the next instance to be activated >> reads it. (This could be tricky, because the newly-activated instance >> would have to wait until the previous one had finished writing.) > > I think this will all be taken care of by the above suggestion. (?) It dodges the first one, but the second one is still valid. Since viminfo is written on exit, registers now have a sort of slow consistency. I was asking whether we should try to synchronize the registers amongst all open Vim processes, which could be done by reading and writing viminfo more aggressively, or through other means. Jonathon Mah [email protected]
