Am 18.07.2015 um 15:33 schrieb Élie Roux: > Le 18/07/2015 12:26, Stephan Hennig a écrit : >> Say I write a pure Lua package replacing >> all A glyphs by Z in whatever callback. How do I hook into that >> callback in a format independent way? A luatexbase package that >> abstracts from minimal format implementations (as far as such are needed >> in a format) would solve that issue. > > This seems highly theoretical to me... Lua adds a /completely new programming layer/ to typesetting besides the TeX macro layer. And both layers are rather orthogonal to another. Any formats should play nice with the Lua layer. That is, they shouldn't force Lua package authors to target a particular format. > If you want a package developped in a format-independant way, I guess > you mean Plain, LaTeX, ConTeXt, and home-made formats. I think there are a few more formats in TL. But anyway, while different formats satisfy different demands, they make up for fragmentation of the TeX ecosystem. This is bad when the same typesetting problems are solved multiple times each solution targeting another format. The Lua programming layer has the potential of bringing different users (developers) of formats together again, making for more effective contributions (hopefully). Side-stepping format independence by design is, well, a crazy idea. > But luatexbase is not ported to ConTeXt and as far as I know, there > is no callback management in ConTeXt, you can't hook into a callback > without breaking everything... Ouch, I've not been aware of that. That's certainly ConTeXt's fault and should be fixed on their side. But LaTeX should learn from that instead of making the same mistake again (inherently coupling format and Lua programming layers). > So format-independant packages are already technically impossible an > I fail to really understand your point... can you give a more precise > example of a possible problem? Come on, you are an experienced open-source programmer. "Technically impossible" is a polemic term for "not yet implemented". ConTeXt is buggy. That's all. For a real-life example, the spelling package is actually a pure Lua package with a LaTeX .sty file wrapping the Lua API. Have a look at spelling.sty. You won't find any TeX foo there, but tons of \direclua calls. The manual has this: > The spelling package requires the LuaT E X engine. All functionality of the > package is implemented in Lua. The L A T E X interface, which is described > below, is effectively a wrapper around the Lua interface. > Implementing such wrappers for other formats shouldn’t be too difficult. > The author is a L A T E X-only user, though, and therefore grateful for contri- > butions. (I should note that the spelling package is in fact a highly experimental piece of code I've written two years ago. It needs a complete redesign w.r.t. node list handling, but that won't change the format-independent approach.) For other examples, please have a look at the padrinoma (PAttern DRIven NOde list MAnipulation) repository at <URL:https://github.com/sh2d/padrinoma>. Examples can be found in the examples directory. Please read examples/README. The padrinoma package is/will be a pure Lua package targeting problems such as pattern driven ligature handling, pattern driven non-standard hyphenation, pattern driven long-s replacement in black-letter fonts, etc. LuaTeX is a great opportunity for lots of new approaches to typesetting problems! Please play nice with pure Lua packages! Don't cut anyone's user/developer base by design. > Also, luatexbase has not moved for a couple of years, and there's no one > to maintain or develop it, so I think what's currently happening is > quite a good thing. If LaTeX people take-over maintenance the same people can do that as well outside the format. No, that won't necessarily be more expensive than an in-kernel solution. What's needed is a defined programming API. With two implementations (luatexbase and ltlatex) that is more or less already there. Compatibility modules that bind a format with its minimal resource allocation implementation (as far as that's needed in a format) and the proposed format-independent package can be contributed by a format's community just like .ldf files for babel. As soon as ConTeXt fix their resource allocation, ConTeXt users can magically use the spelling package to check spelling in their documents with TEX-unaware spell-checkers. I can't see the downside of a format-neutral approach. Best regards, Stephan Hennig