![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
Hi Wolfgang et al, I cleaned up mkiv'd pack-rul, meta-ini, anch-pgr etc and for sure there have been bugs introduced. A couple of mkii artefacts have been removed and some speedups were possible (important as framed is a core macro so especially backgrounds have been redone a bit). I still have to look into framed using the commandhandler but let's first check if the current variant is ok. I'll put a beta on the ftp server, so you might want to test, Hans PS. A few observations: \vbox -> hbox (less callback overhead), kern -> glue (less memory and calback overhead) i.e. some boxing has changed but hopefully for the best. PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc). ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 21.12.2011 um 23:26 schrieb Hans Hagen:
Hi Wolfgang et al,
I cleaned up mkiv'd pack-rul, meta-ini, anch-pgr etc and for sure there have been bugs introduced. A couple of mkii artefacts have been removed and some speedups were possible (important as framed is a core macro so especially backgrounds have been redone a bit). I still have to look into framed using the commandhandler but let's first check if the current variant is ok.
I'll put a beta on the ftp server, so you might want to test,
pack-rul.mkiv \startframed nice:) Tested with a large document and a few test files and they run fine.
Hans
PS. A few observations: \vbox -> hbox (less callback overhead), kern -> glue (less memory and calback overhead) i.e. some boxing has changed but hopefully for the best.
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them: \newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_… Wolfgang
![](https://secure.gravatar.com/avatar/c5ae4f9aa0d3a9bd5376e92b322c3e50.jpg?s=120&d=mm&r=g)
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I hope you don't converge to LaTeX3 syntax after all the rewrite is over :) Aditya
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 22.12.2011 um 01:19 schrieb Aditya Mahajan:
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I hope you don't converge to LaTeX3 syntax after all the rewrite is over :)
Don’t you already use your own syntax? Wolfgang
![](https://secure.gravatar.com/avatar/c5ae4f9aa0d3a9bd5376e92b322c3e50.jpg?s=120&d=mm&r=g)
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
Am 22.12.2011 um 01:19 schrieb Aditya Mahajan:
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I hope you don't converge to LaTeX3 syntax after all the rewrite is over :)
Don’t you already use your own syntax?
No. I reverted to the new internal syntax last week. Now I am using \modulename@macro_name etc. Aditya
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 22-12-2011 01:38, Aditya Mahajan wrote:
No. I reverted to the new internal syntax last week. Now I am using \modulename@macro_name etc.
Personally I try to get rid of the @ as it looks so ugly (:: would look better). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/93131e1e6e2204bd13501390d768dbdc.jpg?s=120&d=mm&r=g)
Am 22.12.2011 um 01:19 schrieb Aditya Mahajan:
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I hope you don't converge to LaTeX3 syntax after all the rewrite is over :)
No, i think there code is too complicated to understand without an knowledge about the syntax. The original purpose of the underscore in context was for modules to provide a namespace for macros. With the prefixes for registers there is a easy method to see whether a register is a counter, a dimension or a box (i know \c_… could also stand for a conditional and \s_… for a signal) but they are only used for internal code. All public command which can be used should remain without underscores, e.g. \doifelsenextbgroup etc. Wolfgang
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 22-12-2011 01:19, Aditya Mahajan wrote:
On Thu, 22 Dec 2011, Wolfgang Schuster wrote:
PS. I hope that in 2012 I've redone all the code (consistency, mkiv'd, namespaces, etc).
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I hope you don't converge to LaTeX3 syntax after all the rewrite is over :)
I have no clue what that syntax is anyway (apart from some obscure shortcuts I saw at a presentation ). There are no plans for such over the top command defining and parsing. I'd rather like to go simpler i.e. less esceptions. The prefixes Wolfgang mentions are just an addition to the already used class_name scheme and it's less code that appending _box _count etc, so it's just simple naming: \framed_width_dimen -> \d_framed_width and \edef\p_framed_width{\framedparameter\c!width} and such. Alternatively we can use \edef\framed_p_width I can change the existing code easily. Of course no scheme is imposed on module writers. (One reason for some system is that it permits parsing the files for official helpers: anything without _ is a potential user command of variable). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
![](https://secure.gravatar.com/avatar/49e63acb01f2ca80efce7eed08310ce8.jpg?s=120&d=mm&r=g)
On 22-12-2011 01:13, Wolfgang Schuster wrote:
Can we now consider the following prefixes for registers as the suggested method to name them:
\newcount: \c_… \newdimen: \d_… \newskip: \s_… \newbox: \b_… \newtoks: \t_…
I also use \c for constants and conditionals (as they are in fact also numbers). I use \m_ for temporary macros and \p_ for expanded parameters (not yet consistently). So we get: %D Conventions: %D %D \starttyping %D \newcount \c_class_whatever %D \newconditional \c_class_whatever %D \newconstant \c_class_whatever %D \newdimen \d_class_whatever %D \newskip \s_class_whatever %D \newmuskip \s_class_whatever %D \newbox \b_class_whatever %D \newtoks \t_class_whatever %D %D \edef\p_class_whatever{\classparameter\c!whatever} %D \edef\m_class_whatever{whatever} %D \stoptyping (coment appended to mult-aux.mkiv) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Aditya Mahajan
-
Hans Hagen
-
Wolfgang Schuster