Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign needed to handle parsing state changes #6

Open
phfaist opened this issue Aug 25, 2023 · 0 comments
Open

Redesign needed to handle parsing state changes #6

phfaist opened this issue Aug 25, 2023 · 0 comments

Comments

@phfaist
Copy link
Owner

phfaist commented Aug 25, 2023

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant