gmane.comp.tex.latex.latex3

Should l3keys provide a key .initial:n?

Marco Daniel — 2012-05-26T15:12:34

Hello,

Today I noticed that there is no key .initial:n. This question popped up 
during writing a small package. Whatever at the moment you have the 
following possibilities to set a key-value-syntax with an initial value:
=======================================================================
%First approach:

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int
  }
\keys_set:nn  { module }
  {
   myoption = 2
  }
\ProcessKeysOptions { module }

=======================================================================
Second approach

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int ,
   myoption .default:n  = 2
  }
\keys_set:nn  { module } { myoption }
\ProcessKeysOptions { module }

=======================================================================

I suggest to define a new key .initial:n so that we have a third approach:

Second approach

\keys_define:nn { module }
  {
   myoption .int_set:N  = \l_modul_myoption_int ,
   myoption .initial:n  =

Deprecated functions

Joseph Wright — 2012-05-23T21:09:01

Hello all,

The following functions have been deprecated and will be removed after
2012-08-31 with no replacement direct:

  \clist_use:N
  \seq_use:N

The appropriate alternatives at present are

  \clist_map_function:NN <argument> \use:n
  \seq_map_function:NN   <argument> \use:n
--
Joseph Wright

Deprecated functions

Joseph Wright — 2012-05-13T09:07:26

Hello all,

As notified previously, we are updating expl3 to address a small number
of inconsistencies in function naming. At present, these changes have
been made in the SVN only: they will be updated on CTAN /after/ the
TL2012 freeze.

The following functions have been deprecated and will be removed after
2012-08-31 with no replacement:

  \clist_if_eq:NN(TF)
  \skip_if_infinite_glue:n(TF)

The following functions have been renamed and are deprecated for removal
after 2012-08-31:

  \tl_length_tokens:n => \tl_count_tokens:n

The following functions have been renamed and are deprecated for removal
after 2012-11-30:

  \clist_length:N => \clist_count:N
  \clist_length:c => \clist_count:c
  \clist_length:  => \clist_count:n
  \prop_del:Nn    => \prop_remove:Nn
  \prop_del:cn    => \prop_remove:cn
  \prop_del:NV    => \prop_remove:NV
  \prop_del:cV    => \prop_remove:cV
  \prop_gdel:Nn   => \prop_gremove:Nn
  \prop_gdel:cn   => \prop_gremove:cn
  \prop_gdel:NV   => \prop_gremove:NV
  \prop_gdel:cV   => \prop_g

Functions moved to 'internal'/deprecated

Joseph Wright — 2012-05-10T07:22:51

Hello all,

The functions \cs_get_arg_count_from_signature:N and
\cs_split_function:NN have been move to 'internal' status, and so may be
renamed or dropped in the future without notice. These functions are not
used outside of the kernel in a current TeX Live installation.

The functions \cs_get_function_name:NN and \cs_get_function_signature:NN
are deprecated, and will be removed from expl3 by 2012-08-31. These
functions are entirely unused in a current TeX Live installation.
--
Joseph Wright

Upcoming changes

Joseph Wright — 2012-05-10T06:43:06

Hello all,

The team will not be updating the CTAN release of LaTeX3 until after the
upcoming TeX Live freeze. We have some 'breaking' changes that we feel
need to be made, and programmers will need time to adjust their code to
match. In particular, we are keen that the same conventions are used as
far as possible across expl3, and after a careful review by Frank
Mittelbach we have found a small number of inconsistencies which we want
to address.

I will be making a series of announcements over the coming couple of
weeks concerning deprecated functions, with associated renaming where
appropriate. These will all go to CTAN at the same time, and so I will
also announce when this happens, probably some time in June.

One change which has already occurred in the SVN version of LaTeX3 is
the replacement of the 'old' FPU with a new expandable version. We are
currently finalising the details of which functions will be retained and
which will be removed. A full announcement on this will follow in due
course as part

Babel

Javier Bezos — 2012-05-01T08:28:02

Babel gets back on track and it is again actively maintained. The
goals are mainly to fix bugs, to make it compatible with XeTeX and
LuaTeX (as far as possible), and perhaps to add some minor new
features (provided they are backward compatible).

No attempt will be done to take full advantage of the features
provided by XeTeX and LuaTeX, which would require a completely
new core (as for example polyglossia or as part of LaTeX3).

Your comments or suggestions (or questions!) are welcomed.

Javier

XMLTeX htmlentities.tex

William Adams — 2012-03-07T13:13:01

Returning to working on an xexemltex project and I've found that I 
added a line: 
\input{htmlentities.tex} 

at the beginning of my .xmt file and I'm not remembering if it's a 
standard thing or no. 

It started w/: 

\XMLentity{apos}{\textquoteright} 
\XMLentity{rsquo}{\textquoteright} 
\XMLentity{lsquo}{\textquoteleft} 
\XMLentity{rdquo}{\textquotedblright} 
\XMLentity{ldquo}{\textquotedblleft} 

and I've already added: 

\XMLentity{nbsp}{\nobreak{ }\nobreak} 
\XMLentity{mdash}{\textemdash} 

Should I continue along these lines (and then upload to CTAN?) or is 
there a finished version of this file extant already? (I looked and 
couldn't find one). 

Thanks!

William

Deprecated functions: \prg_quicksort: family

Joseph Wright — 2012-02-08T21:22:23

Hello all,

The \prg_quicksort: family of functions have been deprecated, and will
be removed from l3kernel on or before 2012-05-31.

Non-expandable but clearer functions are available in the experimental
l3sorrt, recently added to the LaTeX3 CTAN bundle.
--
Joseph Wright

Trees, was Re: Mapping Functions Versions for All and Some

Bruno Le Floch — 2012-02-02T18:24:05

Hello Lars,

The Church Boolean discussion is not forgotten, just on the
back-burner with so many things at the same time. It seemed to bring
some performance improvements, but there were some awkward parts to it
in the way I initially tried to implement them. In your last email on
the topic a few months back, you had a better approach some working
code, which I didn't get to benchmark carefully. I definitely need to
get back to boolean expressions, since at the moment
(...)&&(...)||(...)&&(...) treats && and || with the same priority,
which is wrong. Perhaps that will mean switching to Church booleans,
perhaps not: there are a lot of issues to consider, including
bootstrapping expl3, having a nice interaction with (future) fp
expression, no breaking change, etc.


I'm interested in what you have to say about 2-3 trees. I implemented
sorting based on splay trees, which I think I will also use for
Unicode character property lookup in l3regex eventually. None of that
code is in the svn yet.

What do you mean b

Mapping Functions Versions for All and Some

dongen — 2012-02-02T10:29:58

Howsagoin,


I've started exploring the LaTeX3 sources documentation but
I couldn't find the equivalent of the following predicate
functions for token lists:

 o  \tl_all_TF:NNTF <token list> <predicate> <true> <false>
    results in <true> if all members of <token list> satisfy
    <predicate>. The semantics should be that the evaluation
    is start-to-finish of <token list> but that the evaluation
    is aborted as soon as one of the tokens in <token list>
    doesn't satisfy <predicate>.
 o  \tl_some_TF:NNTF <token list> <predicate> <true> <false>
    results in <true> if some member of <token list> satisfies
    <predicate>. The semantics should be that the evaluation
    is start-to-finish of <token list> but that the evaluation
    is aborted as soon as one of the tokens in <token list>
    satisfies <predicate>.

Similar versions may also be useful for other kinds of lists.

Are such macros defined? If not, do you think it's a good idea
to introduce them?

Regards,


Marc van Dongen

Unexpandability inside \csname

Will Robertson — 2012-01-29T12:56:50

Hello,

I've been away from LaTeX for a little while and now that I come back again I've almost immediately stumbled upon an area that I don't think I've fully understood previously.

Consider:

  \csname\ifnum 3 > 2 foo\fi\endcsname

This (probably obviously to all of you) complains with the standard "Missing \endcsname inserted." presumably because there's an unexpandable implicit \relax inserted somewhere in there.

In expl3 we've discussed the concept of "restricted expandability", which refers to an expandable function that doesn't fully expand inside an "f" function (which is expandable \romannumeral-style expansion).

Does it make sense to also indicate how/where expandable functions won't behave correctly inside "c" arguments? I must admit I haven't considered the ramifications of what these mean entirely. It does seem there's not necessarily much overlap between the f-unexpandable functions and the c-unexpandable ones.

Cheers,

LaTeX 2e here float processing

Frank Mittelbach — 2012-01-11T20:23:08

Hi

Because of the following question on TeX.sx:

http://tex.stackexchange.com/questions/39867/intextsep-gives-doubled-space/40363#40363

I looked into that bit of ancient code that typesets "here" floats and 
the more I look the more issues I find with it.

Basically right now if a "here" float succeeds it will more or less insert

\vskip \intextsep                            %% a)
\box <float>
\penalty \interlinepenalty                   %% b)
\vskip \intextsep                            %% c)
\ifnum\outputpenalty <-\< at >Mii  % float encountered in vmode
     \vskip -\parskip                         %% d)
\fi
\penalty 10000                % the original breakpoint modified by TeX

This has the following consequences:

  a) does not combine with a previous skip (as \addvspace would)

  b) provides a breakpoint after the float

  c) is not seen by any following \addvspace because of the penalty 
after it on the main vertical list

  d) cancels the upcoming \parskip that will be added by the next text 
line afte

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad resul

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad resul

trial typesetting support

Frank Mittelbach — 2012-01-08T10:32:08

I just had a look into the following question on TeX.sx:

http://tex.stackexchange.com/questions/40330/centered-captions-containing-vref-may-not-always-appear-as-expected

The issue here is the following code:

\long\def\< at >makecaption#1#2{%
   \vskip\abovecaptionskip
   \sbox\< at >tempboxa{#1: #2}%
   \ifdim \wd\< at >tempboxa >\hsize
     #1: #2\par
   \else
     \global \< at >minipagefalse
     \hb< at >xt< at >\hsize{\hfil\box\< at >tempboxa\hfil}%
   \fi
   \vskip\belowcaptionskip}


The problem is that this code trial typesets the caption as 
\sbox\< at >tempboxa{#1: #2} but then is not using it if the line is getting 
to long but instead uses  #1: #2\par. If however the line is short 
enough it reuses the box.

There are some reason for doing this (I mean not reusing the box in the 
multi-line version) as this has other deficiencies, but together with 
varioref this produces a problem. The problem being that varioref 
internally increments some counters to add label names and those are 
then never written to the aux file with bad resul

How to describe category codes: documentation and \char_show_value_catcode:n

Joseph Wright — 2011-12-31T23:09:03

Hello all,

I was asked recently about the documentation of category codes in the
LaTeX3 docs. Currently, we say things like "category code 12 ('other')"
when describing what codes are active. We also provide
\char_show_value_catcode:n, which is just a wrapper around
\showthe\catcode. However, for setting catcode we use symbolic names,
for example \char_set_catcode_other:N.

While knowing catcode meanings is a required TeX programming skill, it
seems more in keeping with the LaTeX3 approach to talk about these by
their meaning. That raises two questions

 1) How should we refer to catcode in documentation, both in terms of
    the text and the formatting (for example, do we want to say
    something line 'category code <other>')?
 2) What should we do for \char_show_value_catcode:n? 'show_value' is
    not the right name for showing a symbolic meaning. I guess we just
    use \prg_case_int:nnn to actually show the meaning.

\leavevmode?

Ulrike Fischer — 2011-12-30T09:46:19

Hello,

what is the recommended way to issue a \leavevmode in latex3?

Active characters

Joseph Wright — 2011-12-27T23:14:27

Hello all,

We currently have a few functions in l3token for creating definitions
for active characters. These are defined as 'experimental', and I was
recently asked about them and so though it might be worth raising the
issues here. (I've also done a little tidying: in the following I'm
referring to the SVN/GitHub version of the code rather than the last
CTAN snapshot.)

The current implementation provides \char_(g)set_active:Np(n|x) and
\char_(g)set_active_eq:NN. The logic to these functions is that they set
the N argument active (locally) then attach a definition either locally
or globally as appropriate. Thus \char_set_active:Npn is equivalent to
the inline code

  \char_set_catcode_active:N <token>
  \cs_set:Npn <token> <parameters> { <code> }

and so forth.

There are a few questions this raises. To cover all possible cases,
you'd need ..._nopar..., ...protected... and ...protected_nopar_...
versions, which looks a bit like overkill. (Well, perhaps only
protected, as we are de-emphasising nopar, but e

Deprecated variable: \c_string_cctab

Joseph Wright — 2011-12-21T22:09:32

Hello all,

The LuaTeX-only variable \c_string_cctab has been renamed as
\c_str_cctab. The logic here is that all other 'string' cases in expl3
use 'str'.

The old version will be removed on or before 2012-03-31.
--
Joseph Wright

Documentation of local/global variants

Joseph Wright — 2011-12-03T09:34:24

Hello all,

Part of our recent efforts with LaTeX3 has been to improve the
documentation, adding in for example 'change dates' for functions in
l3kernel.

One area that I am not sure we have quite right at present is the
documentation of local/global variants. Where functions exist in both
local and global versions (for example \tl_set:Nn and \tl_gset:Nn),
there are currently separate documentation entries for the two cases.
This means that the scope of assignments can be clearly documented, but
does make for rather repetitive text.

A similar issue arises with the (TF) functions, where we have decided to
have a general statement about the nature of the two branches for the
entire content of interface3, and only to include information for
individual functions where a special case applies.

I wonder if it would make more sense to take the same approach for
functions with local/global versions. Something like:

'Where functions for variable manipulation can apply either locally or
globally, the latter case is

rien ne va plus after TL-2011 package update

Alexander Grahn — 2011-11-15T14:15:37

Good afternoon,

I updated my TL-2011 packages today. Now, expl3 doesn't work anymore.

  \listfiles
  \documentclass{minimal}
  
  \usepackage{expl3}
  
  \begin{document}
  \ExplSyntaxOn
    \tl_new:Nn\g_example_tl{hello!}
    \g_example_tl
  \ExplSyntaxOff
  \end{document}

leads to:

  ! Undefined control sequence.
  l.8   \tl_new:Nn
                  \g_example_tl{hello!}
  ? q

What is going on?

Regards,
Alexander

 *File List*
 minimal.cls    2001/05/25 Standard LaTeX minimal class
   expl3.sty    2011/10/09 v2900 L3 Experimental code bundle wrapper
 l3names.sty    2011/10/09 v2896 L3 Experimental namespace for primitives
l3bootstrap.sty    2011/09/10 v2798 L3 Experimental bootstrap code
    etex.sty    1998/03/26 v2.0 eTeX basic definition package (PEB)
    calc.sty    2007/08/22 v4.3 Infix arithmetic (KKT,FJ)
   color.sty    2005/11/14 v1.0j Standard LaTeX Color (DPC)
   color.cfg    2007/01/18 v1.5 color configuration of teTeX/TeXLive
   dvips.def    1999/02/16 v3.0i Driver-dependant file (DPC,SPQ