@samcarter Needs documentation explaining how to use it

@samcarter No, I'd leave it: Till always uses multiple dots, and it works OK

@UlrikeFischer You have your interface :)

@JosephWright I tried yesterday night but got only errors and was to tired to figure out if you missed something or if the installation was wrong. But what I already saw: Is the naming "KeysOptions" or "KeysOption" ?? And imho SetKeysXX is not only for "inside packages"

@UlrikeFischer I never said I'd checked it works :)

@UlrikeFischer I fixed a few things this morning, so at least the code loads: I'll probably add some further checks today

@JosephWright well there is a certain probability that if the \Declare-command is completely undefined that I messed up the installation ;-) I will try in a few minutes, but have to finish some other stuff first.

@UlrikeFischer Sure: the test suite is now passing so I've not actively broken the traditional mechanism. I'll perhaps have a few minutes to look at one or two tests before a meeting

@JosephWright oh and I wondered if the doc should mention that "normal" l3keys definitions can be used too in case some more complicated stuff is wanted.

@JosephWright Thanks for your input!

@UlrikeFischer One of the things I wondered about, links to which properties should be available where

I did not know that one can blame the duolingo bloke for captchas: ted.com/talks/luis_von_ahn_massive_scale_online_collaboration

@UlrikeFischer I started to write some notes last night and also queried the double plural, it reads OK as DeclareKeysAsOptions but that's a bit long, otherwise each option is one key so DeclareKeyOption or possibly just DeclareKey (but I'll mail later if I get chance) (@JosephWright)

@DavidCarlisle We will see what the consensus is :)

@PauloCereda A South America model: youtu.be/yi6co_r1PfU?t=51

(turn on captions to get the texts in English)

@samcarter OOH A GIANT ARARA

@PauloCereda yes, is this product placement for your cool automatisation tool? :)

@samcarter royalties

@PauloCereda :D

@samcarter <3

@MarcelKrüger I looked at the space-in-font-name question. The following seems to work, but do you think that luatex will complain somewhere if spaces are no longer removed?

\documentclass{article}
\usepackage{fontspec}

\ExplSyntaxOn
\sys_if_engine_luatex:T
  {
    \cs_set:Nn \__fontspec_sanitise_fontname:Nn
      {
        \tl_set:Nx #1 {#2}
      %\tl_remove_all:Nn #1 {~}
        \clist_map_inline:Nn \l__fontspec_extensions_clist
          {
            \tl_if_in:NnT #1 {##1}
              {
                \tl_remove_once:Nn #1 {##1}
                \tl_set:Nn \l__fontspec_extension_tl {##1}
                \clist_map_break:
              }
          }
      }

@UlrikeFischer you might? want to trim spaces from the ends, leaving interior ones? otherwise \setmainfont{ Arial } uses font " Arial :mode=node;script=latn;language=dflt;+tlig;"! with a space before the : which seems to work OK but ..

@UlrikeFischer If the name contains a space, \fontname surrounds it with quotes. I'm not sure if that breaks something. Actually fontspec is already testing that for us: It adds a space when colors are used, so after this change all fonts will behave like fonts with color set behave currently. IIRC the only issue is with microtype which sometimes did something odd with them, but I'm not sure if that's already fixed.

@DavidCarlisle For font names that shouldn't matter since we normalize them anyway, but filenames might break. So it's probably a good idea to trim them.

@DavidCarlisle, @UlrikeFischer I've now got a working test for the option code: the obvious bugs are fixed

\documentclass{article}
\begin{filecontents}{mypkg.sty}
\DeclareKeysOptions{
  load-option-A .store = \my@A ,
  load-option-A .usage = load  ,
  load-option-B .store = \my@B ,
  load-option-B .usage = load  ,
  general-option-C .store = \my@C
}
\ProcessKeysOptions
\newcommand\mypkgtest{%
  \begingroup
    \edef\x{\my@A:\my@B:\my@C}%
    \show\x
  \endgroup
}
\end{filecontents}
\input{test2e}

\START
\AUTHOR{Joseph Wright}

\usepackage[load-option-A = 111]{mypkg}                           % 1
\mypkgtest

@UlrikeFischer ^^^ :)

@JosephWright I get an error at begin document, and preamble keys seems to be executed later anyway:

\documentclass{article}
\begin{filecontents}[overwrite]{mypkg.sty}
\DeclareKeysOptions{
  general-option-C .store = \my@C,
  preamble-option-D .store = \my@D,
  preamble-option-D .usage = preamble
}
\ProcessKeysOptions%{module}
\newcommand\mypkgtest{%
  \begingroup
    \edef\x{\my@C:\my@D}%
    \show\x
  \endgroup
}
\end{filecontents}

\usepackage[general-option-C= pack,preamble-option-D = pack]{mypkg}
\mypkgtest
\SetKeysOptions[mypkg]{general-option-C = preamble,preamble-option-D=preamble}
\mypkgtest

@UlrikeFischer I'll take a look

@UlrikeFischer What error did you see?

@JosephWright this one:

! LaTeX3 Error: The key 'mypkg/mypkg.code:n' is unknown and is being ignored.

@UlrikeFischer It's OK, I've worked it out :)

@JosephWright I remarked that \ProcessKeysOptions{module} gives not an error. Do you look for an "optional" mandatory argument?

@UlrikeFischer Yes: the l3keys2e version takes a mandatory argument, and we have to manage a transition [it's one of my queries :)]

@JosephWright yes I knew about the argument, I checked the docu ;-). That's why I tested if it explodes or not.

@UlrikeFischer I have a low-level check: my thinking was that if there is a braced argument, it's a 'classical' set up and I leave things to the option-clash code, if there's no brace group, the package is opting-in to the new mech. and all options are keyvals

@JosephWright I think it would be simpler to use different names (as I just commented in mail I'd change \ProcessKeysOptions name anyway) then you don't have to worry about l3keys2e compatibility any more than kvoptions compat or any of the other kv option handlers.

@DavidCarlisle It's a draft PR for a reason ;)

@JosephWright yes it's good to see plausible looking examples even if only to object to them:-)

@DavidCarlisle I think \SetKeys would be fine (and curiously it seems not to be in use yet).

@JosephWright actually I suppose the model of a general key setting and an option processer handling a specified key family is in fact exactly the l3keys2e model

@UlrikeFischer Fixed with a test

@DavidCarlisle Yup :) It's only a question of what 2e interface you want, and how far it goes (see team list)

@JosephWright \DeclareKeys seems to be free too.

@UlrikeFischer Yup

@UlrikeFischer Everyone has left us with the obvious names

@DavidCarlisle, @UlrikeFischer I suspect we have a plan: need to wait for FMi and (probably) Chris ...

@JosephWright It remains the question for the "process command". Like David I don't quite like the two s. What about \ProcessOptionkeys or \ProcessOptionKeys?

@UlrikeFischer Except were are definitely processing options not an option

@JosephWright I think key is an adjective here so ProcessKeyOptions ? or ProcessKeyFamilyAsPackageOptionsBasedOnExplThreeKeys

\catcodes

@AlanMunn pesky umlauts get everywhere

@DavidCarlisle Yes, that would work

@DavidCarlisle Meöw

@AlanMunn H̤m̤m̤

@DavidCarlisle \ProcessZZZZ?

@UlrikeFischer yes but drop the Process prefix

@DavidCarlisle a cat-astrophe surely?

just learned that github has a citation feature: docs.github.com/en/repositories/…

best commit log ever github.com/latex3/latex2e/commit/…

@DavidCarlisle :)

@DavidCarlisle 'Bug in longtable'? ;)

@JosephWright no one would believe that

@DavidCarlisle Enjoy