There's a nice discussion of rubber on the TeX.SE blog.
Quoting the post, which in turn is quoting the man page for rubber:
rubber “is a wrapper for LaTeX and companion programs. Its purpose
is, given a LaTeX source to process, to compile it enough times to
resolve all references, p...
Some features on TeX.SX are time-dependent. For example, voting and comment editing. The bronze critic badge, however, does not fall under such time constraints. It is awarded immediately after you issue your
However, reversing this down vote (within the given time limit) does not reverse the ...
*(with apologies to Lennon/McCartney)* I ain't got nothin' but love TeX 8 days a week, 8 days a week I write packages 8 days a week is not enough to write my code!
Speaking of the above question, I think I am going to write a blog about it. Even if you don't answer the question, could package authors please leave me a message in chat about what their motivation is. Thanks!
@PauloCereda Nope :). The technique he used for xesearch is clever, abusing XeTeXinterchartoks. I believe that it could be coupled with l3regex to do full regex search on every word in the file. But that would become very slow.
Ugh, I'm writing two different emails (stopping in the middle of words), plus posting here, and reading some websites. Not gonna work.
@BrunoLeFloch I'm not sure developing an entirely new kind of regex is a good use of time! I'd hope that regexs have a use in areas of TeX programming that are string-like, such as the classic matching-a-number or making simple changes to something which approximates to 'text'.
@JosephWright At the implementation level, most of the code would be shared. And at the syntax level, probably most things can be shared as well. Just adding a couple more escape sequences to match tokens with given catcode rather than charcode.
@BrunoLeFloch I was thinking more that regex use is already complex (at least for me), and adding additional ideas won't necessarily make things more usable
Unrelated: ^^A gives the character number 1 in all engines, ^^^^1234 gives the Unicode character "1234 (hex) in XeTeX and LuaTeX. How do you get values > "FFFF?
@PauloCereda What does it consist in?
@JosephWright Meh... Regexes are easy :). Well, not always, but many programmers are used to using them. I had never used them before coding l3regex, to be honest.
@BrunoLeFloch I'm planning a code snippets manager app. I'd love to add syntax highlighting to some languages, including TeX. But I was struggling with the grammar to make it work. :)
@BrunoLeFloch Well yes, but we are talking about programming TeX, and this is not the same as programming in other languages. (I'm as always worried about getting distracted from the key questions by interesting-but-not-widely-applicable questions)
@JosephWright I guess my worry is that trying to use regexes when the input is really token lists is just wrong. It's one thing that makes passing material back and forth from Lua to TeX quite awkward.
@PauloCereda If your parser is good, it should be able to handle that.
You just need to run TeX on the input with \tracingall, omitting undefined macros, and parse the log. Piece of cake ;-)
@BrunoLeFloch Okay, but does not mean you have to allow the regex to match by catcode. It means you want the match to pick out characters in a catcode-insensitive way.
@Seamus Bruno's expandable case-change can do that anyway, I think
@BrunoLeFloch That was my conclusion, but it does not seem to be in the LuaTeX manual (XeTeX is poor in this regard anyway - documentation not easy to find)
I know that \setkomafont is supposed to deal with switching fonts but sometimes instead of switching font, I'd like to switch to uppercase. I've not found a way to do this reliably. This breaks:
\documentclass{scrartcl}
\setkomafont{title}{\normalfont\uppercase}
\author{A. Author}
\title{The tit...
@PauloCereda :). The best would be that you implement all of TeX's category codes. Then the user can specify which catcode table is in use (e.g., iniTeX, usual, usual + @=letter, LaTeX3,...)
@JosephWright Yes, although xetexmain.pdf seems quite good (didn't read carefullly).
@JosephWright No. The problem with case changing is that either you expand the user's text before case changing (as \MakeUppercase does), or you don't (as \uppercase), possibly with some extra mappings, but in both cases you'll make people unhappy. All I did is to provide some expandable case-changing functions for ASCII input only, and they have the good feature that they go through braced groups, preserving them.
@Seamus I doubt it. The main problem you have is that you don't have the title directly as an argument to a macro. It would be much easier to perform transformations on the title if you could grab it reliably.
I'll try to think of a way to hack XeTeXinterchartoks as zappathustra did in xesearch.
Would redefining titles with, say titlesec offer a better way of getting consistently uppercase titles? (that work in tables of contents, marks and so on…)
If it is the case that there's no easy way to do this, it seems a strange lacking. Since this is a kind of typographical signposting that gets used a lot, it's weird that it's so hard to do in LaTeX…
@Seamus I've used in before, but would have to look at this in more detail. If it's easy I might come back with something, otherwise I guess I'd rather concentrate on getting a 'real' LaTeX3 solution sorted
@Seamus It comes down to the fact that case is not treated as part of the font
I'd imagine it's easy enough using OpenType features
How to massively fail at being productive: "Today I'm writing about probability. I wonder if I could make a section number counter that outputted the number as that number on dice…"
4
Turns out, you can. But now I've not written the paper.
@JosephWright Re "\c{pm} to match the token \pm". When you say that "that would do", is it that you think I'm making my life more complicated than needed? I'm open to discussions, as I am conscious that I tend to err in what to implement.
@PauloCereda But I think you can get it to work with arbitrary catcodes :). Beware: some on the XeTeX list proposed to increase the number of available catcodes to 256. Not sure what they'd do with all that space, but it does mean that you need to highlight correctly.
@BrunoLeFloch I mean that what is useful from a TeX POV is being able to deal with text which contains 'simple' macros, for example accents of the \c{c} form. For pdfTeX this is important, for UTF-8 engines less so although something like a number 1.23 \pm 0.03 seems reasonable as 'string-like' even with one of the latter engines.
It's all about use cases. For me, the most obvious ones are basically string manipulations, but some tokens do need to be allowed
@JosephWright Sorry, I'm not parsing your sentence fully. It seems that my proposed escape sequence would work for the use case you describe, no? Then there is the question of left and right braces, which may be a little tricky.
@PauloCereda With all the RTL<R trickery? Normalization? Line-breaking? (Yes, I'm trying to break things.)
@JosephWright I'm partly confused because of your choice of \c{c} which is both a valid escape sequence in what I propose (\c), and a reasonable TeX input (c-cedilla).
@BrunoLeFloch Sorry if I was not clear. There are two obvious cases for me (having used l3regex a little). First, you might want to match input where you anticipate a particular token, let's say \pm. Thus it would be useful there to have an easy way to specify the token.
Secondly, you might want to parse 'text' which can contain accents, where detokenization will loose this information and potential introduce 'spaces' into words which will then confuse any attempt to separate things out
@BrunoLeFloch I'm not actually quite sure at the moment! I can see the use in a case where you're worried that tokenization makes a difference: \pm could be the token \pm or the token \p followed by an m (okay, unlikely but possible).
@JosephWright I'm not thinking of using \detokenize anywhere. Rather, a ted-like analysis of the token list on input, converted to charcode+catcode pairs, and to csnames.
What's more of immediate relevance is that the current approach in l3regex detokenizes, adding spaces in as a result, and it's those that are more of an issue when you want to write a regex
To match the single token \pm, you need either \c{pm}, or \c{p.*}, or \c{..}, etc.
@JosephWright Yes. The tricky thing will be to make it interoperate nicely with the rest. E.g., one can reasonably hope for \c{.*}* to match any number of cs tokens.
Also, the conversion token-list => charcode-catcode pair is not trivial to do fast. Is it reasonable to put a hard limit of 32768 characters in one given string?
@BrunoLeFloch I'd say so - we are back with use cases again, and what is really sensible with TeX
So far, cases I've come up with are one or two lines of text. Even if we are talking about data from an external file, I'd expect to deal with it line by line.
@JosephWright I guess those sites must be every Moderator's nightmare! Since Spanish.EX is a newly born site, I wouldn't expect too much problems ;-) (Well, if I really become a pro-tem.)
@JosephWright Loved you're phase about the difference between Turing-complete and omnipotent, by the way.
@JosephWright I think that there are two things that make this an easy site to moderate. Almost all of us a academics of some sort or other and in principle we have better things to do. Secondly, there are almost always very objective means of evaluating answers. On many other sites, one or both of those conditions aren't met.
@GonzaloMedina Nice answer on ser and estar, by the way. I think I mentioned to you before that our lab is looking into how kids acquire this distinction.
Even in cases where it's not clear, we've not got contentious closed questions. For example, some Emacs stuff is borderline, but the questioners for these do seem to realise this
@AlanMunn: Do the term model verb exist in English? (With the meaning of a verb whose conjugation is used as a model for the conjugation of similar verbs).
@GonzaloMedina Not really, since we really only have 1 very type and a bunch of irregulars. There are some sub-regularities, but there's no equivalent of the -ar/-ir/-er classes.
@GonzaloMedina I think I just was looking at the popular questions list for the overall site when I saw the ser and estar question and I looked at it since I know quite a bit about it. I won't generally look at it. Everything I know about Spanish is actually filtered through Portuguese.
@GonzaloMedina Yes, but the problem is that when it comes to language, everyone thinks they're an expert, and then the professionals just get frustrated and leave (or in my case never even arrive.)
@AlanMunn: I remember a conversation we had about cardinals sometimes having two different meanings... but I can't remember exactly the details... (well, perhaps I don't even remember if that was the actual topic). Do you remember that conversation and the precise topic?
@GonzaloMedina Yes, we definitely talked about that. Maybe I didn't mention the ser and estar stuff. It's really hard to test, since neither verb is a subset of the other and the choice is very dependent on context.
@PauloCereda I like him. While I don't agree with all of its choices, he's a fine musician and has his own ideas. A famous Italian journalist said: "Better a bad temper that no temper at all".
@BrunoLeFloch: I decided to take another approach for the (La)TeX syntax highlight, since the editor should support several languages. Now you gave me an interesting idea of a "smart" (La)TeX editor. I'll inspect my automata and try to come up with an adaptive grammar to support catcodes and other tricks. :)
Think of a editor which can change its own behaviour based on the user code. I'm also thinking of a safe checking of names, commands, expansions, even possible traps. :)