@egreg @Joseph Three reasons I didn't go for the predicate approach: (1) Doesn't work for non-expandable tests, even though the sorting code doesn't care. (2) I don't find the matching between TF and ordered/unordered to be obvious, in particular with regards to equality cases, where you may want stable sort: shouldn't sorting 1,01,--1 in non-decreasing order give the same clist on output? ...
(3) In the context of sorting an index, you may want a third option: discard the new item.
Actually, (3) can be generalized to keep track of page numbers in the index, too, but let's not get into this for now :).
The second choice that was proposed is to use a TF test. It only solves (1), neither (2) nor (3), so I'm not keen on it. The obvious drawback of the syntax I proposed and implemented is that it is unusual, and doesn't blend too well with the rest of LaTeX3.
@egreg: I voted to reopen that meta question because I felt that it should not have been closed. It was a legitimate addition to the debate and the original question had been tagged "status-declined" so whilst it could have been added to the original question, that might have been confusing (this is one of the limitations of having meta on an SE-style site instead of a proper forum). I also did not like the "just deal with it" part of the answer (now edited out) ...
... as it smacked of a "We know better than you so shut up" attitude that I do not like to see. I think I've made my views plain on SE mods coming in and "moderating" without getting a feel for the local way of life. Anyone who'd spent any time here would have realised that we do have a tendency to get obsessed by small details (microtyping, anyone? kerning in the TeX logo?) and the way to deal with that is not to say "Grow up" but to listen and then explain why it's not going to happen.
The first question was dealt with properly in this regard: it was declined, but declined politely (I felt). The second then pointed out a discrepancy between the sites, which wasn't touched on by the first and - to some extent - invalidated the declination of the first. Closing it without showing an understanding of that distinction was, for me, a hasty action and one that I would have preferred not to see. So I voted to reopen "on principle".
(Bizarre linguistic note: I've just realised that the English idiom "That smacked of ..." almost certainly has its roots in Norse, where "smake" is the verb "taste", as in "det smakt godt" - it tasted good.)
@AndrewStacey I just wrote a comment to Aarthi's answer
@AndrewStacey and I agree with your view on how the SE mods handled this. Seems like they first did not listen and declined without a thought and then realized they were wrong and reopened. Could have just listened and given it a thought to begin with rather than exercising power.
@BrunoLeFloch Reasonable arguments. Barring objections, I'll move l3sort to the 'release channel' l3experimental, which will then give us the chance to get more feedback
@JosephWright Fine. I have at least 5 alternative implementations to the current merge sort, but all of them have the same user interface, so we're safe to move to l3experimental. Not l3kernel yet at all, though.
@JosephWright Browsing through old questions, I see that Will had a way to use kpsewhich to get access to the max_print_line variable holding the length of one line in the log. Currently we hardcode it in l3io (or l3msg?). Should we use his code instead? tex.stackexchange.com/a/3647/2707
@BrunoLeFloch No, clearly not. My feeling is that (almost) everything we add should go vial3experimental, at least for 'a period'. (I may make an exception to some direct translation of LaTeX22e code: for example, I keep meaning to sort out graphics, and that would be I hope very straight forward.)
@BrunoLeFloch No: we can't assume that we can access this!
As Will notes, it will fail if shell escape is not enabled
Right. I haven't followed carefully some of your recent additions. I guess my next few steps are:
Finish cleaning up l3regex to a point where it can go to l3packages (I think l3flag=>l3kernel, l3tl-analysis=>l3kernel (perhaps l3tl), l3str=>l3kernel and l3regex=>l3packages);
Read xparse's implementation carefully and test it devilishly, perhaps adding the nicer-runaway-arg we discussed useing special-catcodes delimiters;
Try out an idea I have about a "more expandable" `iow_wrap` command, based on some tools from l3str;
@TorbjørnT Nitpicking is definitely allowed! One of my difficulties with learning Norwegian is that no-one nitpicks mine. I find that people rarely even suggest a word if I use an English one because I (clearly) don't know the Norwegian.
@BrunoLeFloch All sounds fine. I'd hope that xparse is 'done', more or less, apart from the messages. l3coffins all works, but of course performance enhancements would be nice. As I keep saying, l3fp revisions, if they are to happen, need to be sooner rather than later (it can't wait a couple of years for us to go 'oh, we'll change the interface')
@BrunoLeFloch I'd imagine l3regex can go into l3kernel. The logic is supposed to be that l3packages is 'higher-level' stuff, and is more tied to LaTeX2e. If we plan to keep it as-is for a stand-alone format, it can go into l3kernel. Obviously, that requires some feedback from the rest of the team
This is now fixed. On the right side of http://tex.stackexchange.com/questions/ask there appears a note on how to ask question:
Note that when the text area for the content of the question or the field for filling in tags gets focus other notes are shown. You can get back the "How to Ask" note...
My response to your comment is: don't mark it as "status-completed" until the "How to ask" box actually makes sense.
@AndrewStacey I'd hope not: 'can we have a how-to-ask' and 'what should the how-to-ask say' seem to be distinct to me. In the first instance, you could ask marked as discussion, so the Powers That Be won't worry about it. Once we have a better text then we can ask for implementation.
As N.N. notes in his answer to Can/should we get a “How to Ask” page?, there is now a "How to ask" page and it is linked from a helpful-looking box on the "Ask Question" page:
I'd like this box made a little clearer and cleaner, if possible. The problems that immediately jump out at me are:
...
@PauloCereda I mean, if you'd only use TeX to draw them instead of Illustrator then they'd be fine.
At the very least, \documentclass{standalone}\usepackage{graphics}\begin{document}\includegraphics{my-latest-weird-drawing}\end{document} and there'd be no problem.
@PauloCereda I'm strongly tempted that every time I ask a question, I should include a link to one of my papers with the comment "The box says that I should show my research. Here's a paper on X.".
@JosephWright The l3fp revisions are most definitely happening this year. I'm keeping the very long term in mind, with stability of the l3fp results as an aim, hopefully by the end of 2012 unless bugs are found. We'll need to "fix l3fp in stone" after a while. You know how hard it can be to write a reliable fp module; here I'm trying to be (1) expandable (2) 16 digits accuracy (3) as fast or faster than your implementation, which means I must optimize pretty much everything. Tough, but doable.
About l3regex, I'm not sure. Obviously it's not tied to LaTeX2e, but it is 2500 lines of code, which is ~15% of the current kernel, for a rather specialized task. Seems like somewhat of an overkill perhaps. Similar in size to the current l3fp (and probably smaller than the future l3fp, although I hope I won't bloat too much there). Anyways, I guess we'll have debates on this somewhat soon.
@PauloCereda So far I've only done +,-,*,/,(,),ln, and parsing (plus unpacking registers when necessary). I still have trigonometric functions (sin,cos,tan,cot,tan2), hyperbolics (sinh, cosh, tanh, coth), arc-trigo (asin,acos,atan,acot), arc-hyperbolics (asinh,acosh,atanh,acoth), exponentials (exp,pow,sqrt), comparisons (<,>,=,?,min(x,y,z,...),max(x,y,z,...),abs(x),sign(x)), conversions (from binary, hexadecimal,...), misc (Gamma function, hypergeometric functions, the Meilin G function... [joking])
@PauloCereda Oh, and what about bitwise operations?
@JosephWright I think a reasonable plan for l3fp is to get trig, exp and pow to work with a similar precision as currently, do the swap, then I can work on better algorithms, more stable ones, etc for trig, and add the rest piece by piece.
Out of 'basically all of The LaTeX Companion' + TikZ + biblatex + siunitx (all for me absolutely essential for a full LaTeX3 kernel), I don't see the issue with l3regex. No one is likely to run out of memory with that amount of code: after all, many of us routinely load all of that and more
@JosephWright Well, yes, but the OR is more a part of (La)TeX(3) than computation, so I'm perfectly happy to "spend" 10k lines on the OR where I'd spend 2k lines on fp if that ws possible to shorten that much.
@JosephWright Yes, memory is probably not that important anymore. I'm just used to thinking in terms of the limits like "I can't sort more than 24k words, because I only have 32k registers", so 2k lines seems like a lot.
@BrunoLeFloch We need fp for rotations (that was why I wrote it) in the coffins module
@BrunoLeFloch I don't worry so much about these things: anyone wanting to go anywhere near the limits for sorting, etc., really should use another tool
I have no issue with keeping things short, but at the same time want to make sure that LaTeX3 avoids the 'now load packages X, Y, Z, ...' problems we see with LaTeX2e
@JosephWright I copied this in part from Heiko's approach, and from the fact that most users won't need any of the encodings. The format could be built including some of the def files without any problem.
Ack, I stupidly had pending changes to the l3sort directory (added some files). I'm going to try committing the deletion (that you already committed), I hope I don't break everything.
@PauloCereda I've seen a similar quote by someone who had written fuzzy regular expression matching: "Some people, when confronted with a problem, think 'I know, I'll use fuzzy regular expressions.' Now they have three or so problems."
@PauloCereda Well, yes, there is a point there. I do a lot of search and replace the old-fashioned way (read it myself) when my regex abilities give out :-)
TIL about Haskell Curry. This man as three programming languages named after him: Haskell, Brooks and Curry (first, middle, and last name)! Of course, currification is also named after him. en.wikipedia.org/wiki/Haskell_Curry
In Deus-Ex, I'm trying to play a run wherein the main character is a cruel, merciless cyborg who cannot distinguish between friend and foe. Basically, everybody dies.
Things seemed to be going well in the first mission, where one of my comrades greeted me after I annihilated the enemy's leader a...
Just followed the link in that. I am surprisingly impressed. I don't think it's good enough to actually use - it was easy to confuse it, but I was surprised that it wasn't trivial to confuse it.
@PauloCereda I was thinking mostly: if when you write a regex, you test it, just put those tests aside in a file, and send them to me once in a while with the expected results or the results you got (hopefully in a format that's parseable aka not random). Nothing more. I think slowly growing the test suite is probably the best bet there. In parallel, I really ought to take a perl or pcre test suite, filter out all the tests which use unsupported features, and run l3regex against those tests.
@LordStryker ABNT is an acronym (in Portuguese) for Brazilian National Standards Organization. They have one of the worst typesetting rules I've ever seen. :)
@lockstep Indeed, Jake was a great interviewee. :)
@lockstep: thanks for reviewing. :)
@BrunoLeFloch: Great answer about extracting first and last characters. If I had to say only 4 words to describe LaTeX3, I'd go with take all my money. Impressive! :)
@PauloCereda Thanks. The trouble is when we don't quite know what version of expl3 to aim for. I tend to forget what's from which version. After I get l3regex done (two weeks /me hopes), I really ought to go back through all of my answers on this site and check that they all run with the latest versions. In particular, I'll have to update the l3regex answers. And take a look at the xstring-related answers, to give them competition :-D.
@BrunoLeFloch I see. :) The code example are simply fantastic. I hope to get more acquainted with TeX from now on, so I could at least help with some tests or documentation; maybe even writing tools in Perl/Python/Ruby/Java/C, since TeX isn't in my utility belt yet. You could tag your answers with the release/build number of LaTeX3's modules you use. :)
@PauloCereda So LaTeX3 is supposed to crush LaTeX2? I haven't heard much about the upcoming iteration. I typically hear people say it isn't worth 'waiting' for. How is the backwards compatibility?
@LordStryker Eventually LaTeX3 is going to replace LaTeX2e. We're talking about a 10 years time period before the whole thing transitions completely I'd say. Frank and others would have more to say about how long it took for LaTeX2.09 to disappear. Our current approach is to build useful tools that can be used together with LaTeX2e, so nothing in l3kernel (aka expl3) is incompatible with LaTeX2e. It's just another package.
On the other hand, there is some work on the galley, fonts, and the output routine, which break compatibility, but those are not part of the kernel that is loaded as a package.
In terms of whether LaTeX2e documents will still compile under LaTeX3, well, if we don't achieve that, there is little chance that LaTeX3 will gain enough traction as a format. So we pretty much have to provide a compatibility mode at least. But many packages will have much enhanced capabilities, or a much simpler code, thanks to LaTeX3.
@LordStryker Bruno saved my life now. :) I wouldn't say crush, but we always expect things to evolve. Take Bruno's answer I mentioned before, LaTeX3 has a great approach to handle things. I'd say it's the future. :)
@BrunoLeFloch Thank you for the summary. The LaTeX3 iteration sounds quite exciting. Is a transition to occur in the near future or are we talking years down the road?
@LordStryker Frank jestingly proposed the end of 2012 a few months back I think. Given that I write at most 1000 lines per month, that I have l3sort (1000 lines?), l3fp (3000-5000 lines?), l3coffin (review: a month?), then some help to provide to Joseph for his much harder tasks of working on the galley and output routine, I'm booked for a year I'd say.
I'm hoping that we can get done before my PhD ends, so my hope is that 2 years from now, we will typeset the first (or not first) publication-quality documents entirely in LaTeX3.
@BrunoLeFloch Wow. I'm all giddy talking to a developer. Well I can honestly say that myself and everyone around here really appreciate the work you and others do. LaTeX is just plain awesome.
@PauloCereda Build numbers on answers are a good idea. (Potentially confusing. Dates may be better since I'm not pushing features just for the sake of an answer that often.)
@PauloCereda I'm not sure yet what we'll need you for, but I'm entirely sure that if you want to help there is some work :-D. Perhaps on providing plugins for various editors? I don't know whether it's boring or fun?
@LordStryker Thanks. I should say, though, that I've been in the LaTeX3 team only since May. Frank Mittelbach (also acitve on this site), our chief, has been working on LaTeX for 20 years!
@PauloCereda I'm starting to think about en.wikipedia.org/wiki/List_of_Greek_mythological_figures, which has a pretty long list. If we restrict ourselves to CTAN releases, then things can remain within reasonable bounds: Joseph tends to commit very 50-100 svn commits.
In the list of Greek mythological figures, there are 512 minor figures. If we use one for 50 commits (i.e., one per CTAN update), that's 25600 commits: 8 times the current number.
Should be enough.
@Paulo what do you think of writing editor plugins, e.g., for proper code highlighting of LaTeX3 code? Perhaps some automatic help; I've been pondering how to extract it automatically from documented sources. Do you think that would be boring, or interesting?
The numbers of votes and edits displayed on the Users page don't feature thousands separators at the moment. This is slightly confusing and inconsistent -- the reputation numbers do feature thousands separators, as well as the numbers of votes displayed on a user's profile page. Please add thousa...
@PauloCereda Great! I think you don't have to know any TeX to do that, "just" how to interface with the editor. We can get l3doc to automatically produce a csv file (or whatever format) with data such as the lines in the documented source where a given function is documented and defined. Then somehow let the editor query this database, and fetch the relevant lines from the doc. Those lines should then perhaps be typeset, or stripped from LaTeX commands and printed as is/...
@BrunoLeFloch I've stuck very much with 'use the latest version'
Ironically, we used to have a warning in the sources saying 'development is very fast' while not much was happening. We took it out (for good reasons), and now stuff is happening!
@PauloCereda I may yet be after you for some graphics at some stage!
@BrunoLeFloch You have to be careful what counts here as 'LaTeX2e'. Something using only documented commands from the user part of the kernel, yes; something using a load of packages and some internal hacks, no.
within used packages "xskak" and "chessboard" and an initialized game, how can I determine the count of white and black pieces of a given \newgame and how I can output the actual position of these pieces on the corresponding chessboard? I know that there is an argument of getpieceslist for \chess...
@lockstep (i) Heiko wouldn't need to ask (ii) I don't think Heiko is so concerned about titles. Just imagine if all of us here who could added Dr. to our user names...
I didn't realize it before, but it seems that we have a chat-room dedicated to us....so an obvious question is....
What should we talk about in the chat room? What is appropriate for that?
@JosephWright The problem with "use the latest version" is that some cutting edge functions get renamed, so the answer that was correct when the functions were added becomes wrong. So having a warning such as "if it doesn't work, please comment, I'll get back to that answer and fix it" may be good. In the case of the regex module, I think it can be a lever for a certain class of people to start looking at LaTeX3 more seriously, so I'd rather have the examples be correct.
@JosephWright Did I send many? You sent a ton, but mostly commits in a region I don't look at yet. Btw, I didn't comment on xmarks because I think Frank and you have a much better grasp.
@JosephWright Well, that part is implemented in l3trial.
@JosephWright Good. Actually, I was wondering: what's the plan for framed boxes (\fbox of galley stuff), with allowed page-breaks? Does it fit in galley? xor? Both? A style attached to each galley, which is consulted when typesetting?
@BrunoLeFloch Currently, we don't have anything about splitting galleys. That's not really what xgalley is about: it's primarily aimed at dealing with the issue you raised recently, that whatsits cannot be removed from the MVL
@BrunoLeFloch Read l3galley and see how it is all done :-)
Basically, you only add to the MVL when you are sure that a new paragraph has started. This means storing all of the information in data structures and catching when to add it.
@JosephWright ...Odd. I remain doubtful, although of course you know your stuff and I have very little clue about whatsits. I'll look at l3galley. After l3regex etc. etc. etc. :|
@BrunoLeFloch To get everything to work, nothing is added to the MVL at all outside of the galley: it's all added to token lists. The galley then adds the token lists to the MVL as appropriate. Of course, this means that we still need to address some details of how we insist that everything goes through the 'front door'
@BrunoLeFloch Exactly. As you say, you cannot remove whatsits, and that then means you can't remove anything added before a whatsit either.
We clearly need 'galley-aware' interfaces for things like \iow_shipout:Nn and \tex_special:D. That will not be programmatically difficult, and so it can wait until we need to address it and have some interface ideas. The key is to have the basics available in the galley system.
Quite unfortunate, that Knuth didn't add a kind of \unwhatsit, be it as a \setbox0\boxedlastwhatsit or something like that, to avoid having to deal with whatsits directly.
@JosephWright Do you think the 2 years time frame is a reasonable hope?
@BrunoLeFloch I'd hope so. I think I need 6 months to really sort the OR, then we need NFSS (which Will may sort). Then we need to bring stuff together and start on some basic structures (sections, lists), which is a minimum for a real document.
So say 12-18 months to 'format which can print something', then an additional 6-9 months for 'some real structures'. Then we have to worry about things like listings, bibliographies, ...
@JosephWright Ok, so my phd thesis is going to be in ttfamily, raggedright, raggedbottom, no formulas, no bibliography (after all, everything must be your own research, ain't it?), no code, no maths, since breqn won't be ported. Just a ton of regexes to change words into others for no reason. Seems like a good plan ;-)
Oh, and all caps since we probably won't have time to implement lowercase, digits and punctuation.
@egreg We need a switch for that, but what I do want is the way it deals with display: all math in breqn is inline from a TeX POV. That has several advantages.
@egreg I think automatic breaking at least when the line is clearly going out of the page is a Good Thing\textsuperscript{TM}. I keep receiving files from my supervisor/collaborators with equations that go overboard. So I have to break them. And if I'm not careful, I end up with differnt equation numbers./
We're definitely looking at this and I, at least, feel it is strongly on-mission.
However, it would be a major feature and will take (seriously, no really) 6-8 months to put together.
And of course there are other things we're working on, but just know that we think this is a great idea that so...
@Canageek I agree with egreg on \left and \right putting too much space, but I still think that automatic typesetting can make things much better there. The very hard part (which TeX totally nailed 30 years ago) is to have sensible defaults (now with better processing power, we an improve that), but remain entirely customizable when needed. Currently, breqn fails the customizability test.
@BrunoLeFloch There are parameters like \delimitershortfall that can be adjusted, but as all parameters regarding math they are unique throughout a formula.
The biggest problem in this respect is that there is only a limited number of sizes for the parentheses and one has to choose the closer one.
@egreg Right, but that is a general problem with TeX, isn't it? Are the sizes fixed throughout the document, or can you change some parameters between formulas to get different brackets depending on the formula?
I've got four macros now for typesetting fractions in text mode. The first writes them horizontally (shilling style, with a hyphen), the second writes them diagonally, the third writes them vertically, and the fourth chooses the style automatically based on the number of digits in the numerator a...
@BrunoLeFloch The parameters can be modified locally; for example $\binoppenalty=10000 a+b$ won't break the line after +, but other formulas would be unaffected. But if you say $\binoppenalty=10000 a+b\binoppenalty0+c$, then TeX may break the line also after the first+
@egreg I was wondering if the set of brackets used throughout the document is fixed, or if you can cheat TeX and use different brackets in different formulas (somehow, I strongly doubt that you can).
@BrunoLeFloch \left examines the next token (after expansion); if it's a character TeX looks at its \delcode; otherwise the token must be \delimiter. The \delcode and the argument to \delimiter are similar and they specify a "small" and a "larger" variant (the larger one usually points to a character that has info for building even larger variants of itself by stacking up various pieces).
The specification is "family and slot" repeated twice (six bytes); \delimiter has also a seventh byte for telling TeX the kind of atom the command should represent if it's not used as a delimiter.
For example, Plain TeX has \def\uparrow{\delimiter"3222378 } that tells TeX that \uparrow is a relation symbol when not coming after \left or \right (first byte is 3); in this case it uses slot "22 from math family "2; the same character if coming after \left or \right and the formula to cover is not too high; if it is, then TeX uses character "78 from math family "3.
In conclusion, if you change the \delcode or the definition of a command, you can do what you want.
@egreg There is another piece to the story, about how TeX goes to see the "next" character in some series within the font, isn't there? Otherwise, how would you get more than two brackets (with constant delcode)?
@egreg Only if the font provides arbitrary sizes of brackets, which it probably doesn't. On the other hand, given enough discrete sized brackets, we could use resizebox-like code to get precisely the size of bracket we want.
@egreg The name reminds me of something (probably texbytopic, a day I was bored).
@egreg Well, I'm thinking of only doing that for tiny adjustments.
Like you use the closest among (, \big(, \Big(,... \Bigg(,... and then resize a little bit. You were the one complaining that there are only so many ( you can have.
@BrunoLeFloch This might be. But I'm not sure if it's typographically sound.
I'd prefer that two adjacent parentheses (say closing and opening) delimiting similarly high subformulas be equal to each other in size, independently from possible small variations of the subformulas' heights
@egreg Makes lotsa sense. I must have misunderstood you earlier.
@egreg Let me cite your post: "The biggest problem in this respect is that there is only a limited number of sizes for the parentheses and one has to choose the closer one."
@BrunoLeFloch I was thinking to the \sum problem. If isolated, the parenthesis may be of the size you prefer to cover properly the object. But you see that complex formulas must be treated "globally" rather than "locally".
@Canageek First try not to have a giant bunch of nested parentheses. :) Then don't worry too much if the outer ones are not bigger than the inner ones (only that they are not smaller): $((a+b)c-d)e$ is perfect without enlarging the outer parentheses.
The main topic in the main chat room for TeX.SX is the same as the site's topic but other things are discussed to (such as sports and cats). Often there are discussion about TeX problems and things happening on the site. Just drop by the , and have a look. You do not have to say anything.
Also n...
I love LordStryker's comment. I think we should put a sign written "Cuidado, llamas!"
Very impressed by http://webdemo.visionobjects.com/equation.html?locale=default
As N.N. notes in his answer to Can/should we get a “How to Ask” page?, there is now a "How to ask" page and it is linked from a helpful-looking box on the "Ask Question" page:
I'd like this box made a little clearer and cleaner, if possible. The problems that immediately jump out at me are:
...
I didn't realize it before, but it seems that we have a chat-room dedicated to us....so an obvious question is....
What should we talk about in the chat room? What is appropriate for that?
