Friends, a silly question. Let's say I have to typeset some text starting 2cm from the left margin. Should I go with \hspace{2cm}\begin{minipage}... or is there a better way of achieving this?
@PauloCereda Don't know about better, but some alternatives are the adjustwidth environment from changepage, and addmargin from scrextend/KOMA-classes. tex.stackexchange.com/q/35933/586
@PauloCereda use an enviroment like \begin{quote}..\end{quote}` that is the same (one line defn in article.cls) but just sets \leftmargin not both margins. (or there is a package who's name I forget that provides an environment with arguments that does exactly this)
@UlrikeFischer, @egreg the new kernel allocation scheme allows you to have 18 \newinsert plus however many you use before the classic count registers run out, but it turns out that reledmac uses 20 and if you load it after biblatex it dies if it is "updated" not to do \RequirePackage{etex}\reserveinserts{32}. Tempting to say just load it earlier (or re-write it not to use 20 \insert classes) but I have a version of \reserveinserts which I'm contemplating adding to the format so it can ..
.. do \ifx\reserveinserts\@undefined\RequirePackage{etex}\fi\reserveinserts{32} and work in the new scheme without loading etex.sty. But as you see above getting useful comments from team members not as easy as you might think..
@JosephWright So can I, That's why I was canvassing for opinions. But generally I think not breaking existing documents (even if they are not really sensible code) is a good plan.
@JosephWright that (was) the lualatex.ini plan wasn't it?
@DavidCarlisle I suspect that with a modern system even with pdfTeX/XeTeX the efficiency loss is not worth worrying about when moving to the extended pool, so I am not entirely joking
@JosephWright Yes I did consider that, but basically that seem like using something like \reserveinserts{100} (built in) which seems odd, or at least encouraging odd behaviour:-) although as you say I doubt any time/space costs are really measurable these days
@JosephWright and of course it still doesn't help documents that have \reserveinserts in the document which stop working if expl3 or memoir or reledmac stop loading etex.sty
@JosephWright true although my main concern about adding any command to the format is \ifx tests doing something different, so even a no-op has that worry
@DavidCarlisle Like I said, mainly not serious (though I do wonder for a LaTeX3 allocator if we should think about this: probably we won't expose a way to make inserts at all)
@DavidCarlisle Yes, I was thinking mainly 'it is pretty tricky to imagine a sensible test'
@DavidCarlisle I see @FrankMittelbach has appeared: you can bother him :)
@JosephWright at least it's not like \mathchardef where there are syntactic restrictions on keeping the original range, all the syntax to refer to an insert uses an arbitrary <number>
@JosephWright From a code perspective it is eminently sensible but from a user perspective people are going to expect lowercase of arbitrary utf8 input to work in pdlatex. Although I suppose as long as things are pre-expanded to LICR form it should work in most cases
@FrankMittelbach Do that first. And Happy Retirement!
@FrankMittelbach That was my thought initially, it may be if we just fix reledmac it'll never come up again to be needed, perhaps. (need to make it not use \newinsert for minipage footnotes) but just defining \reserveinserts is simpler.
@DavidCarlisle the only way I can think of doing that (as long as inserts need to stay below 255 is that one could keep a proprty list of allocations and shift registers up whenever inserts move into used spaces (not really very performant etc and probably a bit complicated but it feels wrong to me to reserve them
@DavidCarlisle it isn't going to be one really as you know :-)
Q: How many psychiatrists does it take to change a light bulb?
A: Only one, but it takes a long time, and the light bulb has
to really want to change.
[paulo@cambridge ~] $
@DavidCarlisle It doesn't sound like a bad idea to leave the pool to the inserts - separating the fighting camps ;-). But as I have no idea about the cost and the side effects ... From the view of support I would be interested that if an document dies, it dies with some identifiable symptom and that there is some not to difficult work-around like "add \handlereserveinsertsproblem before \documentclass"
Here is a big post about new documentation project: Warlords of Documentation: A Proposed Expansion of Stack Overflow
I think, that LaTeX doesn't have good online documentation, almost everything is in pdf and is not structured very well. To search something about tikz I have to open the big pdf...
@JosephWright seems a bit strange to me, especially the comments from SO staff saying they want to be the main doc "for everything" here at work for example we spend often years developing and proof reading the documentation for a new routine in parallel with the development of the code. Moving documentation to be completely separate from code development has lots of dangers it seems.
@JosephWright I suppose it depends if they mean by "documentation" something like the official language or API spec, or being more of a competitor for an O'Reilly animal book on the same language. It's probably true that more people would currently use such a book that use an official language spec.
@JosephWright yes I noticed that, we should fix, it's an artifact of concatenating the ps files for all the routines with some minor perl cleanup then distilling. We should remove the individual pdfmarks setting document properties...
@JosephWright although perhaps going forward we may just concentrate on the html version, now browsers can mostly make a plausible job of printing the mathematics in the pages.
@JosephWright (1) People mix "user manual" and "documentation". These are two very different things. (2) Stepping in a project that does not seem well thought out sounds like anything but a good idea. (3) Do we want people at SO who have often very stupid LaTeX habits themselves to produce documentation and use examples for anything LaTeXy? The internet is flooded by these, and people look at them rather than open the documentation, which is in most cases quite OK.
Couple thoughts.
People mix user manual and documentation. These are two very different things. Every LaTeX package that makes it to CTAN has to be documented, at least to some extent. Most packages are documented well, using docstrip or similar tools; however, this is often the technical docum...
@JosephWright From the discussion of a few days ago (nothing important, just a doubt) \def\increment#1{\edef#1{\noexpand\the\noexpand\numexpr\the\numexpr#1+1\relax\relax}} and then \increment\foo would make the “integer” \foo self terminating, wouldn't it?
@Manuel Difficult to handle coerced values, \relax is there even in cases where you don't want it (for example, if you did \ifnum\numexpr#1\relax=\numexpr#2\relax where #1, #2 could be either stored values or 'raw' numbers)
@Manuel Also there's a performance hit: TeX has to re-read the value (and thus 'find the end') when used, whereas stored in a register it doesn't
@Manuel I don't know, but if I copy the last \relax from your code sample and paste it into r12a.github.io/apps/conversion, clicking on “convert” shows \rU+200C U+200Belax
An L3 question: assume we have a sort of data where a main key name will have several data items associated with it. How is it most convenient to store this data?
To be more precise: Assume my test project playing with fancyref: say I have the prefix thm, then I'd like to store things line title cased name, lower case name, title cases short name, lower case short name, etc. I can store this as say \tl_set:Nn {data-thm-tc}{Theorem} etc, this gives fast access to the data.
Alternatively property lists.
But they seem to have overhead in retrieving the data.
@Manuel If you remove that there is no point in having the two numexpr, the outer one only does anything useful if you \noexpand the \the (or don't have \the at all). Oh I see you said that, remove noexpand and the, OK.
@daleif If property lists seem a little big, you could create your own “interface”. Wether it's with \tl_gset:cn { g_data_ #1-#2 _tl}, or with a \tl_case:NVTF function and pairs of {tc}{Title cased name} {lc}{Lower cased name}.
@Manuel It is basically the step: \prop_get:NnN \prop_list {key} \l_tmp that annoys me be bit. As far as I can see I need to retrieve the key first, and then I can insert it where I want it. just seems easier to use \use:c {data_ #1 _tc}
@Manuel I thought you meant \def\increment#1{\edef#1{\the\numexpr\the\numexpr#1+1\relax\relax}} which isn't very useful but I see you meant \def\increment#1{\edef#1{\numexpr\the\numexpr#1+1\relax\relax}} which is OK, although probably it is better to make your arithmetic operators wrap their arguments in \numexpr..\relax rather than make every numeric variable carry that wrapper
@daleif We may yet have to think again about prop implementation (currently the design was about saving hash table names, although mapping/copying is also easier with a single token than with a linked list)
@daleif Indeed: for siunitx I've used a prop for units and one for numbers in v2, but for v3 plan to use a dedicated (rigid) structure for numbers, sticking with prop for units
@Manuel \str_case: has to be 'hard coded', and gets slower as the number of cases grows. For speed the hash table approach is always going to be fastest for random lookup: I'm not so sure about iterating.
@egreg well, if I understand the description in the user profil right it sounds for me to be spam. But it is of course possible that I missunderstood that. That's the reason for my question here.
@barbara from what I view, the idea behind the Warlords of Documentation is to ... provide documentation. Currently, the loose statements about what is meant by that seems to imply that it could be a lot about example, but to me it seems that ... nobody knows. For giving examples, Q&A work better I think. The effort that could be put into this new project can be also put into improving questions, closing dupes, providing better canonical answers etc.
@yo' -- "nobody knows". well, i do agree with that! (on the other hand, i am frequently distressed by what i see as "accepted wisdom" promulgated in places that are found by google searches. i think i know enough to recognize when something is a bad recommendation, or at least that i ought to double check it, but not everybody is as cautious -- or is that cynical?)
Friends, could you give me an advice on how to properly include this technical report in my .bib file?
It's an article by Hopcroft, called An n log n algorithm for minimizing states in a finite automaton. The ACM library gives me this:
@techreport{Hopcroft:1971:NLN:891883,
author = {Hopcroft, John E.},
title = {An N Log N Algorithm for Minimizing States in a Finite Automaton},
year = {1971},
source = {ncstrl.org:8900/ncstrl/servlet/search?formname=detail\&id=oai%3Ancstrlh%3Astan%3ASTAN%2F%2FCS-TR-71-190},
publisher = {Stanford University},
address = {Stanford, CA, USA},
}
But the title thingy looks immoral to me.
Does title = {An $n \log n$ Algorithm for Minimizing States in a Finite Automaton} look wrong?
@PauloCereda -- have found a scanned copy of the cs report via google (well, sometimes it works). the thing was typed, so is subject to all the deficiencies associated with that. on the cover, everything is uppercase, but on the first page of the body, the "n log n" is all lowercase in an otherwise all uc context. so your interpretation is (i infer) exactly what the author intended.
@yo' -- i would use math. in my youth, i was a technical typist. us tech typists did the best we could, but gee, tex makes it so much easier to get understandable results. if the author of this report could have had it typeset, that would have been set with the "n"s italic. (further down on the first text page is a truly pathetic "n^2", by which i mean the platen was rolled down a half space, and the 2 typed in that way. sigh.)
@yo' -- take another look at the scan of the cover page. would you preserve the spaces you see there in "F I N ITE" ? sometimes you just gotta do what you know is right!
@yo' -- true. i remember typing (for other grad students) theses that required 5 carbons. a mistake was disastrous! (fortunately, by the time i got around to typing mine, the powers that be had decided that photocopies were acceptable.)
But I also have a much easier task, for which Internet users can be particularly helpful. I try to make the indexes to my books as complete as possible, or at least to give the illusion of completeness. Therefore I have adopted a policy of listing full names of everyone who is cited. For example, the index to Volume 1 of The Art of Computer Programming says ``Hoare, Charles Antony Richard'' and ``Jordan, Marie Ennemond Camille'' instead of just ``Hoare, C. A. R.'' and ``Jordan, Camille.''
@barbarabeeton ah the cc. I remember someone from "the West" coming here early in the 90s, not knowing what the carbon paper is (knowing only the copy machines) and saying "Oh this is so cool, you don't have to go to the copy machine!"
@PauloCereda I should try to find the full names of the two Marseilleian people in DEK's list, in order to get his chèque!
@yo' -- oh, dear! it was messy stuff! (the analog is still used as "dressmaker's carbon", with two-sided coating. it's really hard to mark seam and hemlines any other way, short of poking holes in the fabric.)
@yo' -- golly, i don't usually select the implements before the recipe. (obviously, though, it needs to be something that needs to be measured.) well, rice is easy to measure in the "dry measure" cups. some nice broth in the "liquid measure" cup. you don't really need to measure onions or carrots that way.
Couple thoughts.
People mix user manual and documentation. These are two very different things. Every LaTeX package that makes it to CTAN has to be documented, at least to some extent. Most packages are documented well, using docstrip or similar tools; however, this is often the technical docum...
