[latex3-commits] [git/LaTeX3-latex3-latex2e] develop: Two more discussion points (c27e1e62)

[Joseph Wright]

Repository : https://github.com/latex3/latex2e
On branch  : develop
Link       : https://github.com/latex3/latex2e/commit/c27e1e6201c000ad2830aaf78335f4d3a64ec583

>---------------------------------------------------------------

commit c27e1e6201c000ad2830aaf78335f4d3a64ec583
Author: Joseph Wright <joseph.wright at morningstar2.co.uk>
Date:   Wed Mar 9 15:20:04 2022 +0000

    Two more discussion points


>---------------------------------------------------------------

c27e1e6201c000ad2830aaf78335f4d3a64ec583
 required/latex-lab/latex-lab-prototype.dtx | 31 ++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/required/latex-lab/latex-lab-prototype.dtx b/required/latex-lab/latex-lab-prototype.dtx
index 5e1640bf..c87a02b4 100644
--- a/required/latex-lab/latex-lab-prototype.dtx
+++ b/required/latex-lab/latex-lab-prototype.dtx
@@ -373,6 +373,37 @@
 % work well if we allowed instances to be derived from others: effectively
 % the same as instances from templates, but with a `flatter' approach.
 %
+% \subsection{Assignment of key values}
+%
+% The \pkg{xtemplate} approach uses \cs{AssignTemplateKeys} to
+% specify when keys are assigned. In contrast, here key assignment is
+% automatic. If you look over \TeX{} Live, the only places that
+% \cs{AssignTemplateKeys} is not the first thing in the code are in limited
+% use cases in \pkg{enotez} and \pkg{xgalley}. In both packages, that's because
+% they want to limit the scope of assignment. In \pkg{enotez} the key setting
+% is placed inside a group, whereas in \pkg{xgalley} there is a
+% save-and-restore approach as a group is not possible. Both of those use-cases
+% could be covered in other ways: it's a question of setting up the template
+% keys so they assign to an intermediate variable, then assigning those as
+% necessary to the live ones for these cases.
+%
+% The main reason for not using \cs{AssignTemplateKeys} is that the common
+% case doesn't need it. We could of course stick to an explicit-assignment
+% approach, or have two variants or template-creation, etc., where assignment
+% is manual in one of them. 
+%
+% \subsection{Values from other keys}
+%
+% The \pkg{xtemplate} approach offers \cs{KeyValue} to pass the value of
+% one key as the default for another. That relies on the fact that key
+% setting is ordered (\emph{vide supra}). It also means that there is
+% some code to check for this as part of key setting: it's non-trivial
+% to support. The current \pkg{l3keys}-based code doesn't offer this.
+% Instead one could use for example meta keys. That is a different
+% interface and might occasionally be awkward. We can add some
+% \texttt{.store-value:n} property to allow a \cs{keys_value:nn} approach,
+% but without key ordering it might still not work in the same way.
+%
 % \subsection{Collections}
 %
 % These are not implemented at all: we likely want a new approach to