[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bringing the Neovim package up to date
From: |
HiPhish |
Subject: |
Re: Bringing the Neovim package up to date |
Date: |
Tue, 11 Sep 2018 13:12:13 +0200 |
On Monday, 2018-09-10 14:27:02 CEST Ludovic Courtès wrote:
> Sure! While you’re trying things out, you may find that IRC will be
> better suited to get guidance and information on how to debug issues.
OK, noted.
> Yes. In short you would define the new package to “inherit” from
> ‘lua-5.1’, and you would change its ‘inputs’ field. There are examples
> of that in the code. Let us know if anything’s unclear!
I'll give it a try, I just wanted to know if there is maybe something more to
it to be aware of.
> We cannot #:select from (gnu packages …) modules due to the way Guile
> handles circular dependencies among modules. However we could use
> select more frequently for other modules.
I didn't know about circular dependencies. I mainly wanted to know if there is
maybe a reason or guideline against using `#:select` and whether package
definitions like that might get rejected.
> I don’t know if there’s anything similar for (Neo)Vim, but those of us
> who use Emacs also use Geiser, which displays in the “mode line” at the
> bottom the module that provides a given variable.
That explains a lot. I know about Geiser, but Vim is the editor I have settled
in, I feel that switching would be just as much work as porting Geiser to
Neovim at this point. From what I understand Geiser has two parts: the Emacs
plugin and the actual Geiser process which is written in Scheme. "Porting"
Geiser would only require re-writing the editor interface for Neovim while the
Scheme backend could be kept. It's just that no one has ever felt the need to
do that, Lisp programmers who use Vim are very rare.
Is there a way to get the module from a REPL? I can run a REPL in my editor,
that's the crutch I have been using so far. (IMO tying the readability of the
source code to the development environment is a bad idea, that's what IDEs
always end up doing)