you proved once more to be able to dish out very complex code in passing :-)

 > >  > Definition to convert from LICR to glyph:
 > Note that statement!  This really doesn't have anything to do with
 > *input* encoding, but deals with the output encoding.

right and i think this is where the problem lies:

i wrote:

 > > one of the problem is that pressing key  (umlaut-a) on the keyboard maps to
 > > \"a alright in the LICR but that is not equiv to doing
 > >
 > >  \string 
 > >
 > > for typesetting ---  the slot to use varies from encoding to encoding. so if i
 > > interpret your definition above correctly then you end up with exactly
 > > typesetting \char ` always for \"a ... or what?
 > Yes, this is pseudo-TeX.  Replace  \string   with  \\T1\"-a  as for T1.

i understood that this is pseudo code

what i meant is that the slot defined by inputenc for  does not need to have
anything to do with the slot defined by the current font encoding. however the
trick you use makes use of such a relationship (more exactly of a 1-to-1
relationship). of course it is correct for T1 or LY1 in most cases, but this
is not a general rule. it will certainly fail the moment the input encoding
is, say, utf8, right?

it will also fail if you start from the LICR directly, eg

$\texteuro$  % perhaps put there manually or via some utf8 input method

that goes of to try changing the fontencoding and then typeset some slot from
TS1. so even if we get to that point we issue \\TS1\texeuro finally the number
that refers to bears no relationship to the code attached to it by inputenc
(if any). so the trick to trigger the math mode using \char then sneak back
via "8000 to restart the definition of some active char would fail as we don't
know what to do then.

so my claim is still, this doesn't work on a general basis. It would work for
most of current inputenc plus T1 fonts and similar constallations but not otherwise,
eg when supporting utf8 as an input encoding or for chars whose inputenc slot
bears no relation to the font slot.

however as long as the two slots are the same thereisn't much need for
something like inputenc anyway (as long as one only works in that framework)
which is nicely proven by Bernard since he uses catcode type letter to input
his upper 8bits.

since i was wrong often enough perhaps also here ...  but then i would need a
bit more pseudo code :-)


anyway, all that struggling nicely vanishes if one uses eTeX version 2. so why
not do that and have a package that tests for eTeX and if it finds out that it
doesn't run under eTeX emits a warning (at the beginning and end of the run),

* \@spaces The inpmath package was written to support 8bit^^J%
* \@spaces characters as they can be entered from the keyboard both^^J%
* \@spaces in text as well as in math formulas.^^J%
* \@spaces However, for this to work in all circumstances the^^J%
* \@spaces code uses a feature only available with the eTeX^^J%
* \@spaces program.^^J%
* \@spaces eTeX is implemented both as a standalone replacement^^J%
* \@spaces for TeX, as well as being part of pdftex.^^J%
* You do NOT use eTeX to process your document!^^J%
* \@spaces As a result the following might fail: Characters entered at^^J%
* \@spaces the beginning of an array cell (where the cell is typeset^^J%
* \@spaces in math mode) might produce the wrong result or even vanish^^J%
* \@spaces without a warning!^^J%
* Resolution:^^J%
* \@spaces Either use eTeX instead of TeX for processing your^^J%
* \@spaces documents, or put \noexpand\protect before a^^J%
* \@spaces character that poses a problem.^^J%


 a) any obvious problems with this approach?

 b) more particular, can that approach replace textmath.sty, ie what is the
    situation these days in Russia concerning eTeX?

note, that even with normal TeX the package behaves well, except for the
danger outlined in the warning and for that one one has a workaround.

 c) if consider a good thing then some suggestions for a better name for
 \DeclareMathMeaning would be helpful, and perhaps somebody who would help to
 finish providing a base set of such declarations

 d) any other comments? (or perhaps pseudo code that proves there exist a
 different solution)

the implementation is finish for the above except that i not