Din moment ce tocmai am scris cea mai mare parte a funcționalității pentru acest lucru, m-am gândit că aș putea să scriu un alt plugin și să fac un colorator Luajit. Nu sunt necesare dependențe, opțiuni de configurare ușoare și performanțe bune.

neovim

E: De asemenea, odată cu acest lucru, următoarele pluginuri/biblioteci la care voi lucra sunt o interfață de meniu pop-up pentru interfață cu lucruri precum fzf și apoi un client de protocol de server de limbă.

Sincer, pe baza testelor mele, cred că ar putea fi cel mai rapid colorant disponibil.

Știu că există moduri pe care nu le implementează precum cele pe care hexokinaza le-a implementat în mod creativ, dar cred că prim-planul și fundalul (după ce am folosit celelalte moduri) sunt cele mai comune și cele mai utile.

Dacă cineva are sugestii despre ce să mai adăugăm, anunțați-mă.

Da, este foarte rapid, nu m-am înăbușit la deschiderea fișierului CSS de 36K LOC Tailwind generat spre deosebire de alte pluginuri de colorare. Totuși, trebuie să fie setate termguicolors, ceea ce îmi modifică schema de culori, deoarece folosesc 256 de culori cu termguicolors dezactivate.

Excelent de auzit! Spune-le prietenilor tăi despre asta. Nu m-am gândit să-l numesc „cel mai rapid colorant modern”, deoarece sunt prost în marketing.

Am scris-o având în vedere performanța. Cred că ar fi foarte greu să-l învingi cu un plugin care nu se află în Lua, din cauza costurilor RPC. Chiar și în continuare, am scris-o folosind FFI pentru ca un trie să analizeze codurile de nume și am încercat câteva repere pentru celelalte părți. Funcționează chiar bine pe linii lungi.

Dacă doriți să vedeți un test de stres real, faceți .luado returnează vim.inspect (vim.api.nvim_get_color_map ()): gsub ("\ n", "). Linie masivă de culori unice, dar o face instantaneu.

Da, are nevoie de termguicolori. Nu se activează altfel. Aș putea face ceva pentru 256 de culori prin interpolare și căutarea unui vecin cel mai apropiat, dar nu va fi exact, ceea ce diminuează valoarea.

Aș putea doar să evidențiez culorile disponibile în 256, totuși, dacă asta credeți că este util. Asta nu ar fi prea greu, deoarece am funcțiile deja scrise în modulul meu terminal.vim.

Am folosit un colorant coc și uneori mi-a înghețat nvim pe ft = help buffers.

Are nevoie de nvim> = 0,4 pentru api bibliotecă standard lua?

Tocmai am încercat-o la mașina mea de lucru Ubuntu care folosește nvim 0.38 și a eșuat.

Am uitat să pun asta în README, dar da necesită nvim> = 0,4.

Am încercat să-mi dau seama o modalitate de a-l avea la 0.3.8, dar există câteva lucruri care ar fi limitative. Aș putea face să funcționeze, poate, dacă dezactivez selectiv câteva caracteristici.

Care a fost eroarea dvs. specifică?

Ne pare rău, nu mai sunt la serviciu;). Vă pot spune doar luni, dar ar trebui să poată fi reprodus cu ușurință într-un vm sau container Ubuntu.

Problema este că pachetul oficial neovim este înghețat deoarece întreținătorul susține că trebuie să așteptăm atât Debian, cât și Ubuntu pentru a împacheta versiuni mai noi ale dependențelor necesare. Ce prostie. De asemenea, vreau să folosesc ferestre plutitoare.

Ah, mă întrebam de ce PPA a fost atât de mult în urmă. Folosesc și Arch pentru orice, haha. Neovim 0.4 este cu siguranță mai distractiv decât 0.3. Am câteva pluginuri pe care le dezvolt, care vor viza 0.4+. Vor avea nevoie de vim.loop în principal.

Sunt foarte mulțumit de performanțele colorantului (de fapt a depășit așteptările mele) și sunt destul de sigur că pot face cel mai bun/cel mai rapid completator pentru neovim. Următorul slot gratuit pe care îl am, voi termina un client LSP, iar apoi va fi doar un pic de lucru cu UI înainte de a fi funcțional. Chiar nu anticipez că va dura atât de mult înainte de v0.1. De obicei, aștept până când ceva este foarte șlefuit înainte de a publica, dar cred că de data aceasta îl voi lansa „cu acces timpuriu” și îl voi dezvolta în public. (E2: Lol nvm, clientul LSP din neovim este mai departe decât mă așteptam https://github.com/neovim/neovim/pull/10222).

E: Am uitat de ce am început acea dezvăluire. Ar trebui să puneți mâna pe 0.4 la locul de muncă, astfel încât să puteți juca cu noi, a fost punctul meu, haha.

Sunt destul de sigur că pot face cel mai bun/cel mai rapid completator pentru neovim. Următorul slot gratuit pe care îl am, voi termina un client LSP și apoi va fi doar un pic de funcționare a interfeței înainte de a fi funcțional.

De fapt, este minunat, aștept cu nerăbdare să vă verific lucrările viitoare.

Eu personal folosesc coc ca motor de finalizare/client lsp, dar simt că o alternativă mai minimalistă și mai performantă este încă de venit.

Nu ai putea folosi versiunea appimage? Cel puțin până când ppa este actualizat

Nu am încercat niciodată appimages, prefer întotdeauna să folosesc pachete native pentru orice, dacă este posibil.

Singura mea experiență cu pachetele asemănătoare containerelor este cu snap-ul și am urât-o, ceea ce mă face puțin cam precaut să folosesc appimage. În acest moment, prefer să-l construiesc singur.

Ar putea fi modificat acest lucru pentru a adăuga suport pentru variabilele SASS? Am avut tendința de a crea variabile/nume pentru fiecare culoare pe care o folosesc, ceea ce consider că ajută la reducerea numărului de culori similare.

. ar fi uimitor dacă fiecare instanță din $ color_boulder ar fi evidențiată și ea!

Bine am reușit: P

Utilizarea va fi în două părți:

Atașarea la un buffer pentru a declanșa actualizarea dicționarului.

autocmd FileType scss lua require'colorizer/sass'.attach_to_buffer ()

Numai tampoanele care au fost atașate vor fi luate în considerare pentru definițiile variabilelor.

Uau, a fost rapid!

Puteți explica mai multe despre fișierul de configurare? Am adăugat acest lucru la .vimrc .

Puneți-l după declarația plug end # end () în loc să utilizați do .

Iată un exemplu potențial:

Mulțumim pentru exemplu! L-am modificat pentru a utiliza „sass-variable-matcher” așa cum ați sugerat în GitHub și am adăugat „set termguicolors” și funcționează!

Nu exact în forma sa actuală, dar cu o mică modificare a funcției highlight_buffer (.), Aș putea crea o bibliotecă însoțitoare care ar putea efectiv face asta. Dacă adaug un parametru pentru a selecta_buffer pentru a accepta o funcție de potrivire personalizată, care este orice funcție a formei fn (linie, i) -> match_length, rgb_hex, atunci o puteți folosi cu o funcție care analizează fișierul curent pentru declarații variabile și îl adaugă într-un dicționar global care conține acele definiții variabile și în funcție de valorile culorilor.

Cea mai grea parte ar fi crearea unui analizor care reacționează corect la potrivirile incrementale, deoarece spunem că modificați o linie precum $ color_bl: # 00 și continuați să tastați negru, s-ar potrivi parțiale pentru acea linie într-un algoritm naiv care ar adăuga falsuri pozitive. Deci, o abordare naivă ar fi să reparați întregul fișier pentru declarații la fiecare modificare de linie, sau puteți utiliza un algoritm mai incremental, dar ar fi mai complex (ceva de-a lungul liniilor de urmărire în ce linie se află declarația).

Dacă nu vă deranjează o potențială penalizare de performanță pentru repararea fișierului sau puneți un fel de respingere asupra acestuia pentru a minimiza acea penalizare, atunci aș putea să o văd funcționând. Dacă fișierul dvs. este mai mic de 100K, cred că nu ar fi vizibil cu o abordare naivă, tbh.

E: Voi încerca să fac o bibliotecă experimentală pentru asta pe care o puteți încerca:) Utilizarea ar fi ceva de genul autocmd scss lua require'colorizer/sass'.attach_to_buffer () .

Modul în care mă gândesc să pun în aplicare acest lucru, ar funcționa fie pe un buffer pe nivel de buffer, fie pe un nivel global, ceea ce înseamnă că poate evidenția variabilele detectate în buffer-ul curent și numai buffer-ul curent, sau va evidenția toate a variabilelor din toate bufferele, chiar dacă există conflicte.

Acest lucru s-ar putea schimba în cele din urmă, odată ce un analizor mai bun este disponibil pentru scss de la treeitter, dar nu sunt dispus să pun atât de mult timp în acest moment.