On Wed, Dec 23, 2015 at 4:10 AM, Christian J. Robinson <[email protected]> wrote: > On Tue, 22 Dec 2015, James McCoy wrote: > >> On Tue, Dec 22, 2015 at 08:09:47PM -0500, Jonathan Newton wrote: >>> >>> I guess the use case for :RuntimeUpdate is not clear to me. Do you really >>> want a user (perhaps inexperienced at that) to update only the runtime >>> files >>> without updating the binary? It just seems less error prone to update >>> everything together. >> >> >> Pretty much my thought, too. Why invent a whole new mechanism to update >> the runtime files shipped with Vim instead of just making more frequent >> Vim releases? > > > I agree; the problem is not that it's hard to update runtime files, it's > that there are far, far too few full Windows installer releases. > > - Christian
I'm not sure of the status of MacVim, but: • for Linux every distribution includes a "reasonably" up-to-date Vim (where the definition of "reasonably" is left to the distro in question and where there are sometimes code changes and a system vimrc not under Bram's control); compiling one's own Vim is not very hard. As I'm on Linux myself, I have a couple of HowTo pages: — http://vim.wikia.com/wiki/Getting_the_Vim_source_with_Mercurial : this is for all platforms and doesn't change much; the latest change was to mention the bitbucket Mercurial mirror of the github repository when Bram's repo was moved there from the googlecode site — http://users.skynet.be/antoine.mechelynck/vim/compunix.htm : this describes how I compile Vim myself. AFAIK it is up-to-date; if it doesn't work for you, be sure to let me know. Setting the configure options by means of environmental variables defined in a script "sourced" (not run) by the shell has the following advantages: I don't modify the Makefile, so after creating as many shadow directories as I want to compile different versions of Vim (at the moment Huge and Tiny) I replace the copy in the Makefile in the shadowdir by a link to ../Makefile which is then kept up-to-date by Mercurial if make decides to restart configure (admittedly it doesn't happen now as often as it used to) the configure settings are still the ones I want, even on the second run. Also, I need only set those environment variables once in the konsole tab I use for building from a given shadowdir (Mercurial for Vim runs in a different tab since it has a different cuurent directory) and when a new changeset is pulled, plain (make && make install || echo 'exit status' $?), with logging, is enough to run the build. The featureset is set once and for all. Of course, both "your distro's Vim" and "your own-compiled Vim" will be of the 32- or 64-bit architecture appropriate for your OS and CPU. • for Windows there is the "Vim without Cream" distribution, a 32-bit distribution with gvim.exe, vim.exe and all runtime files, distributed by means of an executable installer as is the custom on Windows. It will run on both W32 systems and W64 with WOW64, which AFAIK means all Windows installations. I recommend it to anyone who doesn't need to edit very big files and use more than 2 GiB for Vim alone. As a point of comparison my current gvim session (with 7 windows but no very big files) uses only 13.9 MiB. This distribution is not republished as often as it used to due to Steve Hall's professional duties but it is still without comparison with Bram's own 7.4.0 which dates back to 2013-08-10: in 2015 it has been updated twice in February, twice in April, once in September and once in December (a few days ago in fact). The main problem with this distribution is that AFAIK it is not as well-known as it deserves: too often I see Windows users reporting bugs in 7.4.0 which have been fixed months or even years ago. Best regards, Tony. -- -- 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.
