Hi Javier, Javier Múgica de Rivera wrote:
Yes, I mean exactly that. I chose the example of Russian because in a language that uses the Latin script, as is the case of French or Spanish, it really isn't that annoying not to be able to use accented leters or some particular letter of the alphabet (\~n, \c c, ...), but if you are using another script it is very likely that you need all the letters of your alphabet to be active, and so you are forced to use the
Let me start by saying this: If your font is set up correctly for your language, not all characters really 'have to' be active. Inputenc.sty makes them active so that it can support many encodings, but there is no real need for that. If (for instance) é is in slot 233 of your input encoding, and you use a font encoding that has it in slot 233 as well, then it can simply be a 'letter', and you could happily use it in a control sequence. In the future, even with a different font encoding, the need for all these characters to be active will disappear completely because future versions of pdfTeX will have a separation between characters and font glyphs, with a tunable remapping stage inbetween. Adding a \cscode primitive may be interesting nonetheless, but like Phil said: there will be implications. The next release (1.40) of pdftex is in feature freeze so there is no chance of adding it in there, but I'll do some experiments in LuaTeX to see just how many implications there are and if they can be overcome without breaking compatibility. Cheers, Taco