Re: roadmap

[Henri Menke <henrimenke@gmail.com>]

On 15/05/18 03:17, Hans Hagen wrote:
> Hi,
> 
> The ConTeXt meeting is - as usual - the right place and moment to 
> discuss the roadmap. We never had real binding roadmaps, more informal 
> ones. Anyway, here are some thoughts on the two main components: MkIV 
> and LuaTeX.
> 
> ConTeXt MkIV:
> 
> - Check if some mechanism can (by now) be simplified due to LuaTeX 
> extension introduced the last few years that can be considered stable by 
> now. This has a low impact as we already use Lua a lot.
> 
> - Figure out what mechanism in ConTeXt are bottlenecks in performance if 
> there are such bottlenecks at all. We need user input on this.
> 
> - Get rid of inconsistencies in the user interface e.g. by introducing 
> new commands with settings.
> 
> - Check what additional features users want (miss) and decide to what 
> extent and with what priority we will put effort in this. We've reached 
> a point where interference prevents more complex extensions.

Math typesetting is really crappy in ConTeXt, but I get that this is 
beyond your priorities.  I plan to develop a module which resembles the 
features and syntax of the amsmath LaTeX package for my PhD thesis.  I'm 
not sure how well this will integrate with the existing mechanisms.

> 
> - Try to improve tricky mechanisms, like columns and tables. 
> Improvements are of course always on the agenda.

- columnsets, the new ones have considerably fewer features than the old 
ones.
- rowwise setups in xtables and maybe columnwise, but that is 
computationally expensive.

> 
> - We can add more trickery for fonts and scripts. There are some pending 
> extensions.
> 
> - Maybe we should provide a few more general styles.

What does that mean?  Things like the TUGboat style?

> 
> - Are there reasonable challenges left.
> 
> LuaTeX 1.09:
> 
> - This version is pretty close to what is the final version (seen from 
> the functional point of view). We're still debating where to move after 
> this. LuaTeX 2.0? A stripped down (lean and mean) version specific for 
> ConTeXt? Keep in mind that we cannot fundamentally change something, 
> even if we want to, because other macro packages use it and don't expect 
> it to change much.

More callbacks.  I'm missing callbacks into error handling (i.e. 
intercept errors) not just into error reporting like show_error_hook.

Throw out all non-Lua-related primitives and replace them with Lua 
functions.  People can then define those primitives themselves, e.g.

\suppressoutererror

becomes

\protected\def\suppressoutererror{%
     \directlua{errors.suppressoutererror()}}

This makes it much easier to access that stuff from Lua.  Also interface 
all the \pdfvariable and \pdfextension stuff to Lua.

This should have maybe been done before 1.0 but I guess with 2.0 you can 
introduce “breaking” features.

> 
> - There will probably be some more options in controlling math (given 
> issues with fonts). We have to accept that not everything has a generic 
> programmable solution (which is why we have Lua on board).
> 
> - There might be a few more callbacks but probably nothing fundamental 
> is planned.
> 
> - We keep cleaning up the code base (less code is better, less 
> dependencies too, some documentation is missing or not yet adapted to 
> the new code). For instance the pdf inclusion code will soon be redone 
> (and then tested in the ConTeXt distribution as usual).
> 
> - When possible we will try to improve performance but there is not much 
> to gain to be expected there.
> 
> - We will also keep up with Lua (currently 5.3, some day 5.4). It is 
> unclear to what extent LuaJit follows. When it stays behind we need to 
> decide if support in ConTeXt will stay (to some extent we can have dual 
> code paths as we have now).

LuaJIT will always be 5.1 compatible.  That is one of the declared goals 
of the project.  However there exist compatibility layers for Lua which 
implement recent features for older interpreters.
https://github.com/keplerproject/lua-compat-5.3

I would rather not see LuaJIT support being dropped.  The VM by itself 
(without JIT) is already a lot faster than regular Lua and I feel that 
the ConTeXt runs benefit from that quite a lot.  I use contextjit as my 
daily driver.

> 
> - We expect the ffi interface to external libraries to become more 
> stable over time. ConTeXt will not introduce dependencies (what can be 
> done in Lua will happen in Lua) but on the other hand we might put some 
> libraries in the distribution e.g. for database support.
> 
> - We might add some extensions to MetaPost in MPLib.
> 
> In addition we could formulate ideas with respect to the distribution, 
> garden, documentation and so on.
> 
> You can react on this list but if you come to the meeting, you can 
> participate in discussions.
> 
> So far for now,
> 
> Hans
> 
> -----------------------------------------------------------------
>                                            Hans Hagen | PRAGMA ADE
>                Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>         tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
> -----------------------------------------------------------------
> ___________________________________________________________________________________ 
> 
> If your question is of interest to others as well, please add an entry 
> to the Wiki!
> 
> maillist : ntg-context@ntg.nl / 
> http://www.ntg.nl/mailman/listinfo/ntg-context
> webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
> archive  : https://bitbucket.org/phg/context-mirror/commits/
> wiki     : http://contextgarden.net
> ___________________________________________________________________________________
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________