On Di, 22 Dez 2015, Bram Moolenaar wrote:

> Ben Fritz wrote:
> 
> > On Monday, December 21, 2015 at 2:44:27 PM UTC-6, Bram Moolenaar wrote:
> > > 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).
> > 
> > That all makes sense in a way, I suppose. But having a separate
> > repository for just the runtime might make more sense.
> > 
> > Of course some runtime updates are incompatible with earlier versions
> > of Vim, despite the authors' best efforts. So getting the whole dump
> > to fix a problem in one file might occasionally cause unexpected
> > issues. Better to just update all of Vim IMO.
> 
> Although this is possible, I don't recall this happening.  If it does
> happen, we can fix it.
> 
> > > - 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.
> > 
> > I think this will not work in Windows for reasons below.
> > 
> > > - Rely on the netrw plugin to download the files.
> > 
> > I see this causing problems on Windows as well. I've never bothered
> > downloading the required external tools for netrw to actually work for
> > anything but local access on Windows, I'd guess many others are in the
> > same boat.
> > 
> > Honestly if the solution requires a user to download an extra tool on
> > Windows to allow them to download stuff, why not just have them
> > install Mercurial/Git instead?
> 
> Yes, that is why we need to either use something available on every
> Windows system (I don't know what though) or include wget.exe.  I have
> one that is about 250 Kbyte.  Only problem is that I don't know where it
> came from, need to check if we can distribute it.
> Including this is a good idea anyway, so you can just edit any file on
> an ftp or web server "out of the box".

Usually on Windows I had problems with proxy servers so I avoid netrw at 
all. But perhaps setting the http_proxy variable would fix this for 
wget.

Other than that, I like to have a runtime update command available. 
Until now, I just replaced the vim.exe from tuxproject but did not 
bother to update the runtime files, which has biten me once or twice.

> 
> > > 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?
> > 
> > Don't change line endings. Just distribute Unix-style and it will work
> > on Windows, too. Frankly I'm annoyed it doesn't "just work" on Unix
> > with either style like it does on Windows.
> 
> Traditionally we have always distributed runtime files with CR-LF
> endings on Windows.  This is indeed inconsistent, especially when
> updating with git.
> 
> I can give it a try to use LF on Windows and see what doesn't work.
> There might be a few small problems, but it also solves problems.

Please do. This has caused problems for me in the past and my opinion 
would be to just always use LF for all platforms and not care about 
CR+LF at all.

> > > - 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?
> > 
> > I've never really had success with getting admin rights in a .bat
> > file. Supposedly there is the "runas" command but I don't think
> > provides what we want.
> > 
> > Really you'd either need to roll an .exe file/installer or tell the
> > user to run an elevated command prompt. Telling an average user that
> > will make their eyes glaze over. Although to be fair Vim users
> > probably aren't "average" users in many ways.
> 
> We may need to include a small exe that runs the commands.  Just like
> the installer runs with extra priveleges.  However, there is an answer
> on stackoverflow that might work:
> http://stackoverflow.com/questions/1894967/how-to-request-administrator-access-inside-a-batch-file/10052222#10052222

I have been using this approach with the SudoEdit plugin 
(https://github.com/chrisbra/SudoEdit.vim). Haven't heard many 
complaints from Windows users, although debugging and quoting gets 
nasty.

> > > - 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.
> > 
> > That's fair.
> > 
> > All in all, though, I think such a plugin would not be very useful for
> > most people.
> 
> Best is to have something check for updates, click on "update now", and
> it all works perfectly...  Dreaming?

Well, I would like such a simple command.

Best,
Christian
-- 
Es liegt in der menschlichen Natur, vernünftig zu denken und unlogisch
zu handeln.

-- 
-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui