LyX 1.3.3cvs of Tue, May 6 2003
Built on Sep 9 2003, 23:43:50
Configuration
Host type: i586-pc-linux-gnu
Special build flags:warnings assertions
xforms-image-loader
C Compiler: gcc
C Compiler flags: -O2
C++ Compiler:
Amir Michail wrote:
> Hi,
> The discussion on this has been quite useful to us. I have
> contacted other academics at UNSW CSE and have shown them this
> thread to see what they think.
> BTW, there may be university regulations about whether we can
> require students to submit patches in a publi
Hi,
The discussion on this has been quite useful to us. I have contacted
other academics at UNSW CSE and have shown them this thread to see
what they think.
BTW, there may be university regulations about whether we can require
students to submit patches in a public forum. Some students --
parti
Andre Poenitz wrote:
> Anyway, that's rather cosmetical. Of course it needs to be fixed, but
> I'd rather have your sanitize.diff in, and I'll have a closer look in
> the evening.
This seems to be the culprit. (even if your change seems reasonable and
other parts may be adjusted instead)
Alfredo
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Lgb
>
| And now that I have your ear, what about the Nav patch?
>
| Fixes an unpleasant bug, at some cost in nav menu functionality.
I must admit that I have not looked at that at all.
So I do not know about the but, nor about the patch.
--
On Fri, Oct 24, 2003 at 11:24:29AM +0300, Martin Vermeer wrote:
>
> Now I modified lyxfunc.C so it takes the correct LyXText in this case,
> and indeed distance() works OK now. Only... the cursor doesn't
> actually get positioned. In fact it doesn't budge at all. Bummer.
>
> So we still cannot na
Alfredo Braunstein wrote:
> yep!
And thanks to Mate for that. ;-)
Alfredo
yep!
Alfredo
> Lgb
And now that I have your ear, what about the Nav patch?
Fixes an unpleasant bug, at some cost in nav menu functionality.
- Martin
pgp0.pgp
Description: PGP signature
On Fri, Oct 24, 2003 at 04:43:31PM +0200, Lars Gullik Bjønnes spake thusly:
> Loose the static.
I was wondering about that myself...
The list email really is slow today... HUT is about to get a new mail
system, as this one is in the daytime so overloaded that it takes
hours for some lyx-devel
Alfredo Braunstein wrote:
> Terribly so. Is it to be expected?
I don't think so. Of course now that you are removing bottlenecks in
the core, others elsewhere may be coming into play.
--
Angus
On Fri, Oct 24, 2003 at 04:46:31PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Fri, Oct 24, 2003 at 04:22:32PM +0200, Alfredo Braunstein wrote:
> >> Andre Poenitz wrote:
> >>
> >> > Could you send the .lyx with the problem?
> >>
> >> It's the userguide. 3.1.3 "Fine tunning t
Terribly so. Is it to be expected?
Alfredo
Andre Poenitz wrote:
> On Fri, Oct 24, 2003 at 04:22:32PM +0200, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > Could you send the .lyx with the problem?
>>
>> It's the userguide. 3.1.3 "Fine tunning the defaults."
>> But i see different rowbreaking even on the first paragraphs (in cu
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: FormMathsDelim.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormMathsDelim.C,v
| retrieving revision 1.44
| diff -u -p -r1.44 FormMathsDelim.C
| --- Form
Angus Leeming <[EMAIL PROTECTED]> writes:
| Martin Vermeer wrote:
>
>> Fixes the delimiter borkage.
>>
>> OK to commit?
>>
>> - Martin
>
| No.
>
| namespace {
>
| static int const delim_rversion[] = {...};
| static int const delim_size = sizeof(delim_rversion) / sizeof(int);
>
| } // namespace a
Martin Vermeer wrote:
> OKOKOK... attached.
>
> It even works.
;-) Then shove it in...
--
Angus
On Fri, Oct 24, 2003 at 04:22:32PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Could you send the .lyx with the problem?
>
> It's the userguide. 3.1.3 "Fine tunning the defaults."
> But i see different rowbreaking even on the first paragraphs (in current cvs
> there is typically
Andre Poenitz wrote:
> Could you send the .lyx with the problem?
It's the userguide. 3.1.3 "Fine tunning the defaults."
But i see different rowbreaking even on the first paragraphs (in current cvs
there is typically too much space spreaded around wrt. yesterday night's
cvs)
Alfredo
On Fri, Oct 24, 2003 at 03:48:59PM +0200, Andre Poenitz spake thusly:
> On Fri, Oct 24, 2003 at 02:44:48PM +, Angus Leeming wrote:
> > Martin Vermeer wrote:
> >
> > > Fixes the delimiter borkage.
> > >
> > > OK to commit?
> > >
> > > - Martin
> >
> > No.
> >
> > namespace {
> >
> > stat
On Fri, Oct 24, 2003 at 04:08:42PM +0200, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > Andre Poenitz wrote:
> >
> >> would be closer to the intention. This way, the check you added to the
> >> beginning of rowBreakPoint would not be needed as well.
> >
> > But the doesn't the heig
Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>> would be closer to the intention. This way, the check you added to the
>> beginning of rowBreakPoint would not be needed as well.
>
> But the doesn't the height etc have to be set on the row?
>
> Anyway I have to solve this first (snapshot
On Wed, 22 Oct 2003, Kayvan A. Sylvan wrote:
> That is a good idea.
>
> It might be a good idea to use bugzilla.lyx.org to enter the a feature
> request for this.
Kayvan,
According to the feedback section of the developers' Web pages, the mail
list is the proper forum for suggesting new featur
On Fri, Oct 24, 2003 at 02:44:48PM +, Angus Leeming wrote:
> Martin Vermeer wrote:
>
> > Fixes the delimiter borkage.
> >
> > OK to commit?
> >
> > - Martin
>
> No.
>
> namespace {
>
> static int const delim_rversion[] = {...};
> static int const delim_size = sizeof(delim_rversion) / size
Martin Vermeer wrote:
> Fixes the delimiter borkage.
>
> OK to commit?
>
> - Martin
No.
namespace {
static int const delim_rversion[] = {...};
static int const delim_size = sizeof(delim_rversion) / sizeof(int);
} // namespace anon
Use delim_size in place of that evil '22'.
--
Angus
Fixes the delimiter borkage.
OK to commit?
- Martin
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Index: FormMathsDelim.C
===
Andre Poenitz wrote:
> Well, I think it _is_ a special case, so better handle it as such
> in the place where it occurs and do not shift responsibility to
> rowBreakPoint.
Ok, I'll do it.
Alfredo
On Fri, Oct 24, 2003 at 01:52:12PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > would be closer to the intention. This way, the check you added to the
> > beginning of rowBreakPoint would not be needed as well.
>
> But the doesn't the height etc have to be set on the row?
Hm ye
On Fri, Oct 24, 2003 at 01:19:43PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Could you please send patches as attachment? They arrive somewhat broken
> > here.
> >
> > Look e.g. at the line starting with '> endl;' below. THis should belong
> > to the line above.
>
> It must b
Alfredo Braunstein wrote:
> A simplistic rowbreakpoint sanitizing patch... that works (or seems to).
> It's still somewhat ugly (I'm cleaning it a bit) but loads the UserGuide
> correctly.
But it's not working fine. It leaves too much space sometimes and there are
several visual glitches on the U
Andre Poenitz wrote:
> Could you please send patches as attachment? They arrive somewhat broken
> here.
>
> Look e.g. at the line starting with '> endl;' below. THis should belong
> to the line above.
It must be the mua autobreak "feature", Sorry.
Attached now.
Alfredo
? text.C-goood
? text3-sa
On Fri, Oct 24, 2003 at 01:08:47PM +0200, Alfredo Braunstein wrote:
> A simplistic rowbreakpoint sanitizing patch... that works (or seems to).
> It's still somewhat ugly (I'm cleaning it a bit) but loads the UserGuide
> correctly.
>
> Beware that it introduces a lot of asserts, but if you have the
A simplistic rowbreakpoint sanitizing patch... that works (or seems to).
It's still somewhat ugly (I'm cleaning it a bit) but loads the UserGuide
correctly.
Beware that it introduces a lot of asserts, but if you have the time, please
test it.
Index: lyxrow_funcs.C
On Fri, Oct 24, 2003 at 11:25:48AM +, Angus Leeming spake thusly:
> Lars Gullik Bjønnes wrote:
> > | Please do not try do make me think you'd like something else than
> > | begin == end for empty containers _again_...
> >
> > :-)
>
> Which would mean that we couldn't have a character/inset
On Fri, Oct 24, 2003 at 11:25:48AM +, Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
> > | Please do not try do make me think you'd like something else than
> > | begin == end for empty containers _again_...
> >
> > :-)
>
> Which would mean that we couldn't have a character/inset at
> pos
Lars Gullik Bjønnes wrote:
> | Please do not try do make me think you'd like something else than
> | begin == end for empty containers _again_...
>
> :-)
Which would mean that we couldn't have a character/inset at
pos == endpos, but it will be perfectly acceptable to have
the cursor there.
Mor
Lars Gullik Bjønnes wrote:
> I am just still battling with some preconceived notions that I have.
No problem. I had suddendly the feeling that we would start the "end vs.
last" thread again for a third time. ;-)
Relieved, Alfredo
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> | Because it it conceptually equivalent to Iterator::end(), returning
>> | one past the last element in the row.
>>
>> Is it really?
>
| Should be? This game is getting me tired.
I am just still battling with some
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 24, 2003 at 11:32:43AM +0200, Lars Gullik Bjønnes wrote:
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | I don't understand what's happening. Shouldn't row.endpos() be par->size()
>> | if the par is small enough? Someone can explai
Lars Gullik Bjønnes wrote:
> | Because it it conceptually equivalent to Iterator::end(), returning
> | one past the last element in the row.
>
> Is it really?
Should be? This game is getting me tired.
Alfredo
On Fri, Oct 24, 2003 at 11:52:00AM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> >
> >> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> >>
> >> | I don't understand what's happening. Shouldn't row.endpos() be
> >> | par->size() i
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | I don't understand what's happening. Shouldn't row.endpos() be
>> | par->size() if the par is small enough? Someone can explain to the
>> | thicko here?
>>
>> and wh
Andre Poenitz wrote:
> That's the +/-1 game I was refering to in a discussion a day or two
> ago (the one that ended in total confusion). endpos setting uses wrong
> values just to provide the opportunity to correct them later.
>
> It's complete nonsense but somehow not easily accessible to a 'sm
On Fri, Oct 24, 2003 at 11:32:43AM +0200, Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | I don't understand what's happening. Shouldn't row.endpos() be par->size()
> | if the par is small enough? Someone can explain to the thicko here?
>
> and why not par->size(
Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | I don't understand what's happening. Shouldn't row.endpos() be
> | par->size() if the par is small enough? Someone can explain to the
> | thicko here?
>
> and why not par->size() - 1?
Well, it's used like a past-t
Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | I don't understand what's happening. Shouldn't row.endpos() be
> | par->size() if the par is small enough? Someone can explain to the
> | thicko here?
>
> and why not par->size() - 1?
Because it it conceptually eq
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| I don't understand what's happening. Shouldn't row.endpos() be par->size()
| if the par is small enough? Someone can explain to the thicko here?
and why not par->size() - 1?
--
Lgb
I may be reading wrongly the code, but but seems to me that rowbreakpoint
sets row.endpos() to a value larger by 1 than it should.
I.e. (text.C:LyXText::rowBreakPoint)
if (width < 0) {
row.endpos(pit->size() + 1);
return;
}
or below
pos_type cons
And the patch.
Index: bufferview_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.117
diff -u -p -r1.117 bufferview_funcs.C
--- bufferview_funcs.C 23 Oct 2003 13:28:45 - 1
And now the fun part: This removes all width related computation from
setHeightOfRow.
It's not necessary at all as it already happend in the rowBreakPoint and
fill calls preceding setHeightOfRow.
This furthermore saves a few getPar() calls that showed (and still
show...) up prominently in a prof
On Friday 24 October 2003 8:22 am, Andre Poenitz wrote:
> I believe you are not quoting properly. The lower chunck contained a
> 'fill(...)' call as well and I just shifted the row.fill and row.width
> calls into the fill(...) function.
What I was trying to ask is, couldn't this (the top chunk in
Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | No. As I've said my post, I don't know what are the correct values (for
> | minfill, for x etc) to return when the list is empty. I don't understand
> | what the code does. I'm only pointing where the problem is, i.
On Fri, Oct 24, 2003 at 10:27:38AM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> So when the list is empty, minfill=\infty, x=\infty? Isn't the returned
> >> value x supposed to be the left margin of the row about to be added?
> >
> > Note that this code affects only the MARGIN_R
Andre Poenitz wrote:
>> So when the list is empty, minfill=\infty, x=\infty? Isn't the returned
>> value x supposed to be the left margin of the row about to be added?
>
> Note that this code affects only the MARGIN_RIGHT_ADDRESS_BOX case
> which is currently complete broken anyway (and has been
On Fri, Oct 24, 2003 at 09:15:16AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> Little nits for you ;-)
> Angus
>
> s/witdh/width/
> s/pixel/pixels/
>
> > +/// sets row.witdh to the minimum space a row needs on the
> > screen in pixel
>
> Doesn't this go contrary to your own s
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| No. As I've said my post, I don't know what are the correct values (for
| minfill, for x etc) to return when the list is empty. I don't understand
| what the code does. I'm only pointing where the problem is, i.e.
>
| int minfill = rit->fill();
>
|
On Fri, Oct 24, 2003 at 10:12:18AM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> The problem is that I don't know what's right. It may be the right margin
> >> or something. I certainly doubt the right thing it's "infinite". I'm sure
> >> Andrè will solve it in a snap...
> >
> >
Andre Poenitz wrote:
Little nits for you ;-)
Angus
s/witdh/width/
s/pixel/pixels/
> +/// sets row.witdh to the minimum space a row needs on the
> screen in pixel
Doesn't this go contrary to your own style preferences, recently
codified into Law in Rules?
-} else
+} els
Andre Poenitz wrote:
>> The problem is that I don't know what's right. It may be the right margin
>> or something. I certainly doubt the right thing it's "infinite". I'm sure
>> Andrè will solve it in a snap...
>
> From what I understand any sufficiently large value (i.e. >2000 on
> modern screen
"Jose' Matos" <[EMAIL PROTECTED]> writes:
| On Friday 24 October 2003 03:25, Lars Gullik Bjønnes wrote:
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>> | +
>> | + int minfill = ;
>>
>> This is not acceptable.
>
| How about:
>
| #include
| int minfill = std::numer
Kayvan and Lars,
here is a more complete patch which however still does not satisfy me.
It does the following things:
1) suppresses the menu shortcut for sectioning headers inside (branch,
note) insets;
2) prevents the "hanging" of LyX in the std:distance function in
text.C: parOffset().
The p
On Fri, Oct 24, 2003 at 10:03:25AM +0200, Alfredo Braunstein wrote:
> Lars Gullik Bjønnes wrote:
>
> > this 99 stuff is no good. use INT_MAX or something instead.
> >
> > std::limits::max
>
>
> The problem is that I don't know what's right. It may be the right margin or
> something. I cert
On Fri, Oct 24, 2003 at 10:03:25AM +0200, Alfredo Braunstein wrote:
> Lars Gullik Bjønnes wrote:
>
> > this 99 stuff is no good. use INT_MAX or something instead.
> >
> > std::limits::max
>
>
> The problem is that I don't know what's right. It may be the right margin or
> something. I cert
Lars Gullik Bjønnes wrote:
> this 99 stuff is no good. use INT_MAX or something instead.
>
> std::limits::max
The problem is that I don't know what's right. It may be the right margin or
something. I certainly doubt the right thing it's "infinite". I'm sure
Andrè will solve it in a snap...
On Fri, Oct 24, 2003 at 09:58:56AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Fri, Oct 24, 2003 at 04:23:23AM +0200, Lars Gullik Bjønnes wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> >> |
> >> | -typedef std::list RowList;
> >> | +typed
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Oct 24, 2003 at 04:23:23AM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> |
>> | -typedef std::list RowList;
>> | +typedef std::vector RowList;
>>
>> And you really want me to belive that this is the whol
On Fri, Oct 24, 2003 at 09:57:11AM +0200, Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> >
> >> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
> >>
> >> | +
> >> | + int minfill = ;
> >>
> >> This is not accep
See attached.
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: src/lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/l
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | +
>> | + int minfill = ;
>>
>> This is not acceptable.
>
| Do tell. Have you read the post you are answering?
Yes. But the Pub took the
On Fri, Oct 24, 2003 at 04:23:23AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> |
> | -typedef std::list RowList;
> | +typedef std::vector RowList;
>
> And you really want me to belive that this is the whole patch?
It should be much more diifficult than tha
70 matches
Mail list logo
