@PauloCereda Very good. Went to see an old friend last night and we chatted for four hours. Which is maybe not strange cause we'd not seen each other almost ten years! It was very nice :D
@JosephWright just because the l3prop module has \prop_set_from_keyval:Nn, but not \prop_to_keyval:N (which could be implemented expandably, returning in \unexpanded).
@JosephWright Potential use case: Manage stuff as a property list which should then be parsed as a keyval list by another keyval solution (e.g., managing a TikZ style with expl3, but then passing it on to \pgfkeys).
@JosephWright also, currently \prop_set_from_keyval:Nn can't be used to parse user input after \begin{document} (if comma or equals sign are active). I didn't benchmark this, but instead of implementing \__prop_from_keyval_loop:w one could just use \keyval_parse:NNn to populate the property variable. (I think this might imply a slight performance hit, whether the increased robustness is worth it I'm not sure, after all property lists are meant to store programmatic information)
@Skillmon it is only a small wrapper around \prop_map_function:NN, but it could be useful. The main question is if it should be \prop_to_keyval:N, or \keys_set_from_prop: ;-)
@UlrikeFischer the former to allow other key=value interfaces to be used, imho. I already have an implementation, which takes 39 lines (actually 17, but currently I use two separate implementations if \expanded is available or not, doubling the effective lines of code, plus 5 lines for the conditional)
@UlrikeFischer my implementation expands after two steps of expansion and returns the result inside of \unexpanded.
@UlrikeFischer the most important thing to note is, that my implementation reverses the prop, since they are documented as unordered this seems ok, but it should be noted, as there might be use cases in which the order of keys matters (looking at the image manipulations of graphicx for example).
I could change that behaviour to not reverse the output fairly easily, I think, the result would be a bit slower.
@Skillmon well the keys-module could declare a "key-val" variable type, a tl-var or a direct output which contains the key-val-list and then the keys function could fill this and other implementations could use it too. So it is more the question in which module it belongs more.
BibLaTeX question: How can I avoid shortening the author list in the reference list, but do shorten it in author-year style citations?
I'd like the ref list to contain A. SMith, B. Brown, C. Green, D. Buttle, E. Tuttle, Big important finding, Fancy Journal, 1999.
The citation in the text should stay as [Smith et al, 1999].
Never mind, maxbibnames
I do have another, somewhat weird question: Is it possible to modify the formatting of just one reference out of many? I would effectively like to have minbibnames=2 just for one reference, but keep minbibnames=1 for the rest.
@UlrikeFischer added braces? You mean around the value? Yes, that's quite important. The thing which might need explanation is the space before the opening brace of the values :)
@Szabolcs maybe it is a good idea to ask this as a question on the main site. It seems like something future visitors might be interested in as well!
@Skillmon I thought it might be considered a ridiculous request to want to format just a single reference differently from the rest (there is a very good use case though...)
@Szabolcs if you have a good use-case just include it as a short note in the question, I'm sure the community will understand and not mock you for wanting it in the first place :)
I'm using the authoryear style in biblatex with the following options name length options:
maxcitenames=1, mincitenames=1, maxbibnames=999, minbibnames=999
So citations (usually issued with \cite) are properly typeset with only one author like
Shakespeare et al, The...
However I want to...
@Szabolcs The general idea is to use \AtNextCite and temporarily change the maxnames counter. (See the second answer, not the accepted answer, and not mine).
@Szabolcs It's much easier to search for an answer than a question, which is why it was easy for me to find. I knew the answer, and just searched for AtNextCite. :)
@PauloCereda Apple is unlikely to contribute ... Recently they seem to be saying, "Do it the Apple way or go away!" Think making CUDA impossible to use (no NVIDIA drivers on newer macOS), abandoning OpenGL and OpenCL ...
Big companies like Adobe may be able to afford to support Apple-only technologies like Metal. Open source projects (most of the scientific stuff) simply can't.
@Skillmon That is actually not a problem. Apple ships a BLAS and LAPACK implementation as standard with macOS (see vecLib). Actually, most performant BLAS and LAPACK implementations are not written in Fortran. Only the NetLib implementation is (but that one is slow, it's just a fallback when there's nothing better)
@Szabolcs Yes, although I think the R community is broader, and therefore likely has more people who might be affected. It's certainly true in my corner of the world.
It's better to think of LAPACK as a semi-standardized API than a library (the Fortran library is the NetLib one). It is a Fortran API, but it's callable from C. Basically no one uses NetLib lapack
OpenBLAS is a very common open-source implementation of both the BLAS and LAPACK APIs. MKL provides another (commercial one) and may other things. Apple's vecLib yet another one. As far as I know, none of these are written in Fortran.
But maybe I am getting details wrong. I also learned this only this summer.