>>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Still I think we differ in our views of what the charstyle Martin> paradigm should be (I see it as a longer term complete Martin> replacement of font attributes from the user's POV). Ah well, Martin> some other time. >> No, we differ on what the bug is. The bug is that an insettext >> that wants to set its display font does not work (assume I want to >> have all notes display in sans serif, for example). This has >> nothing to do with what we want to use charstyles for. Martin> This confirms that you don't understand my argument/rationale: Martin> this particular insettext shouldn't even *want* to do that. Martin> The content of a charstyle inset is *not* (should not be) a Martin> full-blown lyxtext with font attributes and all; in somewhat Martin> the same way that the content of an ERT inset is not/should Martin> not be. Only, the ERT makes that circumstance more explicit. Martin> IMHO. I think I understand intent, but I disagree with the proposed cure. The code is already full of ad-hoc limitations to do as if some constraints were enforced. These limitations are useless in so far as they do not enforce anything (as you said it is always possible to obtain the same result by cut and paste (and don't propose a new patch to paste code to remove font changes, the code is already disgusting enough as it is!)). In the future world when you have managed to get rid of font changes, there will be no need to take special action after all. Problem solved :) JMarc
