Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| >>>>> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
|
| >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| Lars> | I was wondering whether we could have a insetunicodeaccent.
|
| Lars> I'd say that would be pointless. If we need such a beast, it
| Lars> should be internal to the frontend. (I.e. the frontend must do
| Lars> what it has to to support combining chars, chars and don't have
| Lars> an available glyph etc.)
|
| Jean-Marc> But this means that the length of a docstring is not much
| Jean-Marc> more usable than the length of an utf-8 string... Also,
| Jean-Marc> cursor movement will be much more complicated. This is not
| Jean-Marc> a frontend matter only IMO.
|
| Since this combining chars should be very rare (am I right? It should
| at least be true for the languages we handle now), an inset makes
| sense in terms of smallest impact on the kernel code.
Smallest impact on kernel code is to treat a combining codepoint as
just anyother codepoint.
| Do you have an idea of what the uses cases are, or are you just
| playing safe?
any accented char might be inserted as a codepoint+combining mark
Any char can get the combination.
If we are to use an inset, it will be an inset that only exists inside
the kernel (never in .lyx f.ex.) to help with cursor movement. Which
IMHO should be a frontend thing and then the inset is not needed...
--
Lgb
