Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vim is not compiled with clipboard support #26726

Closed
vanschelven opened this issue Jun 20, 2017 · 10 comments

Comments

@vanschelven
Copy link
Contributor

@vanschelven vanschelven commented Jun 20, 2017

Issue description

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 /etc/nixos/configuration.nix:

  environment.systemPackages = with pkgs; [
    vim 

Here's how to ask vim whether clipboard support is enabled:

vim --version | grep clip
-clipboard       ..........
..........      -xterm_clipboard

The non-enabledness of the clipboard may also be observed by copying something elsewhere in the system and then in vim trying either "+p or "*p (paste from either of the 2 X11 registers)

Technical details

  • System: (NixOS: 17.03)
  • Nix version: nix-env (Nix) 1.11.10
  • Nixpkgs version: ("17.03.1316.412b0a17aa")
  • Sandboxing enabled: (false)

Partial solution

I've taken a look at the Vim source to understand why this would be the case. The relevant snippets are in src/configure.ac

Detection of X11 headers:

  dnl Check if the X11 header files are correctly installed. On some systems
  dnl Xlib.h includes files that don't exist.  On some systems X11/Intrinsic.h
  dnl is missing.
  AC_MSG_CHECKING(if X11 header files can be found)
  cflags_save=$CFLAGS
  CFLAGS="$CFLAGS $X_CFLAGS"
  AC_TRY_COMPILE([#include <X11/Xlib.h>
#include <X11/Intrinsic.h>], ,
        AC_MSG_RESULT(yes),
        AC_MSG_RESULT(no); no_x=yes)
  CFLAGS=$cflags_save

X11 is a requirement for clipboard (src/feature.h):

#if defined(FEAT_NORMAL) \
        && (defined(UNIX) || defined(VMS)) \
        && defined(WANT_X11) && defined(HAVE_X11)
# define FEAT_XCLIPBOARD
# ifndef FEAT_CLIPBOARD
#  define FEAT_CLIPBOARD
# endif
#endif

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 /etc/nixos/configuration.nix):

  environment.systemPackages = [
    (pkgs.vim.overrideAttrs (oldAttrs: {
      buildInputs = (oldAttrs.buildInputs ++ [ pkgs.xorg.libX11 pkgs.xorg.libXt ]);
    }))

Obviously, this is not a full solution. In particular

  1. It is a solution on the level of my configuration rather than a pull request on nixpkgs
  2. I've unconditionally depended on libX11's libraries. This is undesirable for the (many) scenario's in which X11 is in fact not available. I would assume it to be possible to express something along the lines of "if X11 is enabled, the following libraries are build dependencies". In any case, how this conditional translates into the Nix world I do not yet understand - (I picked up nix a few days ago)

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.

@dezgeg

This comment has been minimized.

Copy link
Contributor

@dezgeg dezgeg commented Jun 20, 2017

IIIRC the oddly named vimHugeX variant comes with X support.

@vcunat

This comment has been minimized.

Copy link
Member

@vcunat vcunat commented Jun 21, 2017

Yes, vim_configurable as well by default IIRC.

@vanschelven

This comment has been minimized.

Copy link
Contributor Author

@vanschelven vanschelven commented Jun 21, 2017

Indeed in vim_configurable both libX11 and libXt are present as build inputs, which would lead to compilation with clipboard support.

The oddly named vimHugeX is simply a reference to vim_configurable, at least in NixOs 17.03 (https://github.com/NixOS/nixpkgs/blob/release-17.03/pkgs/top-level/all-packages.nix#L15549)

I suppose whether this is a bug if a working alternative exists is a matter of taste.

@vcunat

This comment has been minimized.

Copy link
Member

@vcunat vcunat commented Jun 21, 2017

I believe it was intentional that the default vim doesn't depend on X.

@vanschelven

This comment has been minimized.

Copy link
Contributor Author

@vanschelven vanschelven commented Jun 21, 2017

I believe it was intentional that the default vim doesn't depend on X.

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

@vcunat

This comment has been minimized.

Copy link
Member

@vcunat vcunat commented Jun 21, 2017

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

@vcunat

This comment has been minimized.

Copy link
Member

@vcunat vcunat commented Jun 21, 2017

Related thing: environment.noXlibs option in NixOS.

@lheckemann

This comment has been minimized.

Copy link
Member

@lheckemann lheckemann commented Jun 23, 2017

FWIW vimHugeX does have clipboard support compiled in. "Huge" in this case means 25MB and a 161MB closure so you may want to use that.

@bjornfor

This comment has been minimized.

Copy link
Contributor

@bjornfor bjornfor commented Jun 24, 2017

@vanschelven: If you want to make the default "vim" have clipboard support, please make a PR. (I guess one could argue that the "huge" variant should be called "vim" and the minimal vim be called "vim-minimal" or something?)

@bjornfor bjornfor closed this Jun 24, 2017
@vcunat

This comment has been minimized.

Copy link
Member

@vcunat vcunat commented Jun 26, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.