 | Nix Milan | 110 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Nix Milan | 110 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 May 2024 | ||
 Jacob | In reply to Alessandro 🤔➖☀️🖌quando ho dovuto mettere sotto nix la mia config di vim ho dato un occhio a quel progetto ma non supportava ancora lazyvim. A quanto pare hanno fatto qualcosa di recente per implementarlo anche se i commenti non destano fiducia https://github.com/nix-community/nixvim/pull/1175. Alla fine sono andato con qualcosa di opionanato fatto da me e diretto senza troppe astrazioni | 10:45:56 |
 Alessandro 🤔➖☀️🖌 | lazyvim è un'altra cosa che ho scoperto di recente, ma non conosco ancora | 10:52:35 |
| Jacob | In reply to Alessandro 🤔➖☀️🖌per evitare fraintendimenti non intendo la distribuzione lazyvim ma il package manager lazy.nvim https://github.com/folke/lazy.nvim | 10:57:19 |
| Jacob | * per evitare fraintendimenti non intendo la distribuzione lazyvim ma il plugin manager lazy.nvim https://github.com/folke/lazy.nvim | 10:58:24 |
 Marco Turchetto | Forse puo esservi utile https://github.com/nvim-neorocks/rocks.nvim | 11:19:35 |
 aciceri invited  c3n21. | 16:10:01 | |
| c3n21 joined the room. | 16:30:38 | |
| c3n21 | In reply to @telegram_41776856:t2bot.ioMolto figo lo sto provando da un mesetto | 19:42:32 |
| c3n21 | Anche se molti plugin li installa scm perché non sono versionati decentemente upstream | 19:42:57 |
 Alessandro Candido | Anche rocks.nvim sembra figo, però mi da un po' di pensiero il fatto che dica di occuparsi lui delle dependency, quando i plugin di Neovim non hanno un manifest di loro (per questo si è inventato `rocks.toml`). Quindi non è solo una scelta lato utente, ma deve essere adottato anche dagli sviluppatori di plugin... | 20:44:25 |
| Alessandro Candido | Alla fine rischia di non essere troppo diverso da lazy, a meno che non decolli davvero | 20:45:03 |
| 19 May 2024 | ||
| c3n21 | In reply to @annib-ale:matrix.orgSupporta l'installazione "classica" clonando da git per cui non cambia niente ed il fatto di pacchettizzare i plugin lo stanno facendo mano a mano gli autori di rocks | 05:56:22 |
| Alessandro Candido | Ci sta, un lavorone. Però dovranno anche mantenerli aggiornati, per cui avranno bisogno di manpower (che ci sarà, se prende piede e ognuno si fa il suo) | 06:56:47 |
| c3n21 | In reply to @annib-ale:matrix.orgSì è un lavoraccio, però ho visto che hanno una pipeline che mantiene le versioni taggate aggiornate, idem i parser di treesitter | 09:51:15 |
| c3n21 | Il problema principale è che folke sembra abbastanza contro l'uso dei rocks, e lazy.nvim mi sembra diventato abbastanza lo standard de facto per la gestione dei plugin | 09:52:08 |
| 21 May 2024 | ||
| Alessandro Candido | In reply to @c3n21:matrix.orgC'e' anche una motivazione per essere contrari o gli stanno antipatici? | 14:04:50 |
| Marco Turchetto | pare che il ceo di nvim sia abbastanza contento del lavoro di rocks.nvim https://github.com/nvim-neorocks/nvim-best-practices/issues/5 | 14:29:33 |
| c3n21 | In reply to @annib-ale:matrix.org https://github.com/folke/lazy.nvim/issues/253 Diciamo che l'argomentazione di folke è un po' un cane che si morde la coda... se i plugin fossero pacchetizzati come pacchetti per luarocks sarebbe molto semplice gestire le dipendenze ed avremmo anche una libreria sterminata Invece spulciando tra vari plugin che ho usato ed usato spesso c'erano copy & paste di codice, in primis di wrapper per avere una sorta di API per l'asincronia usando le coroutine (l'avevo vista su packer) | 14:37:27 |
| c3n21 | Personalmente io non riesco a pensare ad un solo motivo per cui non si dovrebbe usare luarocks per gestire i plugin Lua | 14:40:56 |
| aciceri | Vero che venite sabato 1 Giugno a continuare questi discorsi di persona? | 16:31:40 |
| c3n21 | Troppa ansia sociale per quello | 17:47:06 |
 Simone Ruffini | Mio take: per me il problema maggiore a livello di ux di neovim (e di molti programmi userspace ad alto livello es: alacritty) è la gestione delle opzioni/configurazioni. 1) non c'è uno standard per documentare i plugin 2) non c'è un modo per vedere tutte le opzioni/parametri di configurazione contemporaneamente se non andare su GH e trovare il giusto sito/link ( vscode all contrario riesce a ovviare a questo quando schiacci ctrl+. E ti mostra tutte le opzioni disponibili) 3) quando si aggiornano i plugin succede sempre un bordello, la roba si rompe spesso e le nuove feature non le puoi vedere di colpo a meno che non ti guardi le release note (vscode sempre risolve con ctrl+.) Questo problema lo noto spesso con alacritty dove ogni release aggiunge qualcosa di nuovo, ma se ad ogni singolo aggiornamento non ti guardi il file di configurazione standard rilasciato in /etc e ti copi dentro le feature nuove (va fatta sempre una diff) poi ti perdi queste opzioni. A lievello di configurazione, secondo me tutti i programmi che hanno G/TUI dovrebbero avere internamente un modo per abilitare disabilitare le opzioni (tra cui installare i plugin) e poi per il fine-tuning da file (come su vscode) | 20:21:12 |
| Simone Ruffini | La configurazione text based only va bene per git o che ne so ssh, per il resto servirebbe qualcosa di piu serio a livello usabilita utente | 20:24:50 |
| Simone Ruffini | * Mio take: per me il problema maggiore a livello di ux di neovim (e di molti programmi userspace ad alto livello es: alacritty) è la gestione delle opzioni/configurazioni. 1) non c'è uno standard per documentare i plugin 2) non c'è un modo per vedere tutte le opzioni/parametri di configurazione contemporaneamente se non andare su GH e trovare il giusto sito/link ( vscode all contrario riesce a ovviare a questo quando schiacci ctrl+. E ti mostra tutte le opzioni disponibili) 3) quando si aggiornano i plugin succede sempre un bordello, la roba si rompe spesso e le nuove feature non le puoi vedere di colpo a meno che non ti guardi le release note (vscode sempre risolve con ctrl+.) Questo problema lo noto spesso con alacritty dove ogni release aggiunge qualcosa di nuovo, ma se ad ogni singolo aggiornamento non ti guardi il file di configurazione standard rilasciato in /etc e poi non ti copi nel tuo config le feature nuove (va fatta sempre una diff)alla fine ti perdi queste opzioni/feature. A lievello di configurazione, secondo me tutti i programmi che hanno G/TUI dovrebbero avere internamente un modo per abilitare disabilitare le opzioni (tra cui installare i plugin) e poi per il fine-tuning da file (come su vscode) | 20:23:33 |
| Alessandro Candido | Per me questa non suona tanto una feature di VS code vs Neovim, quanto dei plugin di uno e dell'altro. E se confronti il numero di utenti (e le aziende che supportano lo sviluppo) è incredibile che Vim/Neovim/Emacs siano anche confrontabili. Scrivere plugin prende tempo, fare dei buoni changelog prende tempo. Versioni e dipendenze richiedono organizzazione (in JS quelle ci sono da Node, ma non per questo sono più affidabili). | 20:38:45 |
| Alessandro Candido | In reply to @telegram_63397700:t2bot.ioBtw, usando Nix e cercando di rendere la configurazione il più dichiarativa possibile, file based è decisamente più riproducibile e interfacciabile :) | 20:40:18 |
| Alessandro Candido | (a me ancora rode che configurare Firefox e Thunderbird è quasi impossibile da Nix, e infatti stavo pensando di cambiare mail client...) | 20:41:22 |
| Simone Ruffini | Penso che il più usabile e semplice sia geary, ma se non hai gnome è tosta | 20:44:30 |
| Simone Ruffini | In reply to @annib-ale:matrix.orgNon volevo metterla nel modo: è una feature di vscode, ma solo che il modo con cui vedi le opzioni e configurazioni è decisamente più intuitivo e ti fa perdere meno tempo, l'ultimo aggiornamento di plugin che ho fatto mi ha rotto un botto di roba, e il tempo per sistemare lo ho solo il weekend | 20:42:58 |
| Simone Ruffini | In reply to @annib-ale:matrix.orgIn bocca al lupo per il client | 20:43:18 |