2015-12-21 23:44 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>
> Since Vim is very stable, it does not happen often that a new version is
> released. Mostly it's fine to run an older version. Unless you run into
> a bug there is no pressing reason to update. With the result that many
> users keep using the last official release, since that's just easier.
>
> What does change between releases is the set of runtime files. These
> are updated more frequently, and often this is a more important reason
> to update than getting all the patches. We often see people complaining
> about a syntax highlighting error that was already fixed.
>
> There are various ways in which users can get an updated version,
> including package managers or getting the latest with git and building
> yourself. For at least some people using git to get the latest version
> is fine, but there is a large group of users, especially on MS-Windows
> and Mac, for who this is not so easy. For this group of users I'm
> thinking of the following solution.
>
> Include a plugin with Vim that provides the command:
>
> :RuntimeUpdate
>
> This will get the latest files from github and put them under
> $VIMRUNTIME. The user can run this once in a while, e.g. when someone
> mentions it will solve the problem he experiences.
>
> How would this work?
>
> - Include a file $VIMRUNTIME/CONTENTS that lists all the files, with a
> checksum or "DELETED".
> - The plugin computes the checksum for the local file, and if it differs
> from the entry in CONTENTS it fetches the new file. Github supports
> direct raw access, e.g.:
> https://raw.githubusercontent.com/vim/vim/master/runtime/syntax/vim.vim
> - If the file was deleted, delete it (duh).
> - If the $VIMRNTIME directory is not writable by the current user, put
> the updates in a temp directory and generate a shell script to move
> them into place. The have one "sudo" command to do the work.
> - Rely on the netrw plugin to download the files.
>
>
> Some things that might cause problems:
> - If the line endings are changed from LF to CR-LF then the checksum
> will always differ. Perhaps we need two entries for each file, with
> and without CR-LF?
> - I'm not sure how to put the files in place on MS-Windows if the
> current user can't write in the $VIMRUNTIME directory. Create a .bat
> file perhaps?
> - If the user has local changes, they will be lost. We probably don't
> care. Files that the user adds are left alone, but they can get
> overwritten.
>
> Comments are welcome.
>
1. This is completely useless idea for *nix (both linux and mac) users
because regular users will install Vim using a package manager and let
package manager handle the updates (NOTE: many system package managers will
not like it if you mess with $VIMRUNTIME). Developers following upstream
are following upstream using a local clone of git or mercurial repository
because version control systems provide far more advantages then such
script or package manager (for the purpose of editing something in Vim
sources, I do not mean that package managers are useless in front of
repository existence).
2. I think this is useless idea for Windows users as well because patches
7.N.xxx *do* add features, thus forcing users to choose packages which have
latest Vim like vim without cream. Such packages, of course, contain
up-to-date runtime. Updating just runtime here makes some sense, but I
think that getting used to updating the whole Vim is better.
In any case this is poor replacement for a proper package manager.
About CRLF: LF endings work on Windows, do not them? Don’t change endings
and you will be fine.
About user changes: there is checksum. Use it to check installed files, in
case it does not match leave user variant, creating {file.vim}.new.{a..z}
(e.g. syntax/vim.vim.new.c on third update with user changes) nearby, abort
update if all {file.vim}.new.{a..z} files exist, in any case give a
warning. I think it is better then silently dropping user changes, but user
should get an idea that changing standard files is a bad variant of
handling things.
About deletion: you do not know from which version to which update is
performed. Just state that files in $VIMRUNTIME must *all* be files that
are distributed with Vim. And delete everything which is in old CONTENTS,
but not in new, assuming checksum matches with old. Give a warning for each
file that is not in old CONTENTS or was edited.
>
>
> --
> CONCORDE: Message for you, sir.
> He falls forward revealing the arrow with the note.
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES
> LTD
>
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net
> \\\
> /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/
> \\\
> \\\ an exciting new programming language -- http://www.Zimbu.org
> ///
> \\\ help me help AIDS victims -- http://ICCF-Holland.org
> ///
>
> --
> --
> You received this message from the "vim_dev" 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_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
