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.
- 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
- 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, 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, I'm using
Bill's patch, matchit, and several of Dr. Chip's plugins, and it works
perfectly.
Regards,
Tony.
--
It's the opinion of some that crops could be grown on the moon. Which
raises the fear that it may not be long before we're paying somebody
not to.
-- Franklin P. Jones
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
