Show HN: PreTeX, a LaTeX preprocessor to make math typesetting easier | Hacker News Reader

Show HN: PreTeX, a LaTeX preprocessor to make math typesetting easier

github.com

31 pointss9w25 comments

Pretty neat! As a suggestion, I would replace also the delimiters "()\{\}[]" with the corresponding left/right versions [1] so LaTeX adjusts automatically the size in the output and I don't have to deal with less readable code missing \left or \right errors.

As another tip to make LaTeX typesetting easier, I'd recommend using a custom keyboard distribution to input symbols easily, (e.g., alt + d for δ instead of \delta). In TeX.sx Jon Wickerson published [2] a layout for the british keyboard and the corresponding package to make LaTeX understand the unicode symbols. If you happen to have a spanish keyboard, I made an adaptation of that code [3].

And another thing: if you plan on using pretex a lot, it may be useful to parse the file on save (maybe before compilation). inotify-tools [4] or watchdog (OS X) [5] can help you, it's easy to create a script that will execute pretex whenever your LaTeX file changes.

Great work!

1: http://tex.stackexchange.com/questions/77589/what-do-the-pie... 2: http://tex.stackexchange.com/questions/110042/entering-unico... 3: https://github.com/gjulianm/MathUnicode 4: https://github.com/rvoicilas/inotify-tools/wiki 5: https://github.com/gorakhargosh/watchdog

left/right: I've thought a lot about this, and I'm still divided. The left/right system in Tex is not the greatest itself and sometimes produces unwanted output. I was thinking of using another "flag" before math envs to force this. Still not sure what's the right thing to do.

Environment flags would be good. Another suggestion: per-file flags? if "% pretex delimiters" is present in the file, change delimiters; else, leave them alone.

Hmm yes configuration options need to expand beyond command line arguments. I'm still debating the best way. A separate json or cfg file would probably be too annoying? Latex comments would be a neat way, I like that

Looks really promising. I think i will give it a try. I am currently using a combination of Markdown and LaTeX (Markdown with embedded LaTeX expressions for math, compiled using pandoc [1]). Do you have any concerns regarding stability or output quality precompiling this combination with PreTeX? In other words: Does PreTeX only precompile statements surrounded by "$" or "$$"?

[1]: http://johnmacfarlane.net/pandoc/

I use Pandoc myself, actually this was written as a companion to it, focusing on the math side on things. As stated in the github text (maybe I should phrase it better), pretex works in any math environment I know of. So inline and all the \begin\ends, starred and unstarred. If you come across anything that doesn't work, shoot. So it works perfectly for pandoc!

Can I haz `|\psi> --> \left\vert \psi \right\rangle` ?

Or even better |ψ> using `{ v:k for k,v in unicodeit.net }` -- though I don't know of a convenient way to input Unicode characters (alpha, beta, ...) so maybe that's not too useful.

Attempt:

    re_ket = re.compile(r"""
    \|(
    [^\|<>]+
    )>
    """, re.VERBOSE)

What could that possibly interfere with? `R_+ = { x \in R | x>0 }` ?

|\psi> should probably be written with the braket package and "\ket{\psi}" in theory, right?! Sure I thought about implementing the bras and kets besides the full braket. I'll have to run some checks to make sure it won't interfere. Would you prefer the "native" latex version besides a braket-package version? Maybe I should make the choice an option

I'm not entirely sure what you mean with the unicode thing. You mean Unicode psi input, latex \psi output? I've started doing those in an earlier version before I realized that there is probably no practical situation where you have unicode input. Any use case that I haven't thought of?

Yes please. Whenever I try typesetting anything with bras and kets (or inner products), I can't stop muttering "langle rangle langle rangle" for a day afterwards.

I've implemented kets, bras and all their friends. That explosive set case is tested and cared for, too.

Still a bit confused about those unicode inputs though

The unicode inputs was just a bad idea. Like you said, there is no convenient way to input unicode characters.

Can we have the inverse transformation also?

So \alpha would become a unicode α and \int would be ∫.

Emacs has an input method that does the transformation automatically [1]. Yet most of my collaborators have not yet caught that bug..

[1] http://www.emacswiki.org/emacs/TeXInputMethod

So wait, just so that I understand: This would be for editors that input unicode greek letters, and preTeX should compile them to \alpha etc? But you seem to suggest the opposite. Care to explain?

It looks like he wants a way to go from \alpha and \int to their respective symbols. But isn't that just LaTeX?

Sure. The modern TeXs (xetex, luatex) take unicode input. Also for math. That makes the text even nicer looking. But most editors are inconvenient for finding the right characters.

Oh now I get it. Yeah I guess every editor that allows for greek input also provides a way for compile-time translation to latex? But if there's still a wish for unicode->latex transformations just open an issue, I'll have look at it

It is meant for those who are already familiar with LaTeX but do not have a handy unicode input method. Emacs has a feature that allows you to literally type \alpha or \in or any of hundreds of other LaTeX commands and have it substituted with the appropriate unicode character right in the plain text buffer you're editing.

So what is needed is a transformation from unicode-alpha to latex-alpha etc? That's no problem to implement, but doesn't emacs do that by itself? Latex can't render those unicode-alphas etc

The real problem with any tex preprocessor is getting your collaborators to use it. One solution is to have a preprocessor that can go backwards, so that when your collaborators edit you can keep working where they left off. Does PreTeX have such a feature?

I've thought about doing this bidirectionally. Besides implementing that all, the problem I see would be having a reasonable "cutoff". It probably wouldn't make sense to use the shortened <bra|ket> notation if the term was insanely huge. So There would be some heuristics, meaning it can't be guaranteed a 100% accurate back transformation.

Still interested? Or maybe there could be an export-mode where the pretex math is backuped in a comment or a separate file to help reconstruction. But that might get awkward fast. Hmm

I was hoping that most of the changes are so trivial that this would be unncecessary

What are \displaystyle{} and \dot{} for?

\displaystyle makes things in $...$ format like things in \[...\] but still inline, so it doesn't squash fractions. \dot puts a dot, usually meaning a time derivative.

Yeah displaystyle makes inline equations render like "normal" equation environments like align etc. The difference is obvious with things that take up a lot of vertical space like integrals or sums with limits. Sometimes you want an integral inline, but you need to make it \displaystyle. It's annoying to write, hurts readability and badly supported by editors. So d$equation$ makes it trivial to toggle it.

typo in Readme.md:

"Instead of writing $\displaymath \int_i^\infty$, just write d\int_i^\infty$"

should be d$, right?

Yes of course. Fixed, thanks!

Reply on news.ycombinator.com