You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no proper handling of parsing state changes at this point in latexpp. On the other hand, pylatexenc 3 is introducing a powerful way of dealing with parsing state changes, including states that mirror more closely how TeX works (e.g. including or not '@' as part of a macro name).
This becomes problematic when parsing \newcommand constructs, for instance: Suppose a command is defined with \newcommand in a separate macros.tex file that is input into the main document. By the time the \input directive is processed, the custom macro in the main document is already parsed into nodes with the default macro spec.
Another problem is that macros defined within \makeatletter...\makeatother or within sty files cannot be handled properly if they have '@' in their names.
Finally, it would be nice to be able to handle constructions such as \newcommand{\be}{\begin{equation}}\newcommand{\ee}{\end{equation}}, although that seems like an additional challenge.
A better design would include the following features:
Already at parsing time, execute any necessary actions to determine how to update the parsing state. This includes looking up files input with \input{} or local custom sty files included with \usepackage{./mymacros}.
Always remember the parsing state associated with pieces of LaTeX code, especially when re-parsing new processed LaTeX code.
Along this redesign effort, we should make sure to always track node positions with respect to the original source file, so that errors can give precise source locations (file/line no/col no).
The text was updated successfully, but these errors were encountered:
There is no proper handling of parsing state changes at this point in latexpp. On the other hand,
pylatexenc 3
is introducing a powerful way of dealing with parsing state changes, including states that mirror more closely how TeX works (e.g. including or not '@' as part of a macro name).This becomes problematic when parsing
\newcommand
constructs, for instance: Suppose a command is defined with\newcommand
in a separatemacros.tex
file that is input into the main document. By the time the\input
directive is processed, the custom macro in the main document is already parsed into nodes with the default macro spec.Another problem is that macros defined within
\makeatletter...\makeatother
or withinsty
files cannot be handled properly if they have '@' in their names.Finally, it would be nice to be able to handle constructions such as
\newcommand{\be}{\begin{equation}}\newcommand{\ee}{\end{equation}}
, although that seems like an additional challenge.A better design would include the following features:
\input{}
or local custom sty files included with\usepackage{./mymacros}
.The text was updated successfully, but these errors were encountered: