Elrond

luca.sartorello” post=87433Mi sto copiando manualmente tutte le note e sono ancora sul più bello… Ricordo questo programma, ma su libre office non ho trovato questa possibilità: ti risulta che ci sia, o devo scaricare open office?
Grazie e ciao,
Luca

http://extensions.libreoffice.org/extension-center/writer2latex-1

OldClaudio” post=87137“Carneade, chi era costui? Lo stesso vale per i file di tipo fdd; la sigla sta per “documented font description” file. Serve per documentare ed estrarre il file di descrizione dei font che hanno estensione .fd (vedi guida tematica sui font). È l’analogo dei file .dtx (documented tex file) che serve per documentare e istruire sull’uso dei file di classe e dei pacchetti di estensione.

Perché l’unico risultato su Google della ricerca “documented font description” è questa discussione? Cosa fa di speciale Texshop per questi file? Semplicemente li gestisce come se fossero file *TeX oppure offre ulteriori funzioni particolari?

samiel” post=87204Ottina scoperta enotez, grazie a Enrico per la senalazione!
Mi chiedevo se esista (ne dubito però) per i pacchetti LaTeX
qualcosa come apropos dlel man di Linux…

m

http://www.guitex.org/home/it/forum/5-tex-e-latex/79830-tex-apropos

robitex” post=87126Dunque Lua 5.2 ha irrobustito il parser delle stringhe.

Mi vien da dire «peccato per questo irrobustimento», ora il formato della stringa diventa un po’ meno leggibile

Puoi più o meno forzare LaTeX a mettere una figure dove appare nel sorgente, ma spesso se non ce la fa non è per dispetto ma perché semplicemente lo spazio non c’è. Hai considerato la possibilità di riformulare il testo in modo da cambiare la posizione della figura oppure, meglio, rimandare questo controllo a quando il documento sarà finito per evitare che qualche aggiunta/cancellazione futura cambi la struttura della pagina?

Detto ciò, aspettiamo risposte più TeXniche dagli esperti 🙂

Liverpool” post=86876

Sì, certo, ogni commit in git scatta una fotografia dell’intero repository, se tu gli dici di tornare al commit 5 con il primo comando che ti ho detto lui ripristina tutti i file presenti all’epoca, il file di classe apparirà come era stato modificato nel commit 4 e l’immagine1 nella commit 3.

Allora mi sorge un dubbio: perché dobbiamo aggiungere i file nella staging area prima del [tt]commit[/tt] se comunque Git “scatta una fotografia dell’intero repository”?

Perché forse mi sono espresso male: il commit scatta una fotografia della staging area, e non qualsiasi file presente nella cartella di lavoro compresi quelli non aggiunti nella staging area. Tutti i file
mai entrati nella staging area, come i file ignorati, non sono mai ricordati, se torni indietro nella cronologia, cambi ramo e operazioni simili, questi file ignorati rimangono sempre tali e quali. EDIT in realtà l’espressione “il commit scatta una fotografia della staging area” può essere ancora ambigua perché potrebbe far pensare che la fotografia contiene solo i file modificati: no, contiene tutti i file che fino a quel momento sono stati aggiunti al progetto con un [tt]git add[/tt] e poi non sono stati successivamente rimossi.

Riferendomi a “intero repository” intendevo dire che un commit memorizza lo stato di tutti i file in blocco, in contrapposizione al funzionamento di CVS che ha una cronologia separata per ogni file. Vedi la prima critica qui: http://en.wikipedia.org/wiki/Concurrent_Versions_System#Criticism
Esempio di Git: https://github.com/giordano/guidagit/commits/master per ogni commit puoi visitare tutti i file presenti all’epoca (pulsante “browse code”)
Esempio di CVS: http://cvs.savannah.gnu.org/viewvc/auctex/auctex/ ogni file ha la sua revisione. Non so se sia possibile dire “fammi vedere tutti i file all’1 gennaio 2013”, a parte usando i tag (ma non è che uno può creare un tag per ogni commit…) (P.S. fortunatamente da qualche mese anche AUCTeX si è convertito a git).

Il funzionamento dei vari VCS moderni è molto simile, così come comune è l’interfaccia utente: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_commands per ogni operazione, i nomi dei comandi scelti dai vari software sono al più due o tre. Quello che cambia sono le opzioni particolari utilizzate da ciascun comando, da questo punto di vista qualcuno dice che git ne ha troppe 😀 Comunque è impossibile negare che git sia il DVCS che ha avuto maggior successo (considerando i tre grandi git, mercurial, bazaar), qui per esempio c’è una statistica basata su tutti i progetti registrati su Ohloh (oltre mezzo milione): https://www.ohloh.net/repositories/compare Qui un’altra statistica basata sui pacchetti presenti in Debian (quasi 14 mila): http://upsilon.cc/~zack/stuff/vcs-usage/ oltre il 60% dei pacchetti sono mantenuti usando git, invece mercurial e bazaar raccolgono le briciole.

In generale, i DVCS sono tremendamente utili, ti permettono di lavorare con maggiore libertà perché hai sempre la consapevolezza di poter tornare indietro a uno stato precedente e ti permettono addirittura lavorare contemporaneamente su due binari paralleli, tracciando tutti i cambiamenti compiuti. Dubito che sistemi di backup siano utili da questo punto di vista (per lo sviluppo collaborativo sono del tutto inutili). Sono fermamente convinto che anche gli utenti di *TeX, siano essi autori di documenti (soprattutto quelli più grossi e importanti) o sviluppatori di classi e pacchetti, possano trarre grande vantaggio dall’uso dei DVCS.

Liverpool” post=86876Forse il [tt]commit[/tt] aggiunge fisicamente una copia dei file aggiunti e un semplice riferimento per gli altri presenti nel repository basandosi non su ciò che c’è nella working directory, ma su ciò che è scritto nel suo database?

Con “gli altri presenti nel repository” intendi i file mai entrati nella staging area? In questo caso ti ho risposto sopra.

Liverpool” post=86876Grazie. Ho visto che hai aggiunto l’elenco dei comandi alla fine.

Grazie a te per l’idea, è davvero utile. Non c’avevo mai pensato, ma effettivamente mi è capitato più di una volta di ritornare a leggermi mezza guida per trovare un comando che sapevo essere presente, il riassuntino di tre pagine è molto comodo per questo!

Non sono sicuro di aver capito bene la domanda: vuoi riportare l’intero repository al commit 5, e non un singolo file? In questo caso basta usare
`git checkout hashdelcommit5`
Se vuoi riportare un singolo file a quel commit
`git checkout hashdelcommit5 — sorgente`
come spiegato nella guida. Il primo comando in effetti non l’ho segnalato però può essere comodo.

Noto solo ora di aver fatto un piccolo disastro nelle ultime modifiche alla guida: per i comandi in linea ho usato [tt]\textt{}[/tt], ma di conseguenza i doppi trattini nel PDF finale appaiono come un unico trattino. Devo sistemare questo problema

Doc” post=86808Ti crei un file [tt]~/.TeXworks/completion/tw-personal.txt[/tt] con qualcosa come questo (ti posto il mio):
`%%!TEX encoding = UTF-8
scolio:=\pstart\newpara \label{#INS#•} #INS#•\pend
paralleli:=\edtext{}{\paralleli{{\textbf{\ref{#INS#•}}}\enspace #INS#•}}
testimonia:=\edtext{}{\testimonia{{\textbf{\ref{#INS#•}}}\enspace •#INS#}}
lectiones:=\edtext{#INS#•}{\lectiones[#INS#•]{#INS#•}}
marginalia:=\ledsidenote{#INS#•}
nrlectiones:=\edtext{}{\lemma{{\textbf{\ref{#INS#•}}}\lectiones[#INS#•]{#INS#•}}
greeknumeral:=\greeknumeral{#INS#}`
A questo punto, scrivi ad esempio [tt]paral[/tt], premi TAB e fa tutto lui!

Nel tuo [tt].emacs[/tt]:
`
(define-abbrev-table 'global-abbrev-table
'((“scolio” “\\pstart\\newpara \\label{} \\pend”)
(“paralleli” “\\edtext{}{\\paralleli{{\\textbf{\\ref{}}}\\enspace}}”)
(“testimonia” “\\edtext{}{\\testimonia{{\\textbf{\\ref{}}}\\enspace}}”)
(“lectiones” “\\edtext{}{\\lectiones[]{}}”)
(“marginalia” “\\ledsidenote{}”)
(“nrlectiones” “\\edtext{}{\\lemma{{\\textbf{\\ref{}}}\\lectiones[]{}}”)
(“greeknumeral” “\\greeknumeral{}”)))
;; stop asking whether to save newly added abbrev when quitting emacs
(setq save-abbrevs nil)
;; turn on abbrev mode globally
(setq-default abbrev-mode t)
`
A questo punto, scrivi per esempio [tt]scolio[/tt], premi un tasto qualsiasi non necessariamente [tt]TAB[/tt] e fa tutto lui! (liberamente ispirato a http://ergoemacs.org/emacs/emacs_abbrev_mode.html) Edit: non proprio un tasto qualsiasi, ma comunque si possono usare molti tasti: [tt]TAB[/tt], [tt]RET[/tt], spazio, segni di punteggiatura, etc…

Difetto, [tt]abbrev-mode[/tt] lascia il cursore alla fine del testo sostituito, immagino che tu voglia posizionarlo in qualche posto in particolare dopo la sostituzione. Credo ci siano altre modalità più raffinate da questo punto di vista, probabilmente Yasnippet, indago e faccio sapere. Non ho mai usato sistemi per l’inserimento semplificato di porzioni di codice, li sto studiando ora 😀