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
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(Continue reading)
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
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 of this wider process. -- Joseph Wright
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
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
--
--
William Adams
(Continue reading)
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
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. > PS: Since I'm posting anyway, I suppose I should mention this too in case > anyone is interested: After my autumn experiments with Church booleans, I > went on to implement a fully expandable package for <integer> to <balanced > text> mappings using 2-3-trees. I didn't quite finish it before getting > sidetracked by other projects (in this case, actual research), but insertion > of entries is there and works. Next would have been popping off entries; > together the two would suffice for making a prioriqueue, which I would > imagine can be useful in places. 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 by converting one <integer> to a <balanced text>?(Continue reading)
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
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, -- Will
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 <-\@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(Continue reading)
RSS Feed10 | |
|---|---|
4 | |
41 | |
21 | |
11 | |
9 | |
59 | |
57 | |
65 | |
2 | |
15 | |
53 | |
24 | |
74 | |
40 | |
114 | |
3 | |
8 | |
15 | |
86 | |
10 | |
6 | |
12 | |
2 | |
27 | |
87 | |
13 | |
10 | |
70 | |
21 | |
52 | |
241 | |
4 | |
15 | |
10 | |
27 | |
59 | |
52 | |
87 | |
62 | |
71 | |
19 | |
176 | |
14 | |
3 | |
22 | |
19 | |
12 | |
51 | |
18 | |
36 | |
16 | |
4 | |
5 | |
2 | |
12 | |
5 | |
3 | |
5 | |
12 | |
18 | |
21 | |
2 | |
10 | |
24 | |
20 | |
2 | |
5 | |
3 | |
12 | |
16 | |
19 | |
4 | |
9 | |
7 | |
12 | |
18 | |
1 | |
21 | |
7 | |
1 | |
4 | |
7 | |
3 | |
102 | |
6 | |
2 | |
4 | |
40 | |
39 | |
131 | |
13 | |
1 | |
3 | |
8 | |
13 | |
127 | |
22 |
