Package Details: neovim-git 0.10.0.r2536.g55c9e2c96e-1

Git Clone URL: https://aur.archlinux.org/neovim-git.git (read-only, click to copy)
Package Base: neovim-git
Description: Fork of Vim aiming to improve user experience, plugins, and GUIs
Upstream URL: https://neovim.io
Keywords: editor
Licenses: custom:neovim
Conflicts: neovim
Provides: neovim, vim-plugin-runtime
Submitter: fhahn
Maintainer: Farzat
Last Packager: Farzat
Votes: 255
Popularity: 1.73
First Submitted: 2014-02-21 19:50 (UTC)
Last Updated: 2024-03-11 05:36 (UTC)

Dependencies (17)

Required by (432)

Sources (3)

Pinned Comments

fwalch commented on 2016-07-04 19:52 (UTC) (edited on 2016-07-04 19:54 (UTC) by fwalch)

Please don't flag this package out-of-date just because the version number displayed on AUR seems old. This is normal for VCS packages. As long as building the package works without problems, it isn't necessary to update the PKGBUILD here. makepkg will automatically retrieve the latest version when you build the package locally.

Latest Comments

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 40 Next › Last »

eworm commented on 2015-10-06 08:09 (UTC)

Looks like this works just fine with libtermkey (the non-bzr package). Can we change the dependency, please? This will not break existing setups as libtermkey-zr provides libtermkey.

fwalch commented on 2015-09-26 21:59 (UTC)

willemw: 1) Yes: $ vercmp 1.0 1.0.r1 -1 3) Well, that's a legacy that can't be changed, because: $ vercmp 0.r1 r1 1 Also, according to the wiki a leading zero is allowed: "If there are no public releases and no repository tags then zero could be used as a release number". Anyway, this will be moot as soon as the first release is out (which is soon). Then the version will be in format 1.0.r1.

willemw commented on 2015-09-26 17:09 (UTC)

1) Dependency check against Neovim's release version ("neovim>=1.0"): OK. Dependency check against an AUR VCS-package version ("neovim>=$pkgver") ==> ("neovim>=1.0.r10"): does not seem OK to me. Didn't know that "pkgver=1.0.r10" would satisfy "neovim>=1.0". Sure? 2) To be honest, in one of my packages I also have a 'depends' refer to a VCS-package. 3) pkgver() function should return a string starting with a version number or with an 'r', not with a dummy '0'.

fwalch commented on 2015-09-26 16:31 (UTC)

willemw: Thanks for your comments! - Conflicts should be detected because of conflicts=(). The pkgver in provides=() is just to eventually be able to handle versioned dependencies. Say after Neovim's 1.0 release, there would be a "neovim" package with pgkver=1.0 and this neovim-git package with pkgver=1.0.r10 (assuming 10 upstream commits after 1.0 release for this example). If something depends on "neovim>=1.0", both "neovim" and "neovim-git" will be able to satisfy that. - Generally, I agree. However the problem is that there are no non-VCS packages for these dependencies, because there are no (or only outdated) upstream releases. If I just use depends=('libvterm'), when installing this package AUR helpers will complain that there is no libvterm package and abort. So this would be very inconvenient for users. - Do you mean that pkgver (the variable) is not up-to-date? That's inherent with VCS packages (and the reason for the pkgver() function), as otherwise for each upstream commit I'd need to push an update to the PKGBUILD.

willemw commented on 2015-09-26 16:14 (UTC)

Some useful general remarks, I hope: - pkgver in provides=("neovim=${pkgver}"), is that correct? Doesn't this mean that conflicts will not be detected when another version is already installed? - depends/optdepends/makedepends should normally not refer to devel (bzr, git, etc.) names. For example, libtermkey-bzr should define provides=("libtermkey"). Then 'depends' here can refer to libtermkey. - pkgver() is not up-to-date.

fwalch commented on 2015-09-22 21:21 (UTC)

@rtwo: I can reproduce, but it's not related to the dependencies. Let's continue the discussion in your upstream issue (https://github.com/neovim/neovim/issues/3374). @fauno: Neovim depends on unibilium and libtermkey since 2014, so naturally lots of things have changed in the meantime. Please report problems upstream.

fauno commented on 2015-09-22 19:35 (UTC)

hi, i've been trying to upgrade my neovim-git build but since it depends on unibilium, libvterm and libtermkey there's a noticeable lag while exiting insert mode. it's really annoying because when i hit escape while in insert mode and start typing commands at normal speed, the escape gets "cancelled" and it continues in insert mode. does this happen to anyone else? my old build didn't depend on these packages and was even faster than vim, but it broke with the ncurses upgrade :(

rtwo commented on 2015-09-22 18:32 (UTC)

I am having a really wired bug that only appears when I build neovim via aur. nvim -u NONE -c 'set autochdir' Then type :b<TAB> which results in :bNext (but expected behavior would be :b - with a list of possible completions). Can someone please confirm? I am also happy for any suggestions on what might be causing this (wrong deps?) and how I might be able to track this down.

fwalch commented on 2015-09-16 15:10 (UTC)

@lilydjwg: Hmm, I see.. that's a bit tricky. I don't want to introduce a dependency on Python in this package. I will check upstream if this file could possible be moved into the python-neovim package.

lilydjwg commented on 2015-09-16 14:30 (UTC)

Hi, would you compile the Python script /usr/share/nvim/runtime/autoload/provider/script_host.py so that after running as root, there won't be a /usr/share/nvim/runtime/autoload/provider/__pycache__/script_host.cpython-34.pyc file pacman doesn't have an record. Use python -m compileall ${pkgdir}/usr/share/nvim/runtime/autoload/provider should work.

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 40 Next › Last »