21 May 2024 |
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.org 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). Non 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.org (a me ancora rode che configurare Firefox e Thunderbird è quasi impossibile da Nix, e infatti stavo pensando di cambiare mail client...) In bocca al lupo per il client | 20:43:18 |
22 May 2024 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) In realtà c'è ed è vimdoc
Quando fai :help <qualcosa> ti si apre la doc e navigare molto velocemente tutta la doc usando i tag che ci sono all'interno (ovviamente qualcuno la deve scrivere ma non è un problema strettamente legato a NeoVim)
| 06:43:42 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100% | 06:44:42 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) Qui opinione personale, ma se con certi tool devo lavorarci non aggiorno così di frequente o almeno mi tengo uno snapshot precedente per cui posso fare rollback velocemente | 06:52:07 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) *
- Qui opinione personale, ma se con certi tool devo lavorarci non aggiorno così di frequente o almeno mi tengo uno snapshot precedente per cui posso fare rollback velocemente
| 06:52:44 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) *
- Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100%
| 06:52:51 |
c3n21 | *
- Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100%
| 06:52:56 |
c3n21 | In reply to @telegram_63397700:t2bot.io 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) * 1): In realtà c'è ed è vimdoc
Quando fai :help <qualcosa> ti si apre la doc e navigare molto velocemente tutta la doc usando i tag che ci sono all'interno (ovviamente qualcuno la deve scrivere ma non è un problema strettamente legato a NeoVim)
| 06:53:05 |
c3n21 | *
- In realtà c'è ed è vimdoc
Quando fai :help <qualcosa> ti si apre la doc e navigare molto velocemente tutta la doc usando i tag che ci sono all'interno (ovviamente qualcuno la deve scrivere ma non è un problema strettamente legato a NeoVim)
| 06:53:18 |
Simone Ruffini | In reply to @c3n21:matrix.org Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100% Dovrebbe essere piu imperativo farlo, come per i pacchetti latex | 06:55:10 |
c3n21 | *
- Qui opinione personale, ma se con certi tool devo lavorarci non aggiorno così di frequente o almeno mi tengo uno snapshot precedente per cui posso fare rollback velocemente
Per il fatto delle feature nuove con lazy.nvim quando aggiorni i plugin ti mostra il changelog, o se non c'è lo autogenera andando a fare il delta dei commit
| 06:55:23 |
Simone Ruffini | In reply to @c3n21:matrix.org Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100% Si ma capisci che questo non sta ne in cielo ne in terra? | 06:55:28 |
c3n21 | In reply to @telegram_63397700:t2bot.io Dovrebbe essere piu imperativo farlo, come per i pacchetti latex Non ho mai usato Latex se non embeddato in altri linguaggi di markdown per cui non saprei, però io sarei molto d'accordo ad adottare il formato di luarocks | 06:58:59 |
c3n21 | In reply to @telegram_63397700:t2bot.io Si ma capisci che questo non sta ne in cielo ne in terra? Questione di abitudine ad un certo punto
Per il mio caso d'uso io mi trovo anche abbastanza bene, non aggiorno spessissimo e quando lo faccio risolvo più problemi insieme (c'è anche da dire che io uso la nightly per cui si spaccano anche le api built-in)
Avere una G/TUI preposta mi sembra complessità in più, anche perché per settare un'opzione basta una riga di Lua o di VimScript e puoi anche fare hotreloading source-andoti di nuovo il config
| 07:02:40 |
Simone Ruffini | In reply to @c3n21:matrix.org
Questione di abitudine ad un certo punto
Per il mio caso d'uso io mi trovo anche abbastanza bene, non aggiorno spessissimo e quando lo faccio risolvo più problemi insieme (c'è anche da dire che io uso la nightly per cui si spaccano anche le api built-in)
Avere una G/TUI preposta mi sembra complessità in più, anche perché per settare un'opzione basta una riga di Lua o di VimScript e puoi anche fare hotreloading source-andoti di nuovo il config
Non è solo questione di abitudine, è anche questione di tempo e quello è diverso per ognuno | 07:03:32 |
Simone Ruffini | In reply to @c3n21:matrix.org Non ho mai usato Latex se non embeddato in altri linguaggi di markdown per cui non saprei, però io sarei molto d'accordo ad adottare il formato di luarocks Sembra interessante, pero deve veramente diventare lo std, altrimenti è un wrapper I piu che le persone si devono imparare, tipo nix | 07:02:53 |
c3n21 | In reply to @telegram_63397700:t2bot.io Non è solo questione di abitudine, è anche questione di tempo e quello è diverso per ognuno Dico che è questione di "abitudine" perché io ormai ho abbandonato l'idea di voler avere sempre l'ultima versione di tutto e non sento bisogno di feature in più di cui sono riuscito a fare a meno fino ad ora | 07:07:02 |
c3n21 | Poi se per altri questo è un problema vuol dire che NeoVim non è l'editor giusto per loro | 07:07:53 |
c3n21 | In reply to @telegram_63397700:t2bot.io Sembra interessante, pero deve veramente diventare lo std, altrimenti è un wrapper I piu che le persone si devono imparare, tipo nix Con rocks.nvim (ennesimo plugin manager per NeoVim) si cerca di promuovere plugin come pacchetti luarocks o in alternativa installarlo tramite git come si tende a fare adesso | 07:09:37 |
c3n21 | Non c'è una vera propria sintassi, lanci un comando e lui ti installa la roba ed aggiorna il config.toml | 07:10:01 |
Alessandro Candido | In ogni caso, in qualunque modo la metti, se tieni la tua configurazione di Neovim sotto un flake il rollback e' istantaneo... | 14:40:01 |
Alessandro Candido | Inoltre, tanti plugin (se non tutti) sono progetti amatoriali. Io mi scrivo la mia cosa che va bene per me, e se voglio aggiungermi una configurazione me la aggiungo.
Se poi qualcuno vuole usarla, liberi tutti, una volta che e' open, ma i maintainer non beccano un centesimo per il lavoro... | 14:41:13 |
Alessandro Candido |
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
MIT License
Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
Apache 2.0
For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software.
GPL v3
| 14:43:41 |
Alessandro Candido | https://xkcd.com/2347/ | 14:44:04 |
Alessandro Candido | Per cui, se i plugin non sono production level la migliore strategia e' farne a meno, oppure assicurarsi rollback facili. | 14:44:54 |
Alessandro Candido | (poi per le dependency in termini di pacchetti Lua sono d'accordo con luarocks e c3n21, ci sono sicuramente modi migliori, ma credo che in realta' la maggior parte dei plugin dipenda solamente dall'API di neovim - queste dipendenze fra plugin sono un po' una cosa nuova, almeno su ampia scala) | 14:46:38 |
Alessandro Candido | In reply to @aciceri:nixos.dev Vero che venite sabato 1 Giugno a continuare questi discorsi di persona? Btw, mi piacerebbe un sacco esserci, ma sono continuamente in viaggio D: | 14:47:38 |
c3n21 | In reply to @annib-ale:matrix.org (poi per le dependency in termini di pacchetti Lua sono d'accordo con luarocks e c3n21, ci sono sicuramente modi migliori, ma credo che in realta' la maggior parte dei plugin dipenda solamente dall'API di neovim - queste dipendenze fra plugin sono un po' una cosa nuova, almeno su ampia scala) plenary.nvim mi sembra che sia una dipendenza molto comune che potrebbe verrebbe gestita meglio da un package manager vero a questo punto invece che lasciare l'onere all'utente finale
Poi già il fatto che plenary reimplementa un subset di busted per unit testing per me è già sintomo che forse avere accesso ad un qualcosa di più strutturato gioverebbe più a tutti e faciliterebbe volendo anche lo sviluppo di plugin più completi, anche perché l'alternativa a questo è infilare questi pacchetti extra direttamente nel programma finale come è stato fatto per il serializzatore JSON in Lua se non erro | 14:51:55 |