[13x] build failure
Jean-Marc, make is currently failing in the po directory when I try compiling under Tru64 unix, (running ksh fwiw). $ cd po $ make Make: Unrecognized modifier '/src -name Makefile.am'. Stop. $ grep '/src -name Makefile.am' Makefile POTFILE_IN_DEPS = $(shell find $(top_srcdir)/src -name Makefile.am) I have no idea why $(top_srcdir) isn't being expanded to anything meaningful. Perhaps something to do with being wrapped up inside a variable? Going to bed, Angus
Re: Format=>Document=>Page size not working
On Tue, Dec 02, 2003 at 10:53:49PM +0100, Herbert Vo? wrote: > Marko wrote: > > >when trying to set the page size of a document to a custom size I notized > >that this does not work in Lyx 1.3.2 (QT frontend). Any custom size seems > >to be completely ignored! > >Attached are two small examples: test1 uses page size A5 (which works); > >test2 uses a custom page size of 13x18cm (which does not work). > >Any ideas? > > enable the custom margins, then LyX enables the use > of the geometry package. But This is still a bug. I don't understand, what is the bug ? I just set custom margin with 4inches top, and it worked fine (lyx 1.3.3) john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Tue, Dec 02, 2003 at 09:35:42PM +0100, Helge Hafting wrote: > That is not how I think about editing or styles. Absolutely, this is my point. > What do you consider the natural UI? Select-and-apply. Like current physical styles work. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: feature request
Markus B. wrote: > Dear John, dear Andre, > > I'm writing my PhD Thesis using Lyx. Sometimes I would like to read > quickly throung the last paragraphs. On the other hand I have to fill in > footnotes all the time. So closing all the footnotes manually just to get > a better view of the text is a bit complicated. > > I believe that the result of your discussion - a view of all the footnotes > open - would be an ideal solution for my problem. I can add the opinion of me and one of my colleagues. We both write our PHDs in lyx and we both miss the open/close all functionality regarding footnotes. I don't understand at all, why the state of viewing footnotes has to be persistent. Either you want to see all of them or none, normally. BTW, what has happened to the footnote numbering patch? Is the latex counter implementation up to the task now? -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Recent inset changes and ERT
On Tue, Dec 02, 2003 at 11:45:15AM -0800, Kayvan A. Sylvan wrote: > ERT insets no longer have the nice special labels when they are closed. > Can this be put back please? > > If you don't know what I mean: If the ERT was short, the label > was the actual contents of the inset. Now, this is no longer the case > and instead the label is "ERT". This is not quite accurate. The labels show up correctly upon closing and reloading the document, but they don't update when you edit them. -- 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: Inline-Mode for InsetCollapsable
On Tue, Dec 02, 2003 at 08:11:21PM +0100, Michael Schmitt spake thusly: > Martin Vermeer wrote: > > > I would like to see inline mode for CharStyle insets with a bool > > option in the .layout file. > > Please let us discuss this before you start working on this. My plan is > to move some code from InsetERT to InsetCollapsable. As a consequence, > we can support the inline mode also for other inset. But that is all. > > It _may_ be useful to declare which inset is allowed to have which > display mode in the layout files. However, I rather doubt if > hyper-configurability is a desired goal. In the end, everything is > configurable but also everything is highly unusable. Do we really need > new options in the layout files? That's precisely why I want it this way. The .layout file is configurability not seen by the end user. If we want in inset to be switchable among the three: open/closed/inline, we would need a dialog to go with it (like insetert). CharStyle does not have one and that's fine with me. (If you ask me also the ERT dialog is excessive :-) > > I haven't started yet, and now will wait to see how your work turns > > out first. > > Give me a few hours or days please... Sure! Better do it right than do it now. > Michael - Martin pgp0.pgp Description: PGP signature
Re: The current char style UI
On Tue, Dec 02, 2003 at 09:35:42PM +0100, Helge Hafting spake thusly: > If this sort of thing won't be possible, how will the alternative > way be to edit? How will a user remove wrong markup, for > this will be necessary at times. > > What do you consider the natural UI? > Delete & rewrite the text? (too much work) > Use some way of undo a whole piece of markup, then > re-mark pieces if necessary? That's what I was thinking of, yes. A way to remove the inset from inside without removing the text. "Melting". > Something else? > > Helge Hafting - Martin pgp0.pgp Description: PGP signature
Re: The current char style UI
On Tue, Dec 02, 2003 at 02:28:26PM +, John Levon wrote:
> On Tue, Dec 02, 2003 at 10:46:35AM +0100, Andre Poenitz wrote:
>
> > On Tue, Dec 02, 2003 at 10:53:26AM +0100, Helge Hafting wrote:
> > > At least latex lets me change from "\emph{This is marked}" to
> > > "\emph{This} is \emph{marked}" without retyping any text. :-)
> >
> > This is implementable with 'boxes in boxes', too.
>
> The question isn't whether it's implementable, it's whether it's natural
> UI to present to the user. And it's not, regardless of what the
> implementation looks like.
>
> Otherwise Helge would have written \emph{This \nonemph{is} marked}
That is not how I think about editing or styles.
If I "unapply" some style in the middle, then I split the
styled part, I do not add a layer of non-style.
In the latex case, I inserted "}" and "\emph{", even if such
actions looks unbalanced and iffy to a highly organized mind. :-)
If this sort of thing won't be possible, how will the alternative
way be to edit? How will a user remove wrong markup, for
this will be necessary at times.
What do you consider the natural UI?
Delete & rewrite the text? (too much work)
Use some way of undo a whole piece of markup, then
re-mark pieces if necessary?
Something else?
Helge Hafting
Recent inset changes and ERT
ERT insets no longer have the nice special labels when they are closed. Can this be put back please? If you don't know what I mean: If the ERT was short, the label was the actual contents of the inset. Now, this is no longer the case and instead the label is "ERT". Also, wrap:Figure insets do not display right (textual contents run right off the edge of the inset). This is probably similar to what I see with footnotes. -- 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: Inline-Mode for InsetCollapsable
Martin Vermeer wrote: I would like to see inline mode for CharStyle insets with a bool option in the .layout file. Please let us discuss this before you start working on this. My plan is to move some code from InsetERT to InsetCollapsable. As a consequence, we can support the inline mode also for other inset. But that is all. It _may_ be useful to declare which inset is allowed to have which display mode in the layout files. However, I rather doubt if hyper-configurability is a desired goal. In the end, everything is configurable but also everything is highly unusable. Do we really need new options in the layout files? I haven't started yet, and now will wait to see how your work turns out first. Give me a few hours or days please... Michael
Re: Inline-Mode for InsetCollapsable
On Tue, Dec 02, 2003 at 08:17:34PM +0200, Martin Vermeer wrote: > I would like to see inline mode for CharStyle insets with a bool > option in the .layout file. That way we can have the "elements" in XML > behave just like collapsable insets (which is fine and natural IMHO; > just Conglomerate upside down ;-) while the "character styles" in > LaTeX can be made to behave in a way that almost hides their > collapsable inset nature (just a box with text in-line, no label) > which I hope would make John happy. And me too. ish Cursor behaviour is also a factor, along with partial selection. But this stuff is well known and I've argued it into the ground already. > At a later stage I would then like to add "inset melting": backspace > in pos = 0 removes the surrounding inset, which addresses one of Good regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Small fix for docbook example file. (CharStyle)
Hi Martin, did you forgot to apply this? Index: lib/examples/docbook_article.lyx === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/examples/docbook_article.lyx,v retrieving revision 1.5 diff -u -p -r1.5 docbook_article.lyx --- lib/examples/docbook_article.lyx12 Nov 2003 14:38:22 - 1.5 +++ lib/examples/docbook_article.lyx2 Dec 2003 18:10:21 - @@ -122,7 +122,7 @@ It is always possible to have more than \begin_layout Author -\begin_inset FirstName +\begin_inset CharStyle Firstname collapsed true \begin_layout Standard @@ -133,7 +133,7 @@ Jose' \end_inset -\begin_inset Surname +\begin_inset CharStyle Surname collapsed true \begin_layout Standard @@ -319,7 +319,7 @@ The only fonts supported are Emphasis \emph default and -\begin_inset Literal +\begin_inset CharStyle Literal collapsed true \begin_layout Standard -- José Abílio LyX and docbook, a perfect match. :-)
Re: Inline-Mode for InsetCollapsable
On Tue, Dec 02, 2003 at 04:18:27PM +0100, Michael Schmitt spake thusly: > > Hello, > > since Andre started to move code from InsetERT to InsetCollapsable, I > will try finish this project (inline mode also for other insets). > > Just in case somebody had the same idea and already started work, please > let me know so that we don't do the same work twice. > > Michael I would like to see inline mode for CharStyle insets with a bool option in the .layout file. That way we can have the "elements" in XML behave just like collapsable insets (which is fine and natural IMHO; just Conglomerate upside down ;-) while the "character styles" in LaTeX can be made to behave in a way that almost hides their collapsable inset nature (just a box with text in-line, no label) which I hope would make John happy. And me too. I haven't started yet, and now will wait to see how your work turns out first. At a later stage I would then like to add "inset melting": backspace in pos = 0 removes the surrounding inset, which addresses one of Helge's peeves. Like in math. (André, which files should I study to learn how to do this?) Does this sound like a plan? - Martin pgp0.pgp Description: PGP signature
Re: Listings patch (was Re: LyX 1.4 task list)
Christian Ridderström wrote: > Actually, the problem can't be that difficult since I had Herbert's patch > working in Xforms, and it is only since I started over by first adding > a patch I got form Juergen (for Qt) that nothing is inserted. Does that problem (nothing inserted) only occur in the qt version? If so, it might well be that you need to (re)connect the signals and slots first. Do you get any console output? > So... do you think it will/should be back-ported to 1.3.x? I don't think so. 1.3.x is a stable release. Only bugfixes, no new features. Regards, Jürgen.
Listings patch (was Re: LyX 1.4 task list)
On Tue, 2 Dec 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > > > I'm working (ok was working before the wiki-stuff sidetracked me) on > > Herbert's listings (support for the listings package). This ought to > > be ready (long) before 1.4 I believe. Basically I have a bug in the > > 1.3.3-version that makes the inset not actually being inserted into > > the document :-(, other than that I just have to port it. > > Do you want me to look at it? I understand this side of things quite > well ;-) Hmm.. maybe, I guess that depends on if there's a point in "back-porting" it to 1.3-x if not, I might as well start porting it to 1.4.x. > The downside (from your point of view) is that this interface code > between frontend and core has been changed totally in 1.4.x. Actually, the problem can't be that difficult since I had Herbert's patch working in Xforms, and it is only since I started over by first adding a patch I got form Juergen (for Qt) that nothing is inserted. So... do you think it will/should be back-ported to 1.3.x? /Christian -- Christian Ridderström http://www.md.kth.se/~chr
the recent changes to footnote widths etc.
Have broken several things, including : o selections inside a footnote expand past the border o text inside a footnote expands past the border o footnotes still take up a full row, but because their actual width is less, row breaking gets confused and half the text is off the screen past the footnote btw, text selection seems much slower regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
Christian Ridderström wrote: >> Did I miss anything? Or is anybody working on some pet project that >> shall be included in LyX 1.4? > > I'm working (ok was working before the wiki-stuff sidetracked me) on > Herbert's listings (support for the listings package). This ought to > be ready (long) before 1.4 I believe. Basically I have a bug in the > 1.3.3-version that makes the inset not actually being inserted into > the document :-(, other than that I just have to port it. Do you want me to look at it? I understand this side of things quite well ;-) The downside (from your point of view) is that this interface code between frontend and core has been changed totally in 1.4.x. Maybe for better of course ;-) -- Angus
What on earth happened to document switching ?
I switch from one doc to the other, switch back, and I have to wait 10 seconds for some kind of rebuild, and my position in the document is lost ! What happened ? john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
On Mon, 1 Dec 2003, Michael Schmitt wrote: > *** > > Did I miss anything? Or is anybody working on some pet project that > shall be included in LyX 1.4? I'm working (ok was working before the wiki-stuff sidetracked me) on Herbert's listings (support for the listings package). This ought to be ready (long) before 1.4 I believe. Basically I have a bug in the 1.3.3-version that makes the inset not actually being inserted into the document :-(, other than that I just have to port it. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [patch] move text from BufferView to Buffer
Andre Poenitz <[EMAIL PROTECTED]> writes: | [We had discussed this already once, but as this is 'fundamental' I | thought we'd better agree explicitly on it ;-)] | This replaces the LyXText 'semi member' of BufferView by a real LyXText | member of Buffer. And multiple views? View/Data separation? Where did the "explict agreement" on this change enter the stage? -- Lgb
Re: [PATCH] fix exit crash
On Tue, Dec 02, 2003 at 04:08:07PM +0100, Andre Poenitz wrote: > > When you change the width of the lyx window the buffer doesn't change. I > > assume that's what you were referring to as being fixed somehow > > I can't reproduce this with current cvs. What version are you using? It has very recently been fixed (i.e. current CVS works). You've confused me a little bit now, since your reply just said that it *had* been fixed :) john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch] move ParagraphList of InsetText and Buffer to LyXText
Andre Poenitz <[EMAIL PROTECTED]> writes: | Step 2. Almost mechanical. I wonder why this is a good move. -- Lgb
Inline-Mode for InsetCollapsable
Hello, since Andre started to move code from InsetERT to InsetCollapsable, I will try finish this project (inline mode also for other insets). Just in case somebody had the same idea and already started work, please let me know so that we don't do the same work twice. Michael
Re: [PATCH] fix exit crash
On Tuesday 02 December 2003 14:56, John Levon wrote: > > When you change the width of the lyx window the buffer doesn't change. I > assume that's what you were referring to as being fixied somehow I don't see that with xforms, gtk or qt... Maybe it is ncurses frontend that is broke. ;-) > john -- José Abílio LyX and docbook, a perfect match. :-)
Re: [PATCH] fix exit crash
On Tue, Dec 02, 2003 at 02:56:32PM +, John Levon wrote: > On Tue, Dec 02, 2003 at 03:44:28PM +0100, Andre Poenitz wrote: > > > > > Btw, the 'resize' problem is fixed now, too. > > > > > > That it doesn't actually resize the buffer at all ? > > > > For the humour impaired: Example please. > > When you change the width of the lyx window the buffer doesn't change. I > assume that's what you were referring to as being fixied somehow I can't reproduce this with current cvs. What version are you using? Andre'
Re: [PATCH] fix exit crash
On Tue, Dec 02, 2003 at 03:44:28PM +0100, Andre Poenitz wrote: > > > Btw, the 'resize' problem is fixed now, too. > > > > That it doesn't actually resize the buffer at all ? > > For the humour impaired: Example please. When you change the width of the lyx window the buffer doesn't change. I assume that's what you were referring to as being fixied somehow john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Right address is horked
On Tue, Dec 02, 2003 at 03:32:06PM +0100, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> On Tue, Dec 02, 2003 at 03:19:31PM +0100, Jean-Marc Lasgouttes > Andre> wrote: > >> I have to admit that I prefer that to > >> one-another-inset-just-to-hide-code. > > Andre> It's pretty much the purpose of insets to encapsulate special > Andre> code related to a specify area on the LyX canvas, isn't it? > > The inset would do absolutely nothing useful, would it? It wraps its contents and draws itself close to the right margin of the text. That's pretty similar to what the RootInset does: Draw its contents at a suitable place. > >> Nevertheless, it strikes me as a bit extreme and I would appreciate > >> some visual clue... > > Andre> There is already a visual clue in form of the layout > Andre> drop-down... > > I do not think that drawing a couple lines (I am not sure which > ones...) would be very expensive as far as the core is concerned. Probably not. But I still don't think it belongs in the core... > I agree though that the current code for right margin is really too > ugly wrt its usefulness. Andre'
Re: [PATCH] fix exit crash
On Tue, Dec 02, 2003 at 02:29:23PM +, John Levon wrote: > On Tue, Dec 02, 2003 at 12:20:24PM +0100, Andre Poenitz wrote: > > > Btw, the 'resize' problem is fixed now, too. > > That it doesn't actually resize the buffer at all ? For the humour impaired: Example please. Andre'
Re: Right address is horked
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Tue, Dec 02, 2003 at 03:19:31PM +0100, Jean-Marc Lasgouttes Andre> wrote: >> I have to admit that I prefer that to >> one-another-inset-just-to-hide-code. Andre> It's pretty much the purpose of insets to encapsulate special Andre> code related to a specify area on the LyX canvas, isn't it? The inset would do absolutely nothing useful, would it? >> Nevertheless, it strikes me as a bit extreme and I would appreciate >> some visual clue... Andre> There is already a visual clue in form of the layout Andre> drop-down... I do not think that drawing a couple lines (I am not sure which ones...) would be very expensive as far as the core is concerned. I agree though that the current code for right margin is really too ugly wrt its usefulness. JMarc
Re: [PATCH] fix exit crash
On Tue, Dec 02, 2003 at 12:20:24PM +0100, Andre Poenitz wrote: > Btw, the 'resize' problem is fixed now, too. That it doesn't actually resize the buffer at all ? good john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Tue, Dec 02, 2003 at 10:46:35AM +0100, Andre Poenitz wrote:
> On Tue, Dec 02, 2003 at 10:53:26AM +0100, Helge Hafting wrote:
> > At least latex lets me change from "\emph{This is marked}" to
> > "\emph{This} is \emph{marked}" without retyping any text. :-)
>
> This is implementable with 'boxes in boxes', too.
The question isn't whether it's implementable, it's whether it's natural
UI to present to the user. And it's not, regardless of what the
implementation looks like.
Otherwise Helge would have written \emph{This \nonemph{is} marked}
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
Re: Right address is horked
On Tue, Dec 02, 2003 at 03:19:31PM +0100, Jean-Marc Lasgouttes wrote: > I have to admit that I prefer that to one-another-inset-just-to-hide-code. It's pretty much the purpose of insets to encapsulate special code related to a specify area on the LyX canvas, isn't it? > Nevertheless, it strikes me as a bit extreme and I would appreciate some > visual clue... There is already a visual clue in form of the layout drop-down... 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: [JMarc]: xforms/Makefile.am
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> I am not really used to this {} syntax (I did not know it existed,
>> actually).
Angus> Wow! You introduced it to me! (Remember some mails long ago
Angus> about ways to improve our shell-scripting?) In this particular
Angus> instance, the 'Useless use of 'test'" idea is that we don't
Angus> need if test return status; then... fi but can use the return
Angus> status direct.
I meant this use of {} for grouping commands (especially when the
opening and closing brackets are not on the same line).
Angus> I shall leave that to you, if you don't mind. I'm reaching
Angus> auto-magic saturation point ;-)
But the goal here is to remove some auto-magic :)
JMarc
Re: Right address is horked
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Mon, Dec 01, 2003 at 02:50:42PM +0100, Jean-Marc Lasgouttes Andre> wrote: >> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> Andre> This would be some kind of solution, too, but I don't really Andre> like this kind of special casing in the core... >> Come on... Andre> Hm. What about I have to admit that I prefer that to one-another-inset-just-to-hide-code. Nevertheless, it strikes me as a bit extreme and I would appreciate some visual clue... JMarc
Re: LyX 1.4 task list
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> What we could do is have >> >> - a text field for the file name, with a browse button >> >> - a combox (less clutter that a list like we have now) with the >> list of types (== templates), which is set initially to 'auto' (or >> 'default'). The user can choose to override the template guessed by >> the dialog. Angus> I think that we're getting ahead of ourselves. This is the Angus> UI-equivalent of syntatic sugar. Worse, we're sweetening an Angus> interface that isn't used yet by the vast majority of our Angus> users. What I mean is that, with such an interface, I would agree with the merging of insetexternal and insetgraphics. Angus> Let me finish the all singing, all dancing inset I have been Angus> promising you and then we can discuss this. Sure. JMarc
Re: [patch] LyXText::read
On Tue, Dec 02, 2003 at 03:14:37PM +0100, Andre' Poenitz wrote:
>
> Can anybody see anything wrogn with this?
> [It works, just asking...]
>
> Counting the unknown tokes seems to be broken (before and after applying
> this patch)
Maybe two note on what I did _not_ change:
> + if (in_inset_) {
> +
> + if (token == "\\end_inset") {
> + the_end_read = true;
> + break;
> + }
> +
> + if (token == "\\end_document") {
> + lex.printError("\\end_document read in inset! Error in
> document!");
> + return false;
> + }
> +
> + } else {
> +
> + if (token == "\\end_document") {
> + the_end_read = true;
> + continue;
> + }
Why should we read on after \\end_document?
> +
> + }
> +
> + // FIXME: ugly.
> + int unknown = 0;
And essentially unused...
Andre'
[patch] LyXText::read
Can anybody see anything wrogn with this?
[It works, just asking...]
Counting the unknown tokes seems to be broken (before and after applying
this patch)
Andre'
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.547
diff -u -p -r1.547 buffer.C
--- buffer.C2 Dec 2003 12:39:10 - 1.547
+++ buffer.C2 Dec 2003 14:00:04 -
@@ -390,6 +390,7 @@ void unknownClass(string const & unknown
} // anon
+
int Buffer::readHeader(LyXLex & lex)
{
int unknown_tokens = 0;
@@ -435,9 +436,8 @@ int Buffer::readHeader(LyXLex & lex)
// if par = 0 normal behavior
// else insert behavior
// Returns false if "\end_document" is not read (Asger)
-bool Buffer::readBody(LyXLex & lex, ParagraphList::iterator pit)
+bool Buffer::readBody(LyXLex & lex, ParagraphList::iterator)
{
- Paragraph::depth_type depth = 0;
bool the_end_read = false;
if (paragraphs().empty()) {
@@ -458,67 +458,10 @@ bool Buffer::readBody(LyXLex & lex, Para
tmpbuf.readHeader(lex);
}
- while (lex.isOK()) {
- lex.nextToken();
- string const token = lex.getString();
-
- if (token.empty())
- continue;
-
- lyxerr[Debug::PARSER] << "Handling token: `"
- << token << '\'' << endl;
-
- if (token == "\\end_document") {
- the_end_read = true;
- continue;
- }
-
- readParagraph(lex, token, paragraphs(), pit, depth);
- }
+ if (text().read(*this, lex))
+ the_end_read = true;
return the_end_read;
-}
-
-
-int Buffer::readParagraph(LyXLex & lex, string const & token,
- ParagraphList & pars, ParagraphList::iterator & pit,
- lyx::depth_type & depth)
-{
- static Change current_change;
- int unknown = 0;
-
- if (token == "\\begin_layout") {
- lex.pushToken(token);
-
- Paragraph par;
- par.params().depth(depth);
- if (params().tracking_changes)
- par.trackChanges();
- LyXFont f(LyXFont::ALL_INHERIT, params().language);
- par.setFont(0, f);
-
- // insert after
- if (pit != pars.end())
- ++pit;
-
- pit = pars.insert(pit, par);
-
- // FIXME: goddamn InsetTabular makes us pass a Buffer
- // not BufferParams
- ::readParagraph(*this, *pit, lex);
-
- } else if (token == "\\begin_deeper") {
- ++depth;
- } else if (token == "\\end_deeper") {
- if (!depth) {
- lex.printError("\\end_deeper: " "depth is already null");
- } else {
- --depth;
- }
- } else {
- ++unknown;
- }
- return unknown;
}
Index: buffer.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.h,v
retrieving revision 1.174
diff -u -p -r1.174 buffer.h
--- buffer.h28 Nov 2003 15:08:38 - 1.174
+++ buffer.h2 Dec 2003 14:00:04 -
@@ -96,12 +96,6 @@ public:
*/
bool readBody(LyXLex &, ParagraphList::iterator pit);
- /// This parses a single token
- int readParagraph(LyXLex &, std::string const & token,
- ParagraphList & pars,
- ParagraphList::iterator & pit,
- lyx::depth_type & depth);
-
///
void insertStringAsLines(ParagraphList::iterator &, lyx::pos_type &,
LyXFont const &, std::string const &);
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.266
diff -u -p -r1.266 lyxtext.h
--- lyxtext.h 2 Dec 2003 12:39:11 - 1.266
+++ lyxtext.h 2 Dec 2003 14:00:04 -
@@ -393,6 +393,8 @@ public:
///
void write(Buffer const & buf, std::ostream & os) const;
+ /// returns whether we've seen our usual 'end' marker
+ bool read(Buffer const & buf, LyXLex & lex);
public:
///
Index: paragraph_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_funcs.C,v
retrieving revision 1.90
diff -u -p -r1.90 paragraph_funcs.C
--- paragraph_funcs.C 28 Nov 2003 15:53:25 - 1.90
+++ paragraph_funcs.C 2 Dec 2003 14:00:04 -
@@ -303,7 +303,8 @@ int getEndLabel(ParagraphList::iterator
namespace {
-int readParToken(Buffer & buf, Paragraph & par, LyXLex & lex, string const & token)
+int readParToken(Buffer const & buf, Para
Re: [PATCH Pot file generation
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Dear Jean-Marc, have you seen my pot file generation patches? Michael> Finally my files match with yours... Michael> Patches for 1.3 and 1.4 are attached. Dear Michael, Yes, I have seen them, and I am sorry for the delay in answering. Actually I am currently looking at the issue. The problems that I am looking at are: - why do you set LC_ALL instead of LC_COLLATE? Does this make a difference? If LC_COLLATE is already set, I do not think that LC_ALL overrides it. - I am not sure that "export FOO=bar" is portable. The portable way seems to be "FOO=bar ; export FOO", which is arguably a bit odd. JMarc
[PATCH Pot file generation
Dear Jean-Marc,
have you seen my pot file generation patches? Finally my files match
with yours...
Patches for 1.3 and 1.4 are attached.
Michael
Index: lyx-devel-1.3.Xcvs/po/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/po/ChangeLog,v
retrieving revision 1.156.2.45
diff -u -r1.156.2.45 ChangeLog
--- lyx-devel-1.3.Xcvs/po/ChangeLog 2003/11/24 17:00:38 1.156.2.45
+++ lyx-devel-1.3.Xcvs/po/ChangeLog 2003/12/02 11:53:58
@@ -1,3 +1,7 @@
+2003-11-28 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * Makefile.in.in: always create pot files with LC_ALL="C"
+
2003-11-24 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* Makefile.in.in (*l10n.pot): fix the file names when building
Index: lyx-devel-1.3.Xcvs/po/Makefile.in.in
===
RCS file: /cvs/lyx/lyx-devel/po/Makefile.in.in,v
retrieving revision 1.28.2.4
diff -u -r1.28.2.4 Makefile.in.in
--- lyx-devel-1.3.Xcvs/po/Makefile.in.in2003/11/24 17:00:39 1.28.2.4
+++ lyx-devel-1.3.Xcvs/po/Makefile.in.in2003/12/02 11:53:59
@@ -197,11 +197,12 @@
$(SHELL) ./config.status
${srcdir}/POTFILES.in: $(POTFILE_IN_DEPS)
+ export LC_ALL=C ; \
rm -f [EMAIL PROTECTED] \
&& ( cd $(top_srcdir); \
grep -l "_(\".*\")" `find src -name \*.[hHC] -print` |\
sed -e '/xforms.forms/d' | \
-LC_COLLATE=C sort | uniq ) > [EMAIL PROTECTED] \
+sort | uniq ) > [EMAIL PROTECTED] \
&& mv [EMAIL PROTECTED] $@
@@ -211,6 +212,7 @@
$(srcdir)/xforms_l10n.pot: $(top_srcdir)/src/frontends/xforms/forms/*.fd
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
BEGIN { \
print "#, fuzzy"; \
@@ -236,6 +238,7 @@
$(srcdir)/qt_l10n.pot: $(top_srcdir)/src/frontends/qt2/ui/*.ui
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
// { \
line=$$0; \
@@ -252,6 +255,7 @@
$(srcdir)/layouts_l10n.pot: $(top_srcdir)/lib/layouts/*.layout
$(top_srcdir)/lib/layouts/*.inc
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
/^Style / { \
line=$$0; \
Index: lyx-devel-1.3.Xcvs/po/de.po
===
RCS file: /cvs/lyx/lyx-devel/po/de.po,v
retrieving revision 1.79.2.16
diff -u -r1.79.2.16 de.po
--- lyx-devel-1.3.Xcvs/po/de.po 2003/11/24 17:01:45 1.79.2.16
+++ lyx-devel-1.3.Xcvs/po/de.po 2003/12/02 11:54:24
@@ -54,9 +54,10 @@
#
msgid ""
msgstr ""
-"Project-Id-Version: LyX 1.3.0\n"
-"POT-Creation-Date: 2003-11-24 15:57+0100\n"
-"PO-Revision-Date: 2003-09-13 15:00+0100\n"
+"Project-Id-Version: LyX 1.3.4\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2003-11-28 23:38+0100\n"
+"PO-Revision-Date: 2003-11-24 24:00+0100\n"
"Last-Translator: Michael Schmitt <[EMAIL PROTECTED]>\n"
"Language-Team: German <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
@@ -789,7 +790,7 @@
#: ../src/frontends/xforms/forms/form_graphics.fd:560
msgid "Clip to bounding box|#C"
-msgstr "Auf Box zuschneiden|#z"
+msgstr "Auf Begrenzungsbox zuschneiden|#z"
#: ../src/frontends/xforms/forms/form_graphics.fd:578
msgid "Get from file|#G"
@@ -1739,7 +1740,6 @@
#: ../src/frontends/xforms/forms/form_tabular.fd:284
#: ../src/frontends/xforms/forms/form_tabular.fd:1200
-#, fuzzy
msgid "Rotate 90 deg|#9"
msgstr "90° drehen|#9"
@@ -2681,7 +2681,7 @@
#: ../src/frontends/qt2/ui/QDocumentDialogBase.ui:278
msgid "Reset default params of the current class"
-msgstr ""
+msgstr "Setzen Sie die Standardparameter der aktuellen Klasse zurück"
#: ../src/frontends/qt2/ui/QDocumentDialogBase.ui:296
msgid "Save as Document Defaults"
@@ -2977,7 +2977,7 @@
#: ../src/frontends/qt2/ui/QGraphicsDialogBase.ui:622
msgid "Clip to &bounding box"
-msgstr "Auf Box &zuschneiden"
+msgstr "Auf Begrenzungsbox &zuschneiden"
#: ../src/frontends/qt2/ui/QGraphicsDialogBase.ui:626
msgid "Clip to bounding box values"
@@ -3019,7 +3019,7 @@
#: ../src/frontends/qt2/ui/QGraphicsDialogBase.ui:891
msgid "Is this just one part of a figure float ?"
-msgstr ""
+msgstr "Ist dies nur ein Teil eines Abbildungs-Gleitobjekts?"
#: ../src/frontends/qt2/ui/QGraphicsDialogBase.ui:902
msgid "Don't un&zip on export"
@@ -3166,9 +3166,8 @@
msgstr "Mathe-Schrift festlegen"
#: ../src/frontends/qt2/ui/QMathDialogBase.ui:213
-#, fuzzy
msgid "Insert fraction"
-msgstr "Bruch einfügen (\frac)"
+msgstr "Bruch einfügen"
#: ../src/frontends/qt2/ui/QMathDialogBase.ui:239
msgid "Toggle between display mode"
@@ -3907,7 +3906,7 @@
#: ../src/frontends/qt2/ui/QPrefPrinterModule.ui:508
msgid "Specify the command option names for your printer command"
-msgstr ""
+msgstr "Geben Sie die Befehlsoptions-Namen für ihren Druckbefehl an"
#: ../src/frontends/qt2/ui/QPrefScreenFontsModule.ui:22
#: src/frontends/xforms/FormPreference
Re: Python warnings from lyx2lyx
On Tuesday 02 December 2003 11:40, Michael Schmitt wrote: > > > > True, that is fixed in 1.4 and probably 1.3.4 (if ever) will have the > > 1.4 lyx2lyx so that will fix the bug in 1.3.x > > I don't think it is fixed in 1.4... Does this fix it? Index: lyx2lyx === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyx2lyx,v retrieving revision 1.15 diff -u -p -r1.15 lyx2lyx --- lyx2lyx 13 Oct 2003 09:50:10 - 1.15 +++ lyx2lyx 2 Dec 2003 13:47:37 - @@ -1,5 +1,5 @@ #! /usr/bin/env python -# -*- coding: iso-8859-1 -*- +# -*- coding: iso8859-1 -*- # Copyright (C) 2002 José Matos <[EMAIL PROTECTED]> # # This program is free software; you can redistribute it and/or > Michael -- José Abílio
Re: copyrights and Lyx wiki site
On Tue, 2 Dec 2003, Angus Leeming wrote: > Christian Ridderström wrote: > > > PS. I wonder if maybe the copyright page is one of the rare pages > > where editing should be restricted... > > Then you should get the spelling right. documentats? > thx /C -- Christian Ridderström http://www.md.kth.se/~chr
Re: Python warnings from lyx2lyx
On Saturday 29 November 2003 10:04, Ronald Florence wrote: I am seeing warnings from the lyx2lyx scripts: [ python error/warning ] If I understand the web page recommended in the warnings, they want lines like # -*- coding: iso-latin-1-unix -*- inserted at the top of the Python files because of José Matos' name. True, that is fixed in 1.4 and probably 1.3.4 (if ever) will have the 1.4 lyx2lyx so that will fix the bug in 1.3.x I don't think it is fixed in 1.4... Michael
[patch] a bit consolitation
Moves idetical code from InsetText and Buffer to LyXText
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...)
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.546
diff -u -p -r1.546 buffer.C
--- buffer.C1 Dec 2003 13:35:37 - 1.546
+++ buffer.C2 Dec 2003 12:24:23 -
@@ -839,19 +839,13 @@ bool Buffer::do_writeFile(ostream & ofs)
<< " created this file. For more info see http://www.lyx.org/\n";
<< "\\lyxformat " << LYX_FORMAT << "\n";
- // now write out the buffer paramters.
+ // now write out the buffer parameters.
params().writeFile(ofs);
ofs << "\\end_header\n";
- Paragraph::depth_type depth = 0;
-
- // this will write out all the paragraphs
- // using recursive descent.
- ParagraphList::const_iterator pit = paragraphs().begin();
- ParagraphList::const_iterator pend = paragraphs().end();
- for (; pit != pend; ++pit)
- pit->write(*this, ofs, params(), depth);
+ // write the text
+ text().write(*this, ofs);
// Write marker that shows file is complete
ofs << "\n\\end_document" << endl;
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.265
diff -u -p -r1.265 lyxtext.h
--- lyxtext.h 1 Dec 2003 13:35:39 - 1.265
+++ lyxtext.h 2 Dec 2003 12:24:23 -
@@ -25,6 +25,8 @@
#include "insets/inset.h"
+#include
+
class Buffer;
class BufferParams;
class BufferView;
@@ -389,6 +391,8 @@ public:
///
bool checkAndActivateInset(bool front);
+ ///
+ void write(Buffer const & buf, std::ostream & os) const;
public:
///
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.505
diff -u -p -r1.505 text.C
--- text.C 2 Dec 2003 07:15:40 - 1.505
+++ text.C 2 Dec 2003 12:24:24 -
@@ -1757,3 +1757,13 @@ void LyXText::getWord(LyXCursor & from,
to.pos(to.pos() + 1);
}
}
+
+
+void LyXText::write(Buffer const & buf, std::ostream & os) const
+{
+ ParagraphList::const_iterator pit = paragraphs().begin();
+ ParagraphList::const_iterator end = paragraphs().end();
+ Paragraph::depth_type dth = 0;
+ for (; pit != end; ++pit)
+ pit->write(buf, os, buf.params(), dth);
+}
Index: insets/insetcaption.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcaption.C,v
retrieving revision 1.51
diff -u -p -r1.51 insetcaption.C
--- insets/insetcaption.C 5 Nov 2003 12:06:07 - 1.51
+++ insets/insetcaption.C 2 Dec 2003 12:24:24 -
@@ -52,7 +52,7 @@ InsetCaption::InsetCaption(BufferParams
void InsetCaption::write(Buffer const & buf, ostream & os) const
{
os << "Caption\n";
- writeParagraphData(buf, os);
+ text_.write(buf, os);
}
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.219
diff -u -p -r1.219 insetcollapsable.C
--- insets/insetcollapsable.C 2 Dec 2003 07:15:42 - 1.219
+++ insets/insetcollapsable.C 2 Dec 2003 12:24:24 -
@@ -79,7 +79,7 @@ bool InsetCollapsable::insertInset(Buffe
void InsetCollapsable::write(Buffer const & buf, ostream & os) const
{
os << "collapsed " << (status_ == Collapsed ? "true" : "false") << "\n";
- inset.writeParagraphData(buf, os);
+ inset.text_.write(buf, os);
}
Index: insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.557
diff -u -p -r1.557 insettext.C
--- insets/insettext.C 1 Dec 2003 13:35:46 - 1.557
+++ insets/insettext.C 2 Dec 2003 12:24:24 -
@@ -143,18 +143,7 @@ auto_ptr InsetText::clone() c
void InsetText::write(Buffer const & buf, ostream & os) const
{
os << "Text\n";
- writeParagraphData(buf, os);
-}
-
-
-void InsetText::writeParagraphData(Buffer const & buf, ostream & os) const
-{
- ParagraphList::const_iterator it = paragraphs().begin();
- ParagraphList::const_iterator end = paragraphs().end();
- Paragraph::depth_type dth = 0;
- for (; it != end; ++it) {
- it->write(buf, os, buf.params(), dth);
- }
+ text_.write(buf, os);
}
Index: insets/insettext.h
===
RCS file: /usr/local/lyx/cvsro
Re: [patch]: lyxlex changes
On Tue, Dec 02, 2003 at 12:12:22PM +, Angus Leeming wrote: > Ok? It works fine but I'm not sure whether I should revert the > LyxLex::operator void const *()... Very well. Andre'
[patch]: lyxlex changes
Ok? It works fine but I'm not sure whether I should revert the
LyxLex::operator void const *()...
I've also made InsetVSpace::read use the new syntax.
--
AngusIndex: src/lyxlex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlex.C,v
retrieving revision 1.47
diff -u -p -r1.47 lyxlex.C
--- src/lyxlex.C 2 Dec 2003 10:19:51 - 1.47
+++ src/lyxlex.C 2 Dec 2003 12:09:09 -
@@ -256,15 +256,19 @@ int LyXLex::findToken(char const * str[]
}
-LyXLex::operator void *() const
+LyXLex::operator void const *() const
{
- return isOK() ? const_cast(this) : 0;
+ // This behaviour is NOT the same as the std::streams which would
+ // use fail() here. However, our implementation of getString() et al.
+ // can cause the eof() and fail() bits to be set, even though we
+ // haven't tried to read 'em.
+ return pimpl_->is.bad() ? 0 : this;
}
bool LyXLex::operator!() const
{
- return !isOK();
+ return pimpl_->is.bad();
}
@@ -316,5 +320,4 @@ LyXLex & LyXLex::operator>>(bool & s)
}
return *this;
}
-
Index: src/lyxlex.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlex.h,v
retrieving revision 1.37
diff -u -p -r1.37 lyxlex.h
--- src/lyxlex.h 2 Dec 2003 10:19:51 - 1.37
+++ src/lyxlex.h 2 Dec 2003 12:09:09 -
@@ -55,10 +55,10 @@ public:
LEX_TOKEN = -4
};
- /// straem is open and end of straem is not reached
+ /// stream is open and end of stream is not reached
bool isOK() const;
/// stream is ok
- operator void *() const;
+ operator void const *() const;
/// stream is not ok
bool operator!() const;
/// return true if able to open file, else false
Index: src/insets/insetvspace.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetvspace.C,v
retrieving revision 1.5
diff -u -p -r1.5 insetvspace.C
--- src/insets/insetvspace.C 2 Dec 2003 10:19:51 - 1.5
+++ src/insets/insetvspace.C 2 Dec 2003 12:09:10 -
@@ -15,6 +15,7 @@
#include "buffer.h"
#include "BufferView.h"
+#include "debug.h"
#include "dispatchresult.h"
#include "funcrequest.h"
#include "gettext.h"
@@ -78,21 +79,21 @@ InsetVSpace::priv_dispatch(FuncRequest c
return InsetOld::priv_dispatch(cmd, idx, pos);
}
}
-
+
void InsetVSpace::read(Buffer const &, LyXLex & lex)
{
- if (lex.isOK()) {
- lex.next();
- space_ = VSpace(lex.getString());
- }
-
- if (lex.isOK())
- lex.next();
- if (lex.getString() != "\\end_inset") {
+ BOOST_ASSERT(lex.isOK());
+ string vsp;
+ lex >> vsp;
+ if (lex)
+ space_ = VSpace(vsp);
+
+ string end_token;
+ lex >> end_token;
+ if (end_token != "\\end_inset")
lex.printError("Missing \\end_inset at this point. "
"Read: `$$Token'");
- }
}
@@ -232,7 +233,7 @@ InsetVSpaceMailer::InsetVSpaceMailer(Ins
string const InsetVSpaceMailer::inset2string(Buffer const &) const
{
- return params2string(inset_.space_);
+ return params2string(inset_.space());
}
@@ -247,7 +248,7 @@ void InsetVSpaceMailer::string2params(st
LyXLex lex(0,0);
lex.setStream(data);
string name, vsp;
- lex >> name >> vsp;
+ lex >> name >> vsp;
if (lex)
vspace = VSpace(vsp);
}
Index: src/insets/insetvspace.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetvspace.h,v
retrieving revision 1.2
diff -u -p -r1.2 insetvspace.h
--- src/insets/insetvspace.h 28 Nov 2003 17:38:39 - 1.2
+++ src/insets/insetvspace.h 2 Dec 2003 12:09:10 -
@@ -36,19 +36,21 @@ public:
OutputParams const &) const;
///
int plaintext(Buffer const &, std::ostream &,
- OutputParams const &) const;
+ OutputParams const &) const;
///
int linuxdoc(Buffer const &, std::ostream &,
- OutputParams const &) const;
+ OutputParams const &) const;
///
int docbook(Buffer const &, std::ostream &,
- OutputParams const &) const;
+ OutputParams const &) const;
///
void read(Buffer const &, LyXLex & lex);
///
void write(Buffer const & buf, std::ostream & os) const;
///
bool display() const { return true; }
+ /// How much?
+ VSpace const & space() const { return space_; }
protected:
///
@@ -56,8 +58,8 @@ protected:
DispatchResult
priv_dispatch(FuncRequest const & cmd, idx_type &, pos_type &);
-public:
- /// how much
+private:
+ ///
VSpace space_;
};
Re: Can't read InsetVSpace from the dialog...
On Tue, Dec 02, 2003 at 11:54:45AM +, Angus Leeming wrote:
> Angus Leeming wrote:
> > so I think that we should change the operator void *() above to:
> > LyXLex::operator void *() const
> > {
> > return pimpl_->is.fail() ? 0 : const_cast(this);
> > }
>
> Incidentally, why not 'void const *'? It compiles...
Good question. Because the std::stream uses a void * there...
Andre'
Re: Can't read InsetVSpace from the dialog...
Angus Leeming wrote:
> so I think that we should change the operator void *() above to:
> LyXLex::operator void *() const
> {
> return pimpl_->is.fail() ? 0 : const_cast(this);
> }
Incidentally, why not 'void const *'? It compiles...
LyXLex::operator void const *() const
{
return pimpl_->is.fail() ? 0 : this;
}
--
Angus
Re: Can't read InsetVSpace from the dialog...
On Tue, Dec 02, 2003 at 11:44:10AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >> because we have reached the end of the stream, so this fails:
> >> bool LyXLex::isOK() const
> >> {
> >> return pimpl_->is.good();
> >> }
> >
> > IIRC: The stream should be good after reading the vsp item. It
> > should go to 'eof' and 'fail' after one tries to read beyond the
> > last item.
>
> which depends on the implementation of getStream() doesn't it?
>
> Here this:
> lex >> name >> vsp;
>
> std::istream & is = lex.getStream();
> lyxerr << "is.good " << is.good() << '\n';
> lyxerr << "is.bad " << is.bad() << '\n';
> lyxerr << "is.eof " << is.eof() << '\n';
> lyxerr << "is.fail " << is.fail() << '\n';
>
> lyxerr << "name = \"" << name << "\" vspace = \"" << vsp
><< "\" lex \"" << bool(lex) << '"' << std::endl;
> if (lex)
> vspace = VSpace(vsp);
>
> gives this output:
> is.good 0
> is.bad 0
> is.eof 1
> is.fail 1
> name = "vspace" vspace = "medskip" lex "0"
Ah, so 'getStream' reads on and causes eof() to be set.
It should not do that...
> So, it seems that we need
> LyXLex::operator void *() const
> {
> return pimpl_->is.bad() ? 0 : const_cast(this);
> }
>
> LyXLex::operator!() const
> {
> return pimpl_->is.bad();
> }
Ok, use this if it works but please place a warning there that this is
not the behaviour of std::stream.
Btw::
std::filebuf fb__;
/// gz__ is only used to open files, the stream is accessed through is.
gz::gzstreambuf gz__;
double underscores in identifiers are not ours to use...
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: copyrights and Lyx wiki site
Christian Ridderström wrote: > Hi > > I just put up some notes regarding copyrights and the LyX wiki site > here: > > http://wiki.lyx.org/pmwiki.php/Site/Copyrights > > I've more or less used something I found for the documetation of the > wiki software, so please have a look at it and comment/object if > you'd like. Seems sensible to me. > /Christian > > PS. I wonder if maybe the copyright page is one of the rare pages > where editing should be restricted... Then you should get the spelling right. documentats? -- Angus
copyrights and Lyx wiki site
Hi I just put up some notes regarding copyrights and the LyX wiki site here: http://wiki.lyx.org/pmwiki.php/Site/Copyrights I've more or less used something I found for the documetation of the wiki software, so please have a look at it and comment/object if you'd like. /Christian PS. I wonder if maybe the copyright page is one of the rare pages where editing should be restricted... -- Christian Ridderström http://www.md.kth.se/~chr
Re: Can't read InsetVSpace from the dialog...
Angus Leeming wrote: >> IIRC: The stream should be good after reading the vsp item. It >> should go to 'eof' and 'fail' after one tries to read beyond the >> last item. > which depends on the implementation of getStream() doesn't it? Sorry. That's 'getString()' -- Angus
Re: Can't read InsetVSpace from the dialog...
Andre Poenitz wrote:
>> because we have reached the end of the stream, so this fails:
>> bool LyXLex::isOK() const
>> {
>> return pimpl_->is.good();
>> }
>
> IIRC: The stream should be good after reading the vsp item. It
> should go to 'eof' and 'fail' after one tries to read beyond the
> last item.
which depends on the implementation of getStream() doesn't it?
Here this:
lex >> name >> vsp;
std::istream & is = lex.getStream();
lyxerr << "is.good " << is.good() << '\n';
lyxerr << "is.bad " << is.bad() << '\n';
lyxerr << "is.eof " << is.eof() << '\n';
lyxerr << "is.fail " << is.fail() << '\n';
lyxerr << "name = \"" << name << "\" vspace = \"" << vsp
<< "\" lex \"" << bool(lex) << '"' << std::endl;
if (lex)
vspace = VSpace(vsp);
gives this output:
is.good 0
is.bad 0
is.eof 1
is.fail 1
name = "vspace" vspace = "medskip" lex "0"
So, it seems that we need
LyXLex::operator void *() const
{
return pimpl_->is.bad() ? 0 : const_cast(this);
}
LyXLex::operator!() const
{
return pimpl_->is.bad();
}
--
Angus
Re: Python warnings from lyx2lyx
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> On Tuesday 02 December 2003 09:41, Jean-Marc Lasgouttes wrote: >> What about submitting patches, then ;) Jose'> I will add the missing convertions to 1.4.x and then prepare Jose'> a patch for 1.3. :-) Thanks. JMarc
Re: Can't read InsetVSpace from the dialog...
On Tue, Dec 02, 2003 at 11:14:45AM +, Angus Leeming wrote:
> André, this (in InsetVSpaceMailer::string2params) fails to fill
> 'vspace':
>
> lex >> name >> vsp;
> if (lex)
> vspace = VSpace(vsp);
>
> because we have reached the end of the stream, so this fails:
> bool LyXLex::isOK() const
> {
> return pimpl_->is.good();
> }
IIRC: The stream should be good after reading the vsp item. It should
go to 'eof' and 'fail' _after_ one tries to read beyond the last item.
> as, therefore, does this:
> LyXLex::operator void *() const
> {
> return isOK() ? const_cast(this) : 0;
> }
>
> isOK() is documented as
> /// stream is open and end of stream is not reached
>
> so I think that we should change the operator void *() above to:
> LyXLex::operator void *() const
> {
> return pimpl_->is.fail() ? 0 : const_cast(this);
> }
return pimpl_->operator void*()
should do the trick Likewise for operator!.
I wonder why it failed though, I inserted a VSpace inset using the menu
and as this got it right I assumed the mailer worked...
> Ok? (Ditto with operator!(). I'll make the changes 'cos I have also
> made InsetVSpace::space_ private...)
Do the changes...
[..., but I am not happy with the semantics of 'isOK'. 'is.good()' is
rarely needed when handling streams, yet it seems to play a major role
in LyXLex. No need to act right now, though...]
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] fix exit crash
On Sun, Nov 30, 2003 at 03:41:15AM +, John Levon wrote: > > ->text() is NULL when you're shutting down with a discarded document > open. > > Fix accesses Btw, the 'resize' problem is fixed now, too. Andre'
Can't read InsetVSpace from the dialog...
André, this (in InsetVSpaceMailer::string2params) fails to fill
'vspace':
lex >> name >> vsp;
if (lex)
vspace = VSpace(vsp);
because we have reached the end of the stream, so this fails:
bool LyXLex::isOK() const
{
return pimpl_->is.good();
}
as, therefore, does this:
LyXLex::operator void *() const
{
return isOK() ? const_cast(this) : 0;
}
isOK() is documented as
/// stream is open and end of stream is not reached
so I think that we should change the operator void *() above to:
LyXLex::operator void *() const
{
return pimpl_->is.fail() ? 0 : const_cast(this);
}
Ok? (Ditto with operator!(). I'll make the changes 'cos I have also
made InsetVSpace::space_ private...)
--
Angus
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 06:33:59PM +, Angus Leeming wrote: > You have my vote too. Which reminds me: I like the mathed approach to > tables ;-) But it's harder to move the outer world tables that way... Andre'
Re: [patch] Qt scrolling
-BEGIN PGP SIGNED MESSAGE- On Dienstag, 2. Dezember 2003 11:18, Andre Poenitz wrote: > Ahm... I thought Angus was asking how to create the example, not how to > recreate the original word... Oh, you are right. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8xqPbewfbDGmeqhAQGaEgQAr/Dw6vib0ZWyHAXGH5C8DexGMi50wqH8 uQt6X1RNmVu4x8JzWhmFfqFYnzdRf77WfJX3KNaKV9kl0a+86QM+uBeqX85nLj/a YTTAZYFhlgUhxDYfbAEU+SXVBlwVPecHDLfKpcyA14sUo/bbSudIPqJeusOlcK4T HiYUmFxhnwA= =B/WG -END PGP SIGNATURE-
Re: Python warnings from lyx2lyx
On Tuesday 02 December 2003 09:41, Jean-Marc Lasgouttes wrote: > > What about submitting patches, then ;) I will add the missing convertions to 1.4.x and then prepare a patch for 1.3. :-) > JMarc -- José Abílio LyX and docbook, a perfect match. :-)
Re: [patch] Qt scrolling
On Tue, Dec 02, 2003 at 11:12:20AM +0100, Kornel Benko wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Dienstag, 2. Dezember 2003 11:09, Andre Poenitz wrote: > > > Not long, about 10 seconds. > > > > That's not bad. How did you do that? > > It was a very long word. There are not too many long-word-examples. > Some of them are starting with Donau ... One of them ends with > kajüte ... So not too difficult to compare the rest. Ahm... I thought Angus was asking how to create the example, not how to recreate the original word... Andre'
Re: [patch] Qt scrolling
-BEGIN PGP SIGNED MESSAGE- On Dienstag, 2. Dezember 2003 11:09, Andre Poenitz wrote: > > Not long, about 10 seconds. > > That's not bad. How did you do that? It was a very long word. There are not too many long-word-examples. Some of them are starting with Donau ... One of them ends with kajüte ... So not too difficult to compare the rest. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8xlhLewfbDGmeqhAQE2GwP+Ncy4VtXFkwdZXCzYSFQWl0LgDuUCrXXJ sc6Pn5GlCnvd5UxCdEoX9Z/D6BmCsvnCA6Msnh8urXUggD7L+j7Q2sgdKdc2d7UC obbId0ScFhBuJagQ6YOuabP+f4e8WTAqYjBKvxDXxmQ1ghQr+Y1qljlC2zyHqaLV 6hyuKMY8dzo= =MhaV -END PGP SIGNATURE-
Re: [patch] Qt scrolling
Kornel Benko wrote: > Sorry for the late reply .. I had to support a customer .. ;-) > Yes, selecting above and/or below the workarea is smoother. This I > like. But, may it be possible to disable the timer while selecting > inside the workarea? It is a little annoying to have to wait for the > selection, even if you are selecting only some few characters. The timeout _is_ disabled when selecting inside the work area. Only when you return from outside is there a delay (of duration one timeout (400ms)). This delay is a feature rather than a bug; it gives us the smooth feel when returning from outside rather than the really jumpy feel we had before as we handled (say) 10 QmouseMove events. > But even so, this is far better then before, so I vote for apply it. Nonetheless, I have reduced the timeout to 200ms (same as that in the xforms frontend). Personally I think that this gives us both smooth, controllable scrolling and instant response. I've committed the patch to cvs. See what you think; we can always return to 400ms if you find that you prefer the current feel. Once the feel has stabilized, I'll prepare a patch for 1.3.x. -- Angus
Re: [patch] Qt scrolling
On Tue, Dec 02, 2003 at 11:02:08AM +0100, Kornel Benko wrote: > > > The cssliac elpmaxe is 'Dcdhhiikmmnnopprssstttuzäüe' > > > > ...which goes to prove something or other ;-) > > > > Incidentally, how long did it take you to rearrange the letters in > > alphabetical order? > > Not long, about 10 seconds. That's not bad. How did you do that? Andre'
Re: [patch] Qt scrolling
On Tue, Dec 02, 2003 at 09:55:23AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > Srue. Wrkos eevn in Grmaen. > > > > The cssliac elpmaxe is 'Dcdhhiikmmnnopprssstttuzäüe' > > ...which goes to prove something or other ;-) > > Incidentally, how long did it take you to rearrange the letters in > alphabetical order? Less than a minute I suppose. echo D o n | tr ' ' '\n' | sort | tr -d '\n' Andre'
Re: [patch] Qt scrolling
-BEGIN PGP SIGNED MESSAGE- On Dienstag, 2. Dezember 2003 10:55, Angus Leeming wrote: > Andre Poenitz wrote: > > Srue. Wrkos eevn in Grmaen. > > > > The cssliac elpmaxe is 'Dcdhhiikmmnnopprssstttuzäüe' > > ...which goes to prove something or other ;-) > > Incidentally, how long did it take you to rearrange the letters in > alphabetical order? Not long, about 10 seconds. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8xjILewfbDGmeqhAQGp8wP/RbdlRm6ksRuwqqAjjGvoIFxY1UGM0E/M 7zgm/0U4jWBHb27wzoilCLBhBY9e7acmeIguAcerkoyHf7ZkrsGViF+iZdxD9lWI Fs7ihXheWurXmOMitvyHiiSuFhsAzuI9HlzNnMffQieVj8nL93cMtSINPG8LesI9 gKSkpP5QgtY= =qgE/ -END PGP SIGNATURE-
Cursor positioning with Pointer/Keys from minipage
-BEGIN PGP SIGNED MESSAGE- There seems to be a new effect. 1.) Position the cursor via pointer inside a minipage 2.) move the cursor down via a key until you leave the minipage 3.) repeat 1. and 2. (one or more times) Each time the cursor leaves the minipage, it is one row farther in text. (The very first time it is on row 1, even if the minipage starts at say row 20) Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8xi8LewfbDGmeqhAQFQjgQAl3217jSbuPNs4V8hwUdBHJT9thTukYQo eDlzGLKnHKlXLsMXQFAEY/ZGJHcxK1pq/72qnyPHQ+E40EO0Ej8y1CCFyFCwBYq/ gjKFq6XdEQPO7rQfPh0otDtgSpjaiHOxoo2IKJ1M6dKyXYWi6AUA0seR5DoU8rl9 dAU94usmke4= =/Yac -END PGP SIGNATURE-
Re: A working InsetVSpace
On Tue, Dec 02, 2003 at 09:52:47AM +, Angus Leeming wrote: > > Btw, I forgot to implement bool operator!() const. > > So, now you need two operators to replace a single isOk()... That's what the std::streams do. Usage is more concise, btw. Andre'
Re: [patch] Qt scrolling
Andre Poenitz wrote: > Srue. Wrkos eevn in Grmaen. > > The cssliac elpmaxe is 'Dcdhhiikmmnnopprssstttuzäüe' ...which goes to prove something or other ;-) Incidentally, how long did it take you to rearrange the letters in alphabetical order? -- Angus
Re: A working InsetVSpace
Andre Poenitz wrote: >> +if (lex) >> +vspace = VSpace(vsp); >> >> However, this isn't std::stream-like. > > Of course it is. > > 27.4.5.3 basic_ios iostate flags functions > [lib.iostate.flags] > > operator void*() const > > Returns: > If fail() then a null pointer; otherwise some non-null pointer > to indicate success. Ok, thank you. > Btw, I forgot to implement bool operator!() const. So, now you need two operators to replace a single isOk()... But, I'm arguing for the sake of it and will stop. Your interface is much more user-friendly than the old one: thanks. -- Angus
Re: [patch] Qt scrolling
-BEGIN PGP SIGNED MESSAGE- On Dienstag, 2. Dezember 2003 00:11, Angus Leeming wrote: > > Try 3, Kornel. > > > > This one should feel much smoother when you move the mouse back into > > the work area. In fact, I thnk that this is ready to go into the > > sources (and, indeed, be ported to 1.3.x) but I'd value it if you > > road-tested it for me one more time. > > Actually, try this. Factually the same but the debug output is gone, > the comments reflect reality and it'll actually apply against current > cvs ;-) Sorry for the late reply .. I had to support a customer .. Yes, selecting above and/or below the workarea is smoother. This I like. But, may it be possible to disable the timer while selecting inside the workarea? It is a little annoying to have to wait for the selection, even if you are selecting only some few characters. But even so, this is far better then before, so I vote for apply it. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8xf4bewfbDGmeqhAQF2/AP+PnfF/cYWByQxlqnVNI3t3Bd07Xbd24ZH fX0RxFi8k9R0Bza4Sd9DI/0OUnVr0ZlmcXBwDB6agEeDgOHJDxJw3l0a+RRgMUNU xgEnkBH9cmTPHVGEEncJJMOfSLbAMCkfh+ANVrSn5f/PjfFa9arMPmu6GhOiLmiP wSrz6dVmmg8= =LmbA -END PGP SIGNATURE-
Re: The current char style UI
On Tue, Dec 02, 2003 at 10:53:26AM +0100, Helge Hafting wrote:
> At least latex lets me change from "\emph{This is marked}" to
> "\emph{This} is \emph{marked}" without retyping any text. :-)
This is implementable with 'boxes in boxes', too.
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: The current char style UI
Martin Vermeer wrote:
On Mon, Dec 01, 2003 at 12:20:33PM +0100, Helge Hafting spake thusly:
Of course code for deleting or "unapplying" an inset (e.g., backspace
in pos 0, like in math) could be created as well. But what you will
never be able to do in this paradigm is "unapplying" a charstyle for a
piece in the middle of an applied charstyle, as you can do with
physical attributes -- or more generally, creating arbitrary bit
patterns of attributes. (But then I would argue "why would you want
to?")
Because people work that way?
Eh, people also insert empty paragraphs and expect them to be there
when they come back :-)
This rarely turns out to be a problem, for me at least. The advantage
of never having to remove extraneous empty paragraphs is substantial.
There is of course nothing wrong in changing the way people work,
as long as the "new" way is equally efficient.
Example:
I paste two big quotes from other text into my document. Between them
is a "and" or something that isn't part of the quote.
(Because of "blablablah" and "blablah" we see that . . .)
I could mark each quote in turn and set them to some quote style. It might be
easier to mark everything and then unapply the "and" in the middle though.
Not easier, same number of steps. Only easier if it is "the way we've
always done it", which I don't really accept as an argument.
Same number of steps, sure. Maybe the example wasn't that good,
but I believe "unapplying" style is necessary. Perhaps I didn't
want that paragraph marked up after all, or perhaps I copied
it and don't want the markup in the copy.
And people really do get the mouse wrong from time to time,
marking too much only to realize it later. It is at least
nice to be able to unapply markup at the ends of marked
text. Unapplying in the middle is a nice extra, unless it is
much more difficult.
I do realize that near all (other) word processors use the "independent
character attribute bits" mental model, which works and is consistent
but somewhat messy to implement. This however is the "text objects with
properties" mental model, which is quite different, but I would claim
just as easy to learn and more logical/realistic. Which is perhaps why
LaTeX uses it.
At least latex lets me change from "\emph{This is marked}" to
"\emph{This} is \emph{marked}" without retyping any text. :-)
The only thing really that is wrong with the current representation of
these objects as insets is how they look. A text containing even many
of them should look continuous and fluently legible on the screen,
across inset boundaries. We aren't there yet.
Perhaps I even want to add the non-quote "and" _after_ pasting in the
stuff and setting the style. I.e. break up the quote, just as I
occationally break up a paragraph.
Perhaps. Or perhaps you should just get used to the reality that *this
is a different paradigm* and you use it best on its own terms. Just
playing the devil's advocate here.
Well, a new way of working is ok, as long as it doesn't restrict me
after learning the details. I guess I don't do that much "unapplying
in the middle" but I certainly turn off markup from time to time.
such as "too many emphasized words in a paragraph turns out ugly,
lets keep only the most important one." Or I might have an
emphasized sentence somewhere, extend it and then find that
there is now too much italic and decide to clean it up.
Or I might get to clean up a text by someone else, with way too much
markup.
This must be possible without retyping. Selective unapplying
is probably the most user friendly. At the very least an ability
to remove all markup in a selection that doesn't end in the middle
of some inset.
Don't get me wrong, I believe the new style system is a good thing.
I just got scared by the impression of not being able to turn
off text properties. Authors don't get everything right the first
time, thats why a document processor beats the typewriter. :-)
Helge Hafting
Re: Python warnings from lyx2lyx
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> On Saturday 29 November 2003 10:04, Ronald Florence wrote: >> I am seeing warnings from the lyx2lyx scripts: >> Jose'> [ python error/warning ] >> If I understand the web page recommended in the warnings, they >> want lines like >> >> # -*- coding: iso-latin-1-unix -*- >> >> inserted at the top of the Python files because of José Matos' >> name. Jose'> True, that is fixed in 1.4 and probably 1.3.4 (if ever) will Jose'> have the 1.4 lyx2lyx so that will fix the bug in 1.3.x What about submitting patches, then ;) JMarc
Re: [patch] Qt scrolling
On Tue, Dec 02, 2003 at 09:22:03AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > On Mon, Dec 01, 2003 at 09:50:17PM +, Angus Leeming wrote: > > > >> + [...] 'psuedo' [...] > > > > The truoble with that langauge of yuors is that their is no > > ricognizible pattern in the youse of vowils. > > And the azamnig tnhig aobut Egnlsih is taht tehre dosen't need to be > to mkae snese of it so lnog as I get the frsit and lsat ltetres > rhgit. Srue. Wrkos eevn in Grmaen. The cssliac elpmaxe is 'Dcdhhiikmmnnopprssstttuzäüe' Andre'
Re: A working InsetVSpace
On Tue, Dec 02, 2003 at 09:17:31AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > At least making the LyXLex interface a bit similar to the > > std::streams would make me feel better. > > > > Patch attached. > > > +/// file is open and end of file is not reached > > +operator void *() const; > > I don't like this. But that's what std::iostream does. > We already have problems catching implicit > conversions. Witness all those (bv()) arguments that are slowly being > changed to (true) or (false) and have nothing to do with the > existence of a BufferView anymore. > > > From a less political, more coding, point of view, why not 'operator > > bool() const;' if that is what you actually use it for? Exactly for the reason you mention: A void * is convertable to a bool, but not an integer (without cast). So this is safer. > +if (lex) > +vspace = VSpace(vsp); > > However, this isn't std::stream-like. Of course it is. 27.4.5.3 basic_ios iostate flags functions[lib.iostate.flags] operator void*() const Returns: If fail() then a null pointer; otherwise some non-null pointer to indicate success. Btw, I forgot to implement bool operator!() const. > The std::stream-like interface would be > if (lex.good()) > vspace = VSpace(vsp); I think if (!lex.fail()) is the correct idiom, at least that's what is required for the implementation of 'operator void *'. But I never needed to understand these details as if (is) and if (!is) do what is needed. > Nonetheless, it does look a lot nicer. It also doesn't address the > 'end_inset' thingy at all ;-) Surprise. 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] Qt scrolling
Andre Poenitz wrote: > On Mon, Dec 01, 2003 at 09:50:17PM +, Angus Leeming wrote: > >> + [...] 'psuedo' [...] > > The truoble with that langauge of yuors is that their is no > ricognizible pattern in the youse of vowils. And the azamnig tnhig aobut Egnlsih is taht tehre dosen't need to be to mkae snese of it so lnog as I get the frsit and lsat ltetres rhgit. But, granted, I'll fix it up. -- Angus
Re: A working InsetVSpace
Andre Poenitz wrote: > At least making the LyXLex interface a bit similar to the > std::streams would make me feel better. > > Patch attached. > +/// file is open and end of file is not reached > +operator void *() const; I don't like this. We already have problems catching implicit conversions. Witness all those (bv()) arguments that are slowly being changed to (true) or (false) and have nothing to do with the existence of a BufferView anymore. >From a less political, more coding, point of view, why not 'operator bool() const;' if that is what you actually use it for? +if (lex) +vspace = VSpace(vsp); However, this isn't std::stream-like. The std::stream-like interface would be if (lex.good()) vspace = VSpace(vsp); Nonetheless, it does look a lot nicer. It also doesn't address the 'end_inset' thingy at all ;-) -- Angus
Re: A working InsetVSpace
On Mon, Dec 01, 2003 at 09:20:33PM +, Angus Leeming wrote:
> Cheers, Georg. Applied, although I suspect that someone will now try
> and factorize all these pieces of code handling 'end_inset'...
At least making the LyXLex interface a bit similar to the std::streams
would make me feel better.
Patch attached.
Andre'
Index: lyxlex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlex.C,v
retrieving revision 1.46
diff -u -p -r1.46 lyxlex.C
--- lyxlex.C6 Oct 2003 15:42:26 - 1.46
+++ lyxlex.C2 Dec 2003 08:58:33 -
@@ -254,3 +254,61 @@ int LyXLex::findToken(char const * str[]
return i;
}
+
+
+LyXLex::operator void *() const
+{
+ return isOK() ? const_cast(this) : 0;
+}
+
+
+LyXLex & LyXLex::operator>>(std::string & s)
+{
+ if (isOK()) {
+ next();
+ s = getString();
+ }
+ return *this;
+}
+
+
+LyXLex & LyXLex::operator>>(float & s)
+{
+ if (isOK()) {
+ next();
+ s = getFloat();
+ }
+ return *this;
+}
+
+
+LyXLex & LyXLex::operator>>(int & s)
+{
+ if (isOK()) {
+ next();
+ s = getInteger();
+ }
+ return *this;
+}
+
+
+LyXLex & LyXLex::operator>>(unsigned int & s)
+{
+ if (isOK()) {
+ next();
+ s = getInteger();
+ }
+ return *this;
+}
+
+
+LyXLex & LyXLex::operator>>(bool & s)
+{
+ if (isOK()) {
+ next();
+ s = getBool();
+ }
+ return *this;
+}
+
+
Index: lyxlex.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlex.h,v
retrieving revision 1.36
diff -u -p -r1.36 lyxlex.h
--- lyxlex.h7 Oct 2003 06:45:24 - 1.36
+++ lyxlex.h2 Dec 2003 08:58:33 -
@@ -57,6 +57,8 @@ public:
/// file is open and end of file is not reached
bool isOK() const;
+ /// file is open and end of file is not reached
+ operator void *() const;
/// return true if able to open file, else false
bool setFile(std::string const & filename);
///
@@ -110,8 +112,7 @@ public:
///
int findToken(char const * str[]);
- /** Pushes a token list on a stack and replaces it with a new one.
-*/
+ /// Pushes a token list on a stack and replaces it with a new one.
void pushTable(keyword_item *, int);
/** Pops a token list into void and replaces it with the one now
@@ -125,10 +126,22 @@ public:
*/
void printError(std::string const & message) const;
- /**
- Prints the current token table on the supplied ostream.
- */
+ /// Prints the current token table on the supplied ostream.
void printTable(std::ostream &);
+
+ /// extract string
+ LyXLex & operator>>(std::string &);
+ /// extract float
+ LyXLex & operator>>(float &);
+ /// extract double
+ LyXLex & operator>>(double &);
+ /// extract integer
+ LyXLex & operator>>(int &);
+ /// extract unsigned integer
+ LyXLex & operator>>(unsigned int &);
+ /// extract bool
+ LyXLex & operator>>(bool &);
+
private:
struct Pimpl;
///
Index: insets/insetvspace.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetvspace.C,v
retrieving revision 1.4
diff -u -p -r1.4 insetvspace.C
--- insets/insetvspace.C1 Dec 2003 21:19:16 - 1.4
+++ insets/insetvspace.C2 Dec 2003 08:58:33 -
@@ -246,18 +246,10 @@ void InsetVSpaceMailer::string2params(st
istringstream data(in);
LyXLex lex(0,0);
lex.setStream(data);
-
- if (lex.isOK()) {
- lex.next();
- string const name = lex.getString();
- }
-
- // This is part of the inset proper that is usually swallowed
- // by Buffer::readInset
- if (lex.isOK()) {
- lex.next();
- vspace = VSpace(lex.getString());
- }
+ string name, vsp;
+ lex >> name >> vsp;
+ if (lex)
+ vspace = VSpace(vsp);
}
Re: LyX 1.4 task list
On Monday 01 December 2003 09:48, Michael Schmitt wrote: > Hello, > > I still do not give up hope that LyX 1.4 will eventually become reality. > > Since http://www.devel.lyx.org/roadmap.php3 is totally outdated (it > lists some features that were initially planned for 1.2), I started to > set up a new task list covering the remaining open issues of LyX 1.4. I really think that you intended to write 0.12 and not 1.2. ;-) > Beside the usual bug fixing, I see the following open issues: > > *** > > Mandatory tasks > > - LyX2LyX > - Vspace conversion - convertion of emphasis and noun to the new logical char styles - revert of vspace, line and pagebreak for 1.3 > Of course, this is just my personal opinion... > > Michael -- José Abílio LyX and docbook, a perfect match. :-)
Re: Python warnings from lyx2lyx
On Saturday 29 November 2003 10:04, Ronald Florence wrote: > I am seeing warnings from the lyx2lyx scripts: > [ python error/warning ] > > If I understand the web page recommended in the warnings, they want lines > like > > # -*- coding: iso-latin-1-unix -*- > > inserted at the top of the Python files because of José Matos' name. True, that is fixed in 1.4 and probably 1.3.4 (if ever) will have the 1.4 lyx2lyx so that will fix the bug in 1.3.x > This is with LyX/Mac-1.3.3 on MacOS-10.3.1. In this case that happens everywhere. :-) -- José Abílio LyX and docbook, a perfect match. :-)
Re: [patch] Qt scrolling
On Mon, Dec 01, 2003 at 09:50:17PM +, Angus Leeming wrote: > + [...] 'psuedo' [...] The truoble with that langauge of yuors is that their is no ricognizible pattern in the youse of vowils. Andre'
Re: [patch] fix for inlied ERT
On Mon, Dec 01, 2003 at 10:32:48PM +0200, Martin Vermeer wrote: > - > @@ -1620,7 +1624,7 @@ void LyXText::metrics(MetricsInfo & mi, > // final dimension > dim.asc = firstRow()->ascent_of_text(); > dim.des = height - dim.asc; > - dim.wid = std::max(mi.base.textwidth, int(width)); > + dim.wid = width; > } > - > > Does this now mean that LyXText returns proper widths again? Probably, yes. Urm... I just found out that short open footnotes are now 'semi inline' but I think I even like this. So everybody please have a look before shouting 'regression'. > In that case I'll have to have a look at inlined CharStyles again ;-) Good idea... 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...)
