Guida tematica alla riga di comando.

Ciao Roberto, grazie mille per la guida.

L’uso del terminale, per LaTeX (e non solo), semplifica e migliora tante cose. Davvero utile, per i principianti (che fanno fatica a capire certe cose) ma anche per l’utente medio di LaTeX.

Appena posso ti scrivo qualche mia impressione.

Grazie
Orlando

Guida tematica alla riga di comando, R.G.Il $ riportato negli esempi come primo carattere, simboleggia la riga di comando ed è
chiamato prompt. Ha il compito di separare informazioni utili dai comandi utente.

Andrebbe specificato che è tipico dei sistemi Unix. L’analogo di Windows dovrebbe essere il >; attendo conferme.

Guida tematica alla riga di comando, R.G.In Windows esiste una modalità esotica di avvio della shell che consiste nell’aprire il
dialogo Esegui… dal menù Start e digitare il comando cmd prima di confermare su OK
o con il tasto (Invio).

Su Windows 7 (non ho verificato su Xp) si apre anche semplicemente premendo il tasto Win e digitando cmd (infine Invio). Si può anche aprire nella cartalla di lavoro con “SHIFT” + “tasto destro del mouse” > “Apri finestra di comando qui”. Questo però vale solo per Windows 7.

Guida tematica alla riga di comando, R.G.Conoscere il modo di rinominare un file con la riga di comando può essere utile specie se
vi trovate ad utilizzare Windows che solitamente è impostato per nascondere la estensioni
dei file, rendendo impossibile cambiarla in modalità grafica.

Non è proprio impossibile, si deve fare qualche operazione (anche semplice, direi).

Aggiungo: a pagina 9 si fa l’esempio sulla “redirezione” ([tt]$ echo ’export PATH=/usr/local/texlive/2011/bin/i386-linux:${PATH}’ >> ~.profile[/tt]) ma non si dice cos’è. Secondo me è utile. Tanto per fare un esempio: [tt]pdffonts main.pdf > fontusati.txt[/tt]

Per ora è tutto. 🙂

Ciao
Orlando

ansys” post=73777

Il $ riportato negli esempi come primo carattere, simboleggia la riga di comando ed è
chiamato prompt. Ha il compito di separare informazioni utili dai comandi utente.

Andrebbe specificato che è tipico dei sistemi Unix.

Tecnicamente non è vero, dipende dalla shell: qui ci sono alcuni esempi di prompt per differenti shell, come vedete non tutti usano [tt]$[/tt]. D’altra parte il dollaro è il prompt predefinito della bash e della sh, probabilmente chi usa altre shell sa anche cos’è un prompt e lo sa riconoscere all’interno di una guida 😉

Passiamo alle osservazioni mie. Intanto grazie per la guida, gran bella idea 😀

A pagina 5 provi brevemente a spiegare come funzionano le opzioni dei comandi: è un compito decisamente non facile visto che non c’è un regolamento rigido (diciamo pure che non c’è proprio, esistono solo delle convenzioni più o meno diffuse) e mi sa che incappi in delle imprecisioni

Se per esempio si vuol conoscere la versione di un programma quasi
sempre è sufficiente eseguirlo con l’opzione -version, e pdftex, il principale programma di
composizione del sistema TEX, non fa eccezione

Sinceramente conosco solo [tt]pdftex[/tt] che segue questa sintassi. I programmi del progetto GNU usano [tt]–version[/tt] ([tt]-v[/tt] per la forma breve) e comunque è generalmente accettato (ma non obbligatorio) usare un solo trattino per le forme brevi delle opzioni, due trattini per le forme estese, anche perché molte funzioni di parsing delle opzioni si aspettano questo comportamento. A questo proposito c’è scritto qualcosa nel paragrafo Standards for Command Line Interfaces del GNU Coding Standards. Lo stesso discorso fatto per [tt]-version[/tt] vale per [tt]-help[/tt], la forma più diffusa è [tt]–help[/tt] ([tt]-h[/tt] per la forma breve).

Problema Windows (sempre problemi dà…): mi pare che le opzioni si indichino con lo slash, ma non ci giurerei e non ho nessuna intenzione di avviare Windows per verificarlo.

Pagina 7:

il carattere tilde r ̃appresenta

Forse non si capisce molto bene qui, c’è la tilde sopra la r, forse ti sei dimenticato di mettere le parentesi [tt]{}[/tt] dopo il comando [tt]\tilde[/tt], ma penso che potresti anche usare [tt]\verb[/tt] o [tt]\texttt[/tt] in quel punto.

Sarebbe interessante spiegare la differenza fra percorso relativo e assoluto, non so per quale motivo tanta gente ha difficoltà a comprendere questo argomento. Per esempio, per quanto riguarda l’esecuzione dei programmi, sui sistemi Unix bisogna specificare il percorso (non necessariamente “completo” come dici tu, interpretandolo come percorso assoluto), relativo o assoluto, vanno ugualmente bene, e questo spiega perché per eseguire programmi presenti nella cartella corrente che non sia una directory di PATH è necessario anteporre [tt]./[/tt] che non è un insieme di simboli magici ma il percorso relativo della cartella corrente.

A pagina 9 spieghi come esportare il valore di una variabile: quella sintassi è vera per la bash e non so quali altre shell, ma sicuramente non tutte lavorano così, per esempio la csh/tcsh richiedono il comando [tt]setenv[/tt]. Forse sarebbe il caso di specificare all’inizio che la guida è orientata alla bash, che comunque è la shell predefinita sulla stragrande maggioranza delle distro GNU/Linux e mi pare anche su Mac Os X.

Pagina 11: non avevo mai sentito parlare del comando [tt]rename[/tt] per rinominare i file su GNU/Linux 😮 Perché non suggerisci [tt]mv[/tt] sui sistemi Unix, visto che ne parli anche dopo? 😉 Solo Windows può avere due comandi diversi per rinominare e spostare un file (non lo sapevo), sono esattamente la stessa operazione logica…

Per il momento penso che basti 😀

Edit: non è vero, mi son dimenticato di segnalare che i link a bitbucket sono errati, manca l’http 😉

Elrond” post=73812Problema Windows (sempre problemi dà…): mi pare che le opzioni si indichino con lo slash, ma non ci giurerei e non ho nessuna intenzione di avviare Windows per verificarlo.

No, le opzioni si indicano al solito modo con [tt]-[/tt] o [tt]–[/tt].

Ciao
Orlando

ansys” post=73814

Problema Windows (sempre problemi dà…): mi pare che le opzioni si indichino con lo slash, ma non ci giurerei e non ho nessuna intenzione di avviare Windows per verificarlo.

No, le opzioni si indicano al solito modo con [tt]-[/tt] o [tt]–[/tt].

Ciao
Orlando

Ok, grazie. Ricordavo che chkdsk vuole le opzioni con gli slash, pensavo quindi che tutti i comandi fossero così

robitex” post=73816Uhm, per ora volevo dire qualcosa solo per la questione mv:
per l’utente il nome del comando dovrebbe ricordare a cosa serve. mv lo identifico per ‘muovere’ file e non per rinominarli.
Mi rendo conto solo ora però, che non tutti i sitemi unix like dispongono di rename.

Però la ridenominazione di un file e lo spostamento in un’altra cartella sono esattamente la stessa operazione: una volta cambi il basename, l’altra il pathname (ed eventualmente il basename), ma in generale se ne cambia sempre il percorso (assoluto). Non ha davvero senso usare due comandi diversi con sintassi completamente diverse per fare la stessa cosa 🙂

robitex” post=73773In futuro, credo che lo sviluppo delle guide tematiche debba essere comunitario. Sto pensando ad una sorta di repository comune dei sorgenti con accesso indipendente per chi ne faccia richiesta… … …

Mi ero tuffato nella lettura della guida saltando questa tua proposta: inutile dire che mi trovi completamente d’accordo 😉

Un consiglio:
`git rm *.aux *.log *.out *.synctex.gz *.toc`
Personalmente cancellerei anche il documento PDF: in un repository andrebbe solo il sorgente, non i binari (o qualsiasi altro file) prodotto a partire dal sorgente già presente. Motivo: se creo un fork il repository e se per qualche motivo con la mia infrastruttura LaTeX produco un PDF diverso (per esempio a causa di versioni differenti dei pacchetti), potrei accidentalmente fare un commit in cui è cambiato solo il PDF senza toccare il sorgente, cioè sarebbe un commit “a vuoto”. Con i software è ancora più semplice incappare in problemi simili, basta lavorare su architetture diverse, il file binario verrebbe continuamente modificato da ogni utente che ha accesso al repository.

Comunque grazie, volevo proprio dare un’occhiata al sorgente di questa guida, mi serve una cosa in particolare, dopo che nei giorni scorsi sono riuscito a vedere finalmente la classe guidatematica 😀

robitex” post=80599

Un consiglio:
`git rm *.aux *.log *.out *.synctex.gz *.toc`
Personalmente cancellerei anche il documento PDF: in un repository andrebbe solo il sorgente, non i binari (o qualsiasi altro file) prodotto a partire dal sorgente già presente. Motivo: se creo un fork il repository e se per qualche motivo con la mia infrastruttura LaTeX produco un PDF diverso (per esempio a causa di versioni differenti dei pacchetti), potrei accidentalmente fare un commit in cui è cambiato solo il PDF senza toccare il sorgente, cioè sarebbe un commit “a vuoto”. Con i software è ancora più semplice incappare in problemi simili, basta lavorare su architetture diverse, il file binario verrebbe continuamente modificato da ogni utente che ha accesso al repository.

Comunque grazie, volevo proprio dare un’occhiata al sorgente di questa guida, mi serve una cosa in particolare, dopo che nei giorni scorsi sono riuscito a vedere finalmente la classe guidatematica 😀

Grazie per i consigli.
Mi chiedevo giusto gusto come regolarmi sugli aspetti che hai segnalato.
Grazie per il comando git (servirà una piccola guida per aiutare gli utenti con questo progetto… 🙂 ).
In realtà i file ausiliari mi sono “scappati” nel repo mentre il pdf è giustamente inutile anzi dannoso comprenderlo.
Grazie.
R.

Sono assolutamente d’accordo sulla necessità di una guida a git: fornirebbe una base importante sia per collaborare ai progetti esistenti sia per eventualmente pubblicare i sorgenti delle guide tematiche.

Ciao
Claudio

robitex” post=80606

Sono assolutamente d’accordo sulla necessità di una guida a git: fornirebbe una base importante sia per collaborare ai progetti esistenti sia per eventualmente pubblicare i sorgenti delle guide tematiche.

Ciao
Claudio

Esiste già una guida (penso fatta da Elrond) ma da quello che ricordo andrebbe ampliata al dopo, ovvero a quelle fase di fork, merge, ecc che dovrebbe essere il pane dei contributori. La guida la vedo troppo poco sintetica. Andrebbe anche fatto un lavoro di sintesi, tipico di una fase successiva a quando gli autori hanno già molta esperienza.

Direi che una “guida tematica a git” sarebbe ideale.
R.

https://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex è un fork di un progetto dell’utente dianoia di questo forum, però il suo repo è fermo da due anni, il mio è un po’ più aggiornato, ho aggiunto diverse cose in più. Però è vero, mancano diverse informazioni sullo sviluppo realmente collaborativo, perché personalmente finora ho usato Git quasi solo per gestire miei progetti personali.

Se non erro la licenza è una Creative Commons, quindi chiunque voglia contribuire è il benvenuto 😀

Elrond” post=80608

[quote=”cfiandra” post=80605]
Sono assolutamente d’accordo sulla necessità di una guida a git: fornirebbe una base importante sia per collaborare ai progetti esistenti sia per eventualmente pubblicare i sorgenti delle guide tematiche.

Ciao
Claudio

Esiste già una guida (penso fatta da Elrond) ma da quello che ricordo andrebbe ampliata al dopo, ovvero a quelle fase di fork, merge, ecc che dovrebbe essere il pane dei contributori. La guida la vedo troppo poco sintetica. Andrebbe anche fatto un lavoro di sintesi, tipico di una fase successiva a quando gli autori hanno già molta esperienza.

Direi che una “guida tematica a git” sarebbe ideale.
R.

https://gitorious.org/~elrondgit/git4latex/elrondgits-git4latex è un fork di un progetto dell’utente dianoia di questo forum, però il suo repo è fermo da due anni, il mio è un po’ più aggiornato, ho aggiunto diverse cose in più. Però è vero, mancano diverse informazioni sullo sviluppo realmente collaborativo, perché personalmente finora ho usato Git quasi solo per gestire miei progetti personali.

Se non erro la licenza è una Creative Commons, quindi chiunque voglia contribuire è il benvenuto :D[/quote]

Grazie mille per il link: è una guida interessante! Anche io però, cercavo qualche informazione in più per quanto riguarda lo sviluppo collaborativo.. delle dritte per non causare disastri irreparabili/semi-irreparabili più che altro perché la mia attuale conoscenza di git consiste solo nel creare e mandare aggiornamenti per i miei repo.

Ciao
Claudio

Il workflow di un progetto collaborativo in genere è questo: un “capo” ha accesso al repository “ufficiale”, tutti gli altri utenti creano fork, fanno le modifiche sul proprio fork e poi chiedono il merge nel repository “ufficiale”. In pratica tutti glu utenti hanno accesso in scrittura solo al proprio repository. È (più o meno) necessario una gestione del genere perché se tutti avessero accesso in scrittura contemporanea a un unico repository si potrebbero facilmente creare conflitti di cui ognuno dovrebbe occuparsi, in questo modo se ne occupa solo il responsabile del repository principale 😛

Elrond” post=80625Il workflow di un progetto collaborativo in genere è questo: un “capo” ha accesso al repository “ufficiale”, tutti gli altri utenti creano fork, fanno le modifiche sul proprio fork e poi chiedono il merge nel repository “ufficiale”. In pratica tutti glu utenti hanno accesso in scrittura solo al proprio repository. È (più o meno) necessario una gestione del genere perché se tutti avessero accesso in scrittura contemporanea a un unico repository si potrebbero facilmente creare conflitti di cui ognuno dovrebbe occuparsi, in questo modo se ne occupa solo il responsabile del repository principale 😛

Questo può avvenire per repository personali (ai quali in genere l’unico ad avere accesso in scrittura è chi li crea) o progetti molto grandi (per questioni di controllo e integrazione dei diversi commit). Ma se sul progetto lavora un team abbastanza compatto, allora tutti i membri hanno accesso allo stesso repository in scrittura. Peraltro, se il repo è open source (nel senso che tutti lo possono leggere), allora chiunque può contribuire in maniera meno diretta al progetto con qualche forma di pull request.

Alcuni che si avvicinano a Git temono i conflitti a priori, ma nei progetti comuni solitamente i conflitti sono abbastanza rari. Una delle caratteristiche più importanti di Git è che è un Distributed VCS: non esiste alcun server, soprattutto non esiste alcun meccanismo di lock (che ha invece SVN). Il lock può essere utile per file binari che vengono modificati spesso, per i quali non si può fare alcun merge. Ma quando si scrive un documento LaTeX si lavora quasi esclusivamente su file di testo (tex, sty, cls, dtx, eccetera: le eventuali immagini sono aggiunte all’inizio e quasi mai modificate) e allora spesso i conflitti possono essere risolti in maniera quasi automatica. Comunque sia, tocca proprio a ciascuno sviluppatore risolvere i conflitti, in locale.

Non va mai dimenticato quel “distributed”… 😉

Comunque l’accoppiata Git+LaTeX è fenomenale e son d’accordo che una guida tematica a Git sarebbe molto utile. Tempo permettendo, mi piacerebbe anche contribuire. 🙂

robitex” post=80650E come se la cava git sotto Windows?
Vi sono dei programmi ad interfaccia grafica?
R.

http://msysgit.github.com/
Oppure un client specifico per Github (che include msygit): http://windows.github.com/ e c’è anche l’analogo per Mac: http://mac.github.com/ Non hanno fatto un client per GNU/Linux, ma dubito che molta gente ne senta la mancanza (comunque per GNU/Linux c’è l’interfaccia predefinita di Git: Gitk). Gli IDE sono spesso integrati con sistemi per il controllo delle revisioni rendendo più o meno inutili questi software, ma non so quale sia la situazione degli editor di testo per LaTeX (a parte Emacs che integra Git e altri sistemi per default).

@antonio.macrì: come ho detto, ho poca esperienza personale per quanto riguarda progetti collaborativi, mi affido a quello che dici tu 🙂 In effetti quello che ho descritto è quello che avviene normalmente per grossi progetti, come il kernel Linux in cui tutti clonano il repository di Linus

Elrond” post=80656

E come se la cava git sotto Windows?
Vi sono dei programmi ad interfaccia grafica?
R.

http://msysgit.github.com/
Oppure un client specifico per Github (che include msygit): http://windows.github.com/ e c’è anche l’analogo per Mac: http://mac.github.com/ Non hanno fatto un client per GNU/Linux, ma dubito che molta gente ne senta la mancanza (comunque per GNU/Linux c’è l’interfaccia predefinita di Git: Gitk). Gli IDE sono spesso integrati con sistemi per il controllo delle revisioni rendendo più o meno inutili questi software, ma non so quale sia la situazione degli editor di testo per LaTeX (a parte Emacs che integra Git e altri sistemi per default).

Oppure http://git-scm.com/ c’è il link diretto all’ultima versione stabile. Personalmente ho installato CygWin (che uso un po’ per tutto, gnuplot, octave, bash, make, e così via) che mette anche git a disposizione. Però uso solo quello da terminale.

Ciao
Orlando

Perdonate la mia domanda che forse era banale: ero e sono convinto che con un giusto approccio il numero delle collisioni può essere evitato/controllato.. e chiaramente chi ha già partecipato a progetti collaborativi conoscerà una “lista” di cose da evitare. 🙂

Ciao
Claudio

ansys” post=80666

[quote=”robitex” post=80650]E come se la cava git sotto Windows?
Vi sono dei programmi ad interfaccia grafica?
R.

http://msysgit.github.com/
Oppure un client specifico per Github (che include msygit): http://windows.github.com/ e c’è anche l’analogo per Mac: http://mac.github.com/ Non hanno fatto un client per GNU/Linux, ma dubito che molta gente ne senta la mancanza (comunque per GNU/Linux c’è l’interfaccia predefinita di Git: Gitk). Gli IDE sono spesso integrati con sistemi per il controllo delle revisioni rendendo più o meno inutili questi software, ma non so quale sia la situazione degli editor di testo per LaTeX (a parte Emacs che integra Git e altri sistemi per default).

Oppure http://git-scm.com/ c’è il link diretto all’ultima versione stabile. Personalmente ho installato CygWin (che uso un po’ per tutto, gnuplot, octave, bash, make, e così via) che mette anche git a disposizione. Però uso solo quello da terminale.

Ciao
Orlando[/quote]
Con CygWin c’è anche gitk e git-gui. L’ho appena scoperto 🙂

@roberto: mi sembra che siamo andati un po’ OT.

Salve.

Non so nulla di make, prima di leggere la guida desidero chiedere: nel lavoro con TeX/LaTeX quale vantaggio si ha nell’usare un makefile invece di un normale file di comandi batch/bash?

Ciao.

@robitex: quale editor di testo utilizzi? TeXworks? È possibile in questo editor limitare automaticamente il numero di caratteri per riga a un certo numero fissato? Un conto è guardare il diff di una riga di 80 caratteri, un altro è per una riga di 800 😆 (è solo un consiglio, ma lavora come preferisci tu)

robitex” post=80916

@robitex: quale editor di testo utilizzi? TeXworks? È possibile in questo editor limitare automaticamente il numero di caratteri per riga a un certo numero fissato? Un conto è guardare il diff di una riga di 80 caratteri, un altro è per una riga di 800 😆 (è solo un consiglio, ma lavora come preferisci tu)

Tu cosa consigli?

Il mio consiglio sarebbe quello di limitare il numero di caratteri per riga (in genere circa 80), aiuta leggermente la leggibilità del codice per le finestre a tutto schermo, soprattutto su schemi con alta risoluzione, è pesante leggere righe di centinaia di caratteri (ricorda il famoso tormentone dei margini 😆 ), inoltre permette di individuare più facilmente le modifiche quando si fa uso dei diff (come con i vari sistemi di controllo delle revisioni): andare a ytovare una microscopica modifica (per esempio una virgola in più o in meno) su una riga di centinaia di caratteri diventa un’impresa simile alla ricerca dell’ago nel pagliaio, invece con una riga di pochi caratteri è molto più semplice.

Esempio: senza evidenziazione (nel terminale le differenze non sono evidenziate, ci sono solo colori diversi per le righe aggiunte ed eliminate), sfido chiunque a trovare rapidamente la modifica al file [tt]section/notefinali.tex[/tt] nel commit https://github.com/GuITeX/guidalineadicomando/commit/d265884480e00f59b23538280b2be5ed98ed5f11 (la riga è lunga oltre 400 caratteri)

Se però limitare il numero di caratteri per riga comporta una complicazione del proprio normale lavoro lo sconsigli. Emacs e Kile mandano automaticamente a capo una volta superato il limite, se ho capito bene TeXworks permette di riformattare il codice dopo che è stato scritto ma manda a capo automaticamente mentre si scrive, lo sviluppatore di Texmaker si è rifiutato di sviluppare questa funzione, non so quale sia la situazione per gli altri editor

Texworks permette di avere un hard wrap e di impostare la larghezza della riga, ma bisogna farlo a file .tex aperto scegliendo la sezione Format > Hard Wrap e poi nella finestrina si può indicare il numero massimo di caratteri per riga; mi pare che sia 64 il valore preimpostato.

Elrond” post=80921… inoltre permette di individuare più facilmente le modifiche quando si fa uso dei diff (come con i vari sistemi di controllo delle revisioni): andare a ytovare una microscopica modifica (per esempio una virgola in più o in meno) su una riga di centinaia di caratteri diventa un’impresa simile alla ricerca dell’ago nel pagliaio, invece con una riga di pochi caratteri è molto più semplice.

Esempio: senza evidenziazione (nel terminale le differenze non sono evidenziate, ci sono solo colori diversi per le righe aggiunte ed eliminate), sfido chiunque a trovare rapidamente la modifica al file [tt]section/notefinali.tex[/tt] nel commit https://github.com/GuITeX/guidalineadicomando/commit/d265884480e00f59b23538280b2be5ed98ed5f11 (la riga è lunga oltre 400 caratteri)

Concordo, e né GitHub né Bitbucket fanno alcun “a capo automatico” quando visualizzano i diff.

Questa è una di quelle cose che distinguono LaTeX, nell’uso con git, rispetto agli altri linguaggi di programmazione. Generalmente programmando non si oltrepassano mai gli 80 o al massimo 120 caratteri, per motivi “fisiologici”, mentre in LaTeX è esattamente il contrario. Penso che si possa sottolineare questo aspetto nella guida git4latex, suggerendo all’utente come comportarsi: sarebbe interessante porre all’attenzione proprio le peculiarità dell’uso di git con documenti LaTeX.

Premetto che ancora non ho una posizione irremovibile su questo, però voglio far notare una cosa: se dopo aver modificato il testo si inseriscono le interruzioni di riga ridistribuendo il testo, facendolo a mano o con un editor, si rischia di avere lo stesso problema. Basta aggiungere una parola al testo (ho trovato un esempio :D) per ottenere un diff ancora difficile da interpretare:
` In questa situazione diventa
-importante assicurarsi che le figure PDF siano aggiornate, infatti è facile
-dimenticarsi di ricompilare la figura dopo aver fatto una piccola modifica al
-suo codice sorgente. È evidente che in questo caso \texttt{make} può risultare
-molto utile per controllare in maniera efficiente che le figure Ti\emph{k}Z
-siano sempre aggiornate.
+importante assicurarsi che le figure \textsc{PDF} siano aggiornate, infatti è
+facile dimenticarsi di ricompilare la figura dopo aver fatto una piccola
+modifica al suo codice sorgente. È evidente che in questo caso \texttt{make}
+può risultare molto utile per controllare in maniera efficiente che le figure
+Ti\emph{k}Z siano sempre aggiornate.`
Essendo un diff su più di una riga, nemmeno GitHub evidenzia le differenze.

Ciao
Antonio

antonio.macrì” post=80948Premetto che ancora non ho una posizione irremovibile su questo, però voglio far notare una cosa: se dopo aver modificato il testo si inseriscono le interruzioni di riga ridistribuendo il testo, facendolo a mano o con un editor, si rischia di avere lo stesso problema.

Hai perfettamente ragione e l’esempio è interessante, ma con righe di lunghezza limitata si spera che questi problemi siano relativamente pochi (e ci sono i casi fortunati in cui il testo aggiunto occupa circa una riga intera e il diff coinvolge non il capoverso fino alla sua fine ma solo una o due circostanti), con righe lunghe 300-400 caratteri praticamente ogni diff è di difficile lettura

robitex” post=80954Ho provato emacs. In questo casi non sono riuscito a fare un gran che per mia scarsa conoscenza.

Nel file di inizializzazione di Emacs (il nome dipende dal sistema operativo utilizzato) dovresti aggiungere
`(setq-default fill-column 80)
(add-hook 'latex-mode-hook 'turn-on-auto-fill)`
se usi la versione standard di Emacs, altrimenti
`(setq-default fill-column 80)
(add-hook 'LaTeX-mode-hook 'turn-on-auto-fill)`
se usi il pacchetto AUCTeX.

Dopo aver riavviato Emacs, ogni qual volta supererai l’ottantesimo carattere per riga di un documento LaTeX verrai automaticamente mandato a capo, puoi automaticamente riformattare il paragrafo in cui si trova il cursore con la scorciatoia da tastiera Alt + Q (gli ambienti matematici non sono toccati proprio per evitare problemi)

Elrond” post=80950

Premetto che ancora non ho una posizione irremovibile su questo, però voglio far notare una cosa: se dopo aver modificato il testo si inseriscono le interruzioni di riga ridistribuendo il testo, facendolo a mano o con un editor, si rischia di avere lo stesso problema.

Hai perfettamente ragione e l’esempio è interessante, ma con righe di lunghezza limitata si spera che questi problemi siano relativamente pochi (e ci sono i casi fortunati in cui il testo aggiunto occupa circa una riga intera e il diff coinvolge non il capoverso fino alla sua fine ma solo una o due circostanti), con righe lunghe 300-400 caratteri praticamente ogni diff è di difficile lettura

(scusate il doppio post) @antonio.macrì: ecco un esempio di quei casi fortunati a cui mi riferivo: https://github.com/GuITeX/guidamakefilelatex/commit/16e71758b638bdcefb0e376967f6c2726ffe73ac ho cambiato una parola, riformattando il paragrafo due righe sono cambiate ma non l’intero capoverso, è abbastanza agevole individuare la differenza anche senza evidenziazione (peraltro qui assente), se usassi righe non limitate uno si dovrebbe rileggere tutti e due i capoversi per intero per trovare quell’unica piccola differenza

Pagina 28, nota 2:

robitexNei moderni sistemi Unix il programma sh non è altro che un collegamento al
programma bash, la Bourne Again Shell divenuta lo standard tra le shell disponibili per
i sistemi aperti ed anche per quelli Mac.

Non è esattamente vero: sh è un link simbolico a una shell che rispetti lo standard POSIX che non necessariamente è la bash, anzi per Debian e derivata (compresa Ubuntu, quindi stiamo parlando di una grossa fetta dei sistemi operativi GNU/Linux) /bin/sh punta a /bin/dash (Debian Almquist Shell), che è ben diversa dalla bash (è molto meno potente della bash). Uno shell script che voglia essere portabile attraverso i diversi sistemi operativi deve o avere esplicitamente /bin/bash nella shebang oppure, se usa /bin/sh come interprete, seguire pedissequamente lo standard POSIX ed evitare come la peste funzioni proprie solo di alcune shell. A questo proposito, un utente Debian sul suo blog pubblica ogni mercoledì a bashism a week, cioè una funzione esclusiva della bash che deve essere evitata nello scrivere script portabili

@robitex: ho visto che hai aggiunto una cronologia al tuo progetto. Visto che Git di base ha una sua cronologia, se uno è abituato a scrivere messaggi per i commit particolarmente ricchi ed esplicativi, si potrebbe creare un changelog a partire dal log di Git. La cosa più semplice potrebbe essere
`git log > HISTORY`
ma questo formato potrebbe non piacere. Il manuale di [tt]git log[/tt] spiega come personalizzare l’output di log, per esempio potresti provare
`git log –format=”Data: %ai – [%h]%d%nAutore: %aN%nOggetto: %B%n” > HISTORY`
Le ultime voci della cronologia del tuo repo così prodotta apparirebbero così:
`Data: 2013-01-05 12:14:12 +0100 – [6cd10b1] (HEAD, origin/master, origin/HEAD, master)
Autore: Roberto
Oggetto: Commit di servizio 🙂

Data: 2013-01-05 11:55:14 +0100 – [4ffd7fd]
Autore: Roberto
Oggetto: Precisazione su sh, bash e dash

Data: 2013-01-04 23:04:16 +0100 – [050346c] (v1.2.1)
Autore: Roberto
Oggetto: Aggiunto il nuovo capitolo Scripting

Data: 2013-01-02 09:56:03 +0100 – [e4c4e59] (v1.2)
Autore: Roberto
Oggetto: Rinominati alcuni file e aggiunta l'History

Data: 2013-01-02 09:52:21 +0100 – [c03ca16]
Autore: Roberto
Oggetto: Formattazione righe ad 80 caratteri ed altre cose

Data: 2012-12-27 15:24:35 +0100 – [2d790f0]
Autore: Roberto Giacomelli
Oggetto: Aggiornato lo script per non stampare data e versione della guida

Data: 2012-12-27 15:22:28 +0100 – [effd750]
Autore: Roberto Giacomelli
Oggetto: Eliminazione file di classe`
Naturalmente sei libero di cambiare il formato a tuo piacimento, in particolare puoi guardare il paragrafo “pretty formats”. Il mio consiglio è quello di non includere questo tipo di cronologia nel repository, dato che si tratta di una semplice riformattazione del log di Git, però potrebbe essere utile, per esempio, se hai intenzione di distribuire un archivio compresso contenente solo il sorgente della guida e la cronologia (dato che potresti voler escludere dall’archivio tutto il repo Git).

Probabilmente adesso è troppo tardi per applicare questa idea alla guidalineadicomando, però magari potrebbe servirti in futuro 😉

PS: non so se hai visto che ti avevo lasciato un commento a un tuo recente commit 🙂

robitex” post=81237Spero di poter contribuire alla guida tematica su git e LaTeX con particolari riguardanti i progetti delle guide stesse.

Cosa intendi di preciso?

robitex” post=81237Ultimo ma non ultimo, la riprogettazione della parte web delle guide…

Cosa intendi di preciso?

Ciao,
Orlando

robitex” post=81237Bellissimo intervento Elrond.
Grazie mille.
Certamente molto utile rendere la HISTORY automatica dai commenti ai commit.
Si ho visto il commento, certamente, ho già fatto la correzione ed aspetto qualcosa di più per fare il commit.
Sono sempre restio a fare commit “leggeri”…
R.

Sì, ho notato che non ti piace fare “piccoli” commit ma ne fai sempre molto corposi (scelta legittimissima, ovviamente, io invece spesso faccio molti micro-commit più che altro perché sono fanatico della “sicurezza” e non voglio mai correre il rischio di perdere anche il minimo lavoro fatto, ma si tratta solo di una mia fissazione 😆 ), con questo tuo modo di procedere potresti trovarti molto bene nel realizzare la cronologia come ho indicato sopra, risparmieresti il doppio lavoro di scriverla due volte, nei messaggi dei commit e nell’apposito file HISTORY.

robitex” post=92869Ciao.
Ho aggiunto, raccogliendo il suggerimento di @And in questo post, alla guida alla riga di comando un messaggio per informare i lettori sulla possibilità di ricambiare il contributo ricevuto, associandosi al GuIT.
Anche gli altri Autori delle guide e della documentazione in generale possono inserire la stessa nota, anche prelevando il codice dal repository GuITeX.

La versione della guida è ora: v1.2.3 del 13/03/2014
Grazie.
R.

Perché non includere direttamente nella classe guidatematica il messaggio?

Ciao
Claudio

robitex” post=92876
Si, ho pensato anch’io che un comando \contribToGuIT andrebbe inserito nella classe.
Nel codice ho creato un “pulsante” su cui poter fare click per essere connessi alla relatia pagina web del sito.
Questo “pulsante” andrebbe però ridefinito perché usa un pacchetto specifico non caricato dalla classe guidatematica.
Ci sarebbe da fare anche una seconda piccola modifica sui nomi dei file pdf che vengono inseriti come immagini: andrebbero rinominati con caratteri tutti minuscoli perché quando li si scarica clonando il repo con Git i nomi sono lowercase mentre evidentemente nella classe i file sono richiamati con nomi Camelcase.
Qualcuno vuole preparare la modifica?
R.

Ho un’idea che mi sembra interessante per il “pulsante” (senza caricare pacchetti strani). 😉

Provo ad implementarla e fare l’upload della classe sul repository.

Ciao
Claudio

Ciao,

robitex” post=81488Ciao.
[…] Sono state apportate migliorie anche alle pagine introduttive del capitolo
sullo scripting, a cui si è aggiunto un nuovo esempio “Ritagliare le immagini”
da un’idea apparsa sul forum del GuIT di Marco87 e Francesco Biccari, con
l’illustrazione di come mettere a disposizione i nostri script tra i menù
dell’ambiente grafico. […]

Naturalmente il merito è tutto di Francesco. L’unica cosa che ho fatto io è stata quella di pubblicizzare quel comodissimo script che lui ha scritto. 🙂

Buona serata a tutti,
Marco.