Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
When getting Vim from the nixpkgs, it doesn't come with "clipboard support". This means copying & pasting from/to the X clipboard doesn't work.
Steps to reproduce
Here's the relevant snippet from my
Here's how to ask
The non-enabledness of the clipboard may also be observed by copying something elsewhere in the system and then in vim trying either
I've taken a look at the Vim source to understand why this would be the case. The relevant snippets are in
Detection of X11 headers:
X11 is a requirement for clipboard (
The default vim package does not come with X11 as a build dependency, so it's understandable why clipboard support doesn't work.
Using this information, I have been able to locally compile a Vim with X11 (and hence clipboard) support (quoting from my
Obviously, this is not a full solution. In particular
Feel free to classify this issue report as you see fit (including closing it). The issue tracker simply seemed like the best location to me to document my findings.
The oddly named
I suppose whether this is a bug if a working alternative exists is a matter of taste.
That there should be no runtime dependency is very clear to me.
Regarding build time dependencies I suppose one could argue both ways, and I'm certainly not going to be the one to take that decision.
Is it possible to express the following in the nix language: "this package has a build dependency to X if X is present on the system"? (or indeed: is it possible to express this in any language?)
We/nixpkgs want to avoid unreproducible behavior such as detecting "what is present on the system" (whatever that means actually). Another thing to avoid is trying to support too many versions/configurations. (more resources to build, more difficult to test, etc.)
Well, that's a matter of policy, I guess. Maybe we should agree on some nixpkgs-wide guideline describing how much heavy/light the default versions are expected to be for non-mass-rebuild packages and how we call the other variants (minimal, full, light, etc.); there might be exceptions in some specific cases, but it would seem nice to aim for some level of consistency.