Classe o pacchetto: definire comandi facilmente ridefinibili

Ciao a tutti,

in una classe che sto realizzando vorrei definire alcuni comandi che però hanno nomi tipici di comandi analoghi forniti da altri pacchetti, per esempio il comando \micro.

Se però l’utente caricherà un pacchetto che definisce il comando \micro (usando \newcommand), LaTeX restituirà un errore.

Esiste un modo sufficientemente generale per mettermi al riparo da questo tipo di errori?
O, in generale, qual è la maniera migliore di definire dei comandi in una classe?

In linea di massima è bene evitare di definire comandi già presenti in pacchetti di uso comune. Pochi giorni fa qualcuno scrisse su comp.text.tex chiedendo come fare per adoperare \o (necessario per una lettera dell’alfabeto danese) che la classe fornitagli dalla rivista ridefiniva come equivalente di \omega. ❗ Si scoprì poi che anche \a, \b, \d e \l erano ridefiniti come abbreviazioni di lettere greche. ❗

Fai l’esempio di “\micro”: a che dovrebbe servire questo comando? Se ti serve per il prefisso del SI, la cosa migliore è di scrivere nella tua classe
`\AtBeginDocument{
\providecommand{\micro}{…}
}`
in modo che, se l’utente della classe carica siunitx, non abbia problemi con l’analogo comando definito nel pacchetto.

Spiegazione: \AtBeginDocument{} esegue durante l’esecuzione di \begin{document}, quando tutti i pacchetti sono stati caricati e il preambolo è finito. Con “\providecommand{\xyz}…” dici di definire il comando \xyz (stessa sintassi di \newcommand) solo nel caso in cui \xyz non sia già definito.

Per altri comandi ci saranno altre strade; esempi?

Ciao
Enrico

Scusate se mi inserisco, ma se ridefinisci \micro e l’utente carica anche siunitx, quando vuole usare \micro all’interno di siunitix può succedere un patatrac…

Secondo me, se sai che le tue definizioni sono incompatibili con siunitx è meglio verificare se il pacchetto siunitx è stato caricato ed eventualmente emettere un errore.

Giacomo

Scusate se mi inserisco, ma se ridefinisci \micro e l’utente carica anche siunitx, quando vuole usare \micro all’interno di siunitix può succedere un patatrac…

Secondo me, se sai che le tue definizioni sono incompatibili con siunitx è meglio verificare se il pacchetto siunitx è stato caricato ed eventualmente emettere un errore.

È appunto lo scopo della definizione che ho proposto:
`\ProvidesClass{pippo}[…]
…
\AtBeginDocument{\providecommand{\micro}{…}}
…`
Se nel documento LaTeX c’è
`\documentclass{pippo}
…
\usepackage{siunitx}
…`
sarà usata la definizione di \micro data da siunitx; se nessuno dei pacchetti caricati dall’utente definisce \micro, ecco che la definizione data dalla classe “pippo” entra in vigore: \providecommand non fa nulla se il comando da definire esiste già. Nessun patatrac.

Ciao
Enrico

Grazie della spiegazione.

Chissa perché ero convinto che \providecommand sovrascrivesse la definizione preesistente.

Giacomo

Grazie della spiegazione.

Chissa perché ero convinto che \providecommand sovrascrivesse la definizione preesistente.

\providecommand è stato introdotto con LaTeX2e, per risolvere in modo rapido problemi del tipo esposto. Infatti \newcommand dà errore se il comando che segue è definito, mentre \renewcommand dà errore se il comando non è definito.

Il contesto in cui si usa \providecommand è tipicamente quello di Francesco: se si vuole avere a disposizione un comando che un altro pacchetto definisce insieme ad altri senza dover per forza caricare l’intero pacchetto, ecco che \providecommand fa esattamente ciò che si desidera.

Altro uso: vogliamo definire a modo nostro un certo comando, indipendentemente dal fatto che sia definito o no in uno dei pacchetti caricati:
`\providecommand{\pippo}{}
\renewcommand{\pippo}{…}`
Con \providecommand ci assicuriamo che \pippo sia definito (non importa che cosa si mette tra le graffe della definizione) e quindi possiamo ridefinirlo.

Per i curiosi: \providecommand esamina il comando che segue; se è definito esegue \renewcommand, altrimenti esegue \newcommand. Facile, no? La costruzione
`\@ifdefinable{\pippo}{\newcommand{\pippo}{…}}`
funziona come \providecommand, ma è molto meno amichevole. La ridefinizione con \providecommand e \renewcommand può essere realizzata con
`\@ifundefined{pippo}{\newcommand}{\renewcommand}{\pippo}{…}`
In tutti i casi si può specificare il numero di argomenti come al solito.

Ciao
Enrico

Sono un po’ stupido.

Almeno nell’esempio proposto credo basti risolvere così:
`\providecommand{\celsius}{\ensuremath{\mbox{\textcelsius}}}`

Però la domanda rimane. Come fare nei casi in cui ho veramente un condizionale o altri costrutti particolari che richiedo un DeclareRobustCommand?

Ciao ciao.
Fra

`\usepackage{etoolbox}
\providerobustcmd{\pippo}{…}`
Tanto per imparare qualcosa: la definizione
`\providecommand{\celsius}{\mbox{\textcelsius}}`
ti fa proprio schifo? 🙂 Volendo emulare meglio siunitx, ti propongo
`\providerobustcmd{\celsius}{%
\ensuremath{{}^{\circ}\kern-\scriptspace\mathrm{C}}}`
Ciao
Enrico

A proposito: sarebbe interessante un paragrafetto nell’Arte dove si parla dei comandi LaTeX per la gestione delle scatole (\mbox, \makebox, \fbox, \framebox, \newsavebox, \sbox, \savebox, \usebox, \parbox, minipage, Lorenzo ci sei?! :D)

Ci sono eccome! 😉

Solo, non credo che quei comandi e ambienti (che, con la sola eccezione di \mbox, trovo piuttosto “TeXnici”) sarebbero utili al lettore “medio” dell’Arte. L’Arte è una guida di base, che ha l’obiettivo di spiegare le cose fondamentali di LaTeX in modo semplice: la compattezza e la semplicità hanno la precedenza sulla “completezza” (peraltro irraggiungible, in una guida a LaTeX).

Rimanderei senz’altro il lettore “pro” a una guida di base più approfondita: quella di Beccari, ovviamente, e forse anche le bibbie di Knuth, Lamport e il Companion.

Ciao,
L.

Scusate se riapro la questione, ma ho due piccole domande:

Volendo emulare meglio siunitx, ti propongo
`\providerobustcmd{\celsius}{%
\ensuremath{{}^{\circ}\kern-\scriptspace\mathrm{C}}}`

1. Ora che ho tolto gli if dai semplici comandi che stavo definendo, è ancora veramente necessario usare etoolbox e il providerobustcmd? Mi è venuto il dubbio perché nel consigliarmi la definizione di \celsius non hai usato un semplice \providecommand.

2. Se l’uso di \providerobustcmd fosse ancora necessario, che ne pensi se al posto di caricare etoolbox mi limitassi a scrivere:
`\@ifdefinable{\pippo}{\DeclareRobustCommand{\pippo}{…}}`

\providerobustcmd è certamente più efficiente di \DeclareRobustCommand; di fatto in questa situazione non è strettamente necessario perché \ensuremath è definito con \DeclareRobustCommand. In genere vanno “irrobustiti” comandi che si pensa possano trovar posto in argomenti mobili.

Se definisci \celsius con il solo \newcommand (o \providecommand), l’unica differenza è che in un file ausiliario troverai invece di \celsius la sua espansione di primo livello, cioè
`\ensuremath{{}^{\circ}\kern-\scriptspace\mathrm{C}}`
perché \ensuremath è irrobustito come \mathrm e gli altri comandi che compaiono non sono espandibili (\circ, \kern e \scriptspace).

Il vantaggio di {\new|\renew|\provide}robustcmd è che ciascuno di questi definisce un solo comando invece di due e l’espansione è di qualche nanosecondo più veloce. 🙂

Ciao
Enrico

Questi sono tutti i comandi che vorrei definire. Non credo se ne aggiungeranno altri.
Il pacchetto textcomp è precaricato dalla classe. Quali di questi, secondo te, necessitano di un irrobustimento? (Assumiamo che tutti possano essere argomenti mobili)
Io credo nessuno, a parte le abbreviazioni \g, \C e \A. Giusto?

`\newcommand*{\class@container}[1]{\textrm{\upshape#1}}
\AtBeginDocument{
% degree
\providecommand{\degree}{\class@container{\textdegree}}
\providecommand{\g}{\degree}

% gradi Celsius
\providecommand{\celsius}{\class@container{\textcelsius}}
\providecommand{\C}{\celsius}

% Angstrom
\providecommand{\angstrom}{\class@container{\AA}}
\providecommand{\A}{\angstrom}

% micro
\providecommand{\micro}{\class@container{\textmu}}

% Ohm
\providecommand{\ohm}{\class@container{\textohm}}

% times (only math)
\providecommand{\x}{\times}

% measurement unit
\providecommand*{\un}[1]{\ensuremath{\mathrm{\,#1}}}

% Napier's number
\providecommand{\eu}{\ensuremath{\mathrm{e}}}

% imaginary unit
\providecommand{\iu}{\ensuremath{\mathrm{i}}}

% roman subscript
\providecommand*{\rb}[1]{\ensuremath{_\mathrm{#1}}}

% roman superscript
\providecommand*{\rp}[1]{\ensuremath{^\mathrm{#1}}}

% differential (only math)
\providecommand{\diff}{\mathop{}\!d}

% derivative and partial derivative (only math)
\providecommand*{\der}[3][]{\frac{d^{#1}#2}{d #3^{#1}}}
\providecommand*{\pder}[3][]{%
\frac{\partial^{#1}#2}{\partial #3^{#1}}%
}
}`
I comandi riguardanti unità di misura devono sempre essere in tondo (diritti). Rimango molto perplesso su \x, ma anche su \A, \g e \C. A parte che l’Angstrom è un’unità deprecata, o sbaglio?

Trova un nome migliore per \class@container. Se usi amsmath i comandi definiti tramite \textrm cambiano grandezza se scritti in esponenti o pedici.

Ciao
Enrico