Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sile: A Modern Rewrite of TeX

sile-typesetter.org

Post reply on HN
Print view View original

121–130 of 181 posts

Re: Sile: A Modern Rewrite of TeX

#121

Post by eesmith »

zzless wrote: post #28
chrisseaton wrote: post #5

Earlier quoted context omitted.

I work with TeX quite a lot and I can't even really understand intuitively the principles of the language design let alone the grammar. Like 15 years later and I'm still copy and pasting spells. I'd love to see an CST of my document and figure out why I'm writing the characters I'm writing!

My experience with TeX is a complete opposite. I feel like I can do pretty much anything in plain TeX, with a very good feel of what it is doing in its 'guts'. I wrote parsers in compilers in pure TeX (the latter was admittedly a silly academic exercise). It took a very thorough reading of 'The TeXbook' but after that I am constantly amazed at how deliberate and tasteful Knuth's choices were. TeX is simply ... elegan…

FWIW, https://sile-typesetter.org/what-is-sile/ points out:

> one of the things that TeX can’t do particularly well is typesetting on a grid. This is something that people typesetting bibles really need to have. There are various hacks to try to make it happen, but they’re all horrible. In SILE, you can alter the behaviour of the typesetter and write a very short add-on package to enable grid typesetting."

Alas, I don't know what that means. https://www.oreilly.com/library/view/latex-cookbook/97817843... appears to give a clue:

> For two-sided prints with very thin paper, matching base lines would look much better. Especially in two-column documents it may be desirable to have baselines of adjacent lines at exactly the same height.

but I don't have access to the full content.

Re: Sile: A Modern Rewrite of TeX

#122

Post by leephillips »

0cf8612b2e1e wrote: post #86
tomrod wrote: post #36

Earlier quoted context omitted.

I think the argument comes down to complexity. Getting Markdown --> Pandoc featureset up to a reasonable fidelity is the next stage IMO, especially if Markdown can be made to support the most common downloaded TeX extension packages.

Not going to happen. If you look at the CommonMark discussions, you will find people adamant that X features not be included for varying reasons. I think the best future option is going to be djot[0]. It is being created by the author of pandoc, who might possibly be the most qualified person in the world to appreciate all if the nuances of marking up text and parsing it. [0] https://www.djot.net/

djot syntax looks just like Pandoc’s markdown. What’s the difference?

Re: Sile: A Modern Rewrite of TeX

#124

Post by neutrono »

NeutralForest wrote: post #61
rhabarba wrote: post #27

Earlier quoted context omitted.

troff exists.

It doesn't have syntax highlighting IIRC

You can hack it with the \m[] escape in groff:

         \m[blue]int\m[] x
Of course, you would use some kind of pre-processor to make this less of a PITA, but it's not inconceivable.

Re: Sile: A Modern Rewrite of TeX

#125

Post by jltsiren »

mapierce2 wrote: post #83
Timwi wrote: post #79

I'm excited for the project, but disappointed that they kept the arcane syntax of TeX/LaTeX. Math expressions are hideous to write and read in LaTeX syntax.

Arcane, but I wouldn't say hideous. What's wrong with \alpha for α or \sum for Σ? Do you have a better idea than this?

You probably meant ∑ (\sum) rather than Σ (\Sigma). The two are different symbols, and they are sometimes used in the same expressions. For example, in the field I (used to) work, a sum over all characters in the alphabet would be written as \sum_{c \in \Sigma}.

Mathematical syntax is complex, and the typesetting often becomes unreadable outside trivial cases. Using Unicode won't help much, especially because it's easy to confuse similar-looking but unrelated symbols. Proper syntax highlighting might help, but I've never seen a tool doing a good job with it.

Re: Sile: A Modern Rewrite of TeX

#126

Post by 0cf8612b2e1e »

leephillips wrote: post #122
0cf8612b2e1e wrote: post #86

Earlier quoted context omitted.

Not going to happen. If you look at the CommonMark discussions, you will find people adamant that X features not be included for varying reasons. I think the best future option is going to be djot[0]. It is being created by the author of pandoc, who might possibly be the most qualified person in the world to appreciate all if the nuances of marking up text and parsing it. [0] https://www.djot.net/

djot syntax looks just like Pandoc’s markdown. What’s the difference?

Clean slate design. I think pandoc markdown is a superset of markdown, which must parse the ambiguous parts of the spec. Djot has a goal to eliminate the corner cases and be able to represent all things without requiring the html escape hatch (eg bold text within a word).

The rationale page can do a better job than myself. https://github.com/jgm/djot#rationale

Re: Sile: A Modern Rewrite of TeX

#127

Post by zzless »

choeger wrote: post #46
zzless wrote: post #28

Earlier quoted context omitted.

My experience with TeX is a complete opposite. I feel like I can do pretty much anything in plain TeX, with a very good feel of what it is doing in its 'guts'. I wrote parsers in compilers in pure TeX (the latter was admittedly a silly academic exercise). It took a very thorough reading of 'The TeXbook' but after that I am constantly amazed at how deliberate and tasteful Knuth's choices were. TeX is simply ... elegan…

> latest fads Context-free languages are the standard for decades now. They haven't been in the very early days of computing due to a lack of formal education of programmers and because they come with a certain, but tiny, memory requirement. What Knuth did with TeX was a violation of KISS. There's no good reason, but several downsides, to mix markup, code, and interpreter state like this.

I am not sure what you mean by context-free languages because literally none of the modern languages have context-free grammars. This includes HTML and XML although I would not call them programming languages per se. C++ grammar is undecidable. On the other hand, TeX's core typesetting language (i.e. not using its macro facilities) is context-free. Quite trivial in fact. Pascal, which is the language used to build TeX is context-free (even LL(1)), as well, which cannot be said about, say, C.

I would also be quite hesitant to claim that Knuth, who literally pioneered modern LR parsing theory (and deservedly got a Turing award for it) somehow lacked knowledge or awareness of cutting edge parser design techniques.

Finally, there is absolutely good reasons to design TeX as Knuth did. That TeX withstood the test of time for over three decades is a perfect testimony to that.

Re: Sile: A Modern Rewrite of TeX

#128

Post by michaelhoffman »

eesmith wrote: post #121
zzless wrote: post #28

Earlier quoted context omitted.

My experience with TeX is a complete opposite. I feel like I can do pretty much anything in plain TeX, with a very good feel of what it is doing in its 'guts'. I wrote parsers in compilers in pure TeX (the latter was admittedly a silly academic exercise). It took a very thorough reading of 'The TeXbook' but after that I am constantly amazed at how deliberate and tasteful Knuth's choices were. TeX is simply ... elegan…

FWIW, https://sile-typesetter.org/what-is-sile/ points out: > one of the things that TeX can’t do particularly well is typesetting on a grid. This is something that people typesetting bibles really need to have. There are various hacks to try to make it happen, but they’re all horrible. In SILE, you can alter the behaviour of the typesetter and write a very short add-on package to enable grid typesetting." Alas, I do…

https://en.wikipedia.org/wiki/Grid_(graphic_design)

TeX usually tries to adjust the space between lines so that a single typeblock is more visually appealing. Unfortunately, doing this adjustment independently for side-by-side columns leads to output where the text lines don't line up, and that is way less visually appealing.

Re: Sile: A Modern Rewrite of TeX

#129

Post by skippp »

daly wrote: post #108

TeX and Literate Programming (and Lisp) are my fundamental, day-to-day tools. Code it, explain it, generate a Literate PDF containing the code. The programming cycle is simple. Write the code in a latex block. Run make. The makefile extracts the code from the latex, compiles it, runs the test cases (also in the latex), and regenerates the PDF. Code and explanations are always up to date and in sync. I have found no b…

You may in interested to learn then, that for the past 10 months I have (slowly) been working on a LaTeX package that does exactly this [1]. It writes all the text from between come \begin{code} blocks out to a file, as well as use minted/listings to highlight it in the generated pdf. (exactly what you described but in LaTeX package form).

I am currently a physics student and one of the main problems that I have day-to-day coding is being unable to include diagrams/equations/pictures in the source code. Moreover, because there is a fair amount of 'domain complexity' the comments are often longer than the code itself.

The package is still very much unstable and not even close to being ready for any sort production. However, I did use it for my masters thesis [2], and it was quite an interesting (in a good way) experience. (I recommend everyone to actually try to write literate code at least once).

[1] https://github.com/Skipp1/fortex [2] https://github.com/Skipp1/mono-rich

Re: Sile: A Modern Rewrite of TeX

#130

Post by leephillips »

0cf8612b2e1e wrote: post #126
leephillips wrote: post #122

Earlier quoted context omitted.

djot syntax looks just like Pandoc’s markdown. What’s the difference?

Clean slate design. I think pandoc markdown is a superset of markdown, which must parse the ambiguous parts of the spec. Djot has a goal to eliminate the corner cases and be able to represent all things without requiring the html escape hatch (eg bold text within a word). The rationale page can do a better job than myself. https://github.com/jgm/djot#rationale

Thanks, that makes sense. Although I’d like to point out that one of the listed problems with commonmark, and the problem you mention, are not problems with Pandoc markdown:

    : echo "word**withboldtext**inside" | pandoc
    
wordwithboldtextinside


    : echo "a*?*b" | pandoc
    
a?b
Post reply on HN