Il meccanismo
Cos’è l’API, e cosa deliberatamente non è.
Due porte, nessuna interpolazione nella shell, e un elenco di omissioni scelto perché nulla di raggiungibile da un pannello possa distruggere lavoro non ancora committato.
01Nessuna stringa di un plugin raggiunge la riga di comando di git
Ramo, stato, cronologia, repository remoti e diff vengono letti attraverso argomenti che costruisce l’host. Un plugin non ha dove iniettare un’opzione, ed è per questo che la lettura non chiede alcun permesso.
02La scrittura è protetta due volte, e verificata tardi
Il manifesto dichiara "git": "write"; tu lo concedi in Gestisci plugin. Il consenso è registrato a fronte di un’impronta delle capacità accettate e riletto al momento di ogni chiamata, quindi un aggiornamento che chiede di più deve richiedere, e revocare ferma un plugin già in esecuzione.
03Il messaggio di commit passa dallo standard input
Mai come argomento. Percorsi, riferimenti, nomi e URL di repository remoti vengono rifiutati subito se potessero essere letti come opzioni.
04I pannelli possono ricevere testo
Un nodo campo con un gestore onSubmit è ciò che rende possibile un messaggio di commit in un pannello laterale. Il plugin fornisce il valore iniziale e la vista possiede ciò che viene scritto dopo, così un ridisegno non porta via mezza frase.
05Le conferme distruttive appartengono all’host
Scartare modifiche tracciate e togliere un repository remoto vengono confermati da Linelark stesso, prima della chiamata. Un plugin non può mostrare quella finestra, e un plugin che potesse sarebbe la cosa sbagliata a cui affidarla.
06I diff si aprono come due file, non come una patch
Un plugin consegna un diff unificato e l’editor disegna le due versioni affiancate, allineate, numerate nei propri file, con le righe lunghe mandate a capo. Un plugin che propone fusioni aggiunge frecce al centro.
07Le operazioni lunghe sono asincrone
Fetch, pull, push e i lettori asincroni girano fuori dal thread principale, così un pannello non blocca l’editor mentre la rete è lenta.