Martin Vermeer [EMAIL PROTECTED] writes:
Actually I'm not too sure we should re-package font attributes as insets.
They should remain themselves, only their direct use discouraged.
Well, we shall definitely keep a separation (at least in the UI)
between fonts and char styles, if only to make
On Fri, 21 Sep 2007 10:35:04 +0200
Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
Actually I'm not too sure we should re-package font attributes as insets.
They should remain themselves, only their direct use discouraged.
Well, we shall definitely
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,
Richard Heck [EMAIL PROTECTED] writes:
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
Jean-Marc Lasgouttes wrote:
But unfortunately, the nest-all approach complicates the use wrt
font-painting for no gain in 90% of the cases (IMO).
Well, I'm no expert whatsoever on that. I stay as far from painting as
possible.
BTW, you should try to grep for font-code in lib/bind...
Martin Vermeer <[EMAIL PROTECTED]> writes:
> Actually I'm not too sure we should "re-package" font attributes as insets.
> They should remain themselves, only their direct use discouraged.
Well, we shall definitely keep a separation (at least in the UI)
between fonts and char styles, if only to
On Fri, 21 Sep 2007 10:35:04 +0200
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > Actually I'm not too sure we should "re-package" font attributes as insets.
> > They should remain themselves, only their direct use discouraged.
>
> Well, we
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,
Richard Heck <[EMAIL PROTECTED]> writes:
> 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
Jean-Marc Lasgouttes wrote:
But unfortunately, the nest-all approach complicates the use wrt
font-painting for no gain in 90% of the cases (IMO).
Well, I'm no expert whatsoever on that. I stay as far from painting as
possible.
BTW, you should try to grep for font-code in lib/bind...
On Thu, 20 Sep 2007 01:45:37 -0400
Richard Heck [EMAIL PROTECTED] wrote:
Per previous discussion, as a first step towards rationalizing this
stuff. No lyx2lyx is necessary here, because font-code simply invoked
texttt or mathtt as appropriate. Killing LFUN_FONT_NOUN etc will be more
fun
Martin Vermeer wrote:
-\bind C-S-P font-code # 'P' for program
Should this already be bound to flex-insert CharStyle:.Code? (One
wishes, doesn't one?)
The reason I didn't do this is that now CharStyle:Code is in the
logicalmkup module, so it isn't guaranteed to be available. I suppose
Richard Heck [EMAIL PROTECTED] writes:
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for code in the logicalmkup module, and with this
included one could bind a key to that charstyle if
On Thu, 20 Sep 2007 10:39:37 +0200
Jean-Marc Lasgouttes [EMAIL PROTECTED] wrote:
Richard Heck [EMAIL PROTECTED] writes:
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for code in the
Martin Vermeer [EMAIL PROTECTED] writes:
Yes... and less intrusive for now.
But is this actually being used anywhere (in addition to the minibuffer)?
lyxserver can use it... I think it does not matter much, but we shall
not remove it without removing all the rest and provide a backup plan
to
Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for code in the logicalmkup module, and with this
included one could
On Thu, Sep 20, 2007 at 01:59:51PM -0400, Richard Heck wrote:
Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for
On Thu, 20 Sep 2007 01:45:37 -0400
Richard Heck <[EMAIL PROTECTED]> wrote:
> Per previous discussion, as a first step towards rationalizing this
> stuff. No lyx2lyx is necessary here, because font-code simply invoked
> texttt or mathtt as appropriate. Killing LFUN_FONT_NOUN etc will be more
>
Martin Vermeer wrote:
-\bind "C-S-P" "font-code" # 'P' for program
Should this already be bound to "flex-insert CharStyle:.Code"? (One
wishes, doesn't one?)
The reason I didn't do this is that now CharStyle:Code is in the
logicalmkup module, so it isn't guaranteed to be available. I
Richard Heck <[EMAIL PROTECTED]> writes:
> For those not privy to the earlier discussion, the rationale here is
> that such things ought to be replaced by character styles. We now have
> such a style for code in the logicalmkup module, and with this
> included one could bind a key to that
On Thu, 20 Sep 2007 10:39:37 +0200
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> Richard Heck <[EMAIL PROTECTED]> writes:
> > For those not privy to the earlier discussion, the rationale here is
> > that such things ought to be replaced by character styles. We now have
> > such a style for
Martin Vermeer <[EMAIL PROTECTED]> writes:
> Yes... and less intrusive for now.
>
> But is this actually being used anywhere (in addition to the minibuffer)?
lyxserver can use it... I think it does not matter much, but we shall
not remove it without removing all the rest and provide a backup
Jean-Marc Lasgouttes wrote:
Richard Heck <[EMAIL PROTECTED]> writes:
For those not privy to the earlier discussion, the rationale here is
that such things ought to be replaced by character styles. We now have
such a style for code in the logicalmkup module, and with this
included one could
On Thu, Sep 20, 2007 at 01:59:51PM -0400, Richard Heck wrote:
> Jean-Marc Lasgouttes wrote:
> >Richard Heck <[EMAIL PROTECTED]> writes:
> >
> >>For those not privy to the earlier discussion, the rationale here is
> >>that such things ought to be replaced by character styles. We now have
> >>such
Per previous discussion, as a first step towards rationalizing this
stuff. No lyx2lyx is necessary here, because font-code simply invoked
texttt or mathtt as appropriate. Killing LFUN_FONT_NOUN etc will be more
fun for that reason.
For those not privy to the earlier discussion, the rationale
Per previous discussion, as a first step towards rationalizing this
stuff. No lyx2lyx is necessary here, because font-code simply invoked
texttt or mathtt as appropriate. Killing LFUN_FONT_NOUN etc will be more
fun for that reason.
For those not privy to the earlier discussion, the rationale
26 matches
Mail list logo
