In reply to @c3n21:matrix.org
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

In reply to @annib-ale:matrix.org
C'e' anche una motivazione per essere contrari o gli stanno antipatici?

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)

In reply to @telegram_63397700:t2bot.io
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

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).

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 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)

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 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 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. 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

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. Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100%

1. Questo è vero infatti bisogna affidarsi alla bontà dei contributor per questo... io a volte mi leggo pure il sorgente per essere sicuro al 100%

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)

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)

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%

1. 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

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%

In reply to @telegram_63397700:t2bot.io
Dovrebbe essere piu imperativo farlo, come per i pacchetti latex

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

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

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