Tony Mechelynck, 28.02.2009: > > On 28/02/09 03:44, Markus Heidelberg wrote: > > Tony Mechelynck, 27.02.2009: > >> On 27/02/09 04:04, Bram Moolenaar wrote: > >>> How about some documentation? So that we know how it's supposed to > >>> work. > >> Yes: the announced eval.txt diff was not included. That's actually a > >> good point, because as long as your patch doesn't make it into "official > >> Vim", you shouldn't touch the official Vim documentation. Why? Because > >> whenever runtime files are updated, the update will sync the user's > >> $VIMRUNTIME/doc/ with the _official_ > >> ftp://ftp.vim.org/pub/vim/runtime/doc/ and ruthlessly eliminate any > >> nonstandard changes you made. Publish your documentation as a separate > >> help file, which can be dropped (on any platform) into > >> $VIM/vimfiles/doc/ or (on Windows) into ~/vimfiles/doc/ or (on Unix) > >> into ~/.vim/doc/, where (in all three cases), runtime upgrade won't > >> touch it. > > > > This workaround with a separate file is not needed if you use the > > vim_extended git repository. > > > > Markus > > You cannot expect that all _users_ of your patches will use it.
I don't. I just pointed out an advantage. BTW: these are not _my_ patches. > So, if you want to > distribute your plugin to _any_ Vim users, you cannot afford to make any > changes in the official runtimes (including the official help) for the > reasons I mentioned: That's not true. Users have always the chance to reapply the patches they are using. And: patches can also contain runtime changes outside of runtime/doc/, where using a separate file doesn't work any more. Or even inside runtime/doc/, where existing documentation has to be adjusted. For the 'relativenumber' patch for example, there are 8 files: http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=aef4930ebeece6fa9c6383b532dabdd56f105cd5 So using a separate file for the documentation is not a generic solution at all. > any user doing a runtime upgrade (by one of the > conventional methods such as e.g. rsync with ftp.nluug.nl::Vim/runtime/ > or ftp from ftp://ftp.vim.org/pub/vim/runtime/), will immediately lose > all your changes to $VIMRUNTIME/**/*. So patch authors should use this "separate file" workaround (which doesn't actually really work), because Vim is not managed in a central way and people don't use the right tool for the right job? With this downside of the runtime files overwriting custom changes, I can't understand why you are so proposing your "only-use-the-patch-tool" workflow. And the git repository simply solves this runtime problem. Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
