On 2020/03/29 14:35:43, hanwenn wrote: > On Sun, Mar 29, 2020 at 4:12 PM <mailto:d...@gnu.org> wrote: > > > > On 2020/03/29 13:55:41, hanwenn wrote: > > > On 2020/03/29 13:52:48, hanwenn wrote: > > > > retain existing > > > > > > how's this? This leaves things backward compatible. > > > > Ugly and a maintenance burden since the code is used twice. Anything > > wrong with my proposal? > > I didn't understand your proposal. > > > It does not have duplicate code, makes > > define-markup-command compilable (while requiring its toplevel use) and > > provides a way of doing the same consistently for module-specific rather > > than toplevel use. > > > > It sacrifices, like your proposal, non-toplevel-performance for the sake > > of compilability in Guilev2. It's just that what the parser then uses > > is in a form that could also be used in a reasonably natural manner from > > Scheme. > > > > Should I write up a patch doing that? > > Yes please. >
Working on it. By the way, it just occured to me that a whole lot of trouble with byte-compilation is caused by the markup macro. git grep '(macro\($| \)' scm |wc -l counts 65 occurences. Those could certainly be replaced with make-...-markup functions without causing too much trouble, leaving the markup macro as only a user-level "feature". That should significantly cut down on our problems, right? The markup macro framework appears to be one of the worst corners for byte-compilation. The performance loss due to run-time argument checking instead of compile-time argument checking (which is likely the motivation for the markup macro design) is likely insignificant compared to the cost of actually typesetting markup. https://codereview.appspot.com/577720043/
