Tony Mechelynck, 28.02.2009: > > On 28/02/09 04:54, Markus Heidelberg wrote: > > 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 > > - Not everyone has git installed or is willing to install it and learn > how to use it, when the time-tested procedure of downloading patches one > by one or 100 at a time over ftp, applying them using patch, and > updating the runtime files using rsync, works perfectly.
Obviously it doesn't work perfectly for updating the runtime files. Otherwise we wouldn't have this discussion. > - Unlike the runtime files (inside or outside runtime/doc/ but inside > runtime/ and its subfolders), changes to src/* or to anything outside > runtime/ are not affected by runtime updates Correct, but what do you want to say with it? > - The "separate file" method works perfectly. Just drop the concerned > helpfile in the doc/ subdirectory of one of the 'runtimepath' folders > other than $VIMRUNTIME (and create the needed directory if it doesn't > yet exist), run ":helptags" on the directory where you just dropped the > file, and voilà! Runtime upgrades will leave that alone, Haven't you read my mail? It doesn't work for runtime changes, which you HAVE to put into existing files. Please response to this instead of repeating yourself. > the only time > you will have to go back to it will be if and when there is an update to > that particular file. Bill McCarthy uses that "separate file" method for > the help for his additional float functions, > Dr. Chip Campbell uses it > for those of his plugins which are not part of the standard Vim > distribution, Benji Fisher uses it for his matchit plugin, Plugins are an entirely different case. They don't have anything to do with the source tree. That's the purpose of plugins, to not be dependent on the code. Plugins work for several Vim versions, patches not necessarily. We are talking about patches against the source tree. You have to compile again after applying a patch. And the runtime files belong to Vim's source tree as well as the source files. > I'm using > Bill's patch, matchit, and several of Dr. Chip's plugins, and it works > perfectly. Your workflow works for Bill's patch. But it surely isn't perfect to have a separate file instead of having his function descriptions integrated in eval.txt, where they belong, between the other functions. After putting the content of float-ext.txt into eval.txt http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=b1c65e933dab3fb14042c56af362c168dce91532 I sorted the descriptions http://repo.or.cz/w/vim_extended.git?a=commitdiff;h=d9664e694ddeb8cc0218f6869dc92c27ad1fd2ab and now it's well integrated. I could also add the one-line descriptions in the TOC (:help functions) and to the grouped one-line descriptions (:help function-list). You don't have this possibility. Markus --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
