I have VIM on Mac & CentOS. So, I see people are writing about -xterm_clipboard, -lua, ... Is there an simple way to install it all? or we have to enable options one-by-one and compile/recompile it?
If you want to install a pre-compiled package, look for a package name like vim-full, vim-huge or something similar.
If you want to compile youself you can pass the --with-features=huge to the configure script. Note, however, this does not enable the different language bindings because those are mostly optional and also the various GUIs need to enabled specifically, because you can have only one gui.
Therefore, you need to pass the --enable-<lang>interp argument for each language you want (e.g. --enable-luainterp --enable-pythoninterp) and the --enable-gui=<gui> e.g. (--enable-gui=gnome for the Gnome Gui).
This should cover the most important compile options. There might still some -flags in the :version output, but those should be generally not really important and would need to be enabled specifically. Read the help of the configure call ./configure --help to see all options available.
Related
I'd like to build a small set of vimscript libraries, however, it seems that the only way to use them would be to load them all globally into vim.
Furthermore, it means that if i wanted to share a single script that depends on those, i'd have to share to them all, which sounds tiresome.
What i was hoping for is some common.js and webpack style approach to vimscript,
does such a thing exist. Something that:
Resolves dependencies
Allows for vimscript files to be "bundled" together into one file.
Everything that i found, winds up being a plugin manager, rather than a plugin build tool.
Do such things exist?
The situation so far, up to Vim 8.
There is no script isolation. When a script is loaded, it's globally. The script can hide variables and functions, but that's all.
Sharing/exporting a function is quite easy: we drop it in an autoload plugin, and we just have to use that function named dirrelatativeto_rtp#subdir#suddir...#scriptname#funcname(). If the script scriptname.vim is installed in dirrelatativeto_rtp/subdir/subdir somewhere in a directory registered in 'runtimepath', it'll get loaded automatically.
Regarding commands, abbreviations, mappings... they are meant to be defined in plugin files, or ftplugin files -- other approaches are possible when we want submodes. Also we cannot use them naively from an autoload plugin or when a script is being loaded -- we'll have to explicitly use :runtime to load the script where this command/mapping/... is defined (as we'd do an import in Python).
Yet, like with Python, scripts aren't installed automagically on our system. It's still up to us to trigger manually the installation of scripts.
We can decide to have library plugins and other plugins that depend on these libraries. But, we need either to tell the end-user everything that must be installed manually, or kindly tell him/her to stop using a plugin manager that don't understand dependencies.
This has been a personal rant of mine for years, the trendy plugin managers don't understand dependencies. There are so far only two plugin managers that do so:
Vim-Addon-Manager (aka VAM): it relies on a central repository (vim-pi) to install a plugin (and its dependencies) with just its name (e.g. :InstallAddon fugitive, :InstallAddon lh-cpp). Unfortunately the central repository is no longer maintained and we can't register new names. Fortunately, we can always install anything with :InstallAddon github:{N}/{repo}. Other functions are available for installing from the .vimrc.
and vim-flavor which is written in ruby, and which install plugins as Vim 8 packages.
Both have their own syntax to declare dependencies. Unlike VAM, we can specify constraints on plugin versions with vim-flavor.
Last thing, if we don't want to distribute all files, we can organize them as several "plugins". But beware of cyclic dependencies. And be kind to end users that are using these trendy plugins managers that don't understand dependencies as they'll need to explicitly install many "plugins"
Starting from Vim 9
We can start to isolate imported plugins in the sense that two plugins can define a function or a command with a same name. Again, this feature seems to mimic Python way of doing things.
However, I expect global stuff like autocommands to continue to operate globally. For instance: I don't see how we could have two template expander plugins running concurrently.
Vim 9 new scripting language won't change anything to the installation of plugins we depend on.
Disclaimer: It has been almost 2 decades now that I've been maintaining my plugins as a bunch of interdependent plugins, organized around a few library plugins, as I don't like to duplicate a same thing several times. In my rant about dependencies & co, I explore quickly other alternative approaches available to us.
Back to the bundling/packaging question (EDIT)
We have ways to package files together.
We can always manually define plugins: put files together in a directory tree, play with git and so on.
We can define tarballs.
We can also define vimballs. Vimballs are a quite old solution for installable archives: files are put in their right directory and documentation tags are produced. There are ways to produce vimballs. I continue to maintain scripts that help producing them for all my plugins. But in all honesty, this is not what people expect to have nowadays to install plugins. I just keep them around in case I release new versions of my plugins on vim.org.
In any case, neither of these solutions end up defining one single file we put somewhere in our ~/.vim/ directory. And I think we will never have something like that because:
Isolation is not perfect. Even with Vim 9 new scripting language: I don't see how we could correctly handle duplication of autocommands. If a same file, that defines autocommands, is duplicated in different versions in several distributed "plugins" I don't see how Vim could handle that correctly.
Vim expects different files in different places: ftplugins, plugins (the original meaning in vim context, not the set of files that could be installed together), syntax files, fold plugins, indent plugins, colorschemes, langmaps, and so on. Vim architecture does not expect everything in a single file.
For these reasons, I cannot see how we could have build systems that build single files ready to be distributed. It could work in some cases (pure collections of functions and "classes"), but not in the general case.
i want to move from using CMake to Premake for my current project, but im usig vim and the YCM plugin which is really great for making my setup like an IDE. However, the plugin needs compilation flags file which is produced when running CMake. Is there something for Premake to generate a file like that as well?
Premake does not do this in its current state (alpha 13). If you have some insights as to what is necessary for getting it to work, the best thing to do would be to submit a ticket in the issue tracker.
I'm afraid, if your new build system does not generate that compilation flags file (yet), you'll need to maintain your own (hand-crafted) one. You can find an example at https://github.com/Valloric/ycmd/blob/0e999dbee209ea79a522259816ce3a68b7d6cddc/examples/.ycm_extra_conf.py.
I would advice to have (at least) one per project rather than one generic one in your $HOME.
Although I have to admit, that it would be beneficial to get it created and in sync with the actual build system, I don't find it too troublesome to maintain it manually. At the end of the day it only contains the C++ standard you want to use, a set of preprocessor symbols and a set of both system and user include directories.
How can one add more delegates to ImageMagick? I'm on gentoo (so, emerge), and while I see a plethora of links to different issues, I've not found any general how-to's:
This points to the source of the delegate libraries here
This points to the need to install underlying image libraries (e.g. libpng), and seems to generally be a repository for everyone's ImageMagick "no decode delegate" questions.
This sort of points back to a second person's issue in the first bullet, though it makes use of a ./configure command that I don't see in my ImageMagick directory
And finally, this might be the answer I need, though the syntax is garbled such that I cannot tell what the intended command is.
In particular, none of these explain what exactly one must do with the delegate libraries here, if they do indeed need to be installed manually. Anyway, my delegates are currently listed (via convert -list configure|grep -i delegate) as bzlib, mpeg, and zlib. I've installed media-libs/libpng, media-libs/tiff, and media-libs/libjpeg-turbo. I didn't grab media-libs/jasper, as it's not clear whether it is necessary. Removing and then installing ImageMagick anew after this (sudo emerge -cav media-gfx/imagemagick then sudo emerge -v media-gfx/imagemagick) didn't change any of my delegates.
Short Answer
A number of these can be handled by setting the USE flags on the imagemagick package. Some use flags can be found by looking at the package's entry on packages.gentoo.org. For a definitive list, check the ebuild on your machine or use tools such as equery.
Details
Portage, gentoo's package manager, is actually just a list of steps needed to build a package from source. USE flags allow you to customize that process. In this case, it changes which packages are built as dependencies.
Steps
One way to set the USE flags is to create a file in /etc/portage/package.use and write the package name on it's own line followed by all the use flag you would like to set. (eg. =media-gfx/imagemagick-7.0.8.8 png would set the png flag for version 7.0.8.8.
Once the USE flags are set, re-emerge the package to build with the new settings (eg. emerge --ask --verbose =media-gfx/imagemagick-7.0.8.8)
For more details on USE flags, read https://wiki.gentoo.org/wiki/USE_flag
I love cygwin and the native windows version of gvim and I use them together all the time. The only problem I have is with cygwin path names. Gvim for windows doesn't understand them so I have to resort to typing things like:
gvim `cygpath -wa ~/scripts/myscript.pl`
Which is annoying!
I was wondering if there's a neat way of using autocmds to detect if a cygwin path has been provided and, if so, convert it to a windows path on the FileReadPre event. Does anyone know if/how this can be acomplished?
There exist several solutions (see vim.wikia.com, cygwin category).
I'm maintaining the more flexible one: cyg-wrapper.sh (flexible in the sense it knows that (vim) flags are not pathnames, and it can even be told that "binary" flags like -c expect another argument that is not a pathname, and in the sense that it is not vim specific)
Regarding the invocation of cygwin executables from win32-vim, you won't have any troubles ... as long as the executable won't return pathnames expressed in *nix format.
For all compilation related executables (gcc/make/doxygen/...) I also have a solution. In the past it was a simple standalone perl script (still available on vim.org). Now I have a full solution that does other compilation related stuff: BuildToolsWrapper (that requires lh-vim-lib on the same site)
Regarding things like :e /etc/hosts, I have no solutions. A long time ago, I've tried to play with FileReadPre & co, but I gave up along the way, and I don't remember why ^^'.
I'm trying to write a configure.ac file such that the resulting configure script searches for a library directory containing a given static library e.g. libsomething.a. How can I do this? At the moment I have it check just one location with:
AC_CHECK_FILE([/usr/local/lib/libsomething.a],[AC_SUBST(libsomething,"-L/usr/local/lib -lsomething")],[AC_SUBST(libcfitsio,'')])
But I want it to try and find it automatically. And if the library isn't in one of the default locations, I'd like configure to say that the library wasn't found and that a custom location can be specified with --use-something=path as is usually done. So I also need to then check if --use-something=path is provided. I'm pretty new at creating configure files, and the M4 documentation isn't very easy to follow, so would appreciate any help.
Thanks!
It's not the job of configure to search where libraries are installed. it should only make sure they are available to the linker. If the user installed them in a different location, he knows how to call ./configure CPPFLAGS=-I/the/location/include LDFLAGS=-L/the/location/lib so that the tools will find the library (this is explained in the --help output of configure and in the standard INSTALL file).
Also --with-package and --enable-package macros are not supposed to be used to specify paths, contrary to what many third-party macros will do. The GNU Coding Standards explicitly prohibit this usage:
Do not use a --with option to
specify the file name to use to find
certain files. That is outside the scope
of what --with options are for.
CPPFLAGS and LDFLAGS are already here to address the problem, so why redevelop and maintain another mechanism?
The best way to figure this out is to look at other autoconf macros that do something similar. Autoconf macros are an amalgam of Bourne shell script and M4 code, so they can literally solve any computable problem.
Here's a link to a macro I wrote for MySQL++ that does this: mysql++.m4.