Package Details: vim-youcompleteme-git r3216.0d855962-1

Git Clone URL: https://aur.archlinux.org/vim-youcompleteme-git.git (read-only, click to copy)
Package Base: vim-youcompleteme-git
Description: A code-completion engine for Vim
Upstream URL: https://ycm-core.github.io/YouCompleteMe/
Keywords: completion engine neovim vim ycm
Licenses: GPL3
Groups: vim-plugins
Submitter: thestinger
Maintainer: artafinde
Last Packager: artafinde
Votes: 169
Popularity: 0.035540
First Submitted: 2013-02-05 21:32 (UTC)
Last Updated: 2024-08-19 15:53 (UTC)

Dependencies (19)

Required by (0)

Sources (2)

Pinned Comments

artafinde commented on 2021-04-10 13:03 (UTC)

If you want to use system's abseil set the _use_system_abseil to ON - default is to download from internet during build.

Latest Comments

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 .. 53 Next › Last »

jamesbrink commented on 2019-07-19 22:15 (UTC)

@staletic this is awesome thank you so much for the info! I will add you as a co-maintainer. Let's get this thing cleaned up!

staletic commented on 2019-07-19 13:11 (UTC)

Hello, I'm one of YCM maintainers. I'll be happy to help with packaging YCM.

Regarding git submodules, instead of pulling from git, just purge them and install the dependencies from official repos.

This is the list of direct YCM/ycmd dependencies (let's leave ycmd bundled for now and let's hope this board supports markdown):

  • python-bottle
  • python-jedi
  • python-regex
  • python-waitress
  • python-future
  • python-requests
  • python-frozendict
  • aur/python-requests-futures

As for completers, TSServer can be installed as an optional dependency and YCM will pick it up if there's no TSServer in third_party.

If this package moves to clangd completer over libclang completer, it could be decoupled too, but the user would need to specify the following

let g:ycm_use_clangd = 1
let g:ycm_clangd_binary_path = 'clangd'

Let's fix those before we dive into decoupling all completers.

jamesbrink commented on 2019-07-15 08:26 (UTC)

I have moved omnisearch-roslyn into it's own package and made it an optional dep. This is still a work in progress, and I will likely need more extensive patches specifically for arch in the future. There is a still a lot of cleanup needed on the git submodules as they should all be listed as sources and not pulled in dynamically per Arch packaging guidelines.

jamesbrink commented on 2019-07-15 01:50 (UTC)

Okay, I have added a simple quick and dirty patch to ycmd that will allow this package to use the existing installed toolchains. I have tested this on my existing account and a fresh account in a chroot. Both seemed to have worked fine for me. If this is an acceptable solution we could decide to re-enable rust support by default.

jamesbrink commented on 2019-07-15 00:27 (UTC)

Interesting regarding rust support. I found this TODO in upstream

https://github.com/ycm-core/ycmd/blob/master/ycmd/completers/rust/rust_completer.py#L89

#TODO: allow users to pick a custom toolchain.

Contemplating making a patch here for this package that could possibly just use the existing default rustup toolchain. The default rustup package actually drops an /usr/bin/rls file which links to rustup and I assume it handles the magic of finding it within each users home directory.

zerophase commented on 2019-07-14 23:14 (UTC) (edited on 2019-07-14 23:15 (UTC) by zerophase)

I don't install the package, but follow this to help find bugs when updating you complete me.

I just use:

function! BuildYCM(info)
    if a:info.status == 'installed' || a:info.status == 'updated' || a:info.force
        !./install.py --all --system-libclang
    endif
endfunction

You could probably edit my vim function for bash to just pass all of the flags you need when building different variations of ycm.

jamesbrink commented on 2019-07-14 22:55 (UTC)

@Foucault I am also pretty torn on this, I think anyone doing rust development would be more likely to have rustup installed over rust but I could be wrong. What is very clear though is we need to get rid of this duplication.

jamesbrink commented on 2019-07-14 22:17 (UTC)

Based on the feedback I have gone ahead and disabled building rust support by default in the build options. I will look into cleaning this up a bit more. My initial concern was just getting everything building and working. Again I appreciate all the feedback and suggestions.

Foucault commented on 2019-07-14 17:45 (UTC) (edited on 2019-07-14 17:49 (UTC) by Foucault)

People using rust completion probably already have one rust toolchain installed. It's wasted space duplicating everything. What is not completely clear from the installation guide is whether this can be avoided as it requires the nightly version of rust so if your system defaults to stable (the archlinux rust package does) then you cannot work with completion at all.

Personally I would just use the rust language server plugin for vim separately rather than installing loads and loads of duplicate stuff.

lahwaacz commented on 2019-07-14 10:20 (UTC)

@jamesbrink Split packages would make sense for a binary repo, but the killer feature of the manual build options is that we can choose not to build some parts at all.

« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 .. 53 Next › Last »