This one can be safely closed (removing outdated packages from a local tree solved the problem):

@Gregory Sounds like a DropBox issue rather than a TeX one

@DavidCarlisle Do we want to modify encguide at all?

@JosephWright oh you mean now that it's all wrong?

@JosephWright I suppose so.

@DavidCarlisle Needs some caveats

@egreg I'm giving some thought to the case changing business: details of how to handle embeded control sequences will be updated once I decide on the best plan!

@JosephWright Can I ask you how do you typeset weight percents? I've seen variants of $50\,\text{w.}\,\%$ and $50\,\mathrm{wt}\%$

@DavidCarlisle Something as simple as a paragraph saying 'Unicode engines work with a different set of assumptions and use lccode/uccode values appropriate to Unicode codepoints throughout'

@yo' Yes, tricky

@yo' I guess I've normally seen the latter formulation, but it does vary a lot

@JosephWright indeed. I changed it from the 1st to the 2nd variant in an article because there was simply too many thin spaces everywhere and too many dots, but it was the only reason I did so

@egreg I'm currently wonder if the best plan is to say that the input should be fully expanded to 'text' but that any control sequences will not be modified further. Otherwise you get into having to test 'can this be expanded: if so loop, if not store as is'.

@yo' As good a plan as any

@JosephWright :) Thanks.

@egreg On the \'{e} side of things, current behaviour is deliberate (skip brace groups) but there are issues. One might imagine in a pure Unicode set up you'd define \' to be expandable of the form \def\'#1{\ifcsname #1acute\endcsname \csname #1acute\endcsname\else\string\'#1\fi, with e.g. \def\eactute{é} (ConTeXt-inspired).

@egreg I can see the brace handling both ways!

@JosephWright yes, unless we want to mention luainputenc (I'm not sure we are ready to mention that yet)

@DavidCarlisle I think we should probably stick to what we support (and as we know luainputenc isn't quite right here anyway)

@DavidCarlisle In any case, encguide is clearly about font encodings only!

@JosephWright agreed, I just wonder if we can word it in a way so that it is still true if luainputenc loaded (even if we don't mention that) perhaps enough to say "by default with Unicode engines....

@DavidCarlisle With LuaTeX callbacks all sorts could be going on, so yes I guess something like 'With a standard set up ...'

@JosephWright sounds like you just volunteered. Your "I only do L3 stuff" resolve is clearly well and truly broken now.

@DavidCarlisle No

@JosephWright not volunteered, or not broken?

@DavidCarlisle Well both

@JosephWright :-) Ok I'll make a pass this evening possibly:-)

@DavidCarlisle I read over encdguide and decided it needs someone who knows what they are doing!

@JosephWright where's Alan J when we need him

@DavidCarlisle I'll tackle stuff if I can see some overlap with L3 :-) For example, we will need to set up lccodes etc. in format mode (I might do something about that soon, for testing)

@DavidCarlisle Indeed

@DavidCarlisle More seriously, my position is more 'there is only so much time in the day, and there are limits on what is doable in LaTeX2e'

@DavidCarlisle One problem I have with encguide is that there are these 'rules' for encoding names, then you read them and more or less all of the encodings don't actually follow them!

@JosephWright no actually it only seems that way. The main result is that most fonts for European languages got remapped to T1 so were usable with the same encoding setup. prior to that every font package loaded a font and then redefined half of latex to fit, so using two fonts was a disaster. So the rules got stretched a bit for cyrillic X encodings and ignored for LGR and the Vietnamese one, but basically it's progress that there is sufficient order that you can spot when the rules are broken..

@DavidCarlisle What I mean is: LGR should not be L... (same for LY1), the Cyrillic encodings should be X not T, ...

@DavidCarlisle Then we have EU1, EU2 which should be (a) one encoding and (b) not experimental ...

@DavidCarlisle I'm not saying it doesn't work!

@DavidCarlisle You see that you are much better placed to update the docs than I am!

@JosephWright No LGR had to be L by the rules, as the rules said that all T* encodings had to use the T1 lccode table and we couldn't make that work for Greek. Similarly LY1 (my name:-) is L because Y&Y didn't want to obey the rules as they didn't want any font re-encoding and wanted to use the same encoding for input and output.

@DavidCarlisle But L is meant to be local (site-specific), not just 'not T'

@DavidCarlisle Also encguide suggests that all encodings have to use the T1 lccode table

> Therefore all encodings need to share these two tables which are defined to be those of the T1 encoding.

@DavidCarlisle I notice that as Heiko's used LuaTeX to compile the docs, encguide 'in the wild' is missing some glyphs (the odd ones in T1!)

@JosephWright yes well the internet makes local things escape, it was supposed to be Local to Berthold's commercial TeX system....

@JosephWright Oh good grief :(

@DavidCarlisle That's an interesting interpretation of 'local' :-)

@DavidCarlisle Indeed :-)

@DavidCarlisle texdoc.net/pkg/encguide then page 13 for example

@JosephWright In a Unicode setup, with no changing output encoding, it's the simplest way. But…

@DavidCarlisle Assuming people go for our build this will be fixed

@JosephWright X2 is not ASCII compliant as well as LGR, so they can't be T...

@egreg Yes: open questions about how much we can realistically do with 8-bit engines in new code

@egreg That part makes sense

@egreg It's the cases that are the other way around that are more odd, e.g. T3: 'The T3 encoding does not fulfil the requirements for T encodings'

@JosephWright Unfortunately, Greek support is a messy kludge. Probably, monotonic Greek can have a T? encoding, but polytonic definitely not, because it needs too many glyphs. Whoever accepted T3 made a big mistake.

@egreg I think even in a pure Unicode set up (ConTeXt MkIV, for example) you'd still want access to input of the format \'{e} for cases where you don't want to look up the char in a separate application, etc.

@JosephWright One of course needs \'{m} to do m+acute

@egreg I realise all of this, what I'm trying to get at is that the naming is in reality pretty arbitrary: Greek is LGR because it is, etc.

@egreg Yes, hence my 'fall back' position in the suggested code earlier

@egreg Like I said, I'm not sure about how to treat a brace group for case changing. The BibTeX syntax is simple but does leave a few issues open.

@JosephWright Nowadays, LGR might even change name because it's not necessary to mention it any more, but this may break older document.

@egreg Same question with Unicode encoding: I'm not that happy with having two, but we may be stuck with it

@egreg not mention because a better encoding is available or because babel switches it in automatically?

@DavidCarlisle Automatic switch behind the scenes.

@JosephWright There I can't see why we can't use a combined encoding everywhere and just leave the existing eu[12] files around so explicit references work?

@egreg ah yes OK

@DavidCarlisle Well yes that's what I'd like to do

@DavidCarlisle Once we ship the current changes!

@DavidCarlisle Of course, we need Will to sort part of this

@DavidCarlisle My feeling is it might be best rather than modifying the existing text to add a new section covering Unicode engines/'post encoding considerations'

@egreg More feedback on case change stuff very welcome!

@DavidCarlisle Worth remembering that we will need a lot of this info for a new format, so there is a logic (even if we do in the end go Unicode-only or whatever)

@JosephWright Encoding schemes which are local to a site or a system should start with |L| Y&Y was the system so LY1 .... I feel vindicated, I should read documentation more often..

@DavidCarlisle OK, I'd missed the 'system' part, although this doesn't explain LGR :-)

@JosephWright Local to Greece?

@DavidCarlisle :-)

@DavidCarlisle Where does Unicode fit, then?

@DavidCarlisle BTW, did you see my checkin this morning about the \lccode of -: I hope it makes sense (certainly it's what LuaTeX and XeTeX currently have)

@DavidCarlisle How do you plan to document stuff for Unicode engines? As I said earlier, my feeling is it's best to leave the current text alone and cover this as a separate section (as the entire situation is very different for 8-bit)

@JosephWright don't know yet been doing work:-) But I just read the existing text in a spare moment, hence the above quote, yes new section seems best, didn't see the svn update yet either, will look

@DavidCarlisle Update v. small :-)

@JosephWright did you see the discussion about whether modifier letters Lm should or shouldn't have lccodes set a while back (on luatex list I think) It sort of petered out as far as I know

@DavidCarlisle May have skimmed it, don't remember details. Will look later.

@DavidCarlisle At the moment, XeTeX and LuaTeX do the same thing, based on what Jonathan Kew decided, and I've also gone with the same plan

@JosephWright ah it was c.t.t comments.gmane.org/gmane.comp.tex.hyphenation/1113

@DavidCarlisle Tricky one: they are down as 'letters' after all

@DavidCarlisle We could take a different line to the current situation but it's risky without more discussion

@DavidCarlisle Do you think catcode 11 but lccode 0 is more appropriate for these cases?

@DavidCarlisle Reading unicode.org/reports/tr44 that might be right: cased letters only covers Lu, Ll, Lt, while Lm and Lo are just 'letters'

@DavidCarlisle Tricky (reading entire thread)

@egreg: hi! Do you mind if I send you an email later on? I need an expert advice. :)

@PauloCereda Not sure I'll answer, but I'll try.

@egreg We don't even know what you need to be an expert on!

@JosephWright I'm expert in everything, of course! I've almost reached a gold badge in tikz-pgf

gotta love my school. Eduroam works on a magic word that I don't know. The university inner WiFi works, but so many webpages are blacklisted causing a silent kick that you can't do anything. Registering the MAC address of my computer will probably take 30 days (read: 7 months).

@yo' Eduroam is a tricky beast to get set up (although once it's working it's usually fine)

@JosephWright it does work, sometimes even for two days without any problem :) it's the university here that's shitty.

@JosephWright possibly but it was a while since I saw that, just googled for Lm and lccode just now to find it again, but didn't read carefully. Although actually it depends on what the hyphenation patterns assume cf a recent discussion about whether either of ' or U+2019 should have a lccode for Italian

@egreg did you make a submission to Unicode? proposed new character for Unicode 8: CRICKET BAT AND BALL blog.unicode.org/2014/11/…

@DavidCarlisle :-)

@DavidCarlisle But is it Lm?

Hi guys, I'm trying to get my university's dissertation template working, but i'm receiving an error when i try to compile; it looks like an emacs error though: "symbol's function definition is void: add-local-hook". I have no idea what to do.

@QuinnCulver Certainly not a TeX error

@JosephWright OK, are you familiar with emacs/AUCTeX?

@QuinnCulver No :-)

@JosephWright OK

@JosephWright I see they are changing some letter classes, 13A0;CHEROKEE LETTER A;Lo;0;L;;;;;N;;;;; changing to Lu in version 8 (draft)

@DavidCarlisle We'll rely on you to tip me off when I need to update ltunicode.ltx and l3unicode-data.def :-)

@DavidCarlisle That's why we need to get this on some more sane basis than 'XeTeX has some version of the Unicode database in use, LuaTeX uses an old version of the derived data'

@DavidCarlisle Link, BTW?

@GonzaloMedina I see that there is an older question again on accents: some cleanup needed

@JosephWright unicode.org/Public/8.0.0/ucd

@DavidCarlisle I like the 2nd one; it's something I should do sooner tonight than I did last night :)

@DavidCarlisle I meant something like 'Key changes' (I'm guessing you didn't read the entire list!)

@JosephWright No I used diff, hence the > in those arrows mentioned above:-)

@DavidCarlisle Ah

@JosephWright which reminds me could the script put a comment in ltunicode.ltx which says which version of unicode-data it matches? There isn't a version inside the original file either but it's easier to know what it's generated from if it said 7.0.0 or something somewhere

@DavidCarlisle We can certainly hand-edit something in: I went with date of generation purely because that can be done without needing to rely on manual intervention. It's a pain that UnicodeData.txt doesn't have version data (the other files do).

E.g.

# EastAsianWidth-7.0.0.txt
# Date: 2014-02-28, 23:15:00 GMT [KW, LI]

@DavidCarlisle We could copy the version lines from one (or both) of the other source files (EastAsianWidth.txt and LineBreak.txt)

@DavidCarlisle Same issue for l3unicode-data.def, of course

All: opinions on tex.stackexchange.com/questions/163716/… and tex.stackexchange.com/q/8857?

@JosephWright yes

@DavidCarlisle This one is already included 🏀

@egreg Codepoint?

Do you think > 1DA07;SIGNWRITING FACE DIRECTION POSITION NOSE FORWARD TILTING;Mn;0;NSM;;;;;N;;;;; has a use in Chemisty?

@JosephWright U+1F3C0 BASKETBALL AND HOOP

@egreg Ah, I thought it was 'SCREWED UP PAPER INTO RUBBISH BIN' :-)

(Seriously: was looking through UnicodeData.txt for more-or-less that)

@DavidCarlisle And this one: ⚽

@JosephWright you and cut and paste egreg's text into w3.org/2003/entities/2007xml/unicode-names.html

@DavidCarlisle Boring!

@DavidCarlisle Guess-the-symbol is much more fun!

@DavidCarlisle We could read on of the two versioned files 'up front', just grab the first line and use that as a hopefully-reasonable version number

@DavidCarlisle Or grab both first lines and check they at least match

@egreg: Thank you, mail sent. :)

Post-docs, free elsevier access under some conditions

elsevier.com/connect/…

Hi, my question was closed because it is similar to another that had already been answered. However, the solution given for the other question doesn't work in my case. I was asked to add a MWE and to request reopening of the question here. This is my question: tex.stackexchange.com/questions/225756/…

Could somebody with the necessary privileges please reopen my question? Thank you.

@tmalsburg it takes several votes to reopen; there are a few now. It should reopen soon.

@tmalsburg Hi there :)

Thanks for reopening the question!

@JosephWright Indeed. What do you propose?

@tmalsburg well, you're welcome of course. It was a mistake that it got closed, but it should be fine now :)

Hello!

@EthanAlvaree Hello

A bit of an odd request, but I created a suggestion on Windows 10's official Uservoice for Microsoft to introduce a touch-capable LaTeX editor as part of its free Microsoft Office. Wondering if anyone here who loves LaTeX would want to check out the suggestion and possibly vote/comment on it? windows.uservoice.com/forums/265757-windows-feature-suggestions/…

So far it's one of the top-voted suggestions. But I'm running into some resistance from people who don't know what LaTeX is, or don't understand why it is fundamentally different than Word, who say that "no need for a new app, all the job can be done in Word"... sigh...

I'm trying to share this Uservoice suggestion with my LaTeX friends, but not sure the best way to circulate it...

@JosephWright not sure it's what you meant, but I added something:-)

@DavidCarlisle Looks about right

@EthanAlvaree I still wonder what a touch-capable Microsoft app restricted to Windows 10 could bring to us :-)

I could touch a backslash button perhaps :-)

@EthanAlvaree not sure I understand the suggestion well enough to comment, it seems to me to have little chance of being accepted. "Office" is a premier MS brand and I would expect that they (and a large chunk of their users) would expect that they had control over the document formatting of an office product. So either they would have to implement a new typesetter (which wouldn't be latex) or they'd use latex (in which case it isn't office). What advantage is their to having an "office" version?

For information, some interesting arguments are already here: http://latex-community.org/forum/viewtopic.php?f=5&t=25548

Stefan, is that you from Latex Community? :)

@PauloCereda A user on Math.SE

@PauloCereda Does it ring a bell? ;-)

@EthanAlvaree Sure :-)

@EthanAlvaree and from goLaTeX.de and TeXwelt, the latter did not discuss it yet ;)

Thanks for your thoughts! I hope Microsoft Office users and TeX lovers alike can support this suggestion. I'm definitely not asking Microsoft to make its own format -- which is why I don't use Word's equation editor and save .doc files. I just want a touch-enabled LaTeX app for Windows, iOS and Android like MS-Office's other free apps

Office provides almost all the productivity apps a user needs... except the one tool I use most in my office, LaTeX ;)

@EthanAlvaree yes I understand you want that but why do you want it to be part of office? I honestly don't understand that at all and can see no advantage.

@EthanAlvaree Feel free to add ideas to forum posts what touch could bring what isn't already available with LaTeX editors on touch capable systems, and what a MS app might have as advantage over other apps (programs) running on Windows and all the other systems

I just have to leave for now, see you

Okay, thanks Stefan!

What Office has done is given students and other ordinary users access to powerful productivity apps (Word, Excel, etc.) for free whether they are on a PC or on a Chromebook or iPad. While it's true there are already many LaTeX editors for PCs, these aren't optimized for touch as well as they could be (even Notepad works better on a touchscreen than, say, Texstudio because Notepad at least lets you scroll with your finger).

And for those users with iPads, there's no LaTeX software available to them, even though they can install free touch-friendly Word, Excel, Powerpoint, Outlook, etc. with one tap from their app store

I don't mean to focus on iPads, by the way. I mean most mobile devices; Microsoft Office is one productivity suite that has come to virtually every phone and tablet. But it's missing the one tool I use most in my office, which is why I posted the Uservoice suggestion.