Nikolay Pavlov wrote:
> 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.
Please keep in mind that this feature is for users who are not familiar
with building programs.
> 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).
Those people who use a package manager or git won't need this command.
Just don't use it. The command can do a check if the Runtime files are
in a place that's likely under control of the package manager and give a
warning.
On the other hand, if the provided packages are stale, this is a useful
way to update the runtime files without having to switch to building Vim
yourself (which requires figuring out the build options, not that easy
if you do it for the first time).
> 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.
I don't agree. Ever looked over the shoulder of someone who tries to
find the Vim installer he wants to use? They probably end up installing
Vim 7.4, just because that's the easiest to find. And that should be
fine, for most users the latests patches don't help them.
> In any case this is poor replacement for a proper package manager.
True. Unfortunately we don't have a proper package manager for all
systems.
> About CRLF: LF endings work on Windows, do not them? Don’t change endings
> and you will be fine.
I'll have to check that. What I'm trying to avoid is that the first
time :RuntimeUpdate runs it downloads all the files.
> 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.
These two paragraphs contradict each other. I think it's OK to
overwrite changed files, because there is no need for the user to change
the files. However, dropping a few plugins in the $VIMRUNTIME/plugins
directory is OK, we can leave them alone.
We can first make an overview of what the command is going to do,
including giving a "CHANGED LOCALLY" warning, before actually making
changes. Although it should probably do its work without a prompt when
everything looks fine.
--
You were lucky to have a LAKE! There were a hundred and sixty of
us living in a small shoebox in the middle of the road.
/// 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.
