How can I make active ^^M expand to non-active ^^M? The following doesn't work.

\let\eol^^M
\begingroup\lccode`\~=`\^^M\lowercase{\endgroup\let~\eol}

@HenriMenke \edef^^M{\string^^M}

Why is it you asking that question!?

With my new unreleased package: \def \cA\^^M { \cO\^^M } (cA and cO are "active" and "other" respectively as in regex syntax)

@DavidCarlisle Is 12 the correct catcode for ^^M?

\the\catcode `\^^M

No it's 5

@HenriMenke define correct. It is a non active ^^M which is what you asked for

You can't get one with cat 5 anyway

catcode 5 is (like a comment catcode) not a valid catcode for a token

@DavidCarlisle Hm, would be good to get one with catcode 5 as to not break other stuff.

???? what are you even trying to do?

@HenriMenke no you can not have a token of catcode 5

Sounds like you want to grab the argument verbatim then scantokens after do the necessary changes

Which is... something some of my other unreleased package does, by the way

@user202729 possibly, or possibly "don't start from there"

@HenriMenke an input character of catcode 5 acts like a comment, it and the rest of the input line buffer are discarded and not tokenized, it then triggers eol processing. So it never corresponds to a token

@samcarter oh no twitter.com/foxes_in_love/status/1544619159241236480

@PauloCereda oh no :)

@samcarter oh no :)

Hey guys, small question on citing

@nathdwek Yes?

I'm working on an article, provided a template, pdftex with bibtex, ieee citation style

no issue with citing in general, just a quirk: ieee sorts citation by order of appearance, which I'm very fine with

@nathdwek An official one or something you found on the internet?

@nathdwek Yes, as it should :)

@JosephWright official one, from the journal I'm publishing in

@nathdwek OK

So here comes the quirk I'd like to know how if it's possible to fix

(easily)

If I cite later on in the paper references which have already been cited, I just put them in the order I remember them

so not ordered anymore. And it annoys me a tiny tiny bit

@nathdwek Example of your input?

\cite{cumbo_advanced_2021,tamarozzi_noise_nodate,devos_sensor_2021,cappelle_sensor_2021,iriarte_optimal_2020,khalil_optimal_2019,mazzanti_improved_2020}

All those were already cited

And I just put them in order they come to mind

but then (expectedly) the output is [8, 3, 4, 2]

@nathdwek Normally natbib would be set up to sort them, but if the template doesn't, I'd leave to the editorial office: this is ultimately their business

I can reorder the cite manually so that it matches order of appearance, but I wonder (curiosity and perfectionism) if there's an easy key to order the number within a citing bracket

@JosephWright heh....I'm publishing in a decent journal, but even Elsevier don't really do this correctly anymore

tbh I don't trust editorial offices a lot with those kind of things, they let so much little things go through...

(when it's not more obvious BS)

Ok, I'll look into natbib

@nathdwek does your journal class pull in a known citation package such as cite or natbib already?

I'm looking into it

no, just \bibliographystyle{iEEEtran_NoDash}

reading the natbib documentation, sounds like what I want to do might be already provided by the cite package, which has a more limited scope

\uspackage{cite} is less invasive than natbib, it basically just sorts

@DavidCarlisle The IEEE styles are natbib-based

@nathdwek oh as I was writing:-)

@DavidCarlisle ok was about to ask if there was any reason to not use cite, but seems like you answered thisalready

@nathdwek Like I said, this is down to the editorial office, as in if they've not set it up to sort, that's a decision they've actively made and I'd respect it

@JosephWright so is this a counterindication to cite? for what it's worth I don't find natbib invoked anywhere in my wirting directory

@JosephWright that's why I asked first, I should never believe the user:-) @nathdwek ^^ as Joseph says...

@nathdwek check your log file (or the cls file)

@JosephWright mmh, personal choice, I'd rather have them tell me using a solution to sort citations is wrong and fix then not fix it.

because I don't trust the quality of their work enough

ok I'll try cite and see if my document implodes

What I mean is if you consider their role is to fix my document so that it meets their standards, I might as well provide the document which I think is best (withing margins around their initial template). If they don't like it I'm open to fixing it, and it's their job to say that, but I think it's likely they don't even notice

I'm not sure if I'm making any sense...thanks for the help still!

neal.fun/absurd-trolley-problems

@PauloCereda Oh no!

@mickep oh no

@PauloCereda The sad lucida square root is... not good.

@mickep boo

by tradition. not a palindrome though

If I have a user macro \foo, and I want a macro named similarly in a package/sty file, say xx.sty then is it reasonable to go with something like \foo@xx?

@FaheemMitha possibly but usual style is to allocate yourself a unique-ish prefix for the package and use that for all internal commands so longtable grabs \lt@.. and all internal macros starting \lt@ are probably from there

@DavidCarlisle Can't package names be the suffix? That seems more natural to me. Is there a dominant convention, or is it a "do as you please" thing?

Probably can as well. Actually making them suffix might actually make hash lookup/resolve faster

@FaheemMitha you don't have to use any naming scheme at all, but as I say those that do almost always prefix (and l3 packages formalise that convention)

@DavidCarlisle OK. But doing it as a suffix is also in line with the natural interpretation of @ as "at".

@FaheemMitha whatever as I say latex dosn't care: the original 209 style was mostly replacing vowels by @ so \foo, \fo@, \f@@

@FaheemMitha if there is a convention at all, it is that the package sets some prefix. Look in the code of some standard packages.

@DavidCarlisle @UlrikeFischer OK.

The new ConTeXt math code is now officially released: mailman.ntg.nl/pipermail/ntg-context/2022/106159.html

@TeXnician Finally. :)

-- we ditched support for \over simply because it is too fragile wrt
spacing (one can \usemodule[oldmath] to get it back

@mickep I could not test it yet on real-world documents. But I love reading about all the detailed work that has gotten into it. Many thanks for all your efforts :)

@TeXnician Thanks! It is a pure joy. (There is still a lot to do...)

@TeXnician ooh

@JosephWright good :-)