Apologies if I'm missing something, but it looks like company-ebuild can't yet complete things like PYTHON_COMPAT or USE_RUBY. It should be possible based on scraping @VARIABLE from eclassdoc. I don't think it needs to be scoped to the inherited eclasses, although that'd be a nice bonus.
Both of them should be scraped from current repository's eclasses. Example: https://imgur.com/a/5jRqU93 To verify you cna open the ::gentoo repository with any ebuild and then run either in "ielm" on with "M-:" the following code: > (member "USE_RUBY" company-ebuild--dynamic-keywords-variables)
> in "ielm" on with "M-:" in "ielm" OR with "M-:"
As discussed on IRC the problem lies in current implementation of variable scraper used by company-ebuild. In current form company-ebuild finds eclass vars only form the repo containing the opened file in the ebuild-mode mode and each opened repo file triggess the action to search the eclasses of that repo. So, if we have ::gentoo and ::sam opened we will have vars from both but if only ::sam is opened ::gentoo vars (eg PYTHON_COMPAT or USE_RUBY) will be inaccessible. tl;dr: we do not read the repo configuration of "masters = repo" The best solution would be to probably delegate variable collection to completely separate tool as doing this in ELisp is quite slow. Waiting form confirmation that vars from ::gentoo are available if ::some-repo (::sam) and ::gentoo were both accessed in the given Emacs session.
Confirmed that workaround helps.
(In reply to Sam James from comment #4) > Confirmed that workaround helps. Thanks, closing this bug then.
