On Wed, Sep 10, 2008 at 02:49:58PM -0400, Richard Heck wrote:
>>> Would you like to have an _inline_ inset that spans more than one row ?
>>>
>>> Like:
>>>
>>> This is a line with XXX
>>> XX an inline inset.
>>
>> That's called the "Three Box Model" in AL. [1]
>>
> Why the name? Where ar
Richard wrote:
> Did anyone try? Were there problems? This would be
> particularly good with character styles
What about using the branch feature. Real cool too,
but very impractical if you use it as little notes in
the text.
Unless
Vincent
Andre Poenitz wrote:
On Wed, Sep 10, 2008 at 08:11:30PM +0200, Vincent van Ravesteijn - TNW wrote:
Note, for example, the weird things that happen with line width
when you have an open footnote at the end of a paragraph. I
really do not want to see that phenomenon with a deleted handfu
On Wed, Sep 10, 2008 at 08:11:30PM +0200, Vincent van Ravesteijn - TNW wrote:
>
> > Note, for example, the weird things that happen with line width
> > when you have an open footnote at the end of a paragraph. I
> > really do not want to see that phenomenon with a deleted handful
> > of words. Bu
> Note, for example, the weird things that happen with line width
> when you have an open footnote at the end of a paragraph. I
> really do not want to see that phenomenon with a deleted handful
> of words. But if we could solve THAT problem, then that would
> open up a lot of territory, I think
rgheck wrote:
I'm fairly puzzled about this, because previously \mathbf seems to have
created an InsetMathFont, whereas we also have InsetMathBoldSymbol,
which is where \boldsymbol would previously have been found. Now we have
both, and we basically have a conflict, as I've mentioned in another
Vincent van Ravesteijn - TNW wrote:
This would be rather easy with changes-as-insets, but currently
changes are just like a font setting. So I doubt that we could go
painlessly to this level of generality.
I thought about mentioning this possibility, but didn't want to start
the "ev
>> This would be rather easy with changes-as-insets, but currently
>> changes are just like a font setting. So I doubt that we could go
>> painlessly to this level of generality.
>>
>>
>I thought about mentioning this possibility, but didn't want to start
>the "everything's an inset" war agai
Enrico Forestieri wrote:
Another option would be the following. When the user enters
\mathbf{x\alpha y}, we could output the following latex code:
\mathbf{x\boldsymbol{\alpha}y}.
Surely this far and away the best option. The user in this case does not
care what LaTeX code is output, only tha
[EMAIL PROTECTED] wrote:
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
Following your reasoning, we should have a Change::paint(..) method, or
better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
- we might not want to see deletions at all, or
- just paint it
On Wed, Sep 10, 2008 at 05:19:26PM +0200, Pavel Sanda wrote:
> hrrm much discussed, if it means the thread around this commit,
> it just follows the scenario of unadvertised commit and revert
> request :) maybe Enrico can say something about this?
>
> http://www.mail-archive.com/lyx-devel@lists.l
Profitable, Home Business Ideas Money Making Online Internet
Great Work from Home Opportunity. Earn up to $5000per month
Earn money on the computer with internet from home without investment
More details; http://xrl.us/bkygk
--~--~-~--~~~---~--~~
You received this
Richard Heck wrote:
> (hopefully, Jurgen, since he has done such a great job with
> 1.5---is that decided?).
Not yet, as far as I know. At the moment, I'm tempted to not say "no", but
that does not mean that anyone else could step up -- s/he will certainly not
step on my toes (also, who knows wh
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Following your reasoning, we should have a Change::paint(..) method, or
> better, ChangeDeleted::paint(..) and ChangeAdded::paint(..), because
> - we might not want to see deletions at all, or
> - just paint it with a marker to indicat
Richard Heck wrote:
> Pavel Sanda wrote:
>> Richard Heck wrote:
>>
>>> I think maybe what we need is another LFUN, say LFUN_FONT_MATHBF, and we
>>> need to make that toggleable. A preference seems the wrong way to go. One
>>> might want both of these easily available, in toggleable form.
>>>
Pavel Sanda wrote:
Richard Heck wrote:
I think maybe what we need is another LFUN, say LFUN_FONT_MATHBF, and we
need to make that toggleable. A preference seems the wrong way to go. One
might want both of these easily available, in toggleable form.
i propose to introduce LFUN_FONT_BOL
Enrico Forestieri wrote:
On Tue, Sep 09, 2008 at 05:50:41PM -, [EMAIL PROTECTED] wrote:
Author: rgheck
Date: Tue Sep 9 19:50:37 2008
New Revision: 26348
URL: http://www.lyx.org/trac/changeset/26348
Log:
Restore toggling behavior to math bold.
With this patch, \boldsymbol behaves
Vincent van Ravesteijn - TNW wrote:
Getting into the philosophy department:
It can do that, but not expose it to the rowpainter code. The
rowpainter
does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
p
Getting into the philosophy department:
> It can do that, but not expose it to the rowpainter code. The
rowpainter
> does not care about the method used to pick a color.
but it is ok to expose that rowpainter should indicate a change by
painting it in a different color ? Even more striking,
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Change::color() should indeed determine the color of a change. This
> method then decides that we color the change according to the rank of
> the author in the AuthorList. Then, it should ask AuthorList what the
> rank is of the author an
>> Very good point,..
>> (although I still feel that Change should not distribute color codes,
>
> Why? Isn't it good encapsulation? The rowpainter code does not need
> to know how changes should look like
Yes, that's the very good point I refered to.
I meant the following:
Change::color()
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
> Very good point, learning every every day.. I'll just move the code into
> Change::color() .
>
> (although I still feel that Change should not distribute color codes,
Why? Isn't it good encapsulation? The rowpainter code does not need to
Vincent van Ravesteijn - TNW wrote:
Yes, it's a general problem that I try to write patches that change the
least as possible, so you can easily review and understand the changes,
but this might introduce the 'errors' you mentioned. Moreover, I try to
do things the same as it is already done in t
>> the best would be if you can run lyx under gdb, ctrl+c in the
>> moment of freeze in gdb window and send the output of bt command.
>
>i would be personally interested if you get something similar to this:
>http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg142186.html
>pavel
Yes, it looks v
Helge Hafting wrote:
> It seems to be outliner related, indeed.
> I started LyX (with outliner)
> Opened the math manual, got a long wait. (10s or so)
> Resized the main window, got a long wait. (horizontal or vertical doesn't
> matter)
> Repeated the resize some times, dead slow each time. The sc
>>> I added a static AuthorList::Color(int id) method in stead of a
>>> Change::Color() method, because I feel that the AuthorList is
>>> deciding on which author gets which id and thus which color. If you
>>> think it should be done differently, I'm sure you'll tell me and
I'll
>>> change
>> it
Pavel Sanda wrote:
Helge Hafting wrote:
1.6svn has recently regressed with some strange 100%cpu delays.
I can start up LyX, File->new then takes 6s. File->new again is quick.
Resizing the main window then needs 8s with 100% cpu work, which is strange
for an _empty_ file.
do you have
Latest Hot Updates
- CWNA Certified Wireless Network Administrator Offi...
- Microsoft Office Project Server 2007 The Complete ...
- Microsoft Office Access 2007 Forms Reports and Que...
- Microsoft Office Project 2007 All in One Desk Refe...
- Microsoft Excel and Access Integration With Micros...
Vincent van Ravesteijn - TNW wrote:
As Richard said, it would be nice if you didn't attach your patch as
mime as they do not appear inline with Thunderbird.
I think the problem is that the mime-type is octet-stream instead of
text.
JMarc
That's indeed what gman
Helge Hafting wrote:
> Similiar delays can happen when click to position the cursor in tables,
> but tables is not necessary for delays to happen. Cursor positioning?
i was asking because of this:
http://bugzilla.lyx.org/show_bug.cgi?id=5082
pavel
>> As Richard said, it would be nice if you didn't attach your patch as
>> mime as they do not appear inline with Thunderbird.
>
>I think the problem is that the mime-type is octet-stream instead of
text.
>
>JMarc
>
That's indeed what gmane says. I also see there that the "[patch]
Cheering up L
Pavel Sanda wrote:
Helge Hafting wrote:
1.6svn has recently regressed with some strange 100%cpu delays.
I can start up LyX, File->new then takes 6s. File->new again is quick.
Resizing the main window then needs 8s with 100% cpu work, which is strange
for an _empty_ file.
do you have
"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes:
>> I added a static AuthorList::Color(int id) method in stead of a
>> Change::Color() method, because I feel that the AuthorList is deciding
>> on which author gets which id and thus which color. If you think it
>> should be done different
Andre Poenitz <[EMAIL PROTECTED]> writes:
> On Tue, Sep 09, 2008 at 10:56:06PM +0200, Abdelrazak Younes wrote:
>>> If you haven't already, bug JMarc for commit privileges. Still always
>>> a good idea to post things for comment, unless they are very trivial.
>>> But at least then you can commit
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> As Richard said, it would be nice if you didn't attach your patch as
> mime as they do not appear inline with Thunderbird.
I think the problem is that the mime-type is octet-stream instead of
text.
JMarc
Christian Ridderström wrote:
> On Wed, 10 Sep 2008, Vincent van Ravesteijn - TNW wrote:
>
>>> what client you use?
>>
>> Thought that would be obvious by now.. MS Outlook. I'm quite out of
>> options, other than installing Thunderbird.
>
> Maybe it'd work better if you accessed the list through th
On Tue, Sep 09, 2008 at 05:50:41PM -, [EMAIL PROTECTED] wrote:
> Author: rgheck
> Date: Tue Sep 9 19:50:37 2008
> New Revision: 26348
>
> URL: http://www.lyx.org/trac/changeset/26348
> Log:
> Restore toggling behavior to math bold.
With this patch, \boldsymbol behaves on screen like \mathbf
37 matches
Mail list logo
