Martin Vermeer wrote:
However, this is othogonal to the
discussion about changing fonts to insets (although I am not a
proponent of this change, as some people know).
Yes, what I was trying to argue is that I am against that too. Reason:
it adds one extra layer of complexity in-between, for no good reason
that I can see.
OK. At least we're clear now what the issue is. (I agree completely
about the need to separate fonts from charstyles, of course.) But here's
what's moving me: Turning fonts into insets solves all kinds of problems
involving nesting, as well as problems involving communication with the
user. As things are, it can be very hard to tell where font changes
begin and where they end, indeed, even where they are in effect and
where they are not (emph plus ital, e.g.). And the possibility of
constructs like the one Martin mentioned earlier:
ab{ab[cd}ef]
where the brackets indicate font changes, causes nasty complexities in
the code. Plus, there are bugs related to the fact that
a[{bc}]d
and
a{[bc]}d
either can't be told apart or get forced one way or the other by magic.
And maybe we even see this monstrosity:
a{[bc}]d
True, there may be other ways to solve those problems, but I guess I'd
like to see or hear what they are.
And by the way, if the User's Guide is---as I believe it is---using
hard-coded font changes for things like menu items, that should be
changed to charstyles. At least we can show new users, by example, the
right way to do things.
Richard
