@yo' well it's hard to argue that \write18 is the most natural interface to system commands, especially if (as is the case for luatex) cross tex-version compatibility is not a goal, and you have a lua os library specifically to interface to the operating system. so unlike disabling hyphenation by default, I think that dropping write18 is sort of reasonable...

... (it came about as they added 256 write streams so 18 was no longer naturally past the upper limit and having 0-17 and 19-255 being files, but 18 being system commands is even odder than \write18 in pdftex

@egreg using a strut is much easier than messing around with \prevdepth (which I'm sure you only did to try to trick @AndrewCashner into mis-directing a tick:-)

@DavidCarlisle Easier to code.

@yo' of course, it does break everything that uses write18, from eps insertion to minted to ... but not breaking latex packages isn't a luatex design aim either...

@DavidCarlisle And how do you classify \nointerlineskip if not “messing around with \prevdepth”? :P

@egreg standing on the shoulders of giants

@DavidCarlisle You should be more creative

@egreg I'll add some % at ends of lines

@DavidCarlisle I understand what is happening better in @egreg's solution. But I am surprised that either kind of trick is needed, since I'm just stacking boxes.

@AndrewCashner A \vtop has height determined by the first item in it, the rest is depth. So it normally has huge depth, which means \lineskiplimit is exceeded.

@AndrewCashner The same happens with \vbox, but before it instead of after.

@JosephWright or other moderator Could somebody unfreeze the forest v2.0 chat room? chat.stackexchange.com/rooms/30992/forest-v2-0. Sašo Živanović asked me, but I can't I don't think. I don't think reputation is enough - only moderators can unfreeze rooms, I think.

@AndrewCashner For instance, LaTeX sets \baselineskip and \lineskip to zero inside tabular and relies on \strut for good leading.

@AndrewCashner tex boxes only have one reference point so they can not (without help) maintain spacing to both the top and bottom baselines. if you choose vtop then the box reference point is the first baseline which makes it easy to get the space above correct, if you chose \vbox then reference point is bottom baseline so it's only easy to get the space after correct

@DavidCarlisle TeX for the Impatient 92: "Struts are useful for obtaining uniform vertical spacing when TeX's usual line spacing is disabled." Okay, I get that, and they do the \strut before and after just as you do. But why is the line spacing disabled in my example?

@AndrewCashner because you can not have \baselineskip space between the reference point of the first box and reference point of the second (because first box is already more than \baselineskip deep)

If you have a strut on the first line and the last then you can just put the boxes one above the other with no intervening space which is what \nointerlineskip does.

@DavidCarlisle So instead of measuring the depth of the box (as in the other solution), you give TeX a deep box (strut) at either end of the line and then tell it just to place the next line below through \nointerlineskip? In other words, you actually tell TeX not to measure the depth and just move on from the depth of the last strut??

@cfr Done

Hi im in

@AndrewCashner well not move on at all, the boxes are just abutted with no glue to adjust their position, but a \strut is a zero-width rule with height and depth adding to \baselineskip so, as long as nothing is deeper or higher than the strut, then the effect is that the space between the last baseline in the top box to the first baseline of the second box is depth of strut at end of box 1 + height of strut at start of box 2 = \baselineskip

@yo' yoin! :)

@PauloCereda Already chosen :)

@egreg Wikipedia suggests Papersera. :) it.wikipedia.org/wiki/Papersera

@yo' ooh :)

Got any experience with the github wiki?

@yo' only README.md :-)

@DavidCarlisle I thought so. I consider two options: 1) keep couple .md files for the crucial "wiki-like" information about the project or 2) starting the wiki.

@yo' as a rule, I'm not that fond of wikis unless you need them for wide collaboration purposes. If you know the html you want it's frustrating having to second guess what weird wiki combination you need to do so the system will generate it.

@DavidCarlisle :)

@DavidCarlisle I think I'll go with markdown files :)

@PauloCereda Ah, yes.

@egreg Please, have you got any idea where to look for a good exemplary dtx+ins files for a package?

@yo' I can soon provide one

@JosephWright thanks! :)

@yo' Do you want a 'self extracting' (just the .dtx) or one in two parts? The latter is probably better for allowing 'growth' but the former is handy for small packages

@JosephWright Well, I thought I may need two dtx files (one containing the manual, another one containing the documented source, which would then be put together, creating one .sty and one .pdf, if you understand me), so I think I need the "fancier" approach

@yo' Give me a few minutes

@JosephWright ok, I will :)

@yo' I feel a blog post in this :-)

@JosephWright ok, I'm not in a hurry, I can start writing the package as .sty and convert later, it's gonna be only couple lines at this point :)

btw, is there (to date) any standardized way how to check for the ability to do system calls?

% \iffalse meta-comment
%
% This part is not going to appear anywhere so is good for 'header'
% information.
%
%% These lines, starting with two "%", will be extracted so can be used
%% to copy some kind of header into target (.sty) files: the team .dtx
%% use this to dump the copyright header from the meta-comment block into
%% the output.
%
%<*driver>
\documentclass{ltxdoc}
% Whatever packages here
%
% Might include
% \usepackage{\jobname}
%
% Very handy is
% \usepackage[numbered]{hypdoc} % hyperref for ltxdoc

\input docstrip.tex
\keepsilent
\askforoverwritefalse
\preamble
----------------------------------------------------------------
mypkg --- Some code I wrote
E-mail: [email protected]
Released under the LaTeX Project Public License v1.3c or later
See latex-project.org/lppl.txt
----------------------------------------------------------------

\endpreamble

\postamble

Copyright (C) 2016 by
  Some Guy <[email protected]>

It may be distributed and/or modified under the conditions of

@yo' ^^^ Simple .dtx and .ins showing off a few features you might want (for example customised pre/post amble)

@JosephWright thanks a lot!

One last thing: How does the @@ notation work? I saw it a lot in L3 code...

@yo' l3docstrip extends DocStrip with a guard %<@@= ...: this will auto-replace @@ in the source by the module prefix. That's handy as in your sources all internal code can simply be noted as @@ and will be 'right' once it's extracted.

@yo' You don't have to use @@, you can just write out e.g. \__siunitx/\l__siunitx ...

@JosephWright yeah I know, I just thought it's cool. But I'm fine without it I think :)

@yo' It's there to save typing and to make the sources clear on what's internal (and to allow rapid changing of the prefix)

@JosephWright yeah I know. However, I (hopefully) won't touch any other prefix etc. Actually, I'm not 100% sure how should I distinguish internal/external if the package's UI is going to be non-L3 (created using xparse)

@yo' All new code should have documented code-level interfaces, even if for use with 2e you provide an xparse wrapper. I need to fix that in siunitx: a better example would be notes2bib where I've done the 'right' thing

@JosephWright so most of my macros should be \__yoin, right?

@yo' Documented interfaces: \yoin_<name>, internal stuff \__yoin_<name>

@yo' For most packages, most stuff will be internal, yes

@JosephWright ok, thanks, that's good to know (and it means I probably got some things wrong in ctuthesis)

@yo' Like I say, I know that siunitx is wrong! The issue there is that defining proper interfaces needs a big re-think (it's a large package)

@JosephWright yeah. I'm afraid I won't get this quite right in the new project... :-(

@yo' I'm happy to take a look as you write it: much easier to address 'early'

@JosephWright right. Well, first, it's the design, then implementation. Just, in parallel with thinking out the design, I need to get familiar with the tool (refresh my knowledge on L3, and learn DTX)

so now, to create the sty, I use tex yoin.ins, right?

@yo' Yes

and to create the pdf, I use pdflatex yoin.dtx

@yo' Exactly

oh jeez

(./yoin.dtx
./yoin.dtx:65: Missing $ inserted.
<inserted text>
                $
l.65 % \begin{macro}{\join_blabla:}

? ^C./yoin.dtx:65: Interruption.
<to be read again>
                   _
l.65 % \begin{macro}{\join_blabla:}

? x
No pages of output.

@yo' Ah, now the thing is I gave you a general .dtx model: if you want to do expl3 code swap ltxdoc for l3doc

@yo' There are a few other adjustments too (it doesn't use \StopEventually). Updated model coming up!

@JosephWright good to know there's a non-hacky solution :)

just one little thing: Is there any standard way to timestamp the package before committing? And git extension for this? If no, should I create one?

% \iffalse meta-comment
%
% This part is not going to appear anywhere so is good for 'header'
% information.
%
%% These lines, starting with two "%", will be extracted so can be used
%% to copy some kind of header into target (.sty) files: the team .dtx
%% use this to dump the copyright header from the meta-comment block into
%% the output.
%
%<*driver>
\documentclass{l3doc}
% Whatever packages here
%
% Might include
% \usepackage{\jobname}
%
\begin{document}
  \DocInput{\jobname.dtx}
\end{document}

@yo' Ah, the version issue

@JosephWright well, I have a tool which creates a header like this:

@yo' Git doesn't work the same as say SVN: there's no $Id line. If you are going with Git, you have to accept that setting the version in the file is an 'active' process. You could arrange for this to be scripted or (more the 'Git way') read a small second file during use, but it's a poor fit as that's mainly promoted for building binaries.

\ProvidesExplClass{ctuthesis}%
	{2015/11/15}{0.1 t1511151022}%MY TIMESTAMP HERE {0.1}
	{Class for typesetting CTU theses and alike}

@yo' Yes, sure, I understand, but part of the Git philosophy is that the version control system shouldn't edit the files themselves

(Note the %MY TIMESTAMP HERE {0.1} -- this is a directive to the script: it takes the current date, the given version at the end of the comment, and adds the timestamps)

@yo' See e.g. stackoverflow.com/questions/1792838/… for discussion of the fact that Git doesn't 'think' this way

@JosephWright well, you can create a tool that allows git vac -m "Message" to run ./myversioningscript and then git add -u and git commit -m "Message"

@yo' Yes, sure, but it's not portable (we had all sorts of 'fun' with beamer as Vedran used the keyword extension for Mercurial, but this has to be enabled by each person checking out the code, and we had a lot of bug reports as a result)

@JosephWright well, the point is, the code I have is a valid TeX code, even without running any external tool, so if you don't have the tool, you can still version correctly manually (or ignore versioning, whichever you wish)

@yo' Sure, the set up Vedran created was more flaky in that regard

@yo' Like I say, the problem I've got here is that it's a philosophical thing: if you want a version control system which timestamps files, Git is the wrong choice

@JosephWright also, no need to rely on external tools, I think this could be done from within pdflatex itself; it's a simple search and replace

@yo' l3build can do this, BTW

@JosephWright well, you do want that for LaTeX files, don't you? (almost "by definition")

@JosephWright ok, for now, I'll use my ./timestamp.sh. One day, I may learn to use l3build.

@yo' You want to set the version before release, but that's where the philosophical thing comes in (and something the team argue about): do you expect that end users pick up only 'release' files or that they might use any version you make available anywhere. I've got ideas about setting up an MD5-based \listfiles extension to address that (and the 'local edit' issue).

@yo' My experience is that very few users install stuff themselves, and even fewer by grabbing an arbitrary version of a file from a version control system. So provided I do a version step on release I'm comfortable. That's of course a personal judgement.

@JosephWright yeah, that's my issue as well

@JosephWright people actually do that with ctuthesis -- it's also been the recommended way so far (with no plan to change that in the near future).

@yo' Like I say, my feeling is that auto-versioning doesn't address all of the issues (particularly local edits), so a better approach is to hash each file each time it's read

@yo' You don't provide tagged releases/zip files?

@JosephWright "not yet".

@yo' I can't imagine I'd have many users if I said 'Do git clone X then <some build/install step>'!

@JosephWright there's the zip file available always for your repo

@JosephWright but you expect hundreds of users, my class had about 10 of them so far (maybe even less).

@yo' Not of the repo itself, only if people use a web interface (and then depending on the website), but that's no good anyway without an install script. I meant a proper TDS-style zip

I should fix this, but so far we were fine with the solution

@JosephWright yeah I know what you mean. OTOH, the class is 5 files, so not that many

(I know this is anything but optimal, but I don't have any plan on getting this right. I should look into this in the near future)

got to go now, I have to move to my parents', I'll meet my sister and my little nephew there.

@yo' why use a dtx for the manual?

@DavidCarlisle well, manual + documented source (in one file). Do you think it's a bad approach?

@yo' oh but I was commenting on a line where you said two dtx files, one for manual and one for documented source?

@DavidCarlisle well, because if you put the manual and the documented source in one file, you have your \ProvidesClass on line 1000, which seems inconvenient.

@yo' I'm confused:-) You can have your providesclass at the top if you want, but generally I'd just use the dtx for "documented source" but use a normal tex file for a "manual" especially if it can then be used as an example of the package. cf grfguide.tex being a user manual and graphicx.dtx being documented source. (unless it's just a small package and making it all one file is convenient, like indentfirst)

@yo' You can put the lines out-of-order, put some up front and skip typesetting them, ..., but as @DavidCarlisle says for larger code blocks its likely best to split the documentation up (I've realised this after ending up with a 12k line long siunitx.dtx!)

@JosephWright so you both advocate for two PDFs for the package?

@yo' Depends on the scale: I've only got one for notes2bib (user documentation + code-interface-documentation, but no typeset code)

@JosephWright I think I want to include the typeset code (in "the dtx style")

@yo' If the documentation part is more than say a couple of pages then probably. longtable has 10 pages before the start of the implementation, but it needed some multi-page examples, in general I probably wouldn't put that much in the source file these days.

@yo' If you want to typeset the code I'd split: most users will (should) never need to see that

@JosephWright yeah, right. I'll probably do that.

btw, a typo in l3candidates part of interface3, 2nd bullet in the introduction (p. 206):

> ... without a issues ...

@JosephWright ^^

@yo' Fixed

@JosephWright still no fix for language 0 in luatex trunk :( (only in experimental branch)

@DavidCarlisle Oh goody

Can someone please point me to a post where the following problem has been treated?

I believe I have seen it somewhere, but can't find it.

IMHO this looks really wrong. I would have considered to obtain three vertical arrows.

Overleaf for the lazy: overleaf.com/4406718wnzzjt#/13151942

That's weird.

Worse, if you use "abcde" instead of the rule, the arrows go outwards instead.

guys, I looked through some of the questions here, but I wasn't successful. In my bibtex file there exists an entry that has a group as author:

Author = {{Early Treatment Diabetic Retinopathy Study Research Group}}

When I cite this with author year, it is horrible because extremely long and I think the standard is to abbr. this with ETDRS as author in the citation.

How do I make this happen?

@halirutan assuming natbib see texdoc natbib sec 2.7 key=ETDRS (I think) (and use organisation or something other than author for the group name

@DavidCarlisle Hmm, that doesn't seem to work right. Organisation cannot be used in Article and if I use InProceedings, then the year is not printed anymore (beside the warning that the author is missing)

@halirutan too much information for chat:-) make an example and ask a question on site, I was just going by what the manual said (having a vague recollection that there was something there:-)

@DavidCarlisle Hehe.. no problem. Thanks.

@LaRiFaRi Imho you need \begin{tikzcd}[cells={shape=rectangle}]

Is anyone here using bibulous? It seems like an interesting project. It's not part of TeXLive though.

@AlanMunn Taken a look, wondered about it, worried that its got the '99%' problem (does 99% of tasks well but ...)

@JosephWright Cheers!

@AlanMunn I wouldn't trust a project which believes that "specifying a style should take only a matter of minutes". It then obviously has not idea that one has to handle the "if there is an editor but no author and a publisher then print ..." cases too.

@UlrikeFischer Indeed: my worry too. The logic looks fine for my area (chemistry) as almost everything is a journal article with very little variation. But then BibTeX styles for those areas are also easy ...

@UlrikeFischer Fair enough, but a little hyperbole isn't necessarily a death knell. :) But it's true that many people vastly underestimate the complexity of the full citation/references problem.

@UlrikeFischer Works fine in a preview where some variation is allowable (e.g. JabRef). I'm also suspicious that its tied to having the data pre-processed before LaTeX sees it: the 'I want to do X in the document itself' business is hard to address.

@AlanMunn Sure, like I say I think for many cases, certainly in the natural sciences, it works fine

@JosephWright Does it handles the punctuation correctly if e.g. the volume field is empty?

@UlrikeFischer I think so: there's a syntax of 'optional fields'

@JosephWright But the example template doesn't look as if it cared. I would have expected to get a space before the colon after the journal.

@DavidCarlisle Do you use any package or similar to help format the documentation of macros etc.? Everything I like seems to turn out to assume I've got the documentation in .dtx format and I don't really want to do that. (I really don't like .dtx files at all.)

@UlrikeFischer I guess I'll have to test properly: one for this evening :-)

@JosephWright If you have free time ;-). But imho there are more interestings things to do.

@AlanMunn I looked at it at one point. I remember I was disappointed, but I can't remember why. It didn't seem like a good alternative to current solutions. However, this was a while ago so possibly whatever it was I didn't like has improved by now. (It had something to do with the amount of work you'd have to do to make minor style changes in terms of duplication/repetition. Simple rather than powerful/flexible/quick. If I remember correctly, which I might not.)

@UlrikeFischer Indeed

@cfr probably I'm the wrong person to ask as I'm probably one of the first other than Frank and Rainer to use doc format (now dtx:_) so been doing it so long..

@UlrikeFischer I'm drafting an email on one such exciting topic!

@JosephWright ??

@cfr There's nothing to stop you simply putting comments into .sty files (the need to strip comments for fast loading is historical)

@UlrikeFischer @JosephWright Yes, indeed. My question was one of idle curiosity to see whether anyone had already done some investigations.

@cfr There are several alternative formats, e.g. gmdoc, or you could roll-your-own (depending on what you feel is useful documentation-wise)

@DavidCarlisle Hmmm. Just because you mentioned using regular .tex files for manuals. Is that why it is called doctools etc.?

@UlrikeFischer Case changing and the questions that come up from Greek

@cfr oh apparently there is something called doctools, not sure what it does

@cfr Yes, it does look simple in a way, although that might also be its downfall.

@JosephWright This is what I do. I didn't really think about the speed, even though I know that was the reason for .dtx. But my question is more about something to use to conveniently format macros etc. for a user manual. I don't like typeset source code anyway: I find it much easier to read commented source than typeset source.I don't want to put the manual in the .sty file (or the .dtx file or in with the source at all).

@DavidCarlisle Yes. I didn't understand the doc bit until your comment.

@cfr OK, so use ltxdoc as your document class but don't bother with the DocStrip side of things

\documentclass{ltxdoc}
\begin{document}

\DescribeMacro{My-macro}
See how this works without the |.dtx| format.

\end{document}

@cfr ^^^

@AlanMunn That was my conclusion precisely. So to make some small formatting change, as I understood it, you'd need several lines of code for each kind of source. Then if you wanted to tweak it, you'd have to tweak the code specifying the format for every affected kind of source. Simple in the way that constructing Stone Henge by moving the rocks on timber rollers is simple....

@cfr :D

@JosephWright Oh - that's possible? I thought ltxdoc went with dtx so I couldn't use it for a regular .tex-type manual.

@UlrikeFischer Thank you, works perfectly.

what is the default shape in tikz-cd?

@JosephWright Thank you.

@cfr All that happens normally is that you arrange to input the file such that the leading % is ignored on each line. But that's not a requirement.

@UlrikeFischer if I do cells={nodes=draw}, I see rectangles, but the above error persists. Strange...

Hi!

@UlrikeFischer I can forward the mail if you are burning to know!

@LaRiFaRi Why not this?

\documentclass[margin=10pt]{standalone}
\usepackage{tikz-cd}

\begin{document}
\begin{tikzcd}
\rule{1cm}{1mm}
\arrow[xshift=-3mm]{d}
\arrow{d}
\arrow[xshift=3mm]{d}
\\
\rule{1cm}{1mm} \end{tikzcd}
\end{document}

@JosephWright Yes, I'm always curious (and if I guessed right that it is about the greek hyphenation in luatex I'm also involved)

@UlrikeFischer OK, will forward

@LaRiFaRi the default is the asymmetrical rectangle

\documentclass{article}
\usepackage{tikz-cd}
\begin{document}

\begin{tikzpicture}

\node[asymmetrical rectangle,draw](a) at (1,0) {\phantom{\rule{4cm}{3cm}}};

\foreach\x in {0,10,20,...,350}
{ \draw[blue,fill] (a.\x) circle(1pt);}

\end{tikzpicture}
\qquad\begin{tikzpicture}

\node[rectangle,draw](a) at (1,0) {\phantom{\rule{4cm}{3cm}}};

\foreach\x in {0,10,20,...,350}
{ \draw[blue,fill] (a.\x) circle(1pt);}

\end{tikzpicture}
\end{document}

@UlrikeFischer Three mails forwarded. (There is a hyphenation part to the same thing, but I'm yet to properly pursue it from the comments in xgreek)

@JosephWright you might even get a reply if you forward them to @UlrikeFischer :-)

@DavidCarlisle oh I see what you (he) did here :)

@Alenanno Thanks for your suggestion. But my MWE was just a setup in order to show some behavior I could not understand. The shifting would make much more sense here, indeed.