On Sun, Oct 19, 2003 at 06:32:15PM +0100, John Levon spake thusly:
On Sun, Oct 19, 2003 at 08:40:26PM +0300, Martin Vermeer wrote:
Would it be possible at this point to force the *row* that a displayed
math inset is on, to be aligned centre? Then (1) the offset_ hack in
formula.C will
On Sun, Oct 19, 2003 at 06:32:15PM +0100, John Levon spake thusly:
Can't we make this a little helper function ? rowBreakPoint is bad
enough already ...
Concretely, how? Anonymous namespace, and then what?
Anything that makes things cleaner is welcome...
About the remaining problems...
I am pretty confident about this one; it fixes things cleanly in the
right places with a minimum of fuss.
Attached the slightly cleaned up patch with changelogs. This handles
now mathinsets, footnote-like and floats. We can extend this as we go.
OK to commit?
- Martin
--
Martin Vermeer
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin I am pretty confident about this one; it fixes things cleanly
Martin in the right places with a minimum of fuss.
Martin Attached the slightly cleaned up patch with changelogs. This
Martin handles now mathinsets, footnote-like and floats.
Martin Vermeer [EMAIL PROTECTED] writes:
| I am pretty confident about this one; it fixes things cleanly in the
| right places with a minimum of fuss.
| Attached the slightly cleaned up patch with changelogs. This handles
| now mathinsets, footnote-like and floats. We can extend this as we go.
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
| Martin I am pretty confident about this one; it fixes things cleanly
| Martin in the right places with a minimum of fuss.
| Martin Attached the slightly cleaned up patch with changelogs. This
|
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I think not. But of course an inset should never be both newline
Lars and display at the same time. But they have different meaning.
I mean that an inset could have a breakBeforeMe and a breakAfterMe
property, and the algorithm would
On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
I am pretty confident about this one; it fixes things cleanly in the
right places with a minimum of fuss.
Attached the slightly cleaned up patch with changelogs. This handles
now mathinsets, footnote-like and floats. We can
On Mon, Oct 20, 2003 at 05:03:19PM +0200, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin I am pretty confident about this one; it fixes things cleanly
Martin in the right places with a minimum of fuss.
Martin Attached the slightly cleaned up patch
On Mon, Oct 20, 2003 at 05:12:25PM +0200, Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I think not. But of course an inset should never be both newline
Lars and display at the same time. But they have different meaning.
I mean that an inset could
On Mon, Oct 20, 2003 at 05:03:19PM +0200, Jean-Marc Lasgouttes spake thusly:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin I am pretty confident about this one; it fixes things cleanly
Martin in the right places with a minimum of fuss.
Martin Attached the slightly cleaned up
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Perhaps... but I don't see any straightforward way to do that.
Martin display() actually does a lot more: prevent stretching in
Martin block mode of the *previous* line, where isNewline() prevents
Martin stretching of *its own line*.
Andre Poenitz [EMAIL PROTECTED] writes:
| On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
I am pretty confident about this one; it fixes things cleanly in the
right places with a minimum of fuss.
Attached the slightly cleaned up patch with changelogs. This handles
now
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I think we should put it in after some of hte issues you raise
Lars is fixed.
Lars and then we can see if we shall do the breakBefore and
Lars breakAfter stuff.
Agreed.
JMarc
On Mon, Oct 20, 2003 at 05:20:58PM +0200, Andre Poenitz spake thusly:
On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
I am pretty confident about this one; it fixes things cleanly in the
right places with a minimum of fuss.
Attached the slightly cleaned up patch with
On Mon, Oct 20, 2003 at 08:19:07PM +0300, Martin Vermeer wrote:
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.465
diff -u -p -r1.465 text.C
--- text.C20 Oct 2003 13:55:51
On Sun, Oct 19, 2003 at 06:32:15PM +0100, John Levon spake thusly:
> On Sun, Oct 19, 2003 at 08:40:26PM +0300, Martin Vermeer wrote:
>
> > Would it be possible at this point to force the *row* that a displayed
> > math inset is on, to be aligned centre? Then (1) the offset_ hack in
> >
On Sun, Oct 19, 2003 at 06:32:15PM +0100, John Levon spake thusly:
> Can't we make this a little helper function ? rowBreakPoint is bad
> enough already ...
Concretely, how? Anonymous namespace, and then what?
Anything that makes things cleaner is welcome...
About the remaining problems...
I am pretty confident about this one; it fixes things cleanly in the
right places with a minimum of fuss.
Attached the slightly cleaned up patch with changelogs. This handles
now mathinsets, footnote-like and floats. We can extend this as we go.
OK to commit?
- Martin
--
Martin Vermeer
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> I am pretty confident about this one; it fixes things cleanly
Martin> in the right places with a minimum of fuss.
Martin> Attached the slightly cleaned up patch with changelogs. This
Martin> handles now mathinsets,
Martin Vermeer <[EMAIL PROTECTED]> writes:
| I am pretty confident about this one; it fixes things cleanly in the
| right places with a minimum of fuss.
>
| Attached the slightly cleaned up patch with changelogs. This handles
| now mathinsets, footnote-like and floats. We can extend this as we
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
| Martin> I am pretty confident about this one; it fixes things cleanly
| Martin> in the right places with a minimum of fuss.
>
| Martin> Attached the slightly cleaned up patch with
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think not. But of course an inset should never be both newline
Lars> and display at the same time. But they have different meaning.
I mean that an inset could have a breakBeforeMe and a breakAfterMe
property, and the
On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
> I am pretty confident about this one; it fixes things cleanly in the
> right places with a minimum of fuss.
>
> Attached the slightly cleaned up patch with changelogs. This handles
> now mathinsets, footnote-like and floats. We
On Mon, Oct 20, 2003 at 05:03:19PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> I am pretty confident about this one; it fixes things cleanly
> Martin> in the right places with a minimum of fuss.
>
> Martin> Attached the slightly
On Mon, Oct 20, 2003 at 05:12:25PM +0200, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> I think not. But of course an inset should never be both newline
> Lars> and display at the same time. But they have different meaning.
>
> I mean
On Mon, Oct 20, 2003 at 05:03:19PM +0200, Jean-Marc Lasgouttes spake thusly:
>
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> I am pretty confident about this one; it fixes things cleanly
> Martin> in the right places with a minimum of fuss.
>
> Martin> Attached the
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Perhaps... but I don't see any straightforward way to do that.
Martin> display() actually does a lot more: prevent stretching in
Martin> block mode of the *previous* line, where isNewline() prevents
Martin> stretching of *its
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
>> I am pretty confident about this one; it fixes things cleanly in the
>> right places with a minimum of fuss.
>>
>> Attached the slightly cleaned up patch with changelogs. This handles
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think we should put it in after some of hte issues you raise
Lars> is fixed.
Lars> and then we can see if we shall do the breakBefore and
Lars> breakAfter stuff.
Agreed.
JMarc
On Mon, Oct 20, 2003 at 05:20:58PM +0200, Andre Poenitz spake thusly:
>
> On Mon, Oct 20, 2003 at 06:16:35PM +0300, Martin Vermeer wrote:
> > I am pretty confident about this one; it fixes things cleanly in the
> > right places with a minimum of fuss.
> >
> > Attached the slightly cleaned up
On Mon, Oct 20, 2003 at 08:19:07PM +0300, Martin Vermeer wrote:
> Index: text.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
> retrieving revision 1.465
> diff -u -p -r1.465 text.C
> --- text.C20 Oct 2003
On Sat, Oct 18, 2003 at 03:10:58PM +0300, Martin Vermeer spake thusly:
...
I plan to try adding code testing the inset's display() and then
setting 'thiswidth' to the text width if true (at around line 723).
In that way we have the 'width fudge' back - i.e., we rely on the
existing line
On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer spake thusly:
...
Would that be a clean enough solution if it works?
Forget it... works kind-of, but not well enough (i.e. just as poorly
as fudging the width in metrics).
1) The empty line below the inset is still there... I
On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer wrote:
1) The empty line below the inset is still there... I don't really
understand it.
I somehow introduced this when hacking rowBreakPoint. ii.e. looking
there is where it is generated. But be careful ! It's hell to hack
john
--
On Sun, Oct 19, 2003 at 04:33:41PM +0100, John Levon spake thusly:
...
On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer wrote:
1) The empty line below the inset is still there... I don't really
understand it.
I somehow introduced this when hacking rowBreakPoint. ii.e. looking
On Sun, Oct 19, 2003 at 08:40:26PM +0300, Martin Vermeer wrote:
Would it be possible at this point to force the *row* that a displayed
math inset is on, to be aligned centre? Then (1) the offset_ hack in
formula.C will no longer be needed, and (2) also the cursor will be
positioned correctly
On Sat, Oct 18, 2003 at 03:10:58PM +0300, Martin Vermeer spake thusly:
...
> I plan to try adding code testing the inset's display() and then
> setting 'thiswidth' to the text width if true (at around line 723).
> In that way we have the 'width fudge' back - i.e., we rely on the
> existing
On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer spake thusly:
...
> > Would that be a clean enough solution if it works?
>
> Forget it... works kind-of, but not well enough (i.e. just as poorly
> as fudging the width in metrics).
>
> 1) The empty line below the inset is still
On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer wrote:
> 1) The empty line below the inset is still there... I don't really
> understand it.
I somehow introduced this when hacking rowBreakPoint. ii.e. looking
there is where it is generated. But be careful ! It's hell to hack
john
--
On Sun, Oct 19, 2003 at 04:33:41PM +0100, John Levon spake thusly:
...
> On Sun, Oct 19, 2003 at 02:45:07PM +0300, Martin Vermeer wrote:
>
> > 1) The empty line below the inset is still there... I don't really
> > understand it.
>
> I somehow introduced this when hacking rowBreakPoint. ii.e.
On Sun, Oct 19, 2003 at 08:40:26PM +0300, Martin Vermeer wrote:
> Would it be possible at this point to force the *row* that a displayed
> math inset is on, to be aligned centre? Then (1) the offset_ hack in
> formula.C will no longer be needed, and (2) also the cursor will be
> positioned
On Tue, Oct 14, 2003 at 02:00:56PM +, Angus Leeming spake thusly:
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
...
A brief synopsis of the problem
===
All this stuff used to be hardcoded in the core in lots and lots of
On Tue, Oct 14, 2003 at 02:00:56PM +, Angus Leeming spake thusly:
>
> Jean-Marc Lasgouttes wrote:
>
> >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
...
> A brief synopsis of the problem
> ===
> All this stuff used to be hardcoded in the core in
On Sunday 12 October 2003 3:13 pm, Martin Vermeer wrote:
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
Why not call breakLineBefore() display() and break the line after too?
Then there would be no need to fudge the width. The width is needed
as-is when trying to
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Ok, Martin, I have tried it. Indeed, the attached patch extends
Angus it so that it also 'works' with math insets. The inverted
Angus commas are there for a reason I'm afraid.
Although I tried to follow the thread, I have to admit that I
On Tue, Oct 14, 2003 at 02:34:28PM +0200, Jean-Marc Lasgouttes wrote:
How is this implemented right now?
Basically hardcoded in the core by specifically checking for NEWLINE_CODE;
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve,
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre On Tue, Oct 14, 2003 at 02:34:28PM +0200, Jean-Marc Lasgouttes
Andre wrote:
How is this implemented right now?
Andre Basically hardcoded in the core by specifically checking for
Andre NEWLINE_CODE;
OK, so the important part is the
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Ok, Martin, I have tried it. Indeed, the attached patch
extends Angus it so that it also 'works' with math insets. The
inverted Angus commas are there for a reason I'm afraid.
Although I tried to follow
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus So, the challenge is to re-introduce the ability to break the
Angus line before and/or after the inset without adding lots of code
Angus in lots of different places in the core.
As I say in the next message, the isNewline method seems to do
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
| Angus So, the challenge is to re-introduce the ability to break the
| Angus line before and/or after the inset without adding lots of code
| Angus in lots of different places in the core.
| As I
On Sunday 12 October 2003 3:13 pm, Martin Vermeer wrote:
> On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
> > Why not call breakLineBefore() display() and break the line after too?
> > Then there would be no need to fudge the width. The width is needed
> > as-is when trying
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Ok, Martin, I have tried it. Indeed, the attached patch extends
Angus> it so that it also 'works' with math insets. The inverted
Angus> commas are there for a reason I'm afraid.
Although I tried to follow the thread, I have to
On Tue, Oct 14, 2003 at 02:34:28PM +0200, Jean-Marc Lasgouttes wrote:
> How is this implemented right now?
Basically hardcoded in the core by specifically checking for NEWLINE_CODE;
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve,
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Tue, Oct 14, 2003 at 02:34:28PM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> How is this implemented right now?
Andre> Basically hardcoded in the core by specifically checking for
Andre> NEWLINE_CODE;
OK, so the important
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Ok, Martin, I have tried it. Indeed, the attached patch
> extends Angus> it so that it also 'works' with math insets. The
> inverted Angus> commas are there for a reason I'm afraid.
>
> Although I
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> So, the challenge is to re-introduce the ability to break the
Angus> line before and/or after the inset without adding lots of code
Angus> in lots of different places in the core.
As I say in the next message, the isNewline method
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
| Angus> So, the challenge is to re-introduce the ability to break the
| Angus> line before and/or after the inset without adding lots of code
| Angus> in lots of different places in the
Martin Vermeer wrote:
On Fri, Oct 10, 2003 at 12:39:44PM +0100, John Levon spake thusly:
On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
I attach Martin's original patch, 1147 lines. Could people look
it over again in the light of our current experience and comment
on
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
584 InsetOld * inset = pit-getInset(z);
585 if (inset-breakLineBefore()) // bool to be
impl
586 // suppress filling of line
587 f = 0;
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
Why not call breakLineBefore() display() and break the line after too?
Then there would be no need to fudge the width. The width is needed
as-is when trying to render a pixmap image on the screen I think...
Okay, the
On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
Okay, the attached patch fixes the reported problem of previous-line
stetch -- but for footnote only -- and does nothing more. (I did
change the name to display() :-) Please test it.
Now all you need is to reintroduce the cursor
John Levon wrote:
On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
Okay, the attached patch fixes the reported problem of
previous-line stetch -- but for footnote only -- and does nothing
more. (I did change the name to display() :-) Please test it.
Now all you need is to
On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
Okay, the attached patch fixes the reported problem of
previous-line stetch -- but for footnote only -- and does nothing
more. (I did change the name to display() :-) Please test it.
Now all you need is to reintroduce the
On Sun, Oct 12, 2003 at 04:35:49PM +0100, John Levon spake thusly:
On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
Okay, the attached patch fixes the reported problem of
previous-line stetch -- but for footnote only -- and does nothing
more. (I did change the name to
On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
Cursor placement problems? Where? Connected to this problem/patch?
That placing the cursor on the end of a line ends up on the next line
etc.
Assertion triggered in const class LyXFont
Paragraph::getFontSettings(const
On Sun, Oct 12, 2003 at 05:06:22PM +0100, John Levon spake thusly:
On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
Cursor placement problems? Where? Connected to this problem/patch?
That placing the cursor on the end of a line ends up on the next line
etc.
Yes, I
On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
Yes, I remember the discussion on that, or rather, about what the End
key did/should do.
But does this patch make it worse?
No, which is why I said then ...
john
--
Khendon's Law:
If the same point is made twice by the same
On Sun, Oct 12, 2003 at 05:27:40PM +0100, John Levon spake thusly:
On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
Yes, I remember the discussion on that, or rather, about what the End
key did/should do.
But does this patch make it worse?
No, which is why I said
On Sun, Oct 12, 2003 at 08:08:48PM +0300, Martin Vermeer wrote:
So, again, did anything you wrote earlier in this thread constitute an
objection to this patch? (If I understood you correctly, no.)
You understand me correctly
john
--
Khendon's Law:
If the same point is made twice by the same
Martin Vermeer wrote:
> On Fri, Oct 10, 2003 at 12:39:44PM +0100, John Levon spake thusly:
>>
>> On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
>>
>> > I attach Martin's original patch, 1147 lines. Could people look
>> > it over again in the light of our current experience and
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
> > 584 InsetOld * inset = pit->getInset(z);
> > 585 if (inset->breakLineBefore()) // bool to be
> > impl
> > 586 // suppress filling of line
> > 587
On Sun, Oct 12, 2003 at 09:48:59AM +, Angus Leeming spake thusly:
> Why not call breakLineBefore() display() and break the line after too?
> Then there would be no need to fudge the width. The width is needed
> as-is when trying to render a pixmap image on the screen I think...
Okay, the
On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
> Okay, the attached patch fixes the reported problem of previous-line
> stetch -- but for footnote only -- and does nothing more. (I did
> change the name to display() :-) Please test it.
Now all you need is to reintroduce the
John Levon wrote:
> On Sun, Oct 12, 2003 at 06:13:52PM +0300, Martin Vermeer wrote:
>
>> Okay, the attached patch fixes the reported problem of
>> previous-line stetch -- but for footnote only -- and does nothing
>> more. (I did change the name to display() :-) Please test it.
>
> Now all you
On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
> >> Okay, the attached patch fixes the reported problem of
> >> previous-line stetch -- but for footnote only -- and does nothing
> >> more. (I did change the name to display() :-) Please test it.
> >
> > Now all you need is to
On Sun, Oct 12, 2003 at 04:35:49PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 04:29:41PM +, Angus Leeming wrote:
>
> > >> Okay, the attached patch fixes the reported problem of
> > >> previous-line stetch -- but for footnote only -- and does nothing
> > >> more. (I did change
On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
> Cursor placement problems? Where? Connected to this problem/patch?
That placing the cursor on the end of a line ends up on the next line
etc.
> "Assertion triggered in const class LyXFont
> Paragraph::getFontSettings(const
On Sun, Oct 12, 2003 at 05:06:22PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 07:14:39PM +0300, Martin Vermeer wrote:
>
> > Cursor placement problems? Where? Connected to this problem/patch?
>
> That placing the cursor on the end of a line ends up on the next line
> etc.
Yes, I
On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
> Yes, I remember the discussion on that, or rather, about what the End
> key did/should do.
>
> But does this patch make it worse?
No, which is why I said "then ..."
john
--
Khendon's Law:
If the same point is made twice by the
On Sun, Oct 12, 2003 at 05:27:40PM +0100, John Levon spake thusly:
> On Sun, Oct 12, 2003 at 07:41:21PM +0300, Martin Vermeer wrote:
>
> > Yes, I remember the discussion on that, or rather, about what the End
> > key did/should do.
> >
> > But does this patch make it worse?
>
> No, which is
On Sun, Oct 12, 2003 at 08:08:48PM +0300, Martin Vermeer wrote:
> So, again, did anything you wrote earlier in this thread constitute an
> objection to this patch? (If I understood you correctly, no.)
You understand me correctly
john
--
Khendon's Law:
If the same point is made twice by the
On Fri, Oct 10, 2003 at 12:39:44PM +0100, John Levon spake thusly:
On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
I attach Martin's original patch, 1147 lines. Could people look it
over again in the light of our current experience and comment on
which bits should be
On Fri, Oct 10, 2003 at 12:39:44PM +0100, John Levon spake thusly:
>
> On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
>
> > I attach Martin's original patch, 1147 lines. Could people look it
> > over again in the light of our current experience and comment on
> > which bits
On Thu, Oct 09, 2003 at 05:53:05PM +, Angus Leeming wrote:
It seems to me that display mode is not local to a single inset but
affects the rows above and below. In other words it _is_ the core
that should handle this.
If it is not just previewed math, a solution in the core is fine.
I
On Thu, Oct 09, 2003 at 06:49:11PM +0200, Lars Gullik Bjønnes spake thusly:
Andre Poenitz [EMAIL PROTECTED] writes:
| On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
This got rid of fullRow but also got rid of the logic controlling
display(). Looks like it was a little
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Wrong is in the eyes of the beholder. The line before is
Martin stretched indicating that the inset is part of the line.
This is just plain ugly. If we want to indicate that the inset is pat
of the paragraph, we should show the corners
Jean-Marc Lasgouttes wrote:
Not only math. Stretching a line like that should not happen.
Martin Angus's idea of adding an invisible newline (or invisible
Martin horizontal stretch?) sounds good to me.
I'd rather see the display() stuff restored.
I attach Martin's original patch, 1147
On Fri, Oct 10, 2003 at 09:33:09AM +0200, Jean-Marc Lasgouttes spake thusly:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Wrong is in the eyes of the beholder. The line before is
Martin stretched indicating that the inset is part of the line.
This is just plain ugly. If we
Martin Vermeer wrote:
One question: should it also not happen if the inset is, e.g., an
insetERT in in-line mode, i.e., shorter than the text width? I can
see why you have a problem with it aestetically, but how to be
consistent?
'Consistent' here means 'allow the inset to decide how it
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin One question: should it also not happen if the inset is, e.g.,
Martin an insetERT in in-line mode, i.e., shorter than the text
Martin width? I can see why you have a problem with it aestetically,
Martin but how to be consistent?
I tend
On Fri, Oct 10, 2003 at 09:53:28AM +, Angus Leeming spake thusly:
Why not if it cures the current problem.
Rename the function 'breakLineAfter' and add a function
'breakLineBefore' or some such and all should be clear for posterity
too ;-)
--
Angus
Hmmm, playing around now.
On Fri, Oct 10, 2003 at 08:57:03AM +, Angus Leeming wrote:
I attach Martin's original patch, 1147 lines. Could people look it
over again in the light of our current experience and comment on
which bits should be returned.
I have not been following this discussion (sorry), but reverting
On Thu, Oct 09, 2003 at 05:53:05PM +, Angus Leeming wrote:
> It seems to me that display mode is not local to a single inset but
> affects the rows above and below. In other words it _is_ the core
> that should handle this.
If it is not just previewed math, a solution in the core is fine.
I
On Thu, Oct 09, 2003 at 06:49:11PM +0200, Lars Gullik Bjønnes spake thusly:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Oct 09, 2003 at 05:29:13PM +, Angus Leeming wrote:
> >> This got rid of fullRow but also got rid of the logic controlling
> >> display(). Looks like it was
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> "Wrong" is in the eyes of the beholder. The line before is
Martin> stretched indicating that the inset is part of the line.
This is just plain ugly. If we want to indicate that the inset is pat
of the paragraph, we should show
Jean-Marc Lasgouttes wrote:
> Not only math. Stretching a line like that should not happen.
>
> Martin> Angus's idea of adding an invisible newline (or invisible
> Martin> horizontal stretch?) sounds good to me.
>
> I'd rather see the display() stuff restored.
I attach Martin's original patch,
On Fri, Oct 10, 2003 at 09:33:09AM +0200, Jean-Marc Lasgouttes spake thusly:
>
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> "Wrong" is in the eyes of the beholder. The line before is
> Martin> stretched indicating that the inset is part of the line.
>
> This is
Martin Vermeer wrote:
> One question: should it also not happen if the inset is, e.g., an
> insetERT in in-line mode, i.e., shorter than the text width? I can
> see why you have a problem with it aestetically, but how to be
> consistent?
'Consistent' here means 'allow the inset to decide how it
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> One question: should it also not happen if the inset is, e.g.,
Martin> an insetERT in in-line mode, i.e., shorter than the text
Martin> width? I can see why you have a problem with it aestetically,
Martin> but how to be
1 - 100 of 130 matches
Mail list logo
