Comparing changes
Open a pull request
The second version is going to be quite different, so it is easier to start from a blank slate.
Probably the names should be "l3backend-XXXX.def", as for l3str-end-XXXX.def.
This is the usual pattern and makes it easier to see how any new files might get added.
This does not show up in a full test run, but does when you run just one or two tests after cleanup.
As discussed, in preparation for wider distribution.
No need to do l3packages: no changes there.
These were all 'expired' but now cannot be resurrected.
* Some indexing fixes to the l3doc doc (see #450) Some indexing fixes after Stone-Zeng's comments in #450. Namely: 1) Replace <@@=...> by <@@@@=...> in comments (bug introduced with #596); 2) Fixed `\@for\@tempa:=` (: is a letter here): replaced by `\clist_map_inline:Nn`; 3) Removed indexing of pseudo commands (`\meta{name}:\meta{signature}`); 4) `\>` would become `\!\efill` and `|` and `=` would fail to index. * Added do-not-index option to macro environment Added a `do-not-index` option to the `macro` environment to keep some control sequences from being indexed when innapropriate.
Rather than add Phelype, try to avoid giving the same information slightly differently in several places.
This reverts commit b43cf91.
Same as b43cf91, modulo messing up line endings.
Same as b43cf91, modulo messing up line endings.
To match pgf but also as an error here is not helpful.
I suppose. At least it's certainly not a change on our part
The reason is that \fp_abs:n expresses its result in decimal notation.
There remains two uses of the constant \c__fp_prec_int (=16)
Not efficiently, but there is no good solution
This will match a new seq function in the same area, needed for upcoming file module changes.
In readiness for file module changes.
This works by pure expansion so is needed for upcoming file function additions. At present, it may not be available hence needing to retain the older non-expansion code in a conditional.
The \pdffilesize primitive reports nothing for e.g. /dev/null.
This doesn't actually cost a stream, only a csname, so there is no real 'hit' in doing things the official way.
What's important is that for a non-existent file
This is a straight copy from the dvips driver: not sure why it got missed!
…ng for dvipdfmx backend
None of it is public so this doesn't really make sense.
Don't use \file_input:nT, which has been removed in commit ecd4174. Use \file_input:n instead.
…-to-read-l3doc.cfg l3doc.cls: fix bug when trying to read l3doc.cfg
Also the const version.
Well-attested, e.g. C++ ref.
The test for a RNG can stay experimental: once we require TL'19 XeTeX, it will go.
"get_shell" not "shell_get": This is consistent with other usage:
\<module>_get_<more-info>:<arg>
As \(pdf)filemoddate got added along with \(pdf)filesize, there is no case where we can run into an issue here.
Eventually, of course, this will go! Roll on TL'19 as the minimum engine age.
We need this for epstopdf-like support.
The concept is clearly going to be useful: one can imagine for example implementing pgfplots data structures as fparrays.
Compared to before the last few commits, \exp_args:NXY for various letters X and Y became around 1.5 to 2 times faster, and more importantly perhaps we get 2 times fewer lines in the log. Mumble
Tags in Git do not live in any specific branch, so a branch condition for builds based on tags doesn't really fit into Git's model. Therefore Travis silently ignores `branch: ...` if `tags: true` is given.
This is the only place we need raw \openin.
Their \newcatcodetable does not \initicatcodetable: see https://chat.stackexchange.com/transcript/message/52072701#52072701 onward.
Use tex.cprint if available to allow multiple uses of l3kernel.charcat affecting each other and avoid the use of a special catcode table.
This means we know tex.cprint() is available. Leave in loading of ltluatex: really is a requirement for LuaTeX use on plain.
As discussed with Japanese users, this matches graphics and would be desirable for them. Almost all test changes are trivial but note the l3pdf ones: may need to think about PDF version in dvips route (assume some known base value?). 'Full page' tests will show headers for dvips: making the contrib tests output those before starting the test is the best plan. There is some knock-on for other engines as a result.
This enables faster loading of expl3 with a suitably set-up TeX system.
Showing you all comments on commits in this comparison.
This comment has been minimized.
This comment has been minimized.
|
don't you just need the bachmode, not the vbox? The vbox example on tex.sx was to show that that was enough to end if inside a vbox. |
This comment has been minimized.
This comment has been minimized.
|
Adjusted |
This comment has been minimized.
This comment has been minimized.
|
As I said in the other discussion I don't think we should do this via a test but instead provide an empty definition in the LaTeX2e kernel so that the commands can be used without the next for an additional test which is an unnecessary runtime cost. As an initial step I would suggest doing a single test when xparse gets loaded and define the command and remove that later when it gets provided by the kernel |
This comment has been minimized.
This comment has been minimized.
|
@josephwright Do you expect that we will have any other tags which are not based on master? Then we should add some additional conditions, maybe some tag name parsing as in luaotfload? |
This comment has been minimized.
This comment has been minimized.
|
No real reason beyond wanting to keep things 'tight': I assumed Travis-CI would check 'is this tag matching a commit on the master branch' ... |
There are no files selected for viewing