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". > > 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. > > - 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 > > - 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? -- Not too long ago, cut and paste was done with scissors and glue... /// Bram Moolenaar -- [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
