Re: A lyx::stringstream containing font info?
On Mon, Oct 20, 2003 at 10:06:58PM +, Angus Leeming wrote:
> I'm a bit pissed off with the way we handle fonts and strings.
Good starting point.
> It seems to me that we are duplicating code in the inset metrics and
> draw functions. Only in the very inner block of code do things
> differ, one ascertaining the width of the string in this particular
> font and the other calling the painter with this info.
>
> As an example, I append the code from render_graphic.C to print out a
> diagnostic message.
>
> It seems to me that this mess could be avoided if we had some
> container that could contain both the string and the font information.
> Indeed, the STL stream classes do something very similar.
>
> I can imagine code like:
>
> void RenderGraphic::metrics(MetricsInfo & mi, Dimension & dim) const
> {
> if (!image_ready)
> lyx::rendered_stringstream rss;
> create_message(rss);
> dim.wid = std::max(50, rss.width() + 15);
> }
> }
>
> RenderGraphic::draw(PainterInfo & pi, int x, int y) const
> {
> if (!image_ready)
> lyx::rendered_stringstream rss;
> create_message(rss);
> pi.pain.text(x + InsetOld::TEXT_TO_INSET_OFFSET + 6, y - 4,
> rss);
> }
> }
>
> where the magical helper function contained code like:
>
> void RenderGraphic::create_message(lyx::rendered_stringstream & rss)
> {
> rss << setFont(mi.base.font)
> << setFamily(LyXFont::SANS_FAMILY);
>
> string const justname = OnlyFilename(params_.filename);
> if (!justname.empty()) {
> rss << setSize(LyXFont::SIZE_FOOTNOTE)
> << justname;
> }
>
> string const msg = statusMessage(loader_.status());
> if (!msg.empty()) {
> rss << setSize(LyXFont::SIZE_TINY)
> << msg;
> }
> }
>
> Is this just a wild flight of fancy, or does anybody else think that
> it's a sensible proposal?
I think this could be handled on a case-by-case base by using some
helper functions in the insets that really need it.
Most insets are simple enough not to need such a thing, so any generic
solution is like to complicate matters.
However, we certainly _have_ a font problem. I'll ask a question in the
next mail ;-} IMNSHO the optimal solution would be "font insets" but
we'd need Asger's three-box model for insets implemented to go this
route...
> ps, current code follows...
That's indeed a case that could make use a local helper function.
But I don't think this very helper would be useful for, say,
MathSqrtInset.
Andre'
Fonts
text2.C:153 // Realize with the fonts of lesser depth. tmpfont.realize(outerFont(pit, ownerParagraphs())); tmpfont.realize(defaultfont_); text2.C:169 // Realize with the fonts of lesser depth. font.realize(outerFont(pit, ownerParagraphs())); font.realize(defaultfont_); Under which circumstances is the 'outerFont' lines necessary? I.e. what does a .lyx file look like that behaves differently with and without these two lines? Andre' -- 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...)
Re: [PATCH] Inverse search update.
Angus Leeming wrote: > Alfredo Braunstein wrote: > >> btw, how should we introduce source-latex only for view->dvi? a >> latexflavour? > > Your pet project surfaces again? Why not try and put a few thoughts > down on e-paper about how it might be implemented and we can knock > some ideas around. Yes... somehow. I think that using latex flavours one can get a hackish but simple solution fast (and I suggest Joao Luis to have a look at that). Maybe I'll follow your advice and write something about my (even if for starters, I've tried to have you doing it from the very beginning, and you have rejected every stroke with a Winbledon-level swing) pet project (mostly what we have discussed in Chemnitz). I don't think, however, that hacking into that is a wise thing to do now: I'll probably better fix some bugs in my spare time, instead of introducing new ones in what is probably the last non-regressed part of the code... ;-) > Angus (back from a long w/e in a beautiful, but cold, Budapest.) Completely OT! (no envy here ;-) Alfredo
Re: Fonts
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> text2.C:153 Andre> // Realize with the fonts of lesser depth. Andre> tmpfont.realize(outerFont(pit, ownerParagraphs())); Andre> tmpfont.realize(defaultfont_); Andre> text2.C:169 Andre> // Realize with the fonts of lesser depth. Andre> font.realize(outerFont(pit, ownerParagraphs())); Andre> font.realize(defaultfont_); Andre> Under which circumstances is the 'outerFont' lines necessary? Andre> I.e. what does a .lyx file look like that behaves differently Andre> with and without these two lines? Assume that the Theorem layout puts its contents in italics. Then, any Standard (or itemize...) layout that is included in the theorem (depth=1) will inherit this italics setting. Is that clear? JMarc
Re: [CRASH] with 1.4.0cvs (fwd)
> "Alain" == Alain Castera <[EMAIL PROTECTED]> writes: Alain> Hi All. Alain> I apologize to bore you again, but I got no reaction to this Alain> message. Should I file a bug under bugzilla ? Or is it a Alain> temporary effect of using cvs version ? Please file a bug. I am not able to look at it right now. JMarc
Re: A lyx::stringstream containing font info?
Andre Poenitz wrote:
>> Is this just a wild flight of fancy, or does anybody else think
>> that it's a sensible proposal?
>
> I think this could be handled on a case-by-case base by using some
> helper functions in the insets that really need it.
Actually, I did some reading and I think I have stumbled across
something very powerful.
The C++ streams allow us to define arbitrary new modifiers --- and
enable subsequent operations on the stream to be aware of them. For
example, the code below would be used
std::ostringstream os;
os << font::setFamily(font::SERIF) << "André "
<< font::setFamily(font::SANS_SERIF) << "Pönitz\n";
Note that it works on existing stream types!!! Thereafter one would
need to write a 'decipherer'. For example, something to establish the
width of the string in this font, or to paint it, but the beauty is
that this 'mark-up' is entirely separate.
Don't you think that that is beautiful? A built-in stack of string
modifiers. I can imagine latex output, html output etc, etc, just by
parsing a stringstream.
namespace font {
enum Family {
SERIF,
SANS_SERIF,
TYPEWRITER
};
class setFamily {
public:
static int getAlloc() { return xalloc_id_; }
explicit setFamily(Family family) : family_(family) {}
friend std::ostream & operator<<(std::ostream &, setFamily const &);
private:
Family family_;
static int const xalloc_id_;
};
int const setFamily::xalloc_id_ = std::ios_base::xalloc();
std::ostream & operator<<(std::ostream & os, setFamily const & sf)
{
os.iword(CName::GetAlloc()) = sf.family_;
return os;
}
} // namespace font
--
Angus
Re: LyX/Mac - beta testers wanted for new release
Ronald Florence wrote: > I welcome beta testers for a new release of LyX/Mac. New features: > > - Inverse DVI search: if you use MacDviX with Preview -> DVI, you > can Option-Click in the DVI window and have LyX jump to the > corresponding point in the source file. The feature should also > work with xdvi. > > - Simplified installation, even on configurations where the user's > home directory is on a symbolic link or remotely mounted. > > - Automatically installs the preview-latex and srcltx LaTeX > macros. > > Prerequisites are MacOS-10.2 and a teTeX installation, including > libiconv, which is normally part of the Wierda and fink > installations. > If you're interested, email me for download information. Installing > the new version takes a few minutes. Thanks, Ronald, what's going on here! Are you backporting João's stuff to the 1.3.x branch? If that is the case, I am 100% against this 'new release'. It is _very_ experimental code and completely untested. Indeed, we _know_ it isn't finished yet. Regards, Angus
Re: A lyx::stringstream containing font info?
On Tue, Oct 21, 2003 at 09:25:46AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> >> Is this just a wild flight of fancy, or does anybody else think
> >> that it's a sensible proposal?
> >
> > I think this could be handled on a case-by-case base by using some
> > helper functions in the insets that really need it.
>
> Actually, I did some reading and I think I have stumbled across
> something very powerful.
>
> The C++ streams allow us to define arbitrary new modifiers --- and
> enable subsequent operations on the stream to be aware of them. For
> example, the code below would be used
> std::ostringstream os;
> os << font::setFamily(font::SERIF) << "Andr? "
><< font::setFamily(font::SANS_SERIF) << "P?nitz\n";
I know this in theory but never managed to work with that in praxi.
I wanted to transform the different "math output stream" to a scheme
like that at one point of time but then got distracted somehow...
> Note that it works on existing stream types!!! Thereafter one would
> need to write a 'decipherer'. For example, something to establish the
> width of the string in this font, or to paint it, but the beauty is
> that this 'mark-up' is entirely separate.
Not really, is it?
You just modify some state of the stream (i.e. to "SERIF"). Than every
write on that stream has to check this state and respond to it.
It is not a kind of out-of-band signalling, rather some fancy way to add
more data room to a stream.
This safes you writing lots of 'operator<<' for the standard types like
int, double, ... fro your custom streams, but that's it.
> class setFamily {
> public:
> static int getAlloc() { return xalloc_id_; }
>
> explicit setFamily(Family family) : family_(family) {}
> friend std::ostream & operator<<(std::ostream &, setFamily const &);
> private:
> Family family_;
> static int const xalloc_id_;
> };
>
> int const setFamily::xalloc_id_ = std::ios_base::xalloc();
>
> std::ostream & operator<<(std::ostream & os, setFamily const & sf)
> {
> os.iword(CName::GetAlloc()) = sf.family_;
> return os;
> }
And now you've got some new state in the stream object. It does not
affect the data buffer at all. This is basically only syntactic sugar
over
void write(ostream & os, MyObject const &, SomeExtraData const & extra)
by combining 'os' and 'extra' and re-using operator<<() for the base
types.
Andre'
--
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...)
Re: A lyx::stringstream containing font info?
Angus Leeming wrote:
> std::ostream & operator<<(std::ostream & os, setFamily const & sf)
> {
> os.iword(CName::GetAlloc()) = sf.family_;
Ouch! That's
os.iword(setFamily::getAlloc()) = sf.family_;
> return os;
> }
>
> } // namespace font
>
>
--
Angus
Re: Inset display?
On Tue, Oct 21, 2003 at 09:33:29AM +0300, Martin Vermeer spake thusly: > > On Mon, Oct 20, 2003 at 09:10:51PM +, Angus Leeming spake thusly: ... > I have experimentally placed display() =true in footnote/marginnote > and floatinsets. I think eventually we want to make all collapsable > insets displayed *when open*. > > As for insetinclude, insettoc etc. -- the "button insets", I wonder. > The current system, with center_indent_ and the button as a sensitive > box, works. But we need display() in order to make the line above the > inset not stretch. So once we have it, I suppose we could get rid of > center_indent as the inset will be centered anyway. But I would leave > the button box logic in place -- it's only three lines and it's IMHO > conceptually wise to distinguish inset and button. But that's just my > opinion. Attached is a patch that does the following: 1) André's remaining points (define things as locally as you can) 2) The "silly" bug is now eliminated. It consisted actually of two sub-bugs: a) After a text-wide/displayed inset, an extra row would be produced not containing any character belonging to the par. This is fixed in the second chunk of text.C. Fundamentally correctly, I believe. b) Empty paragraphs. Both when starting a new document, and when having (or creating) an empty inset. This is handled in the third chunk of text.C: don't try to access even the first character in an empty paragraph. 3) display() is now made true for a) Opened collapsable insets b) "Button insets" like insetinclude, insetindex etc. ... and of course display mode math insets. I haven't done anything to remove center_indent yet (this will produce a problem with the input inset BTW, which according to policy (?) should be displayed but not centered :-( ) Can this go in (as it is the polishing touch on the inset display patch)? - Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Dept. of Surveying, Inst. of Geodesy P.O. Box 1200, FIN-02015 HUT, Finland :wq x.diff.gz Description: application/gunzip pgp0.pgp Description: PGP signature
Re: Inset display?
On Tue, Oct 21, 2003 at 12:10:38PM +0300, Martin Vermeer wrote: > Can this go in (as it is the polishing touch on the inset display > patch)? Yes. Andre'
dvi search
I somehow lost track: Is this in? If so, does it work with xdvi 22.40h (Stock SuSE 8.1)? If so, how? Andre' -- 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...)
Re: A lyx::stringstream containing font info?
Andre Poenitz wrote:
> On Tue, Oct 21, 2003 at 09:25:46AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> >> Is this just a wild flight of fancy, or does anybody else think
>> >> that it's a sensible proposal?
>> >
>> > I think this could be handled on a case-by-case base by using
>> > some helper functions in the insets that really need it.
>>
>> Actually, I did some reading and I think I have stumbled across
>> something very powerful.
>>
>> The C++ streams allow us to define arbitrary new modifiers --- and
>> enable subsequent operations on the stream to be aware of them. For
>> example, the code below would be used
>> std::ostringstream os;
>> os << font::setFamily(font::SERIF) << "Andr? "
>><< font::setFamily(font::SANS_SERIF) << "P?nitz\n";
>
> I know this in theory but never managed to work with that in praxi.
>
> I wanted to transform the different "math output stream" to a scheme
> like that at one point of time but then got distracted somehow...
>
>> Note that it works on existing stream types!!! Thereafter one would
>> need to write a 'decipherer'. For example, something to establish
>> the width of the string in this font, or to paint it, but the
>> beauty is that this 'mark-up' is entirely separate.
>
> Not really, is it?
>
> You just modify some state of the stream (i.e. to "SERIF"). Than
> every write on that stream has to check this state and respond to
> it.
>
> It is not a kind of out-of-band signalling, rather some fancy way to
> add more data room to a stream.
>
> This safes you writing lots of 'operator<<' for the standard types
> like int, double, ... fro your custom streams, but that's it.
> And now you've got some new state in the stream object. It does not
> affect the data buffer at all. This is basically only syntactic
> sugar over
>
>void write(ostream & os, MyObject const &, SomeExtraData const &
>extra)
>
> by combining 'os' and 'extra' and re-using operator<<() for the base
> types.
My main point is that the metrics and draw routines repeat large
blocks of code and that my separating the information from the way it
is used we can only win.
I agree that we need to operate on the resulting data and I openly
admit that I haven't read enough to do that. Perhaps you can help
fill in my knowledge gap?
I imagine something like
int fontWidth(std::ostream & os) {
int width = 0;
std::ostream::iterator it = os.begin();
std::ostream::iterator end = os.end();
for (; it != end; ++it) {
int const family = os.iword(setFamily::getAlloc())
if (family == -1) {
std::cout << "Family data not set\n";
continue;
}
LyXFont font(family);
width += (*it, font);
}
return width;
}
But such a stream would also allow the frontends to implement their
own mark-up. Ie, pass a stringstream to the dialog and get bold and
italic mark up in the right places.
Regards,
Angus
Re: dvi search
Andre Poenitz wrote:
> I somehow lost track: Is this in?
Partially. There's a patch waiting for approval (support for sockets on qt
and shell variables fiddling). And you still have to define latex
--source-specials as your latex->dvi converter (if supported) or manually
\include[active]{srcltx.sty}.
> If so, does it work with xdvi 22.40h (Stock SuSE 8.1)?
No idea. xdvi 22.05 doesn't.
Alfredo
Re: dvi search
Andre Poenitz wrote: > > I somehow lost track: Is this in? Yes. > If so, does it work with xdvi 22.40h (Stock SuSE 8.1)? > If so, how? > Andre' You need two things. 1. Either a latex compiler that understands the --src-specials flag or the srcltx package. Here, my latex does not understand the flag so I installed the package. 2. A dvi viewer that can pass info back to João's lyxclient. xdvi -editor 'lyxclient -g %f %l' your_file Apparently you need at least xdvi-22.38, so you should be ok. Compile lyxclient (in development/lyxsocket), put it in you path and you should be away. -- Angus
Re: LyX/Mac - beta testers wanted for new release
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Ronald, what's going on here! Are you backporting João's stuff Angus> to the 1.3.x branch? If that is the case, I am 100% against Angus> this 'new release'. Actually he is using the code against 1.3.x send a long time ago by Joao. Angus> It is _very_ experimental code and completely untested. Indeed, Angus> we _know_ it isn't finished yet. Keep in mind that macosx is a relatively well defined environment, where things are easier to get right. And no, I do not plan to include this in 1.3.x. JMarc
Re: LyX/Mac - beta testers wanted for new release
On Tuesday 21 October 2003 9:10 am, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Ronald, what's going on here! Are you backporting João's stuff > Angus> to the 1.3.x branch? If that is the case, I am 100% against > Angus> this 'new release'. > > Actually he is using the code against 1.3.x send a long time ago by > Joao. > > Angus> It is _very_ experimental code and completely untested. Indeed, > Angus> we _know_ it isn't finished yet. > > Keep in mind that macosx is a relatively well defined environment, > where things are easier to get right. > > And no, I do not plan to include this in 1.3.x. Thanks for putting me straight. I thought I'd better query this but sent the mail to the devel list rather than the users list because I didn't know the details. Regards, Angus
Re: A lyx::stringstream containing font info?
On Tue, Oct 21, 2003 at 10:04:44AM +, Angus Leeming wrote:
> My main point is that the metrics and draw routines repeat large
> blocks of code
Only in a few cases in which we could have a local helper function which
is called from both. Unless I miss the point completely...
> and that my separating the information from the way it
> is used we can only win.
>
> I agree that we need to operate on the resulting data and I openly
> admit that I haven't read enough to do that. Perhaps you can help
> fill in my knowledge gap?
I assume we are still talking about metrics/draw and not about output
formats. [For output it somehow would make much more sense...]
> I imagine something like
> int fontWidth(std::ostream & os) {
> int width = 0;
> std::ostream::iterator it = os.begin();
> std::ostream::iterator end = os.end();
> for (; it != end; ++it) {
> int const family = os.iword(setFamily::getAlloc())
> if (family == -1) {
> std::cout << "Family data not set\n";
> continue;
> }
> LyXFont font(family);
> width += (*it, font);
> }
> return width;
> }
I fail to see how this should work. At what point of time are you
actually writing to the ostream?
Is the stream already "filled" when passed to fontWidth()?
It seems you assume that the extra data somehow sticks to the position
in the stream where it is written. It does not work like that. This
extra data is "stream global data" which gets overwritten the second
time you write to it and it does not store a position or anything
similar.
Furthermore, I don't really see why it should be needed. We already have
a mechanism set up to pass data to metrics() _and_ draw(): The
MetricsBase structure. Which has a few advanteages:
1. It's there already and works.
2. It was specifically "designed" for this task of passing information
to metrics() and draw() [It's part of MetricsInfo and PainterInfo]
3. It already contains a "LyXFont"
4. .. and a few more items with more or less sensible names and thus..
5. .. has more decent access than 'word' sizes anonymous chunks
If you want to store record a certain width, try using the inset's
dim_.wid, or if you need something completely different, add a new
'fancy_width_' cache-variable to the inset, set it's value in metrics()
and use in in draw().
> But such a stream would also allow the frontends to implement their
> own mark-up. Ie, pass a stringstream to the dialog and get bold and
> italic mark up in the right places.
I am not sure why you need markup in some string. You won't get markup
_in_ the stream this way.
What problem are you trying to solve that's not solvable by locally
factoring out some common code from metrics() and draw() in a few fat
insets?
Andre'
--
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...)
Re: dvi search
On Tue, Oct 21, 2003 at 10:11:06AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > > > I somehow lost track: Is this in? > > Yes. > > > If so, does it work with xdvi 22.40h (Stock SuSE 8.1)? > > If so, how? > > Andre' > > You need two things. > 1. Either a latex compiler that understands the --src-specials flag or > the srcltx package. Here, my latex does not understand the flag so I > installed the package. --src-specials seems to be supported here. > 2. A dvi viewer that can pass info back to Jo?o's lyxclient. > > xdvi -editor 'lyxclient -g %f %l' your_file > > Apparently you need at least xdvi-22.38, so you should be ok. It seems to be ok. > Compile lyxclient (in development/lyxsocket), put it in you path and > you should be away. Not really. Both ways. The lyxclient does not seems to talk to lyx properly. Opening $EDITOR from xdvi works fine. How do I start lyxclient manually if I want to go to a certain line? lyxclient -g newfile16.lyx 13 brings up a 'document is already loaded, want to switch' dialog. The buttons present me with a choice of immediate crash or full freeze. So it "sort of works", but not really automatic, nor robust... Andre'
Re: A lyx::stringstream containing font info?
Andre Poenitz wrote:
> On Tue, Oct 21, 2003 at 10:04:44AM +, Angus Leeming wrote:
>> My main point is that the metrics and draw routines repeat large
>> blocks of code
>
> Only in a few cases in which we could have a local helper function
> which is called from both. Unless I miss the point completely...
No, you're right. That was the original motivation.
>> and that my separating the information from the way it
>> is used we can only win.
>>
>> I agree that we need to operate on the resulting data and I openly
>> admit that I haven't read enough to do that. Perhaps you can help
>> fill in my knowledge gap?
>
> I assume we are still talking about metrics/draw and not about
> output formats. [For output it somehow would make much more
> sense...]
I know and agree. But really that is the point. All these various
'applications' are doing the same logical stuff in different ways at
the moment.
>> I imagine something like
>> int fontWidth(std::ostream & os) {
>> }
>
> I fail to see how this should work. At what point of time are you
> actually writing to the ostream?
>
> Is the stream already "filled" when passed to fontWidth()?
Yes!
std::ostringstream os;
os << font::setFamily(font::SERIF) << "Andre"
<< font::setFamily(font::SANS_SERIF) << "Ponitz";
> It seems you assume that the extra data somehow sticks to the
> position in the stream where it is written. It does not work like
> that. This extra data is "stream global data" which gets overwritten
> the second time you write to it and it does not store a position or
> anything similar.
Ok, thanks. I did not understand that. However, before I stumbled
across the xalloc stuff I had a mental picture of a 'fontstream'.
Something like
class fontstream: public::basic_ostream<> {
private:
std::ostringstream data;
std::stack positionstack;
std::stack weightstack;
};
Of course this would need lots of operator<< methods to either fill
the stringstream or add font info to the stacks (in the setFamily etc
version of ostream<<).
Now, this 'fontstream' would most certainly have the info I imagined
and could be subsequently iterated over by
int fontWidth(fontstream const &);
int paint(fontstream const &, Painter &);
void latex(std::ostream &, fontstream const &);
etc
> Furthermore, I don't really see why it should be needed. We already
> have a mechanism set up to pass data to metrics() _and_ draw(): The
> MetricsBase structure. Which has a few advanteages:
>
> 1. It's there already and works.
> 2. It was specifically "designed" for this task of passing
> information
> to metrics() and draw() [It's part of MetricsInfo and
> PainterInfo]
> 3. It already contains a "LyXFont"
> 4. .. and a few more items with more or less sensible names and
> thus.. 5. .. has more decent access than 'word' sizes anonymous
> chunks
I know and I started off this thread by saying that I was pissed off
that I had to do essentially the same thing twice, remember?
> If you want to store record a certain width, try using the inset's
> dim_.wid, or if you need something completely different, add a new
> 'fancy_width_' cache-variable to the inset, set it's value in
> metrics() and use in in draw().
>> But such a stream would also allow the frontends to implement their
>> own mark-up. Ie, pass a stringstream to the dialog and get bold and
>> italic mark up in the right places.
>
> I am not sure why you need markup in some string. You won't get
> markup _in_ the stream this way.
You would in the way I describe above though...
> What problem are you trying to solve that's not solvable by locally
> factoring out some common code from metrics() and draw() in a few
> fat insets?
Have I answered this question with the above? I _really_ would like
the ability to mark-up text handled by the frontends and think that a
fully-fledged widget embedding one of our Painters would be excessive
in many instances...
--
Angus
Re: dvi search
Andre Poenitz wrote: > The buttons present me with a choice of immediate crash or full > freeze. So it "sort of works", but not really automatic, nor > robust... Be fair, André. It's new code and I'm sure that its author would welcome prescriptions to make it fail... -- Angus
Optional arguments to elsart styles.
How about this Jean-Marc? diff -u -p -r1.8 elsart.layout --- lib/layouts/elsart.layout 13 Oct 2003 09:50:09 - 1.8 +++ lib/layouts/elsart.layout 21 Oct 2003 10:50:21 - @@ -122,6 +122,7 @@ Style Author ParSep0 Align Center AlignPossible Center + OptionalArgs 1 Font Series Bold EndFont @@ -137,6 +138,7 @@ Style Author_Address AlignPossible Center Labeltype Static LabelString "Address: " + OptionalArgs 1 LabelFont Shape Italic EndFont -- José Abílio LyX and docbook, a perfect match. :-)
Re: dvi search
Andre Poenitz wrote: > The buttons present me with a choice of immediate crash or full freeze. > So it "sort of works", but not really automatic, nor robust... But there is also a bug in the core it seems... The dialog appears because of a full path/only name problem. It doesn't if the full path is specified. So somehow lyx detects (wrongly arguably) that it has the doc loaded, but then cannot find it. Regards, Alfredo
Re: A lyx::stringstream containing font info?
On Tue, Oct 21, 2003 at 11:41:41AM +0100, Angus Leeming wrote: > > What problem are you trying to solve that's not solvable by locally > > factoring out some common code from metrics() and draw() in a few > > fat insets? > > Have I answered this question with the above? Sort of. > I _really_ would like the ability to mark-up text handled by the > frontends and think that a fully-fledged widget embedding one of our > Painters would be excessive in many instances... Think to the end: This amounts to implementing a "stream language" which is capable to carry all "interesting" information. Not just font stuff, but a \hat accent and maybe a \sqrt drawing. So this languange is more or less as powerful as the .lyx file format. The core would encode data in this language and the frontends would "interpret" them. So the relation between frontend and streamlanguage is about the same as the between web browsers and HTML. It might be an interesting idea, but in my opinion any step in this direction is a complete waste of resources of developers and users. Neither your nor we will finish creating the equivalent of two web browsers and the whole encoding/decoding idea smells like bloat. If you have the feeling that the current drawing primitives by the frontends are not sufficient, try to point to a real problem. Maybe this could be overcome by a new "primitive" operation. I really don't see a point in encoding font changes in a string to be drawn. The mechanism is the same for all frontends, so this work could as well be done in the core once. Andre' -- 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...)
Re: dvi search
On Tue, Oct 21, 2003 at 11:45:45AM +0100, Angus Leeming wrote: > Andre Poenitz wrote: > > The buttons present me with a choice of immediate crash or full > > freeze. So it "sort of works", but not really automatic, nor > > robust... > > Be fair, André. I did not complain. Andre'
Re: A lyx::stringstream containing font info?
Andre Poenitz wrote:
> On Tue, Oct 21, 2003 at 11:41:41AM +0100, Angus Leeming wrote:
>> > What problem are you trying to solve that's not solvable by
>> > locally factoring out some common code from metrics() and draw()
>> > in a few fat insets?
>>
>> Have I answered this question with the above?
>
> Sort of.
>
>> I _really_ would like the ability to mark-up text handled by the
>> frontends and think that a fully-fledged widget embedding one of
>> our Painters would be excessive in many instances...
>
> Think to the end: This amounts to implementing a "stream language"
> which is capable to carry all "interesting" information. Not just
> font stuff, but a \hat accent and maybe a \sqrt drawing.
>
> So this languange is more or less as powerful as the .lyx file
> format.
>
> The core would encode data in this language and the frontends would
> "interpret" them. So the relation between frontend and
> streamlanguage is about the same as the between web browsers and
> HTML.
>
> It might be an interesting idea, but in my opinion any step in this
> direction is a complete waste of resources of developers and users.
> Neither your nor we will finish creating the equivalent of two web
> browsers and the whole encoding/decoding idea smells like bloat.
>
> If you have the feeling that the current drawing primitives by the
> frontends are not sufficient, try to point to a real problem. Maybe
> this could be overcome by a new "primitive" operation.
>
> I really don't see a point in encoding font changes in a string to
> be drawn. The mechanism is the same for all frontends, so this work
> could as well be done in the core once.
FWIW, I agree with you ;-)
Anyway, in order to reach that opinion for myself, I tried to code it
up. See attached.
int main()
{
font::MetricsStream fs;
fs << font::setFamily(font::SERIF) << "angus"
<< font::setFamily(font::SANS_SERIF) << " leeming";
int const width = font::getWidth(fs);
std::cout << "Width = " << width << std::endl;
xmlOutput(std::cout, fs);
std::cout << std::endl;
return 0;
}
Output:
Width = 13
angus leeming
So, it could clearly be made to work.
--
Angus#include
#include
#include
#include
#include
namespace font {
enum Family {
SERIF,
SANS_SERIF,
TYPEWRITER
};
class setFamily;
class MetricsStream : public std::ostream {
public:
std::ostringstream buffer;
typedef std::string::size_type pos_type;
typedef std::pair FamilyPair;
typedef std::list FamilyStack;
FamilyStack family_stack_;
};
MetricsStream & operator<<(MetricsStream &, char const *);
MetricsStream & operator<<(MetricsStream &, std::string const &);
MetricsStream & operator<<(MetricsStream &, setFamily const &);
class setFamily {
public:
explicit setFamily(Family family) : family_(family) {}
friend MetricsStream & operator<<(MetricsStream &, setFamily const &);
private:
Family family_;
};
int getWidth(MetricsStream const & os);
} // namespace font
// IMPLEMENTATION
namespace font {
MetricsStream & operator<<(MetricsStream & os, std::string const & text)
{
os.buffer << text;
return os;
}
MetricsStream & operator<<(MetricsStream & os, char const * text)
{
if (text)
os.buffer << text;
return os;
}
MetricsStream & operator<<(MetricsStream & os, setFamily const & sf)
{
MetricsStream::pos_type const pos = os.buffer.str().size();
os.family_stack_.push_back(std::make_pair(pos, sf.family_));
return os;
}
namespace {
MetricsStream::FamilyPair const nextFontChange(std::string::size_type cur,
MetricsStream const & os)
{
typedef MetricsStream::FamilyStack::const_iterator iterator;
iterator it = os.family_stack_.begin();
iterator end = os.family_stack_.end();
for (; it != end; ++it) {
if (it->first > cur)
return *it;
}
return std::make_pair(std::string::npos, Family(-1));
}
void outputFamily(std::ostream & os,
char const * prefix,
Family family,
char const * postfix)
{
os << prefix;
switch (family) {
case SERIF:
os << "serif";
break;
case SANS_SERIF:
os << "sans_serif";
break;
case TYPEWRITER:
os << "typewriter";
break;
}
os << postfix;
}
} // namespace anon
int getWidth(MetricsStream const & os)
{
int width = 0;
std::string const buffer = os.buffer.str();
if (buffer.empty())
return width;
std::string::size_type pos = 0;
while (pos != std::string::npos) {
MetricsStream::FamilyPair const next_font =
nextFontChange(pos, os);
std::string::size_type const next = next_font.first;
// The real thing would apply the font to this substring.
width += buffer.substr(pos, next).size();
pos = next;
}
return width;
}
void xmlOutput(std::ostream & os, MetricsStream const & ms)
{
std::string const buffer = ms.buffer.str();
if (buffer.empty())
return;
std::string::size_type pos = 0;
font::Family family = font::SERIF;
while (pos != std::string::npos) {
MetricsStream::FamilyPair const next
Re: Optional arguments to elsart styles.
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> How about this Jean-Marc? Well the optional arguments to \author and \address seem to work as a \label/\ref pair... I think this is a bit abusing the 'short title' inset (and that people will get confused if they put strange things in there). OTOH, I cannot think of a decent way to provide an UI for that. Maybe that would work if we provide good documentation for the feature. I am not an elsart user anyway. What do others think? JMarc
Re: Inset display?
On Tue, Oct 21, 2003 at 10:57:55AM +0200, Andre Poenitz spake thusly: > > On Tue, Oct 21, 2003 at 12:10:38PM +0300, Martin Vermeer wrote: > > Can this go in (as it is the polishing touch on the inset display > > patch)? > > Yes. > > Andre' It's in. - Martin pgp0.pgp Description: PGP signature
Re: dvi search
Hello, On Tue, 21 Oct 2003, Andre Poenitz wrote: > How do I start lyxclient manually if I want to go to a certain line? > > lyxclient -g newfile16.lyx 13 > > brings up a 'document is already loaded, want to switch' dialog. -g is an alias to LFUN_GOTOFILEROW. My inverse search patch just extended this lfun to work also with files that are in lyx_tmpdir. So, unles you are not using a temporary directory, you should use lyxclient -g /tmp/lyx_tmpdir//newfile.tex 13 which is what xdvi would call. Why don't you let xdvi do it's job instead of trying manually? > The buttons present me with a choice of immediate crash or full freeze. As you are not referencing a file in lyx_tmpdir, you are using the old part of the lfun. I don't believe that the crash is due the lfun itself, which is very simple, but a bug somewhere else. > So it "sort of works", but not really automatic, nor robust... I would really like to continue my work on it, but having two patches waiting for approval is too much for me. If something is wrong with them, I need to know before resume coding. Joao.
Re: dvi search
On Tue, Oct 21, 2003 at 11:49:44AM -0200, Joao Luis Meloni Assirati wrote: > > Hello, > > On Tue, 21 Oct 2003, Andre Poenitz wrote: > > > How do I start lyxclient manually if I want to go to a certain line? > > > > lyxclient -g newfile16.lyx 13 > > > > brings up a 'document is already loaded, want to switch' dialog. > > -g is an alias to LFUN_GOTOFILEROW. My inverse search patch just extended > this lfun to work also with files that are in lyx_tmpdir. So, unles you > are not using a temporary directory, you should use > > lyxclient -g /tmp/lyx_tmpdir//newfile.tex 13 > > which is what xdvi would call. Why don't you let xdvi do it's job instead > of trying manually? Because it does not work, i.e. the cursor does not move. No error message whatsoever. As xdvi does work with EDITOR=vi I figured it might be a problem with teh lyxclient <-> LyX communication. > I would really like to continue my work on it, but having two patches > waiting for approval is too much for me. If something is wrong with them, > I need to know before resume coding. I have not payed too much attention to it. Are you refering to the putenv.diff.gz export-socket.diff.gz lyxclient.diff.gz lyxclient.man.gz stuff sent under Subject: [PATCH] Inverse search update. Date: Tue, 14 Oct 2003 20:15:47 -0700 ? Andre' -- 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...)
Assert trigged with last version.
Hi, as you know I am using the latest cvs version to test the back-converter. I have trouble with undo, almost all undos will lead to a crash. Now, after updating since last morning, so just with Martin's patch, I get this, opening a file that I have been working on: (gdb) run Starting program: /home/jamatos/lyx/lyx-devel/src/lyx-xforms text not available! no text in cache! Assertion triggered in InsetOld* Paragraph::getInset(int) by failing check "pos < size()" in file paragraph.C:296 Program received signal SIGABRT, Aborted. 0xe002 in ?? () (gdb) bt #0 0xe002 in ?? () #1 0x42028b93 in abort () from /lib/tls/libc.so.6 #2 0x082e110b in lyx::support::abort() () #3 0x0810d321 in Paragraph::getInset(int) () #4 0x0812e4bd in LyXText::prepareToPrint(std::_List_iterator, std::_List_iterator) const () #5 0x081307ce in LyXText::redoParagraphInternal(std::_List_iterator) () #6 0x081308b3 in LyXText::redoParagraphs(std::_List_iterator, std::_List_iterator) () #7 0x08130e75 in LyXText::init(BufferView*) () #8 0x0805a1d1 in BufferView::Pimpl::resizeCurrentBuffer() () #9 0x08059c8e in BufferView::Pimpl::buffer(Buffer*) () #10 0x08059168 in BufferView::Pimpl::loadLyXFile(std::string const&, bool) () #11 0x08053e2d in BufferView::loadLyXFile(std::string const&, bool) () #12 0x080ed140 in LyXFunc::open(std::string const&) () #13 0x080e93af in LyXFunc::dispatch(FuncRequest const&, bool) () #14 0x082a5d2b in XFormsMenubar::MenuCallback(flobjs_*, long) () #15 0x400bfeb1 in fl_object_qread () from /usr/X11R6/lib/libforms.so.1 #16 0x400d2849 in fl_check_forms () from /usr/X11R6/lib/libforms.so.1 #17 0x081e1c3d in lyx_gui::start(std::string const&, std::vector > const&) () #18 0x080d8eb4 in LyX::priv_exec(int&, char**) () #19 0x080d8834 in LyX::exec(int&, char**) () #20 0x0805391d in main () #21 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 -- José Abílio LyX and docbook, a perfect match. :-)
Re: Assert trigged with last version.
On Tue, Oct 21, 2003 at 04:17:37PM +0100, Jose' Matos spake thusly: > Hi, > as you know I am using the latest cvs version to test the back-converter. > > I have trouble with undo, almost all undos will lead to a crash. > > Now, after updating since last morning, so just with Martin's patch, I get > this, opening a file that I have been working on: > > (gdb) run > Starting program: /home/jamatos/lyx/lyx-devel/src/lyx-xforms > text not available! > no text in cache! > Assertion triggered in InsetOld* Paragraph::getInset(int) by failing check > "pos < size()" in file paragraph.C:296 Ah. This should not happen(tm). Could I have the file (or a minimal part of it that crashes; disable the assert to get around to cutting it up ;-) )? Alternatively, could I have a backtrace with line numbers in text.C? (just add -g to CXXFLAGS in your makefile, touch text.C and recompile) > Program received signal SIGABRT, Aborted. > 0xe002 in ?? () > (gdb) bt > #0 0xe002 in ?? () > #1 0x42028b93 in abort () from /lib/tls/libc.so.6 > #2 0x082e110b in lyx::support::abort() () > #3 0x0810d321 in Paragraph::getInset(int) () > #4 0x0812e4bd in LyXText::prepareToPrint(std::_List_iterator Paragraph&, Paragraph*>, std::_List_iterator) const () I would like to know which line in prepareToPrint(), and on what kind of paragraph... > #5 0x081307ce in ... > -- > José Abílio > > LyX and docbook, a perfect match. :-) - Martin pgp0.pgp Description: PGP signature
Re: Assert trigged with last version.
On Tue, Oct 21, 2003 at 04:17:37PM +0100, Jose' Matos spake thusly: > Now, after updating since last morning, so just with Martin's patch, I get > this, opening a file that I have been working on: > > (gdb) run > Starting program: /home/jamatos/lyx/lyx-devel/src/lyx-xforms > text not available! > no text in cache! > Assertion triggered in InsetOld* Paragraph::getInset(int) by failing check > "pos < size()" in file paragraph.C:296 Just to make sure: does this include this afternoons's commit? - Martin pgp0.pgp Description: PGP signature
Re: Assert trigged with last version.
On Tuesday 21 October 2003 17:03, Martin Vermeer wrote: > > Assertion triggered in InsetOld* Paragraph::getInset(int) by failing > > check "pos < size()" in file paragraph.C:296 > > Just to make sure: does this include this afternoons's commit? Yes, and it happens not matter the frontend I am using (as it should btw. :-) I sent you the file in another message. :-) > - Martin -- José Abílio
Re: dvi search
On Tue, 21 Oct 2003, Andre Poenitz wrote: > > Why don't you let xdvi do it's job instead > > of trying manually? > > Because it does not work, i.e. the cursor does not move. No error > message whatsoever. As xdvi does work with EDITOR=vi I figured it might > be a problem with teh lyxclient <-> LyX communication. I miss a better explanation of how you are trying this. If you did not apply the two pending patches, you must use xforms and define the DVI viewer as xdvi -editor 'lyxclient -a $$a -g %f %l' and the latex->dvi converter as latex --src-specials Note that xdvi 22.40f has a bug in the wrapper script that hast trouble with -editor option. If this occours with your version too (22.40h, right?) you can try, instead of defining the dvi viewer as I said, let it be simply xdvi with no options and export the variable XEDITOR='lyxclient -g %f %l' I advise that this will only work if you have only one lyx runing, as we cannot in this case pass the socket address $$a to lyxclient. After applying the two pending patches, qt will work and xdvi and kdvi can be defined as dvi viewers with no options. > > I would really like to continue my work on it, but having two patches > > waiting for approval is too much for me. If something is wrong with them, > > I need to know before resume coding. > > I have not payed too much attention to it. Are you refering to the > > putenv.diff.gz > export-socket.diff.gz > lyxclient.diff.gz > lyxclient.man.gz > > stuff sent under > > Subject: [PATCH] Inverse search update. > Date: Tue, 14 Oct 2003 20:15:47 -0700 ? This is the first patch. The other, providing qt support for sockets, is in the same thread: http://marc.theaimsgroup.com/?l=lyx-devel&m=106625556317450&w=2 Joao.
Re: dvi search
On Tue, Oct 21, 2003 at 01:59:03PM -0200, Joao Luis Meloni Assirati wrote: > On Tue, 21 Oct 2003, Andre Poenitz wrote: > > > > Why don't you let xdvi do it's job instead > > > of trying manually? > > > > Because it does not work, i.e. the cursor does not move. No error > > message whatsoever. As xdvi does work with EDITOR=vi I figured it might > > be a problem with teh lyxclient <-> LyX communication. > > I miss a better explanation of how you are trying this. If you did not > apply the two pending patches, you must use xforms and define the DVI > viewer as > > xdvi -editor 'lyxclient -a $$a -g %f %l' Ah. I missed that $$a bit. Works now. Good stuff. Andre'
Grmpf
- if (point == last || chunkwidth >= width - left)
- point = (pos < i) ? i - 1 : i;
- break;
+ if (point == last || chunkwidth >= width - left) {
+ if (pos < i) {
+ point = i - 1;
+ break;
+ }
+ }
No good.
Andre'
Warning with inset box.
Hi Martin, it is me again. ;-) I added the support for minipage convertions to lyx2lyx, but I did not considered the default values of those values not defined in the 1.3 version. Because of it I get: $src/lyx InsetBox::Read: Missing 'hor_pos'-tag!c InsetBox::Read: Missing 'has_inner_box'-tag! InsetBox::Read: Missing 'inner_pos'-tag!c InsetBox::Read: Missing 'use_parbox'-tag! InsetBox::Read: Missing 'width'-tag! InsetBox::Read: Missing 'special'-tag! InsetBox::Read: Missing 'height'-tag! InsetBox::Read: Missing 'height_special'-tag! InsetCollapsable::Read: Missing collapsed! Do you, and others, think that I should set the default values of the missing parameter? This will be probably safer when dealing with later convertions, but I would like to hear from other developers. -- José Abílio LyX and docbook, a perfect match. :-)
Re: Warning with inset box.
On Tue, Oct 21, 2003 at 06:17:24PM +0100, Jose' Matos wrote: > Do you, and others, think that I should set the default values of > the missing parameter? This adds a bit bloat to the .lyx but is on sthe safe side, isn't it? I'd rather have lyx2lyx on the safe side. The bloat should vanish after the next 'Save' from LyX... Andre'
Re: Warning with inset box.
On Tuesday 21 October 2003 18:25, Andre Poenitz wrote: > On Tue, Oct 21, 2003 at 06:17:24PM +0100, Jose' Matos wrote: > > Do you, and others, think that I should set the default values of > > the missing parameter? > > This adds a bit bloat to the .lyx but is on sthe safe side, isn't it? Yep. > I'd rather have lyx2lyx on the safe side. The bloat should vanish after > the next 'Save' from LyX... Probably it does not, in most places LyX also works from the safe side. OTHO, there is not nothing preventing you from using .gz files. :-) Also with lyxl2lyx it does not need to be that way, as I can add the different previous value if the defaults changes in the new version. This would make easier to read LyX files. Ok, comments requested... :-) > Andre' -- José Abílio
Re: Warning with inset box.
Jose' Matos wrote: > Also with lyxl2lyx it does not need to be that way, as I can add > the different previous value if the defaults changes in the > new version. This would make easier to read LyX files. Do this. We do it elsewhere. (graphics, tabular, ...) If it's documented, it's safe. -- Angus
Configuring the makefile
Hi. In the INSTALL file I read: --enable-optimization=VALUE enables you to set optimization to a higher level as the default (-O), for example --enable-optimization=-O3. So I give the following configure command: ./configure --with-frontend=qt --enable-optimization=-O3 but after the make command I read: g++: unrecognised option '-03' This behaviour still remains if I give before the command: CXXFLAGS='-03' for BASH. I use Linux-2.4.22 on Slackware 9.1, LyX-1.3.3, gcc (GCC) 3.2.3, g++ (GCC) 3.2.3 Any suggestions for me? Perhaps I wrong something? best regards Costantino
Re: Warning with inset box.
On Tuesday 21 October 2003 18:17, Jose' Matos wrote: > Hi Martin, > it is me again. ;-) > Because of it I get: > $src/lyx [several warnings] > InsetCollapsable::Read: Missing collapsed! This one is weird since colapsed is there. So something fishy is going on. :-) -- José Abílio LyX and docbook, a perfect match. :-)
Re: Configuring the makefile
Kostantino wrote: > > Hi. > In the INSTALL file I read: > > --enable-optimization=VALUE enables you to set optimization >to a higher level as the default (-O), for example > --enable-optimization=-O3. > > So I give the following configure command: > > ./configure --with-frontend=qt --enable-optimization=-O3 > > but after the make command I read: > > g++: unrecognised option '-03' > > This behaviour still remains if I give before the command: > > CXXFLAGS='-03' > > for BASH. > > I use Linux-2.4.22 on Slackware 9.1, LyX-1.3.3, gcc (GCC) 3.2.3, > g++ (GCC) 3.2.3 > Any suggestions for me? Perhaps I wrong something? > > best regards > > Costantino Try --enable-optimisation="-O3" I think that is what WFM. Garst
Re: Configuring the makefile
On Tue, Oct 21, 2003 at 07:36:57PM +0200, Kostantino wrote: > but after the make command I read: > > g++: unrecognised option '-03' You typed zero-three "-03" instead of oh-three "-O3". See ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Assert trigged with last version.
On Tue, Oct 21, 2003 at 04:54:07PM +0100, Jose' Matos spake thusly:
> On Tuesday 21 October 2003 17:03, Martin Vermeer wrote:
> > > Assertion triggered in InsetOld* Paragraph::getInset(int) by failing
> > > check "pos < size()" in file paragraph.C:296
> >
> > Just to make sure: does this include this afternoons's commit?
>
> Yes, and it happens not matter the frontend I am using (as it should btw.
> :-)
>
> I sent you the file in another message. :-)
>
> > - Martin
Thanks!
That'll teach me to be over-confident. The attached will work for your
file José. Please try it on some other files too... if there's any
'...a bit silly' messages I want to hear about it. (As John said, this
is hell.)
(There are now 'dont like' messages... what to think of those?)
If nobody shouts, I'l check this in tomorrow morning. So LyX CVS works
again...
- Martin
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.467
diff -u -p -r1.467 text.C
--- text.C 21 Oct 2003 13:04:13 - 1.467
+++ text.C 21 Oct 2003 21:33:55 -
@@ -739,15 +739,17 @@ pos_type LyXText::rowBreakPoint(Paragrap
if (point == last || chunkwidth >= width - left) {
if (pos < i) {
point = i - 1;
- break;
+ break; // exit on last registered breakpoint
}
}
+ if (i + 1 < last)
+ break; // emergency exit
}
if (!in || in->isChar()) {
// some insets are line separators too
if (pit->isLineSeparator(i)) {
- point = i;
+ point = i; // register breakpoint
chunkwidth = 0;
}
}
@@ -1465,7 +1467,8 @@ void LyXText::prepareToPrint(ParagraphLi
// Display-style insets should always be on a centred row
// The test on pit->size() is to catch zero-size pars, which
// would trigger the assert in Paragraph::getInset().
- inset = pit->size() ? pit->getInset(rit->pos()) : 0;
+ //inset = pit->size() ? pit->getInset(rit->pos()) : 0;
+ inset = pit->isInset(rit->pos()) ? pit->getInset(rit->pos()) : 0;
if (inset && inset->display()) {
align = LYX_ALIGN_CENTER;
}
Index: insets/insetbibitem.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetbibitem.h,v
retrieving revision 1.16
diff -u -p -r1.16 insetbibitem.h
--- insets/insetbibitem.h 17 Oct 2003 18:01:12 - 1.16
+++ insets/insetbibitem.h 21 Oct 2003 21:33:56 -
@@ -41,6 +41,9 @@ public:
///
EDITABLE editable() const { return IS_EDITABLE; }
///
+ bool display() const { return false; }
+
+ ///
InsetOld::Code lyxCode() const { return InsetOld::BIBITEM_CODE; }
/// keep .lyx format compatible
bool directWrite() const { return true; }
Index: insets/insetcite.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcite.h,v
retrieving revision 1.42
diff -u -p -r1.42 insetcite.h
--- insets/insetcite.h 17 Oct 2003 18:01:12 - 1.42
+++ insets/insetcite.h 21 Oct 2003 21:33:56 -
@@ -40,6 +40,8 @@ public:
int latex(Buffer const &, std::ostream &,
LatexRunParams const &) const;
///
+ virtual bool display() const { return false; }
+ ///
dispatch_result localDispatch(FuncRequest const & cmd);
///
void validate(LaTeXFeatures &) const;
pgp0.pgp
Description: PGP signature
Re: Configuring the makefile
John Levon wrote: > > On Tue, Oct 21, 2003 at 07:36:57PM +0200, Kostantino wrote: > > > but after the make command I read: > > > > g++: unrecognised option '-03' > > You typed zero-three "-03" instead of oh-three "-O3". See ? > Oh! Good spotting John. I can't believe how stupid IBM was to put the 0 above the O instead of to the left of the 1 where it belongs. Garst
Re: Grmpf
On Tue, Oct 21, 2003 at 07:17:22PM +0200, Andre Poenitz spake thusly:
>
> - if (point == last || chunkwidth >= width - left)
> - point = (pos < i) ? i - 1 : i;
> - break;
> + if (point == last || chunkwidth >= width - left) {
> + if (pos < i) {
> + point = i - 1;
> + break;
> + }
> + }
>
> No good.
>
> Andre'
Grmpf indeed.
Your patch is close but I think you need the following:
if (point == last || chunkwidth >= width - left) {
if (pos < i) {
point = i - 1;
- break; <-- *don't* delete this
}
}
+ if (i + 1 < last) <-- needed to prevent trailing empty row
creation after wide inset
+ break; <-- OK.
This works perfectly on the file José sent me.
- Martin
pgp0.pgp
Description: PGP signature
Re: Assert trigged with last version.
Martin Vermeer wrote:
> +bool display() const { return false; }
> +
Why do you need these? The function defaults to false (inset.h).
--
Angus
Re: Assert trigged with last version.
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: text.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
| retrieving revision 1.467
| diff -u -p -r1.467 text.C
| --- text.C21 Oct 2003 13:04:13 - 1.467
| +++ text.C21 Oct 2003 21:33:55 -
| @@ -739,15 +739,17 @@ pos_type LyXText::rowBreakPoint(Paragrap
| if (point == last || chunkwidth >= width - left) {
| if (pos < i) {
| point = i - 1;
| - break;
| + break; // exit on last
| registered breakpoint
Please don't put comments at end of line like this. Put the comment
right before the statement instead.
--
Lgb
latest lyx crashes on Help->Introduction
text not available! no text in cache! Assertion triggered in InsetOld* Paragraph::getInset(int) by failing check "pos < size()" in file ../../lyx/src/paragraph.C:296 Aborted (core dumped) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Assert trigged with last version.
On Tue, Oct 21, 2003 at 11:45:12PM +, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
>
> > +bool display() const { return false; }
> > +
>
> Why do you need these? The function defaults to false (inset.h).
... but these inherit from InsetCommand, which sets it to true
(correctly for most of its heirs).
(Trust me, I wouldn't do this if I hadn't noticed in practice
it was necessary :-)
> --
> Angus
>
- Martin
pgp0.pgp
Description: PGP signature
Re: Assert trigged with last version.
On Wed, Oct 22, 2003 at 01:03:34AM +0300, Martin Vermeer spake thusly: > If nobody shouts, I'l check this in tomorrow morning. So LyX CVS works > again... > > - Martin It's in now, with Lars's comment formatting point taken. Please shout if you *now* get '...is a bit silly' warnings. The assert shouldn't be triggered at all. Sorry for the mess. - Martin pgp0.pgp Description: PGP signature
Re: Configuring the makefile
On Tue, Oct 21, 2003 at 07:36:57PM +0200, Kostantino wrote: > Hi. > In the INSTALL file I read: > > --enable-optimization=VALUE enables you to set optimization > to a higher level as the default (-O), for example > --enable-optimization=-O3. > > So I give the following configure command: > > ./configure --with-frontend=qt --enable-optimization=-O3 Letter "Oh" > > but after the make command I read: > > g++: unrecognised option '-03' I doubt this. That's not what you passed. Please _always_ cut&paste error messages verbatim. Do not write them by yourself. Number "0" Zero > > This behaviour still remains if I give before the command: > > CXXFLAGS='-03' > > for BASH. > > I use Linux-2.4.22 on Slackware 9.1, LyX-1.3.3, gcc (GCC) 3.2.3, > g++ (GCC) 3.2.3 > Any suggestions for me? Perhaps I wrong something? Try to get a keyboard where 0 and O are visually different ;-) Andre'
Re: Assert trigged with last version.
On Wednesday 22 October 2003 07:23, Martin Vermeer wrote: > On Wed, Oct 22, 2003 at 01:03:34AM +0300, Martin Vermeer spake thusly: > > If nobody shouts, I'l check this in tomorrow morning. So LyX CVS works > > again... > > > > - Martin > > It's in now, with Lars's comment formatting point taken. Please shout > if you *now* get '...is a bit silly' warnings. The assert shouldn't be > triggered at all. You are right, I don't get an assert this time is real, it is a crash. ;-) (gdb) run Starting program: /home/jamatos/lyx/lyx-devel/src/lyx-xforms text not available! no text in cache! Program received signal SIGSEGV, Segmentation fault. 0x08110fe0 in Paragraph::getChar(int) const () (gdb) bt #0 0x08110fe0 in Paragraph::getChar(int) const () #1 0x0811050e in Paragraph::isNewline(int) const () #2 0x0812e5f7 in LyXText::prepareToPrint(std::_List_iterator, std::_List_iterator) const () #3 0x0813099b in LyXText::redoParagraphInternal(std::_List_iterator) () #4 0x08130a63 in LyXText::redoParagraphs(std::_List_iterator, std::_List_iterator) () #5 0x081310ed in LyXText::init(BufferView*) () #6 0x0805a1d1 in BufferView::Pimpl::resizeCurrentBuffer() () #7 0x08059c8e in BufferView::Pimpl::buffer(Buffer*) () #8 0x08059168 in BufferView::Pimpl::loadLyXFile(std::string const&, bool) () #9 0x08053e2d in BufferView::loadLyXFile(std::string const&, bool) () #10 0x080ed32c in LyXFunc::open(std::string const&) () #11 0x080e959b in LyXFunc::dispatch(FuncRequest const&, bool) () #12 0x082a5e67 in XFormsMenubar::MenuCallback(flobjs_*, long) () #13 0x400bfeb1 in fl_object_qread () from /usr/X11R6/lib/libforms.so.1 #14 0x400d2849 in fl_check_forms () from /usr/X11R6/lib/libforms.so.1 #15 0x081e1d79 in lyx_gui::start(std::string const&, std::vector > const&) () #16 0x080d8eb4 in LyX::priv_exec(int&, char**) () #17 0x080d8834 in LyX::exec(int&, char**) () #18 0x0805391d in main () #19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 I'm sending the xforms debug message because the output is smaller, but as stated earlier this happens for all frontends. > Sorry for the mess. No problem, and it best to detect earlier than later. :-) > - Martin -- José Abílio
