On Wed, 2006-01-11 at 10:26 +0100, Jean-Marc Lasgouttes wrote: > >>>>> "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!)).
Actually as I also said earlier, cut & paste in this case works "correctly" (i.e., as you would want the direct font change to work). So no, that doesn't create any further complications. > 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 > :) Yes. - Martin
signature.asc
Description: This is a digitally signed message part
