Használható szintet ért el a Neovim

 ( enpassant | 2015. június 25., csütörtök - 15:51 )

A múlt év elején nagy fába vágta fejszéjét Thiago de Arruda (tarruda), elhatározta, hogy teljesen refaktorálja a Vim-et.

Egy modernebb fejlesztési modellre vált, ahol nem egy személyen múlik a projekt sorsa.
Szétvagdalja különböző részekre a programot, UI, backend, plugins. A pluginek tetszőleges nyelven írhatók, aszinkron módon kapcsolódnak a programhoz, de a régi pluginek is használhatók lesznek egy kompatibilis rétegen keresztül.
What is Neovim, and why should you care?

Mivel úgy látta, hogy ez olyan nagy falat, hogy szabadidőben nem igazán lehet megcsinálni, támogatókat keresett a BountySource-on. 10e$ volt a minimális cél (2 hónapnyi munkáért), de közel 34e$ jött össze.

Azóta sokat fejlődött és ma találkoztam egy olyan videóval, ahol azt állítja a videó készítője, hogy már teljesen használható és át is váltott rá.

Nosza ki is próbáltam én is. Telepítettem PPA tárolóból Ubuntura, de nagyon sok másik rendszerre is lehet.
A .vimrc fájlt és a .vim könyvtárakat linkeltem .nvimrc-nek és .nvim-nek.
Ezután elindítottam.
Szinte minden ment kapásból, egyedül a clipboard és a python támogatással kellett egy kicsit küzdeni, illetve a remote rendszer teljesen kikerült a programból és helyette a sokkal jobban használható msgpack-rpc rendszer került.

Mindenkinek tudom ajánlani, már most tényleg teljesen használható!

A fejlesztés még nem ért véget, rengeteg javítás és okosság kerül még bele, ezért továbbra is várják a támogatókat!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem használok semmilyen vimet, de ez nagyon érdekes olvasmány. Elég gáznak tűnik ez a Bram nevű arc.

--

Néhány kommenttel azért teljesebb a kép, állítólag a patch amit a blogíró említett Windowson nem működött, félkész patchet nem sok ember fogadna be szívesen.

A legtöbb felsorolt dolog pedig nem annyira rémes, a pathogen, vundle, neobundle csomagkezelőkkel a plugin fejlesztők és használók már régen a GitHubon élnek, a vimproc.vim-mel még az aszinkron futtatás is meg van oldva.

Így van, azért nem annyira fekete-fehér a kép, mint ahogy elsőre látszik, de nagyjából ennyi írható a vim javára, mint amennyit írsz is (a sok negatívum mellett).

"A legtöbb felsorolt dolog pedig nem annyira rémes,"
A leírás alapján a kód eléggé rémesnek tűnik és az eddigiek alapján nem is látszik, hogy ezen szándékoznának, illetve egyáltalán lehetséges-e az adott fejlesztési modellel változtatni.
vs letisztított kód, erős tesztrendszerrel.

A fejlesztési modell is egy nagy plusz. Emiatt vélhetően sokkal gyorsabban fog fejlődni a neovim, mint a vim (sőt talán már meg is előzte).
Az, hogy elvileg sokféle nyelven lehet plugint írni, az is. Emiatt a pluginek minősége is nőhet (lua, python, ... vs vimscript)

Az ui különválasztása is hatalmas plusz. Így mindenféle helyekre könnyen bekerülhet (lásd Atom-hoz már készült ui), és a portolás része is egyszerűbb illetve független az alaptól.
Illetve ezáltal egyszerűbb lesz az IDE jellegű szolgáltatások fejlesztése is.

Subscribe.

Én még várok az atomstabil egypontnulla LTS verzióra :-)

Nekem jó az atomstabil 0.0.0-ás verzió is :)

sub +1

sub

Megérkezett az atomstabil 0.1-es verzió! :)

0.1: "whoa"

The primary goal of the 0.1 release ("first public release") is to reach a stable, functional baseline that can be built upon and used as a benchmark for further progress. Releasing a stable product to a larger audience will increase feedback on potential "blind spots", and will signal the most effective next direction for the project to focus on.

Ha valaki távolról szeretné vezérelni a neovim-et, akkor az alábbi python scripttel megteheti:

#!/usr/bin/env python
import click, re, sys
from neovim import attach

IP_ADDR = re.compile(r'^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\:(\d{1,5})$')

@click.command(context_settings=dict(allow_extra_args=True))
@click.option('--address', default='127.0.0.1:22913')
@click.option('--remote-send', default=None)
@click.option('--expr', default=None)
@click.option('--tab/--no-tab', default=False)
@click.option('--silent/--no-silent', default=False)
@click.pass_context
def main(ctx, address, remote_send, expr, tab, silent):
    result = IP_ADDR.match(address)
    if result:
        args = ('tcp',)
        kwargs = {'address': result.group(1), 'port': int(result.group(2))}
    else:
        args = ('socket',)
        kwargs = {'path': address}
    try:
        nvim = attach(*args, **kwargs)
    except Exception as e:
        if not silent:
            print >> sys.stderr, e.message
        sys.exit(1)

    if remote_send:
        nvim.input(remote_send)
    elif expr:
        print nvim.eval(expr)
    else:
        files = ctx.args
        if not files:
            print >> sys.stderr, 'Need at least one file to edit'
            sys.exit(1)
        cmd = 'tabedit' if tab else 'edit'
        for f in files:
            nvim.command('{0} {1}'.format(cmd, f))

if __name__ == '__main__':
    main()

Akik nvim-et használnának Scala fejlesztéshez és szeretnék, ha hiba esetén a hibára ugorjon a kurzor, azok így tudják beállítani:
1.a. A ~/.sbt/0.13/plugins/plugins.sbt -ba tegyük be: addSbtPlugin("com.dscleaver.sbt" % "sbt-quickfix" % "0.4.1")
1.b. Ha 0.13.8 utáni sbt-t szeretnél használni, akkor ennél a pull requestnél leírt dolgokat kell megcsinálni
2. A fenti sciptet nevezzük el mondjuk nvim-remote.py-nak (és tegyük be a path-ba)
3. A ~/.sbt/0.13/global.sbt -be tegyük be a következő beállítást: QuickFixKeys.vimExecutable := "nvim-remote.py", ha nem tettük a path-ba, akkor ide a teljes elérési út kell.

Ezt kiprobalom en is, jelenleg Pathogen-es kornyezetet hasznalok, eleg randa sok pluginnel, de hat sokfele fajlt kell tudnom szerkeszteni. Ha valakit erdekel, a https://github.com/hron84/dotvim oldalon nezelodhet a profilomban, vagy akar at is vehet dolgokat.
--
Blog | @hron84
Üzemeltető macik

Én Vundle-t használok, a config oldalamon ott van nekem is minden vim-es és zsh beállításom, ha valakit érdekelne.

A pathogen elég idejétmúlt. tpope továbbra is a legjobb, de pluginkezelőt írtak már ezerszer jobbakat nála.

vim-plug aszinkron leszedi neked githubról a plugineket, make-el ha kell, és még azt is beállíthatod, hogy egyes pluginek csak bizonyos fájltíusoknál töltődjenek (pl. css highlighter minek egy .sh szerkesztéséhez)

Ránéztem a dotvim repódra, ez a gitm submodulos bohóckodás nagyon maintainelhetetlen, de kb. 10 perc áttérni valami jobbra. BTW itt az én vimrc-m: https://bitbucket.org/kmARC/vim/src/3e43477cdf19a3dc822c019ab7a97fc06116c892/vimrc?at=master
Éles felhasználásra még nem ajánlom a repót, de vim-plughoz ötletet meríteni jó lehet.

Ez a vim-plug nagyon jónak tűnik, köszi!
Bár 1 mp alatt indul a (n)vim nálam, de minek töltődjön be minden plugin, ami nem is kell.
Teszek is vele egy próbát!

Cserébe hadd mutassak egy plugint (mivel látom, hogy nem használod), ami killer feaute, már emiatt is érdemes vim-et használni :). Természetesen ez is a vim mesterétől van: 'tpope/vim-abolish'.

Itt egy jó kis screencast hozzá a vim cast-ok mesterétől, Drew Neil-től: Supercharged substitution with :Subvert
Még ezeket is tudja ez a plugin: Smart search with :Subvert, Enhanced abbreviations with :Abolish

Nincs mit. Tobbet kiprobaltam, ez a legjobb. Ami kicsit zavaro,hogy git submodulok toltesenel fagy az ui, illetve a YCM makeje sokaig tart, es vegig kell nezni :)

Abolisht probaltam, engem meg nem sodort magaval...

Nem rossz. A matchit-et miert toltod kulon? Nekem pathogen-nel siman megy...

Mondjuk nekem a Makefile miatt gyakorlatilag mindig csak egy make parancs kiadasa a telepites, egy uj modul telepitse pedig egy "git submodule add URL bundle/vim-lofasz", aztan git commit.
--
Blog | @hron84
Üzemeltető macik

A matchit az alap disztrib resze,nem volt ra szukseg,h kulon toltsem. Ja, konzisztensebb lenne.

Hidd el, felejtsd el a makefile baszakodast, tobb munka... Git submodult kivenni macera, pluggal sokkal konnyebb egy-egy pugint kiprobalni

Hogy nez ki a profil elso telepitese? Marmint, en a vim profilomat foleg azert tartom GitHubon, mert tobb gepen is fut egyszerre, most igy hirtelen alapbol negy gepet tudok felsorolni, de ennel sokkal nagyobb lehet a szam.

A makefile valoszinuleg marad a konfig helyremasolas es az elso telepitesek miatt.
--
Blog | @hron84
Üzemeltető macik

Nezd mmeg a readmet a repomban. Ami miatt az en disztribem lassan telepul,az a YCM forditas, amire nincs mindenhol szuksegem. Majd egyszer csinalok egy install.sh-t.

Fellovok egy vmet altalaban ez az elso :)

Oks, akkor kiprobalom.

A NeoVim viszont ugy nez ki, parkolopalyara kerul egy idore. Nincs if_ruby, anelkul meg nem szol a LustyExplorer, anelkul meg nincs erdemi fejlesztes. Szoval I'll stay tooned.

Viszont egy erdekes problemam van: amiota kiprobaltam a NeoVim-et, azota nem tudok pasztazni rendesen a _normal_ Vimbe, mert mindig elemasol valami karaktert (^W-t talan?), holott ilyen nincs a vagolapon, es pl. shellbe tokeletesen tudok beilleszteni.

A .vim mappat es a .vimrc fajlt direkt masoltam, nem linkeltem, hogy ha barmi neovim-specifikus beallitas kerulne bele, azzal ne torjem el a mukodo konfigot. Oszt' megis...
--
Blog | @hron84
Üzemeltető macik

Elvileg semmi hatása nem kellene legyen a vim-re a neovimnek.
Telepítettél valamilyen új clipboard kezelő programot?
- xclip
- xsel (newer alternative to xclip)
- pbcopy/pbpaste (only for Mac OS X)

(Én xsel-t telepítettem, de ilyen hatást nem tapasztaltam)

Milyen módon paste-zol?
set clipboard=unnamedplus?
vagy a +, * regiszterekkel?

- Telepítettél valamilyen új clipboard kezelő programot?

Nem, pontosabban az xclip-et mar regota hasznalom, de csak mint one-shot cuccot, bizonyos programok kimenetenek vagolapra kuldesere (konkretan csinaltam Linuxra egy pbcopy scriptet, ami az OS X-es beepitett pbcopy parancs mukodeset utanozza)

- Milyen módon paste-zol?

Gnome Terminal-t hasznalok, a sima selection clipboardra teszem ki a szoveget (egerrel kijelolom valahol), utana Shift+Insert (ezt normalisan a Gnome Terminal kezeli le) pasztazza be. Korabban ezzel semmilyen problemam nem volt, illetve parancssorban most sincs.

Ami fura, hogy se ":set paste" modban, se normal insert modban nem jo a dolog. Ha insert modban nyomok ^V -t, akkor utana latom, hogy bepasztazza jol a szoveget, de az elso karakter valami specialis cucc, amit nem tudok hova tenni, hogy micsoda, korabban sose talalkoztam ilyen mukodessel.

Holnap megprobalom ujrainditani a gepet, hatha valami a memoriaban torott el benne, mindenkeppen referalok, hogy megjavult-e.
--
Blog | @hron84
Üzemeltető macik

(Én xsel-t telepítettem, ahogy írtam is.)

A set clipboard=unnamedplus van beállítva nálam.
Így a clipboard része működik (oda-vissza) a szabvány vim p, y, d (paste, yank, delete) gombokkal.

A Shift+Insert pedig működik a selection clipboard-dal.

Plusz karaktert nem tapasztalok sem az nvim-ben, sem a vim-ben, pedig én is Gnome Teminálban használom.
Lehet, hogy az xclip vs xsel az ok? Más különbséget egyelőre nem látok.

Illetve még ilyesmit találtam a témában:
[SOLVED] Weird characters while pasting in terminal

Az xclip az tobbmillio eve fenn van a gepen, es eddig nem okozott problemat.

Ujrainditas utan a problema nyomtalanul eltunt. Nem tudom reprodukalni a hibat. Biztos a kvantum miatt volt.
--
Blog | @hron84
Üzemeltető macik

Szerintem a LustyExplorer-nél jobb a CtrlP és a NERDTree páros, és ezek mennek nvim-mel.

Szerk.:
CtrlP, keresés a projekt alatti összes fájlban egész útvonal vagy csak fájl név alapján, szövegesen vagy reg.exp-pel. Tud egyszerre több fájlt is megnyitni, lehet az utoljára megnyitottak között keresni illetve a bufferben levők között.

NERDTree, grafikus tree-ben lehet mozogni, fájlokat megnyitni, rejtett fájlokat mutatni, eltüntetni, tud fájlokat, könyvtárakat törölni, létrehozni, másolni, átnevezni, és még egyebeket.

CtrlP-t nem nagyon fejlesztik mar, Unite-ot toljak nagyon sokan, de mint a konfigbol is lathato, en meg kitartok az elobbi mellett.

Amugy a CtrlP+NerdTree kombo nagyon bevalt. Uj, ismeretlen projektnel a faban akarok navigalni, nezelodni, ha egyszer viszont benne vagyok mar, akkor csak is fuzzyfinder johet szoba. Ilyen eclipse-es project trees bohockodast mar el sem tudok kepzelni.

Szerk. Amugy probalgattam csak netrw-t, meg vinegart, sot meg uniteot is, de egyelore a lustasag, meg a bevalt gyakorlat gyozott...

A CtrlP-nél a kereséshez én ag-t használok, az eszméletlen gyors.

Sőt a vim-plug-gal még függőséget is lehet kezelni, ha netán valamelyik plugin függ valamelyik másiktól.
Pl.:
" Group dependencies, vim-snippets depends on ultisnips
Plug 'SirVer/ultisnips' | Plug 'honza/vim-snippets'

Nekem az is nagyon tetszik, hogy akár parancsokra is lehet kötni a pluginek betöltését ("On-demand loading: Commands or <Plug>-mappings")
Pl.:

" NERD tree will be loaded on the first invocation of NERDTreeToggle command
Plug 'scrooloose/nerdtree', { 'on': 'NERDTreeToggle' }

" Multiple commands
Plug 'junegunn/vim-github-dashboard', { 'on': ['GHDashboard', 'GHActivity'] }

Felcsigaztatok, hetvegen megprobalok atterni ra.
--
Blog | @hron84
Üzemeltető macik

Atterni kb. 10 perc. Fasza konfigot oaszehozni (dependencyk,ondemand,etc) az kb. tovabbi fel ora. Nezd meg a repom,van benne egy readme is,hogy mibol all a pluginstall meg a plugupdate. De ahogy hallom mar sok uj ficsor van upstream is, szoval erdemes atolvasni a vimplug readmejet is.

Pont ezert akarok egy hetveget raszanni. Nekem a vim munkaeszkoz, le kell demoznom a lokal gepen valo atallast is.
--
Blog | @hron84
Üzemeltető macik

Kipróbáltad?

Tapasztalatok?

Hupsz, ez a topic eltunt nalam a trackerben. Kiprobaltam a NeoVim-et, de volt valami cucca, aminel konstans osszecrashelte magat, valoszinuleg valami build-hiba volt, de nem volt eleg idom erdemben kidebugolni. Most karacsony kornyeken lesz egy nyugisabb idoszak, akkor lehet nekifutok megint.

Kulonben atalltam VimPlug-ra, illetve a Makefile-os rendszert is atalakitottam egy kisse, fu alatt a Plug cuccait hivja meg. Sajnos keves ondemand meg hasonlom van, a legtobb plugint indulaskor toltom be, de annyira nem is erdekes, mert nincs tul sok.

Ami a NeoVim-es vegleges atallast illeti, az nalam nagyban fugg az if_ruby-tol, mert a Lusty-rol nem mondok le. Ami itt felreertes volt, en a Lusty-t nem a kodkiegeszitese miatt szeretem (azt kb. nem is hasznalom sehol), hanem a nyitott fajlok kozti egyszeru navigacioja miatt. Alig bonyolultabb, mint egy masik "fulre" atkattintani. Mivel sosem egy projekten belul navigalok, hanem egy komplett rendszeren belul, igy az ilyen faszerkezetes, fancy mappabongeszos cuccok nalam nem hasznosak.

Ami a Plug-ositast illeti, nezd meg a repomat. Az mindenkepp jo, hogy kikerult belole az a sok submodule, kicsit nyugos volt frissitgetni...
--
Blog | @hron84
Üzemeltető macik

Hmm... Mi itt felreertettuk egymast, en arra gondoltam, hogy a _vim-plug_-ot probald ki, nem feltetlenul a neovim-et :-) Azzal megcsak a makefile-jaidat is elfelejtheted.

Amugy tenyleg, megis mire hasznalsz makefile-t?
(Egy :PlugUpdate ritkabban :PlugUpgrade nekem megold mindent)

Szerk: Ja ertem, hogy magahoz az initial setuphoz hasznalod. Ja, arra nekem is kene valami. Mondjuk egy sima shellscript is megteszi :)

Amugy most megneztem a repodat, azt irod sajnos keves ondemandod van, de ez nem igaz:

Dockerfile, Gemfile, smarty, coffe-script, vagrant, puppet, markdown, ezek biztosan ondemand tolthetoek lennenek... Igazabol alig van olyan plugined, amit indulaskor kell betoltened, a legtobb mind filetype specifikus.

Igazából de, ugyanis az ondemand-nál az a bajom, hogy _új_ fájl esetében nem fogja tudni a szintaxist, illetőleg pl. a Gemfile esetében pl. a filetype csak akkor él, ha a plugin már be van töltve (hiszen maga az ftdetect definíció is a pluginben van benne), és nem láttam, hogy ezt a problémát hol lehet feloldani. A Plug gondolom nem fogja megtanulni az ftdetect szabályokat (ennyire nem intelligens), én meg nem akarom ezeket a szabályokat háromszor megírni.
--
Blog | @hron84
Üzemeltető macik

> az a bajom, hogy _új_ fájl esetében nem fogja tudni a szintaxist
De. Amikor letrehozol egy uj fajlt, pl. mondjuk Makefile-t, akkor mar a filenevbol beallitja a filetype=make-et.

Az igaz viszont, hogy ha mag a Gemfile definicioja a Gemfile-pluginban van, akkor nem fog mukodni. A tobbi plugin is ilyen?

Majdnem az osszes szintaxis pluginom ilyen, es a repo tobb, mint fele abbol all, hogy kulonbozo fajlok szintaxisaihoz plugin. Szoval ja.

De ott a Plugfile.vim, nyilt forrasu, olvasd el. :-)
--
Blog | @hron84
Üzemeltető macik

Vagy a plug#load(names...) segítségéval akkor amikor te akarod, hogy betöltődjön.

Ez érdekes, de hogyan mondod megy egy pluginnál, hogy ne töltődjön be automatikusan induláskor, ha nem az on demand-ot használod (for, on)?

Szerk.: közben a FAQ-ban megtaláltam.

Hmmm ez nem remlett, mikor kerult be ez a ficsor vajon? Koszi!

Nem tudom, kb 1 hónapja kezdtem el használni. Akkor már tudta. :D

Plugint én vopherrel managelek, egy file lista aztán kész.
--
HUP Firefox extension

Fuggosegeket tud? Ondemand loadingot? Plugin update-et, chnagelog mutatasaval? Parallel letoltest?

Nem, csak letolti es feltelepiti, amit listazol. Readme-t nem nezted?
--
HUP Firefox extension

Nem,telefonrol vagyok, maceras... :)

Szoval alig tud valamit a vim-plughoz kepest.

Hát arra való, hogy könnyen fel tudd húzni magadnak a plugineket, másra nincs szükségem. :)

Másra nincs is szükséged hozzá csak a vopher binárisra meg a listára. :) https://github.com/mgumz/vopher#faq
--
HUP Firefox extension

A pluginek ondemand betöltésének szerintem ezek lehetnek az előnyei:

  • gyorsabban indul a vim,
  • kevesebbet memóriát használ,
  • kevesebbet processzort használ,
  • több gépes használatnál nem gond, ha egy plugin egyik gépen nem megy, de ott nincs is rá szükség
  • a parancsok gépelésekor kiegészítéskor nem kapsz sok lényegtelen találatot

Nem tudom, hogy van-e tényleges előnye, de számomra megnyugtató tudat, hogy nem tölt be olyat, amire éppen nincs szükségem.

Kobalta!!444negy!
--
Blog | @hron84
Üzemeltető macik

Kapott egy új funkciót, amit érdemes megemlíteni.
A :terminal paranccsal képes egy teljes értékű terminál emulátort futtatni. A terminál a natív puffereket és ablakokat használja, így át lehet váltani a különböző üzemmódok között (Terminal, Normal, Visual).

Ettől a változtatástól félek a legjobban.

1) Már régóta benne van, és lassú.
2) A vim-nek nem ez a mögöttes gondolatvilága. Nem egy IDE, nincs benne debugger, nincs benne terminál, nincs benne gui editor, etc.
3) A probléma, amit megpróbál megoldani, már rég megoldódott a különféle tmux-integrációs pluginek segítségével. Ezáltal a tmux amolyan opcionális "külső függőség", de éppúgy az (sőt, mégcsak nem is feltétlenül opcionális) a python, lua, make, etc. is.
4) A neovimet embeddable-nek szánják, pl. IDE-kbe, ezen kívül nincs is GUI támogatása, csak terminálos. Namost az a "hoszt" szoftver, ami embeddeli, az tud magának valószínűleg terminált is embeddelni, a terminal-only nvim-nek pedig (mivel amúgy is terminálban fut, ezért feltételezhetően a usernek vannak eszközei terminálbeli munkavégzéshez) pont terminálra nincs szüksége.

Egyszóval ez egy koncepcionálisan ellentmondó(2), már amúgyis megoldott(3), fölösleges(4) és gyatrán implementált(1) funkció.

Az egyeten pozitívumaként azt látom, hogy most, hogy "alapból lesz" terminál a nvim-ben, fognak íródni hozzá mégkúlabb pluginek, ahol eddig esetleg a tmux-, és a sokféle tmux-integrációs plugin-függőség visszatartó tényező volt.

Sok mindennel egyetértek amit írsz.

1) Miből látszik, hogy lassú és, hogy gyatrán implementált?
2)
"Nem egy IDE": ezen sok vita folyt már. Ha igaznak is vesszük, akkor is az IDE-k nagyon sok funkcióját tudja vagy alapból, vagy plugin segítségével.
"Nincs benne debugger": benne nincs, de tud külső debuggerekhez kapcsolódni (a legtöbb IDE egyébként ilyen).
"Nincs benne terminál": ez is igaz, de a :shell parancsot azért valamiért létrehozták.
"Nincs benne gui editor": gvim, MacVim
3) Ez is igaz, de az, hogy valamire már van valamilyen megoldás, még nem jelenti azt, hogy ne lenne létjogosultsága más, akár egyszerűbb és/vagy jobb megoldásnak is.
4) "A neovimet embeddable-nek szánják". Nem annak szánják, hanem annak IS szánják. Önálló editornak IS szánják. Éppen ez utóbbi miatt kell bele a terminál támogatás, hogy lehessen önállóan szerkeszteni vele. Ha meg már ez benne van, akkor egy kis lépés, hogy az emulátor is bele kerüljön.

> 1) Miből látszik, hogy lassú
Kipróbáltam. SLuggish, laggish, nonresponsive. Ennyi. Ez mondjuk két-három hónapja volt, lehet azóta van változás.

> "Nincs benne gui editor": gvim, MacVim
- Egyrészt gui editor alatt visual studios - qt creatoros - etc. tehát IDE-kre jellemző platformot értettem, amikkel lehet gui-kat összekattintgatni. Mintegy példaként.
- De ha így is értelmezzük, akkor is, a neovim lib-only, amihez defaultból csak cli UI van. Tehát nincs gvim, etc. Azok mind külső projektek, és ez egy szándékos választás volt

> 4) "A neovimet embeddable-nek szánják". Nem annak szánják, hanem annak IS szánják.
Lásd előző pont. Lib-only, egy referenciaimplementációval. Nincs gvim, macvim, etcvim. nvim lib van, ahhoz van egy cli UI, és a többi már a főprojekten kívüli dolog.

"Lib-only, egy referenciaimplementációval."

Ezt honnan veszed?
Erre sehol sem találok utalást, inkább az ellenkezőjére.
Nem az van, hogy lib + terminálos referencia implementáció, vagy lib + GUI, hanem van egy nvim nevezetű szövegszerkesztő, ami terminálos, és azt el lehet indítani --embed és --headless módban is, amit egy GUI (vagy IDE, vagy bármilyen más program) msgpack-rpc channel-en szólongathat.
Abban igazad van, hogy a GUI függőségek ki vannak gyomlálva az alap (terminálos) szövegszerkesztőből és azokat külön projektben lehet megvalósítani.

Tehát nvim az nem egy lib, hanem egy alkalmazás, ami más alkalmazások felé szerverként tud üzemelni.

> Ezt honnan veszed?
Így emlékszem.

> Abban igazad van, hogy a GUI függőségek ki vannak gyomlálva az alap (terminálos) szövegszerkesztőből
Valószínűleg ezért.

Emlékeim szerint a legfontosabb célkitűzés az volt, hogy maga a neovim egy olyan (nevezzük akkor lib helyett így:) entitás lesz, ami arra biztatja az IDE fejlesztőket stb. hogy a saját szövegmegjelenítő és -szerkesztő widgetük helyett a neovimet használják. A konzolos nvim parancs pedig egy PoC, ami 100% supported, és maintainelt és a jövőben is az lesz. Két okból van így:

1) demonstrálandó hogy a neovimmel ez megvalósíŧható
2) praktikus okok: van egy full-feautored konzolos szövegszerkesztő