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. > - 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? > > 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. > - 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. > - 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. -- -- 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.
