LaTeX-Result: 101 Error(s) ! Extra }, or forgotten \endgroup

Ciao a tutti,
chiedo l’aiuto del forum perché sono ormai disperato! C’è un errore che mi sta tormentando da tutto il giorno, e non riesco a venirne a capo in nessun modo.

Quando compongo con pdfLaTeX (pdfeTeX Version 3.141592-1.30.6-2.2, MiKTeX 2.5 su Windows XP, purtroppo per ora non posso cambiare macchina e/o distribuzione) il mio file Lezione_19.tex, ottengo in risposta:
`LaTeX-Result: 101 Error(s), 0 Warning(s), 0 Bad Box(es), 0 Page(s)`
Andando a spulciare il file di log, leggo le seguenti righe:
`! Extra }, or forgotten \endgroup.
\egroup

l.20

I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.`
Non vorrei sbagliare, ma è questo stesso errore ad essere ripetuto altre 99 volte; infatti, dopo una lunghissima sfilza di messaggi uguali a quello sopra riportato, il log si chiude con
`(That makes 100 errors; please try again.)`
Ulteriori tentativi di composizione non cambiano le cose.

Cercando di interpretare l’errore, sembra che io abbia aggiunto un «}» di troppo. Ma non sono riuscito a trovarlo da nessuna parte. Non capisco che cosa ci sia che non vada. A questo punto pubblico tutto quello che ho usato, cercando di riportare un codice minimale (che è fin troppo lungo, chiedo scusa).

Il file di classe (lezione.cls):
`\NeedsTeXFormat{LaTeX2e}[1995/12/01]

\ProvidesClass{lezione}

\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}

\ProcessOptions\relax

\LoadClass[11pt,a4paper,italian,twoside]{article}

\RequirePackage[ansinew]{inputenc}
\RequirePackage[T1]{fontenc}
\RequirePackage[italian]{babel}
\RequirePackage{datetime}
\RequirePackage[bf,sf]{titlesec}
\RequirePackage[%
bindingoffset=1.5cm,%
hmargin={1.5cm,3.5cm},%
vmargin={4cm,4cm},%
includehead]{geometry}
\RequirePackage{fancyhdr}
\pagestyle{fancy}
\fancyhf{}
\renewcommand{\sectionmark}[1]{\markboth{#1}{}}
\renewcommand{\subsectionmark}[1]{\markright{#1}}
\fancyhead[LE,RO]{\thepage}
\fancyhead[RE]{\thesection. \leftmark}
\fancyhead[LO]{Lezione}
\renewcommand{\headrulewidth}{0pt}
\setlength{\headheight}{13.6pt}
\fancypagestyle{plain}{%
\fancyhf{}%
\renewcommand{\headrulewidth}{0pt}%
\renewcommand{\footrulewidth}{0pt}}
\RequirePackage[toc]{multitoc}
\RequirePackage{tikz}
\RequirePackage{listings}
\RequirePackage[nottoc]{tocbibind}
\RequirePackage[activate={true,nocompatibility}]{microtype}
\RequirePackage[%
bookmarksnumbered,%
bookmarksopen,%
pdfstartview=FitV,%
colorlinks,%
linkcolor=black]{hyperref}

\definecolor{celeste}{rgb}{0,.5,.99}
\definecolor{oro}{rgb}{.8,.49,.19}
\definecolor{verde}{rgb}{0,.5,0}

\lstset{%
language=Java,%
basicstyle=\footnotesize\sffamily,%
keywordstyle=\color{celeste}\bfseries,%
stringstyle=\color{verde},%
showstringspaces=false,%
commentstyle=\color{oro}\itshape,%
keepspaces=true,%
columns=[r]spaceflexible}

\lstnewenvironment{uscita}{%
\lstset{basicstyle=\footnotesize\sffamily\color{verde}}%
}%
{}

\endinput`
Il file da comporre (Lezione_19.tex):
`\documentclass{lezione}

\author{Da decidere}
\title{Da decidere}

\begin{document}

\maketitle

\tableofcontents

\input{Pgm_19.1_(ContenitoriIO)}

\end{document}`
Uno (dei tanti, ma restiamo sul minimale) file che vengono importati, Pgm_19.1_(ContenitoriIO).tex:

Attenzione: visto che è lungo e noioso, consiglio di saltare la sua lettura, almeno per ora, e di leggere invece quello che scrivo subito dopo
`\section[\texorpdfstring{\lstinline!Pgm_19.1 (ContenitoriIO)!}{Pgm\_19.1 (ContenitoriIO)}]{Pgm\_19.1 (ContenitoriIO)}

La presente applicazione costituisce un semplice esempio per la creazione e la successiva visualizzazione di alcune strutture dati.

\subsection[\texorpdfstring{\lstinline!ContenitoriIO!}{ContenitoriIO}]{ContenitoriIO}

\lstinputlisting[firstline=5]{../../Codici/Lezione_19/Pgm_19.1_(ContenitoriIO)/ContenitoriIO.java}

I metodi forniti dalla classe, tutti di tipo statico, consentono di inserire informazioni all'interno di un contenitore particolare.

L'implementazione di tali metodi è tuttavia degna di nota. Ciascuno di essi restituisce infatti la versione estesa della struttura dati ricevuta come parametro in ingresso. In realtà, se per ciascun metodo il tipo del valore di uscita fosse stato specificato essere \lstinline!void!, l'istruzione \lstinline!return! avrebbe anche potuto essere omessa. Non sarebbe cambiato nulla, dal momento che ci si trova in presenza del passaggio
per indirizzo dell'handler di un contenitore di oggetti, indirizzo che non viene modificato in uscita, dal momento che l'unica cosa che cambia è il contenuto della struttura.

Vale anche la pena di notare che sebbene le informazioni aggiunte ai contenitori risultino in taluni casi duplicate, la semantica del metodo \lstinline!add()! è tale da \emph{rispettare} le \emph{caratteristiche della struttura dati} sulla quale va ad operare. In presenza di un contenitore che non ammette informazioni duplicate, il secondo accesso viene quindi ignorato.

Di seguito viene riportata una possibile uscita dell'applicazione:

\begin{uscita}
Contenuto List: [23, 41, 23, 708]

Contenuto Set: [23, 41, 708]

Contenuto Map: {13024=Lupo Virgilio, 17024=Lupo Grigio}
\end{uscita}

Per quanto riguarda la lista, gli oggetti presenti al suo interno vengono restituiti nell'\emph{ordine di inserimento}; nel caso dell'insieme, il valore «23», che si era tentato di inserire due volte, viene invece restituito una volta sola per le ragioni già discusse in precedenza, dal momento che il secondo tentativo di accesso del metodo \lstinline!add()! viene ignorato, essendo l'elemento in questione già presente nell'entità. Lo stesso fenomeno caratterizza anche la mappa.

Più in generale, le informazioni compaiono nell'\emph{ordine di allocazione}. Tale ordine è noto a priori nel caso delle liste, poiché queste strutture seguono una legge di composizione ben precisa, la quale accoda all'elemento di testa la sottocoda di concatenamento seguente. In tale collezione è pertanto sempre possibile conoscere l'elemento associato ad una posizione specifica.

Nel caso degli insiemi e delle mappe, essendo il supporto utilizzato di tipo hash, il loro contenuto viene visualizzato nell'\emph{ordine di allocazione sulla tabella hash}. Nel caso in cui si fosse fatto riferimento ad un supporto costituito da un albero, la sequenza avrebbe seguito l'ordine imposto da quest'ultimo.

\subsection[\texorpdfstring{\lstinline!Pgm_xContenitoriIO!}{Pgm\_xContenitoriIO}]{Pgm\_xContenitoriIO}

Un'unica osservazione su questo banalissimo metodo \lstinline!main()! che crea le strutture dati e le produce.

\lstinputlisting[firstline=8]{../../Codici/Lezione_19/Pgm_19.1_(ContenitoriIO)/Pgm_xContenitoriIO.java}

Finché è possibile, la struttura va gestita mediante handler che sono di tipo il più generale possibile. Quindi, questo significa che se serve un puntatore ad un oggetto struttura dati complessa, esso va dichiarato nei termini dell'interfaccia di quella struttura dati. L'implementazione va specificata nei termini del costruttore della classe di implementazione. Per cui lì la lista è dichiarata di tipo \lstinline!List! ma nasce da un costruttore \lstinline!ArrayList!, e, in maniera simile, \lstinline!Set! e \lstinline!Map! sono di tipo insieme e mappa rispettivamente però nascono dai costruttori delle due classi \lstinline!HashSet! e \lstinline!MapSet!. Ci sono situazioni in cui non è che sia così immediata e fattibile la cosa, però, il più possibile, è il caso di seguire questa prassi. In particolare, non va usata l'istruzione \lstinline!new List! per la costruzione della lista \lstinline!List!, perché quella è un'interfaccia.`
Il file Pgm_19.1_(ContenitoriIO).tex, importato così come sopra, genera i 101 errori; se invece lo «depuro» del testo normale, lasciando solo le istruzioni per i listati e i comandi di sezionamento, in modo che risulti come illustrato di seguito, tutto fila liscio (prova del fatto che non ho commesso qualche altra stupidaggine, del tipo sbagliare il path dei file Java da importare).

Pgm_19.1_(ContenitoriIO).tex (versione «depurata»)
`\section[\texorpdfstring{\lstinline!Pgm_19.1 (ContenitoriIO)!}{Pgm\_19.1 (ContenitoriIO)}]{Pgm\_19.1 (ContenitoriIO)}

\subsection[\texorpdfstring{\lstinline!ContenitoriIO!}{ContenitoriIO}]{ContenitoriIO}

\lstinputlisting[firstline=5]{../../Codici/Lezione_19/Pgm_19.1_(ContenitoriIO)/ContenitoriIO.java}

\begin{uscita}
Contenuto List: [23, 41, 23, 708]

Contenuto Set: [23, 41, 708]

Contenuto Map: {13024=Lupo Virgilio, 17024=Lupo Grigio}
\end{uscita}

\subsection[\texorpdfstring{\lstinline!Pgm_xContenitoriIO!}{Pgm\_xContenitoriIO}]{Pgm\_xContenitoriIO}

\lstinputlisting[firstline=8]{../../Codici/Lezione_19/Pgm_19.1_(ContenitoriIO)/Pgm_xContenitoriIO.java}`
Giuro di non avere la più pallida idea di dove sto sbagliando; sono andato a ricontrollare parola per parola il testo nella versione originale di Pgm_19.1_(ContenitoriIO).tex che ho poi rimosso, ma non riesco a trovare un «}» di troppo (o forse sono io ad essere fuso).

A questo punto, spero che la risposta al mio problema sia una cosa del tipo «il pacchetto x va caricato prima del pacchetto y», e non un’incompatibilità tra pacchetti (tutti quelli che ho caricato mi servono, anche quelli per i quali l’utilizzo non è evidente, come hyperref). Ovviamente, non posso tenere la versione depurata di Pgm_19.1_(ContenitoriIO).tex, perché tutto quel testo mi serve…

Grazie e buonanotte a tutti!