Re: Patches waiting
On 12-Dec-2001 Jean-Marc Lasgouttes wrote: I have to admit that I am not sure. Harcoding SUBSCRIPT SUPERSCRIPT to output ^ and _ in text mode is not better than hardcoding them in math as we had before. Maybe these functions could be changed in text to insert the character they have been bound to, but this is really hackish. Well as much as I know ^ may be a deadkey and if it IS a deadkey it can be used to put it over a character! But if it's no deadkey then it definitely in textmode should input a ^ character. For the _ (underscore) in text mode it definitively should input a _ character always. As for mathmode I don't know (and don't really care ;) but the problem is if we want be 100% compatible with the behaviour in 1.1.6 or if we don't. Anyway IMO ^ can be used to go in subscript (in mathed) and if ^ is a deadkey it should anyway go into subscript (if we get the token otherwise it can handle it only after the (space). For _ it's never a deadkey so there seems to be no problem. In mathmode go in subscript in math-text mode insert a _ character. I do not know what the right solution is, but we have to find one... I was just thinking out aloud above, but that's what I think is most resonable. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ OK, now let's look at four dimensions on the blackboard. -- Dr. Joy
Re: Herbert's problems with large documents loading time
On 12-Dec-2001 Lars Gullik Bjønnes wrote: Found a LyXText that fits: Buffer: 0x84d0aa0 Width: 667 TextCache: resizeCurrentBuffer Buffer: 0x84d06b8 Width: 667 Why does it a resize if the sizes are the same??? A resize has to recalculate ALL of the insettext! Are you sure we do a resize REALLY or are we just outputting the text? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Can you program? Well, I'm literate, if that's what you mean!
Re: menus
On Tue, Dec 11, 2001 at 03:23:34PM +0100, Jean-Marc Lasgouttes wrote:
Do we really need this part:
+Menu insert_math_symbol
+ Item Black board bold N math-insert \mathbb{N}
+ Item Black board bold Q math-insert \mathbb{Q}
+ Item Black board bold R math-insert \mathbb{R}
+ Item Black board bold Z math-insert \mathbb{Z}
End
Put them in the math panel if you want them.
I don't like the math panel for at least three reasons:
- there is no way to navigate it using the keyboard,
- it is much more effort to fiddle around with the xform dialogs,
- I do not xform dialogs.
And \mathbb{C} is not even present...
I missed that one.
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Re: Herbert's problems with large documents loading time
I don't know what JMarc did, but it seems to be the right patch for working with the 1.2 doc. Well I would say we have the Hero of the day then ;) Anyway IMO 2 secs is too much if you didn't change the width of the BufferView. We just have to switch over pointers and redraw the visible area, that shouldn't take that long! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Boycott meat -- suck your thumb.
Re: new spam control?
On Wed, Dec 12, 2001 at 12:39:47PM -0600, Mate Wierdl wrote: The main reason is that there are still at least two-three spams each week slipping into the lyx lists. (Nowadays, there are over 100 spam messages addressed to the lyx lists each day). I think two or three spam postings per _week_ are ok. Don't make using the list too awkward... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: new spam control?
On 13-Dec-2001 Andre Poenitz wrote: On Wed, Dec 12, 2001 at 12:39:47PM -0600, Mate Wierdl wrote: The main reason is that there are still at least two-three spams each week slipping into the lyx lists. (Nowadays, there are over 100 spam messages addressed to the lyx lists each day). I think two or three spam postings per _week_ are ok. Don't make using the list too awkward... Well IMO that we could do something like that on lyx-devel as I've seen that lot's of devel list restrict the access much more. Are there really lot's of people on this list who post from different addresses? Anyway Mate you know more or less who's posting to the list right now and so an initial whitelist can be created from that. I don't find it too much hassle to confirm just one time a post to a developers list (especially if we write some nice text in the confirmation message). Anyway IMO that 85% of the posts (if not more) are always from the same people. But really the SPAM on this list is fortuantely (due to Mate's good work) really low! But it's a bit annoying to have spam in the mailing-archive (does it work Mate?). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Let the people think they govern and they will be governed. -- William Penn, founder of Pennsylvania
Re: [martin.vermeer@hut.fi: Re: Patches waiting]
On Wed, Dec 12, 2001 at 10:35:10PM +0100, Lars Gullik Bjønnes wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk X-No-Archive: yes List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [[EMAIL PROTECTED]: Re: Patches waiting] From: [EMAIL PROTECTED] (Lars Gullik Bjønnes) Organization: LyX Developer http://www.lyx.org/ Date: Wed, 12 Dec 2001 22:35:10 +0100 In-Reply-To: [EMAIL PROTECTED] User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) Martin Vermeer [EMAIL PROTECTED] writes: | Ctrl-_ subscript Ctrl-_ is undo (in emacs.bind) -- Lgb Drat! Next attempt. 1) Index: lyx_main.C === RCS file: /cvs/lyx/lyx-devel/src/lyx_main.C,v retrieving revision 1.97 diff -u -p -r1.97 lyx_main.C --- lyx_main.C 2001/11/26 10:19:49 1.97 +++ lyx_main.C 2001/12/13 08:25:25 @@ -523,6 +523,11 @@ void LyX::defaultKeyBindings(kb_keymap kbmap-bind(Delete, LFUN_DELETE); kbmap-bind(BackSpace, LFUN_BACKSPACE); + + // sub- and superscript -MV + kbmap-bind(~S-M-underscore, LFUN_SUBSCRIPT); + kbmap-bind(~S-M-asciicircum, LFUN_SUPERSCRIPT); + kbmap-bind(~S-M-dead_circumflex, LFUN_SUPERSCRIPT); // kbmap-bindings to enable the use of the numeric keypad // e.g. Num Lock set @@ -580,7 +585,7 @@ void LyX::deadKeyBindings(kb_keymap * kb kbmap-bind(~C-~S-~M-dead_caron, LFUN_CARON); kbmap-bind(~C-~S-~M-dead_cedilla, LFUN_CEDILLA); kbmap-bind(~C-~S-~M-dead_abovering, LFUN_CIRCLE); - kbmap-bind(~C-~S-~M-dead_circumflex, LFUN_CIRCUMFLEX); + kbmap-bind(~C-~S-dead_circumflex, LFUN_CIRCUMFLEX); kbmap-bind(~C-~S-~M-dead_abovedot, LFUN_DOT); kbmap-bind(~C-~S-~M-dead_grave, LFUN_GRAVE); kbmap-bind(~C-~S-~M-dead_doubleacute, LFUN_HUNG_UMLAUT); 2) Index: lyx_main.C === RCS file: /cvs/lyx/lyx-devel/src/lyx_main.C,v retrieving revision 1.97 diff -u -p -r1.97 lyx_main.C --- lyx_main.C 2001/11/26 10:19:49 1.97 +++ lyx_main.C 2001/12/13 08:26:26 @@ -523,7 +523,11 @@ void LyX::defaultKeyBindings(kb_keymap kbmap-bind(Delete, LFUN_DELETE); kbmap-bind(BackSpace, LFUN_BACKSPACE); - + + // sub- and superscript -MV + kbmap-bind(C-~S-M-minus, LFUN_SUBSCRIPT); + kbmap-bind(C-~S-M-plus, LFUN_SUPERSCRIPT); + // kbmap-bindings to enable the use of the numeric keypad // e.g. Num Lock set //kbmap-bind(KP_0, LFUN_SELFINSERT); Both work, allow _ and ^ insertion in text and don't seem to conflict with any bind file entries. And all accents work. Ad 1: + close to existing TeX convention - lots of keystrokes required, including extra M-space if no asciicircum on keyboard Ad 2: + less keystrokes, fairly intuitive + doesn't use those #¤%#¤ deadkeys (believe me, they will continue to haunt us!) - requires new learning - should be in mathpanel/menu with shortcut listed - people that have set up X to switch resolution with C-M-KP_Add etc may get confused. But they probably know what they are doing anyway. I am sure there are other alternatives too, but none that are free look tempting or intuitive. What to do? Cheers Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg30462/pgp0.pgp Description: PGP signature
Bugs in Debian BTS
There are quite a few bugs in the debian BTS which neither me nor Jules know if they are valid or not, I'd be happy if someone more knowledgeable in this bugs can let me know their status. The whole bug lists cant be found at: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=lyxrepeatmerged=no Specific bugs that should be looked over: Lyx Crashes when a character is composed of deadkeys http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69396 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75926 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77894 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77989 LyX crashes randomly when pasting text from another window http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=103715 too large menu fonts cause segfault with german locale http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120450 Errors handling 'Paragraph' type paragraphs http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120688 Baruch
Re: dramantic increases in forced rodent use
John Levon [EMAIL PROTECTED] writes: and for years, people have been forced to go to the manual to work out ^ some how to enter lengths. More recently, we have had a vague help message in some places. Other people have entered length just as they always did. The new interface makes it patently clear what we are expecting, and reduces the potential for user error. ACK. But it does make thing for people who know harder. This is basic good UI design [1] No, absolutely not. A good UI is not only easy but also convenient. This might be a bit hard for a GUI, but it is possible. What about the following idea: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Bug #57
Jean-Marc this should be easy for you to resolve! What do you need to disable the paragraph menu? Or we could ask inside the Controller and call some function bool Paragraph::noDialog(). What do you think? Jug P.S.: Could we registrate a [EMAIL PROTECTED] user on the buglist? It would be nice if we could add it as Cc: to some replies we make so that they go to the lyx-devel list to (I'm thinking of faster response times and people like Andre, but also myself), otherwise one has to post the question to lyx-devel separately as I did here! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ He who attacks the fundamentals of the American broadcasting industry attacks democracy itself. -- William S. Paley, chairman of CBS
Re: dramantic increases in forced rodent use
On 13-Dec-2001 Thomas Steffen wrote: You can still enter length as usual, the parser recognises it and sets the drop-down list accordingly. I think we already somehow decided to adapt this solution (or a similar one which also gives the power to insert stuff like 1cm+2em-4em). Since the parser did check for correct units, and since the drop-down list is implemented, it should be only a little additional work. And it marks both sides happy. Well not only but with the above solution we also need to (de)activate the Ok/Apply buttons and also output an error message why the buttons got disabled, but let's say it's doable with a bit of work. You could also go as far as XEmacs: provide two ways for every option. One keybord based in the status line and one pop-up window for rodent users. But this is of course a lot more work (though it is extremely fast to use). Well we're not that far away from that aproach already now if you know how you can do a lot of things that way (I mean Meta-x command options). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Inspiration without perspiration is usually sterile.
Re: crash=stupid me
On 13-Dec-2001 Garst R. Reese wrote: Garst R. Reese wrote: duh Well IMO a crash is a crash! But I lost the former mail so why is it only your error? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ In the misfortune of our friends we find something that is not displeasing to us. -- La Rochefoucauld, Maxims
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Lars Gullik Bjønnes wrote: Oh just read the code... Oh may I do that! You're too good! (and it is possible that we do a resize to many) Well you surely had a look so you should know ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Oh this age! How tasteless and ill-bred it is. -- Gaius Valerius Catullus
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Lars Gullik Bjønnes wrote: _or_ are we just covering the real problem? No he really resolved a problem we had looking up paragraphs inside insets! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Moneyliness is next to Godliness. -- Andries van Dam
Re: menus
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Put them in the math panel if you want them.
Andre I don't like the math panel for at least three reasons: - there
Andre is no way to navigate it using the keyboard, - it is much more
Andre effort to fiddle around with the xform dialogs, - I do not
Andre xform dialogs.
What I meant is that it is not an excuse for populating the menu with
a random list of what you may find useful at a given moment.
And \mathbb{C} is not even present...
Andre I missed that one.
This was just an example. What about having a blackboard math toggle
in the menu?
JMarc
Re: bug tracker
On Wed, Dec 12, 2001 at 09:14:46AM +, John Levon wrote: - relyx - LaTeX Import program please add me to reLyX, because sometimes I understand a little bit how it works. (but only sometimes) regards john -- Take the ideas you find useful. Try not to get hung up on the labels. - Jonathan S. Shapiro -- José Abílio Matos LyX and docbook a perfect match. :-)
Re: bug tracker
On Thu, Dec 13, 2001 at 10:51:14AM +0100, Lars Gullik Bjønnes wrote: | Good point. The categories should be end-user friendly. I disagree. The enduser should be provided a broad set of categories, _but_ the developers should have a _detailed_ set of categories. We expect the bug-receiver to analyze the bug and put it in the correct category. | When bugs get created, they can be sifted and assigned to the appropriate | developers. When _analyzed_. It is not the end-users job to find the correct category. Hi Lars, We violently agree. The best solution is to give the users broad categories and us developers fine-grained categories. ---Kayvan -- 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: Herbert's problems with large documents loading time
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 12-Dec-2001 Lars Gullik Bjønnes wrote: Found a LyXText that fits: Buffer: 0x84d0aa0 Width: 667 TextCache: resizeCurrentBuffer Buffer: 0x84d06b8 Width: 667 Juergen Why does it a resize if the sizes are the same??? A resize Juergen has to recalculate ALL of the insettext! Are you sure we do a Juergen resize REALLY or are we just outputting the text? I did some profiling (I did a lot of document switches to give it a higher weight than the initial loading phase) and a lot of time is spent in Buffer::resizeInsets. I notice too that this method is called unconditionally in BufferView::Pimpl::resizeCurrentBuffer. And then I ran out of competence, and stopped here. Does it make sense. JMarc
Re: Herbert's problems with large documents loading time
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Juergen Vigna [EMAIL PROTECTED] writes: I don't know what JMarc did, but it seems to be the right patch for working with the 1.2 doc. Lars | Well I would say we have the Hero of the day then ;) Lars _or_ are we just covering the real problem? Let's say we have to handle one problem at a time. JMarc
Re: menus
On Thu, Dec 13, 2001 at 11:11:02AM +0100, Jean-Marc Lasgouttes wrote: This was just an example. What about having a blackboard math toggle in the menu? Ok, so be it... Although I'd rather have the most common symbols diretly in the menu... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: menus
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Thu, Dec 13, 2001 at 11:11:02AM +0100, Jean-Marc Lasgouttes Andre wrote: This was just an example. What about having a blackboard math toggle in the menu? Andre Ok, so be it... Can you provide the necessary infrastructure? And for greek too, I guess. Andre Although I'd rather have the most common symbols diretly in Andre the menu... I doubt that the menu will remain as useful if we begin to add random things in it. Why blackboard symbols and not your favourite greek letters?
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Jean-Marc Lasgouttes wrote: I did some profiling (I did a lot of document switches to give it a higher weight than the initial loading phase) and a lot of time is spent in Buffer::resizeInsets. I notice too that this method is called unconditionally in BufferView::Pimpl::resizeCurrentBuffer. And then I ran out of competence, and stopped here. Does it make sense. Well maybe. In pre-InsetText times a resize was not so heavy as it only had to rebreak the actual LyXText! Now if you use a lot of insets it is MUCH heavier. We surely can do some profiling here and make a resize a bit faster, but we surely should maybe with the LyXText save also it's width and then on reputting it on screen check this with the actual width and do a resize only if really needed! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Excellent day for drinking heavily. Spike the office water cooler.
Re: menus
On Thu, Dec 13, 2001 at 11:28:35AM +0100, Jean-Marc Lasgouttes wrote: Andre Although I'd rather have the most common symbols diretly in Andre the menu... I doubt that the menu will remain as useful if we begin to add random things in it. Why blackboard symbols and not your favourite greek letters? I was thinking about putting them into differnt submenus later. Sort of menuized math panel... As I said, I find the panel too clumsy to use - both as programmer and as user. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Bug #57
P.S.: Could we registrate a [EMAIL PROTECTED] user on the buglist? It would be nice if we could add it as Cc: to some replies we make so that they go to the lyx-devel list to (I'm thinking of faster response times and people like Andre, but also myself), otherwise one has to post the question to lyx-devel separately as I did here! Done -- | Michael Koziarski |Conventional wisdom is often | | Data Engineer, Linux user | long on convention and short | | Objectivist. | on wisdom -- | | http://www.koziarski.com| Warren E. Buffett, BRK.A |
Re: Herbert's problems with large documents loading time
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 13-Dec-2001 Jean-Marc Lasgouttes wrote: I did some profiling (I did a lot of document switches to give it a higher weight than the initial loading phase) and a lot of time is spent in Buffer::resizeInsets. I notice too that this method is called unconditionally in BufferView::Pimpl::resizeCurrentBuffer. And then I ran out of competence, and stopped here. Does it make sense. Juergen Well maybe. In pre-InsetText times a resize was not so heavy Juergen as it only had to rebreak the actual LyXText! Now if you use Juergen a lot of insets it is MUCH heavier. We surely can do some Juergen profiling here and make a resize a bit faster, but we surely Juergen should maybe with the LyXText save also it's width and then Juergen on reputting it on screen check this with the actual width Juergen and do a resize only if really needed! Yes, but Buffer::resizeInsets should not be run if the window has not changed size, isn't it? JMarc
Re: Herbert's problems with large documents loading time
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | Let's say we have to handle one problem at a time. Lars Sure, but if you do a fix that covers the real problem, the real Lars problem will never be fixed. I fixed the problem that resize take a quadratic time when they should not. What remains to fix is that we resize in cases where is is unnecessary IMO. JMarc
Re: Undo leaking
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen I'm pretty sure I know now where we leak (and where we ALWAYS
Juergen leaked) with undo/redo. The problem is that we don't delete
Juergen the paragraphs we substitute.
Juergen The code is in textHandleUndo() and IMO we have to change
Juergen this peace of code:
I applied you patch since it seems fine. However, this exposes a bug
and crashes when one uses undo in the first paragraph of a document.
For your viewing pleasure, here is what I wrote in undo_funcs.C:
// put the new stuff in the list if there is one
if (tmppar3){
if (before)
before-next(tmppar3);
else
#warning Juergen, why is this needed?? (JMarc)
// since tmppar3 is not yet inserted in the document, I do not see why
// the getParFromID which is done by the function below makes sense.
// OTOH, since you wrote the method just for this instance, I guess you
// have something in mind
#if 1
bv-text-ownerParagraph(tmppar3-id(),
tmppar3);
#else
// in this case, since getParFromID is not called, the program does
// not crash on trying to access buffer()-paragraph, which does not
// exist anymore if we undid the first par f the document. (JMarc)
bv-text-ownerParagraph(tmppar3);
#endif
tmppar3-previous(before);
Juergen, would you care to explain what happens or (better) to provide
a fix?
JMarc
Re: [noreply@sourceforge.net: [ lyxbugs-Feature Requests-439373 ] Support \intertext in mathed]
On Wed, Dec 12, 2001 at 04:35:43PM +0100, Jean-Marc Lasgouttes wrote: Andre How am I supposed to react to mails like this: You are not supposed to, since these are from the old bugtracker. Whom should I tell that such a bug is fixed? The original poster? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [noreply@sourceforge.net: [ lyxbugs-Feature Requests-439373 ] Support \intertext in mathed]
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Wed, Dec 12, 2001 at 04:35:43PM +0100, Jean-Marc Lasgouttes Andre wrote: How am I supposed to react to mails like this: You are not supposed to, since these are from the old bugtracker. Andre Whom should I tell that such a bug is fixed? The original Andre poster? You could go here http://cvs.koziarski.com/show_bug.cgi?id=90 and close it, but maybe Michael or John can propose a mail only solution to do that. JMarc
wysiwyM - the origin
Hi, someone know who created the word what youe see is what you MEAN and the abbreviation wysiwym? (allways for my p-h-a-n-t-a-s-t-i-c study :-) ciao, antonio
Re: LDN mascot
On Thu, Dec 13, 2001 at 10:58:42AM +1000, Allan Rae wrote: On Wed, 12 Dec 2001, Jose Abilio Oliveira Matos wrote: On Wed, Dec 12, 2001 at 10:26:21AM +1000, Allan Rae wrote: As for the contest I think we have had arguements on that earlier this year and nobody wanted to change from the existing creature design. The pretty anti-aliased version will be used soon enough but it is still the same design. I love the present design, I only want a name for our pet. And no John, I don't think that he is called Steve. :-) I suppose one question we might want to answer first is: Is it a he, she or an it? Do we care? I guess that -- although I have no particular liking for the name, I'd have to go for Felix (Felyx?). Or Alyx. -Amir
Re: LDN mascot
Amir == Amir Karger [EMAIL PROTECTED] writes: Amir I guess that -- although I have no particular liking for the Amir name, I'd have to go for Felix (Felyx?). Or Alyx. Obelyx? JMarc
Re: LDN mascot
On Thu, Dec 13, 2001 at 03:16:42PM +0100, Jean-Marc Lasgouttes wrote: Amir I guess that -- although I have no particular liking for the Amir name, I'd have to go for Felix (Felyx?). Or Alyx. Obelyx? This somehow suggests some kind of bloat... Don't know why... So yes, looks suitable ;-) Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Bugs in Debian BTS
Baruch == Baruch Even [EMAIL PROTECTED] writes:
Baruch There are quite a few bugs in the debian BTS which neither me
Baruch nor Jules know if they are valid or not, I'd be happy if
Baruch someone more knowledgeable in this bugs can let me know their
Baruch status.
Baruch The whole bug lists cant be found at:
Baruch http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=lyxrepeatmerged=no
Baruch Specific bugs that should be looked over:
Baruch Lyx Crashes when a character is composed of deadkeys
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69396
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=75926
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77894
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77989
This an incompatibility between lyx 1.1.6 and xforms = 0.89.5.
AFAIK, this is solved now.
Baruch LyX crashes randomly when pasting text from another window
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=103715
This is for lyx 1.1.4. I know that several clipboard problems have
been fixed since then, so I would think you can close it.
Baruch too large menu fonts cause segfault with german locale
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120450
I think this one is known. What has been done about it (tab too long
in german == crash).
Baruch Errors handling 'Paragraph' type paragraphs
Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120688
Could you send the example file?
Other ones:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69483
It is also quite old, and the strace just shows LyX writing its
emergency file. Not very useful. Some bugs like that have been fixed
since 1.1.4.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107117
This guy is using a file like
\documentstyle{article}
\input preamble
\begin{center}
...
\end{document}
So presumably the \begin{document} is hidden in the preamble. I do not
think reLyX ever intended to handle such bad structure. IMO this is
WONTFIX.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=115034
The use of geometry package is fixed in 1.2.0cvs and somehow fixed in
1.1.6fix4cvs.
JMarc
Re: Problem with lyx 1.1.6
Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel See lib/examples/mathed.lyx I think that the script there Dekel should be added to the lyx distribution, and it should be Dekel invoked by 'make install'. Thanks. JMarc
Re: new spam control?
On Thu, 13 Dec 2001, Juergen Vigna wrote: Well IMO that we could do something like that on lyx-devel as I've seen that lot's of devel list restrict the access much more. Are there really Those mailing lists are broken, IMO. Once upon a time, we needed a small feature in GTK to let it live peacefully with XForms. So, I wrote a nice long e-mail explaining what the feature was, and why we needed it, and sent it to the GTK mailing list. Then the mailing list replied that I was not subscribed, so my mail was blocked. I had to subscribe, or reply, or something to get my mail through, except that my mail was lost. That was such a disappointment that I just gave up. I hate such mailing lists. I don't think we should trade two spam mails a week for a white-list approach. Greets, Asger
It's a long way to 1.1.6fix4 (status update #4)
Hello,
Appended as usual is a list of what has been fixed since 1.1.6fix3. I
think that a 1.1.6fix4 is mostly feqture complete now, so I'd like a
bit of testing before release. Ben, could you try to play a bit with
undo under your memory checking tool to see whether everything is
alright?
Please tell me what are the open bugs you consider important for
1.1.6fix4. Also tell me if I forgot some of the changes. Changes since
last time include support for ae fonts and dvipdfm, and fixes to
insertion of error insets, bad display of symbol fonts with redhat and
mandrake and a potentially big memory leak in undo.
I'd be glad if some of you could take the time to check it out (or fix
a bug or two if you are feeling adventurous). Let me recall that all
these fixes have been checked in the branch BRANCH_1_1_6, which you
can get with the command
cvs checkout -d lyx-1_1_6 -r BRANCH_1_1_6 lyx-devel
JMarc
What's new
==
** Updates
- add support for latin3, latin4 and latin9 encodings
- change the encoding for estonian from latin4 to latin1, since it
appears to be more suitable.
- add support for ae fonts (emulation of T1 encoding with OT1 fonts).
This is useful for creating pdf files in T1 encoding
- add support for dvipdfm
- when passing a file name as argument from command line, the
extension `.lyx' is added if necessary
- insert error insets in the documents when there have been unknown
tokens in the file
- new class `kluwer'; update to hollywood class
- the class encts has been renamed to entcs (stupid typo!) and
slightly updated
- updates to the introduction manual and the italian user guide;
- updates to the russian localisation
** Bugfixes
- faster loading of large files (should now be proportional to file size)
- fix positionning of error insets when running LaTeX
- fix bug where latex would not be re-run if no depfiles were changed,
but the .dvi was removed
- fix bug where symbol fonts (greek letters...) would not show in
maths when using scalable fonts. This is really a bug in Mandrake
and Redhat fonts.
- fix possible crash when the cursor is between two spaces and a
selection is begun
- fix memory leak where undo memory was never released
- fix reading under unix of lyx files produced under windows (was
actually not fixed in 1.1.6fix3)
- fix problem where document is marked `changed' when going in/out an
empty tabular cell
- fix the logic of quote insertion after '-', '[' and '{'
- fix generation of an extra space after an inset in linuxdoc creation
- do not ignore newline/hfill chars when copying to the clipboard
- fix insertion of \Upsilon in the math editor
- fix crash if banner-file was not found
- the `SubSection' layout of the cv class has been renamed to
`Subsection'
- fix compilation with gcc 2.8.x
- improve the rpm spec file
Re: [PATCH] mmap CRC checking 1.2cvs
Ben == Ben Stanley [EMAIL PROTECTED] writes: Ben Thanks for the reference - I think it shows the _POSIX_C_SOURCE Ben macro is the right thing to do to get the correct prototype. Ben, it seems to me that you sent a patch, but I lost it. Could you re-send? JMarc
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Jean-Marc Lasgouttes wrote: Juergen Well maybe. In pre-InsetText times a resize was not so heavy Juergen as it only had to rebreak the actual LyXText! Now if you use Juergen a lot of insets it is MUCH heavier. We surely can do some Juergen profiling here and make a resize a bit faster, but we surely Juergen should maybe with the LyXText save also it's width and then Juergen on reputting it on screen check this with the actual width Juergen and do a resize only if really needed! Yes, but Buffer::resizeInsets should not be run if the window has not changed size, isn't it? Well but you don't know if it changed size while inside another buffer, do you? So when you're switching buffer you have to: 1. Resize the buffer in any case 2. Check the actual size with the saved size (which we actually don't have) and call resize only if really needed. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Staff meeting in the conference room in %d minutes.
Re: Herbert's problems with large documents loading time
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen Well but you don't know if it changed size while inside Juergen another buffer, do you? So when you're switching buffer you Juergen have to: AFAIK, if you find a textcache with the right buffer and the right width, you can use it right away. Or maybe I misunderstand something (I told you I don't know this stuff). Juergen 2. Check the actual size with the saved size (which we Juergen actually don't have) and call resize only if really needed. Isn't it what bv_-text = textcache.findFit(buffer_, workarea_.workWidth()); does? JMarc
Re: Undo leaking
On 13-Dec-2001 Jean-Marc Lasgouttes wrote: I applied you patch since it seems fine. However, this exposes a bug and crashes when one uses undo in the first paragraph of a document. For your viewing pleasure, here is what I wrote in undo_funcs.C: I don't think the patch was really thought to be commited, it was more a stuff to see if it solves leaking. After that we know that we would have to free the paragraphs. But the place is wrong! We have to release the paragraphs only at the end of the function! I think we could save the Paragraph * in a vector and then delete them at the end. That would be clean enough IMO. bv-text-ownerParagraph(tmppar3-id(),tmppar3) Head that now we don't have ONE ownerParagraph but EVERY InsetText has it's own FIRST (owner) paragraph. So if tmppar3 is INSIDE an inset it means that it is the ownerParagraph() of that inset! bv-text-ownerParagraph(tmppar3); Here you would only handle the case where tmppar3 == buffers-first-paragraph! Juergen, would you care to explain what happens or (better) to provide a fix? Sure we are still using the freed paragraphs UNTIL we have the new ones REALLY assigned. I explained it above! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I exist, therefore I am paid.
RE: It's a long way to 1.1.6fix4 (status update #4)
On 13-Dec-2001 Jean-Marc Lasgouttes wrote: mandrake and a potentially big memory leak in undo. I don't know how you fixed this, but I would say this is VERY dangerous for 1.1.6 series. I would leave the mem-leak asis (it was there since ever so why remove it in a stable series if you're not sure it's the right fix!) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ QOTD: I drive my car quietly, for it goes without saying.
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Jean-Marc Lasgouttes wrote: Isn't it what bv_-text = textcache.findFit(buffer_, workarea_.workWidth()); does? Well Lars wrote that particullary part of code so, Lars? But my answer would be no it is obviously not enough. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ TOO BAD YOU CAN'T BUY a voodoo globe so that you could make the earth spin real fast and freak everybody out. -- Jack Handley, The New Mexican, 1988.
Re: Herbert's problems with large documents loading time
On 13-Dec-2001 Lars Gullik Bjønnes wrote: bv_-text = textcache.findFit(buffer_, workarea_.workWidth()); | Well Lars wrote that particullary part of code so, Lars? | But my answer would be no it is obviously not enough. Why? Well I have to admit I didn't look at the code but do we save the old width? And for what is workarea_.workWidth() used there? Anyway it seems we call resize anyway so maybe we have all the data but don't use it. I'm really busy right now with undo/redo (+ real work) so I don't look at other files right now to not loose concentration it's not really trivial stuff! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ What fools these mortals be. -- Lucius Annaeus Seneca
Re: Undo leaking
On 13-Dec-2001 Lars Gullik Bjønnes wrote: Wouldn't that take care of deletion, and also keeping the paragraphs around until there are no one referencing this paragraph anymore? Aren't the refering one another (next() previous()!) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ aquadextrous, adj.: Possessing the ability to turn the bathtub faucet on and off with your toes. -- Rich Hall, Sniglets
Re: [martin.vermeer@hut.fi: Re: Patches waiting]
On Wed, Dec 12, 2001 at 10:35:10PM +0100, Lars Gullik Bjønnes wrote: ... Martin Vermeer [EMAIL PROTECTED] writes: | Ctrl-_ subscript Ctrl-_ is undo (in emacs.bind) -- Lgb 3) Index: lyx_main.C === RCS file: /cvs/lyx/lyx-devel/src/lyx_main.C,v retrieving revision 1.97 diff -u -p -r1.97 lyx_main.C --- lyx_main.C 2001/11/26 10:19:49 1.97 +++ lyx_main.C 2001/12/13 16:03:48 @@ -523,7 +523,12 @@ void LyX::defaultKeyBindings(kb_keymap kbmap-bind(Delete, LFUN_DELETE); kbmap-bind(BackSpace, LFUN_BACKSPACE); + // sub- and superscript -MV + kbmap-bind(M-m ~S-underscore, LFUN_SUBSCRIPT); + kbmap-bind(M-m ~S-dead_circumflex, LFUN_SUPERSCRIPT); + kbmap-bind(M-m ~S-asciicircum, LFUN_SUPERSCRIPT); + // kbmap-bindings to enable the use of the numeric keypad // e.g. Num Lock set //kbmap-bind(KP_0, LFUN_SELFINSERT); Ad 3: + close to existing TeX convention + within M-m convention for math - even longer to type than alternative 1: M-m S-_ and M-m S-^ (or M-m S-^ space) for sub- and superscript. This is my preference, a decent compromise I think. Cheers Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg30501/pgp0.pgp Description: PGP signature
Re: Undo leaking
Juergen == Juergen Vigna [EMAIL PROTECTED] writes:
Juergen I don't think the patch was really thought to be commited, it
Juergen was more a stuff to see if it solves leaking. After that we
Juergen know that we would have to free the paragraphs. But the place
Juergen is wrong!
OK, but it is right for 1.1.6, isn't it?
Juergen We have to release the paragraphs only at the end
Juergen of the function! I think we could save the Paragraph * in a
Juergen vector and then delete them at the end. That would be clean
Juergen enough IMO.
Why do we have to do that?
bv- text-ownerParagraph(tmppar3-id(),tmppar3)
Juergen Head that now we don't have ONE ownerParagraph but EVERY
Juergen InsetText has it's own FIRST (owner) paragraph. So if tmppar3
Juergen is INSIDE an inset it means that it is the ownerParagraph()
Juergen of that inset!
OK, this LyXText::ownerParagraph starts with
void LyXText::ownerParagraph(int id, Paragraph * p) const
{
Paragraph * op = bv_owner-buffer()-getParFromID(id);
if (op op-inInset()) {
static_castInsetText *(op-inInset())-paragraph(p);
So you are looking for tmppar3 inside the buffer, right? But how can
it be there already, since you have not linked it in at this point?
bv- text-ownerParagraph(tmppar3);
Juergen Here you would only handle the case where tmppar3 ==
Juergen buffers-first-paragraph!
I know that. Actually I figured this out after looking at the code
long enough.
Juergen, would you care to explain what happens or (better) to
provide a fix?
Juergen Sure we are still using the freed paragraphs UNTIL we have
Juergen the new ones REALLY assigned. I explained it above!
So we are looking for information in these freed paragraphs although
we know they are not quite right?
JMarc
Re: It's a long way to 1.1.6fix4 (status update #4)
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 13-Dec-2001 Jean-Marc Lasgouttes wrote: mandrake and a potentially big memory leak in undo. Juergen I don't know how you fixed this, but I would say this is VERY Juergen dangerous for 1.1.6 series. I would leave the mem-leak asis Juergen (it was there since ever so why remove it in a stable series Juergen if you're not sure it's the right fix!) You may be right. What I know is that it does solve the leak (as shown by LeakTracker) and that I do not see how it could fail in 1.1.6. But I am ready to remove it if you do not trust it. I thought that it may help a lot with largish tables, where undo is terrible in 1.1.6. JMarc
Re: Herbert's problems with large documents loading time
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Yes, since a inset only (currently) exits in one buffer at a Lars time, the lyxtext that it contains, will have the same Lars geometry as the enclosing lyxtext, and should be usable right Lars away. There should be no need to rebreak the textinset's Lars lyxtexts. I'll let you take a look at it :) JMarc
Re: Undo leaking
On Thu, Dec 13, 2001 at 04:47:33PM +0100, Lars Gullik Bjønnes wrote: | Sure we are still using the freed paragraphs UNTIL we have the new ones | REALLY assigned. I explained it above! What if we used a boost::shared_ptr for all Paragraph pointers _everywhere_? Everywhere is probably a bit strong... But I think everything with value semantics is better than the current mess aka Look, a Paragraph *! Now, is that the paragraph itself? Some iterator in some 'list'? Some container of paragraphs? But then, I don't know what I am talking about... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Herbert's problems with large documents loading time
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | I'll let you take a look at it :) Lars If I have to look outside resizeCurrentBuffer, I have no clue. So look there first. The resizeInsets thing is suspiciously outside of all if clauses. JMarc
Re: [martin.vermeer@hut.fi: Re: Patches waiting]
On Thu, Dec 13, 2001 at 06:20:26PM +0200, Martin Vermeer wrote: + kbmap-bind(M-m ~S-underscore, LFUN_SUBSCRIPT); + kbmap-bind(M-m ~S-dead_circumflex, LFUN_SUPERSCRIPT); + kbmap-bind(M-m ~S-asciicircum, LFUN_SUPERSCRIPT); This is my preference, a decent compromise I think. I always get a bit lost here. Could you please put that into some kind of list like Case 1 ( ^ is no deadkey neither in X nor LyX ) to get '^' in text mode press: ... 'ê' ... '_' ... to get '^' in math mode press: ... 'ê' ... '_' ... superscript ... subscript... Case 2 ( ^ is deadkey in X ) ... Case n ... Would be really nice. I would certainly prefer plain ^ and _ for the math *script stuff and do not care too much about the others as long as entering them is somehow possible (without using a text editor on the .lyx file...) Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Undo leaking
On Thu, Dec 13, 2001 at 05:34:27PM +0100, Lars Gullik Bjønnes wrote: One of my huge goals is to get rid of the paragraph linked list as we have it now, and have the paragraphs in an stl container of some sort. This also means moving a lot of algorithms out of LyXParagraph so it is a lot of work. So thinking about it should be postponed until 1.3? I am not exactly sure whether it is really as much work as we tend to think... But I have a very strong feeling that this would cleanup the code a _lot_. I have a faint feeling you might be right ;-) Andre' -- André Pönitz .. [EMAIL PROTECTED]
tiny undo patch
This is (more or less) part of the somewhat larger undo patch I send some
time ago.
It's not only whitespace stuff, making 'pop' more STL like, and removal of
some spurious 'using lyx::pos_type'
It serves only as a measure to remove distraction (Gosh... why two spaces
here) when reading undostack.C...
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Index: undo_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo_funcs.C,v
retrieving revision 1.9
diff -u -p -r1.9 undo_funcs.C
--- undo_funcs.C2001/12/13 11:35:25 1.9
+++ undo_funcs.C2001/12/13 17:02:26
@@ -26,10 +26,12 @@ bool undo_finished;
/// a flag
bool undo_frozen;
+
bool textUndo(BufferView * bv)
{
// returns false if no undo possible
- Undo * undo = bv-buffer()-undostack.pop();
+ Undo * undo = bv-buffer()-undostack.top();
+ bv-buffer()-undostack.pop();
if (undo) {
finishUndo();
if (!undo_frozen) {
@@ -50,7 +52,8 @@ bool textUndo(BufferView * bv)
bool textRedo(BufferView * bv)
{
// returns false if no redo possible
- Undo * undo = bv-buffer()-redostack.pop();
+ Undo * undo = bv-buffer()-redostack.top();
+ bv-buffer()-redostack.pop();
if (undo) {
finishUndo();
if (!undo_frozen) {
@@ -247,7 +250,6 @@ void setRedo(BufferView * bv, Undo::undo
bv-buffer()-redostack.push(createUndo(bv, kind, first, behind));
}
-using lyx::pos_type;
Undo * createUndo(BufferView * bv, Undo::undo_kind kind,
Paragraph const * first, Paragraph const * behind)
@@ -276,8 +278,8 @@ Undo * createUndo(BufferView * bv, Undo:
// check wether storing is needed
if (!bv-buffer()-undostack.empty()
bv-buffer()-undostack.top()-kind == kind
- bv-buffer()-undostack.top()-number_of_before_par ==
before_number
- bv-buffer()-undostack.top()-number_of_behind_par ==
behind_number ){
+ bv-buffer()-undostack.top()-number_of_before_par ==
+before_number
+ bv-buffer()-undostack.top()-number_of_behind_par ==
+behind_number) {
// no undo needed
return 0;
}
@@ -345,6 +347,7 @@ void setCursorParUndo(BufferView * bv)
bv-text-cursor.par()-next());
}
+
Paragraph * firstUndoParagraph(BufferView * bv, int inset_id)
{
Inset * inset = bv-buffer()-getInsetFromID(inset_id);
@@ -355,6 +358,7 @@ Paragraph * firstUndoParagraph(BufferVie
}
return bv-text-ownerParagraph();
}
+
LyXCursor const undoCursor(BufferView * bv)
{
Index: undostack.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undostack.C,v
retrieving revision 1.1
diff -u -p -r1.1 undostack.C
--- undostack.C 2001/06/25 00:06:21 1.1
+++ undostack.C 2001/12/13 17:02:26
@@ -23,18 +23,18 @@ UndoStack::UndoStack()
: limit(100) {}
-Undo * UndoStack::pop()
+void UndoStack::pop()
{
- if (stakk.empty()) return 0;
- Undo * result = stakk.front();
+ if (stakk.empty())
+ return;
stakk.pop_front();
- return result;
}
-Undo * UndoStack::top()
+Undo * UndoStack::top() const
{
- if (stakk.empty()) return 0;
+ if (stakk.empty())
+ return 0;
return stakk.front();
}
@@ -63,7 +63,8 @@ void UndoStack::SetStackLimit(Stakk::siz
void UndoStack::push(Undo * undo_arg)
{
- if (!undo_arg) return;
+ if (!undo_arg)
+ return;
stakk.push_front(undo_arg);
if (stakk.size() limit) {
@@ -74,6 +75,7 @@ void UndoStack::push(Undo * undo_arg)
}
-bool UndoStack::empty() const {
+bool UndoStack::empty() const
+{
return stakk.empty();
}
Index: undostack.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undostack.h,v
retrieving revision 1.1
diff -u -p -r1.1 undostack.h
--- undostack.h 2001/06/25 00:06:21 1.1
+++ undostack.h 2001/12/13 17:02:26
@@ -33,13 +33,13 @@ public:
///
UndoStack();
///
- Undo * pop();
+ ~UndoStack();
///
- Undo * top();
+ void pop();
///
- bool empty() const;
+ Undo * top() const;
///
- ~UndoStack();
+ bool empty() const;
///
void clear();
///
Re: tiny undo patch
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre This is (more or less) part of the somewhat larger undo patch I Andre send some time ago. Andre It's not only whitespace stuff, making 'pop' more STL like, and Andre removal of some spurious 'using lyx::pos_type' Andre It serves only as a measure to remove distraction (Gosh... why Andre two spaces here) when reading undostack.C... Juergen, can I apply this? You say your are looking at undo. JMarc
Re: tiny undo patch
On Thu, Dec 13, 2001 at 06:20:02PM +0100, Jean-Marc Lasgouttes wrote: Juergen, can I apply this? You say your are looking at undo. Too late ;-) Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: tiny undo patch
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Thu, Dec 13, 2001 at 06:20:02PM +0100, Jean-Marc Lasgouttes Andre wrote: Juergen, can I apply this? You say your are looking at undo. Andre Too late ;-) I saw that :) JMarc
Re: new spam control?
On Thu, Dec 13, 2001 at 04:17:37PM +0100, Asger K. Alstrup Nielsen wrote: Then the mailing list replied that I was not subscribed, so my mail was blocked. I had to subscribe, or reply, or something to get my mail through, except that my mail was lost. That was such a disappointment that I just gave up. I hate such mailing lists. Hence the reason we do not use the subscribers only feature. With the software I am proposing, your mail gets retained, and you just have to confirm your post, and then it gets delivered to the list. Mail does not get lost. I don't think we should trade two spam mails a week for a white-list approach. That is fine with me. Just let me know when you think either of the lists receives too much spam, and then we bring up the question again. Happy lyxing, Mate
Re: new spam control?
On Thu, Dec 13, 2001 at 06:43:19PM +0100, Lars Gullik Bjønnes wrote: | Hence the reason we do not use the subscribers only feature. | With the software I am proposing, your mail gets retained, and you | just have to confirm your post, and then it gets delivered to the list. | Mail does not get lost. I see that some mailinglists (YahooGroups f.ex.) have a feature where new posters to a mailinglist is moderated. The moderator can then later turn off moderation for individual users. Would that be something we could use? This would lead to a lag of a couple of hours or even days, and then if you ask for more details, you'll probably will ask for private mail just to speed it up, then you start forwarding the relevant parts to the list etc... In the end it's probably much more hassle than pressing 'd' twice a week to delete spam in my mailbox Andre' -- André Pönitz .. [EMAIL PROTECTED]
Row * - Row , part I
It is possible to change a few 'Row *' to 'Row ' without sematical
changes. One could even add some 'const' in some places.
Patch attached.
Andre'
PS: Note that most of the '*cursor.row()' thingies could be changed back
to 'cursor.row()' if we had MathCursor::row() return a Row . But I did not
want do change too much in one chunk...
--
André Pönitz .. [EMAIL PROTECTED]
Index: bufferview_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.C,v
retrieving revision 1.43
diff -u -p -r1.43 bufferview_funcs.C
--- bufferview_funcs.C 2001/11/26 10:19:47 1.43
+++ bufferview_funcs.C 2001/12/13 18:28:18
@@ -228,7 +228,7 @@ void toggleAndShow(BufferView * bv, LyXF
if (font.language() != ignore_language ||
font.number() != LyXFont::IGNORE) {
LyXCursor cursor = text-cursor;
- text-computeBidiTables(bv-buffer(), cursor.row());
+ text-computeBidiTables(bv-buffer(), *cursor.row());
if (cursor.boundary() !=
text-isBoundary(bv-buffer(), cursor.par(), cursor.pos(),
text-real_current_font) )
Index: lyxscreen.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxscreen.h,v
retrieving revision 1.30
diff -u -p -r1.30 lyxscreen.h
--- lyxscreen.h 2001/11/26 11:08:42 1.30
+++ lyxscreen.h 2001/12/13 18:28:18
@@ -101,7 +101,7 @@ private:
int y_offset = 0, int x_offset = 0, bool internal=false);
/// y is a coordinate of the text
- void drawOneRow(LyXText *, BufferView *, Row * row,
+ void drawOneRow(LyXText *, BufferView *, Row const row,
int y_text, int y_offset = 0, int x_offset = 0);
///
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.102
diff -u -p -r1.102 lyxtext.h
--- lyxtext.h 2001/12/12 09:56:00 1.102
+++ lyxtext.h 2001/12/13 18:28:18
@@ -219,14 +219,13 @@ public:
/** returns the column near the specified x-coordinate of the row
x is set to the real beginning of this column
*/
- lyx::pos_type getColumnNearX(BufferView *, Row * row,
+ lyx::pos_type getColumnNearX(BufferView *, Row row,
int x, bool boundary) const;
/** returns a pointer to a specified row. y is set to the beginning
of the row
*/
- Row * getRow(Paragraph * par,
-lyx::pos_type pos, int y) const;
+ Row * getRow(Paragraph * par, lyx::pos_type pos, int y) const;
/** returns the firstrow, this could be done with the above too but
IMO it's stupid to have to allocate a dummy y all the time I need
the first row
@@ -401,7 +400,7 @@ public:
solution but faster.
*/
void getVisibleRow(BufferView *, int y_offset, int x_offset,
- Row * row_ptr, int y, bool cleared=false);
+ Row const row, int y, bool cleared = false);
///
void toggleInset(BufferView *);
@@ -473,7 +472,7 @@ public:
///
int workWidth(BufferView *, Inset * inset) const;
///
- void computeBidiTables(Buffer const *, Row * row) const;
+ void computeBidiTables(Buffer const *, Row const row) const;
/// Maps positions in the visual string to positions in logical string.
inline
@@ -540,11 +539,11 @@ private:
///
void breakAgainOneRow(BufferView *, Row * row);
/// Calculate and set the height of the row
- void setHeightOfRow(BufferView *, Row * row_ptr) const;
+ void setHeightOfRow(BufferView *, Row row_ptr) const;
/** this calculates the specified parameters. needed when setting
* the cursor and when creating a visible row */
- void prepareToPrint(BufferView *, Row * row, float x,
+ void prepareToPrint(BufferView *, Row const * row, float x,
float fill_separator,
float fill_hfill,
float fill_label_hfill,
@@ -555,7 +554,7 @@ private:
// the bufferview
BufferView * bv;
// the row
- Row * row;
+ Row const * row;
// the painter to use
Painter * pain;
// has the background been cleared
@@ -678,21 +677,21 @@ private:
/** returns the number of separators in the specified row.
The separator on the very last column doesnt count
*/
- int numberOfSeparators(Buffer const
Re: new spam control?
On Thu, Dec 13, 2001 at 09:28:05AM +0100, Juergen Vigna wrote: Well IMO that we could do something like that on lyx-devel as I've seen that lot's of devel list restrict the access much more. Are there really lot's of people on this list who post from different addresses? Anyway every additional hurdle means another chance a bug won't get reported. For example, I certainly couldn't be bothered to report a bug on libmad, as their list is sub-only, and they even REJECT valid posts that have been put to the admin queue !!! regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: Bug #57
On Thu, Dec 13, 2001 at 11:48:28PM +1300, Michael Koziarski wrote: P.S.: Could we registrate a [EMAIL PROTECTED] user on the buglist? It would be nice if we could add it as Cc: to some replies we make so that they go to the lyx-devel list to (I'm thinking of faster response times and people like Andre, but also myself), otherwise one has to post the question to lyx-devel separately as I did here! Done what email options did you give it ? It should only send email on added comments IMHO regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: [noreply@sourceforge.net: [ lyxbugs-Feature Requests-439373 ] Support \intertext in mathed]
On Thu, Dec 13, 2001 at 01:46:44PM +0100, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Wed, Dec 12, 2001 at 04:35:43PM +0100, Jean-Marc Lasgouttes Andre wrote: How am I supposed to react to mails like this: You are not supposed to, since these are from the old bugtracker. Andre Whom should I tell that such a bug is fixed? The original Andre poster? You could go here http://cvs.koziarski.com/show_bug.cgi?id=90 and close it, but maybe Michael or John can propose a mail only solution to do that. 1) if someone else closes a bug, you will get an email from bugzilla 2) if you fix a bug and want it closed, mention on the list and someone (me, michael k., someone else) will pick it up and close the bug for you The last thing we want is the tracker getting in the way of you fixing mathed bugs regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
XListFonts question
When I call to XListFonts with the pattern -*-cmsy-* (or equivalently, when typing xlsfonts -fn -*-cmsy-* in the shell), I get only one result as expected: -bluesky-cmsy-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific However, when I use the pattern -*-cmsy-*-*-*-*-*-*-*-*-*-*-*-*, I get two results: -bluesky-cmsy-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific -bluesky-cmsy-medium-r-normal--12-120-75-75-m-0-adobe-fontspecific Why is that ? Also, will the pattern -*-cmsy-* work on every system ?
added_space_top/bottom patch
as I wrote in another mail I got very often a string like
\added_space_top 0cm \added_space_bottom 0cm \align center
while converting from 1.1.6 to 1.2. For this nonlength
in 1.2 there is always a lengthmarker drawn which is senseless.
the following patch prevents lyx from saving such values.
HErbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.460
diff -u -r1.460 ChangeLog
--- src/ChangeLog 2001/12/13 17:19:53 1.460
+++ src/ChangeLog 2001/12/13 20:38:35
@@ -1,3 +1,6 @@
+2001-12-13 Herbert Voss [EMAIL PROTECTED]
+
+ * buffer.C: no added_space 0cm
2001-12-13 André Pönitz [EMAIL PROTECTED]
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.279
diff -u -r1.279 buffer.C
--- src/buffer.C2001/12/11 14:33:50 1.279
+++ src/buffer.C2001/12/13 20:38:43
@@ -1019,10 +1024,14 @@
}
} else if (token == \\added_space_top) {
lex.nextToken();
- par-params().spaceTop(VSpace(lex.getString()));
+ VSpace value = VSpace(lex.getString());
+ if (value.length().len().value() != 0)
+ par-params().spaceTop(value);
} else if (token == \\added_space_bottom) {
lex.nextToken();
- par-params().spaceBottom(VSpace(lex.getString()));
+ VSpace value = VSpace(lex.getString());
+ if (value.length().len().value() != 0)
+ par-params().spaceBottom(value);
#ifndef NO_COMPABILITY
#ifndef NO_PEXTRA_REALLY
} else if (token == \\pextra_type) {
Re: Bug #57
John Levon wrote: On Thu, Dec 13, 2001 at 11:48:28PM +1300, Michael Koziarski wrote: P.S.: Could we registrate a [EMAIL PROTECTED] user on the buglist? It would be nice if we could add it as Cc: to some replies we make so that they go to the lyx-devel list to (I'm thinking of faster response times and people like Andre, but also myself), otherwise one has to post the question to lyx-devel separately as I did here! Done what email options did you give it ? It should only send email on added comments IMHO regards john It will send mail on added comments, and when the bug is verified or closed. -- Cheers Koz
Re: page-down binding doesn't work within margin note
On Thu, Dec 13, 2001 at 03:23:34PM -0500, Richard E. Hawkins wrote: like it says :) use an arrow key to get out, and the page keys work again. Complain to Juergen - he reckons this is a feature request. I totally disagree ... regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: page-down binding doesn't work within margin note
On Thu, Dec 13, 2001 at 08:56:20PM +, John Levon wrote: On Thu, Dec 13, 2001 at 03:23:34PM -0500, Richard E. Hawkins wrote: like it says :) use an arrow key to get out, and the page keys work again. Complain to Juergen - he reckons this is a feature request. I totally disagree ... A similar problem is that if you have an inset that its height is more than the height of the display, then when you try to scroll up/down with pageup/down you get a weird result. Why can't the pageup/down be implemented by shifting the display window by the height of the display and then fake a mouse button press near the top/bottom of the display ?
Re: [martin.vermeer@hut.fi: Re: Patches waiting]
On Thu, Dec 13, 2001 at 05:32:01PM +0100, Andre Poenitz wrote: ... On Thu, Dec 13, 2001 at 06:20:26PM +0200, Martin Vermeer wrote: + kbmap-bind(M-m ~S-underscore, LFUN_SUBSCRIPT); + kbmap-bind(M-m ~S-dead_circumflex, LFUN_SUPERSCRIPT); + kbmap-bind(M-m ~S-asciicircum, LFUN_SUPERSCRIPT); This is my preference, a decent compromise I think. I always get a bit lost here. Could you please put that into some kind of list like Case 1 ( X handles deadkeys; ^ is no deadkey (asciicircum)) to get '^' in text mode press: ^ 'ê' doesn't work '_' _ to get '^' in math mode press: ^ 'ê' doesn't work '_' _ superscript M-m ^ subscriptM-m _ Case 2 (X handles deadkeys; ^ is a deadkey (dead_circumflex)) ... to get '^' in text mode press: ^ space 'ê' ^ e '_' _ to get '^' in math mode press: ^ space 'ê' ^ e [doesn't seem to work though; a cursor left is needed inbetween] '_' _ superscript M-m ^ space (or M-m ^ ^) subscriptM-m _ Case 3 (Lyx handles deadkeys; ^ is no deadkey) to get '^' in text mode press: ^ 'ê' doesn't work (I think?) '_' _ to get '^' in math mode press: ^ 'ê' doesn't work (I think?) '_' _ superscript M-m ^ subscriptM-m _ Case 4 (Lyx handles deadkeys; ^ is deadkey) to get '^' in text mode press: ^ space 'ê' ^ e '_' _ to get '^' in math mode press: ^ space 'ê' ^ e [doesn't seem to work] '_' _ superscript M-m ^ space subscriptM-m _ Would be really nice. Actually with the three patches above you can try it in your local tree. Especially no. 3. I suspect that even with compile times, that's quicker than trying to explain it ;-) I would certainly prefer plain ^ and _ for the math *script stuff and do not care too much about the others as long as entering them is somehow possible (without using a text editor on the .lyx file...) So would I. But we are professionally deformed scientists, all the time entering formulas with super- and subscripts ;-) For a more general audience, esp. an international one, things like ê and á etc. should really just work. Yes I know the French keyboard has accented characters ready, but that doesn't apply for all locales. If a keyboard provides deadkeys, they are meant to be used. Naturally. Same with ^ and _ characters; especially _ is needed in programme listings. One can of course argue whether for the typical user sub- and superscripts are more common than the raw ^ and _ characters. If this is the case, then sub/superscript should perhaps be bound to plain ^ and _ and the symbols to longer escaped sequences; then also the hat accent should be bound to such a longer sequence. (That was my original proposal, binding hat to M-m h and thus the ^ symbol to M-m h blank. But I gradually changed my mind when LGB and JMarc pointed out the problems with that.) [And note, perhaps redundantly, that as I understand it it is *not easily possible* to have plain ^ and _ for *both* super/subscript *and* insert symbol/hat accent; before the introduction of LFUN_*SCRIPT it worked, but that was really a kludge as far as I can see.] However, my proposed solution (3) is IMHO more consistent/natural. 1. The sub- and superscript bindings start with M-m like all the others in math 2. The hat accent works the same way as the other accents ' ` ~ both in and out of math 3. No need to escape any characters to be inserted. Item 1. does make the key sequences a little longer, but so what? There are many others already of the same length, and we all type happily M-m g D to get a \Delta etc. etc. I don't think it will make a typical formula much longer/harder to type as this is offset by the greater consistency. I suspect it may be possible (but you should know best :-) to change LyX thus that being in mathed always implicitly prepends M-m to keysequences typed. This should make that easier. Andre' -- André Pönitz .. [EMAIL PROTECTED] Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg30525/pgp0.pgp Description: PGP signature
Re: added_space_top/bottom patch
Herbert Voss wrote:
the following patch prevents lyx from saving such values.
sorry, it was the wrong one. here it comes again.
Herbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.460
diff -u -r1.460 ChangeLog
--- src/ChangeLog 2001/12/13 17:19:53 1.460
+++ src/ChangeLog 2001/12/13 22:04:49
@@ -1,3 +1,6 @@
+2001-12-13 Herbert Voss [EMAIL PROTECTED]
+
+ * buffer.C: no added_space 0cm
2001-12-13 André Pönitz [EMAIL PROTECTED]
Index: src/buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.279
diff -u -r1.279 buffer.C
--- src/buffer.C2001/12/11 14:33:50 1.279
+++ src/buffer.C2001/12/13 22:04:59
@@ -1019,10 +1024,16 @@
}
} else if (token == \\added_space_top) {
lex.nextToken();
- par-params().spaceTop(VSpace(lex.getString()));
+ VSpace value = VSpace(lex.getString());
+ if ((value.length().len().value() != 0) ||
+ (value.kind() != VSpace::LENGTH))
+ par-params().spaceTop(value);
} else if (token == \\added_space_bottom) {
lex.nextToken();
- par-params().spaceBottom(VSpace(lex.getString()));
+ VSpace value = VSpace(lex.getString());
+ if ((value.length().len().value() != 0) ||
+ (value.kind() != VSpace::LENGTH))
+ par-params().spaceBottom(value);
#ifndef NO_COMPABILITY
#ifndef NO_PEXTRA_REALLY
} else if (token == \\pextra_type) {
Re: [PATCH] mmap CRC checking 1.2cvs
Jean-Marc Lasgouttes wrote:
Ben, it seems to me that you sent a patch, but I lost it. Could you
re-send?
Here it is.
I'd appreciate it if people on strange platforms could test it out and
report any problems to me, thanks. I think this one should resolve the
compile problems we had on Solaris and compaq cxx, and satisfy the
regulations of the style police...
Ben.
--- lyx-devel-orig/src/support/ChangeLogThu Dec 6 12:28:42 2001
+++ lyx-devel/src/support/ChangeLog Wed Dec 12 09:53:19 2001
@@ -1,3 +1,7 @@
+2001-12-12 Ben Stanley [EMAIL PROTECTED]
+
+ * lyxsum.C: portability fix for mmap patch
+
2001-12-05 Lars Gullik Bjønnes [EMAIL PROTECTED]
* filetools.C:
--- lyx-devel-orig/src/support/lyxsum.C Thu Dec 6 12:28:42 2001
+++ lyx-devel/src/support/lyxsum.C Wed Dec 12 09:52:15 2001
@@ -23,6 +23,10 @@
#warning lyx::sum() using mmap (lightning fast)
#endif
+// Make sure we get modern version of mmap and friends with void*,
+// not `compatibility' version with caddr_t.
+#define _POSIX_C_SOURCE 199506L
+
#include sys/types.h
#include sys/stat.h
#include fcntl.h
@@ -40,7 +44,8 @@
void * mm = mmap(0, info.st_size, PROT_READ,
MAP_PRIVATE, fd, 0);
- if (mm == MAP_FAILED) {
+ // Some platforms have the wrong type for MAP_FAILED (compaq cxx).
+ if (mm == reinterpret_castvoid*(MAP_FAILED)) {
close(fd);
return 0;
}
Re: Undo leaking
Lars Gullik Bjønnes wrote: One of my huge goals is to get rid of the paragraph linked list as we have it now, and have the paragraphs in an stl container of some sort. This also means moving a lot of algorithms out of LyXParagraph so it is a lot of work. But I have a very strong feeling that this would cleanup the code a _lot_. I like this idea. (Just not the work involved...) Anything that cleans up the code can help squash strange bugs... (and introduce new ones, I know, but if the architecture is superior then the bugs should be fewer and easier to squash.) But, als while we are at it, can someone explain to me why a Paragraph is not some kind of Inset? I suppose it's historical... Ben
Inset Visitors...
When I did my extended error reporting modification to LyX, I added
Inset Visitors. I found them to be very useful...
For those unfamiliar with the Visitor pattern, I strongly suggest you
grab a copy of Design Patterns, by Gamma et al. See page 331. Well
worth the read... but, I'll attempt to summarise the properties of the
pattern here.
The Visitor pattern is useful for processing different elements in a
polymorphic structure (eg the document tree). It allows you to define
operations upon different classes (eg Inset types) differently depending
upon the class type, without modifying the original class. Consider the
following infrastructure:
class InsetVisitor;
class Inset {
// blah blah
virtual void Accept(InsetVisitor) = 0;
};
class InsetA : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetA(*this); }
};
class InsetB : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetB(*this); }
};
class InsetVisitor {
// blah blah
virtual void VisitInsetA( InsetA ) = 0;
virtual void VisitInsetB( InsetB ) = 0;
};
I may now extract the, for example, spell-checking methods from
LyXParagraph, and define a single visitor which knows what to do to any
particular kind of inset to perform spell-checking on it (that was a bad
example to pick, maybe someone else can come up with a better one...):
class SpellCheckInsetVisitor : public InsetVisitor {
// blah blah
virtual void VisitInsetA( InsetA i ) {
// Carry out spellcheck on contents of InsetA
}
virtual void VisitInsetB( InsetB i ) {
// InsetB doesn't have any text that you can spellcheck, so do
nothing.
}
};
This means that all the 'spellchecking' (or whatever) code related to a
single kind of operation is contained within a single visitor class
instead of being strewn all over the code in methods of individual insets.
To use it, the spell checker driver does this:
SpellCheckerVisitor spell;
for( InsetIterator i = insets.begin(); i != insets.end(); ++i ) {
i-Accept(spell);
}
(I usually define some fancier ways of doing this so that information
can be passed to the spell checker object, but this is simplest for
illustration.)
The call to Inset::Accept bounces to the visitor's VisitInsetA or
VisitInsetB method depending on what type of inset it is, according to
the vtable ie it's efficient.
I actually used these for traversing the document and collecting labels,
citations, bibliography boxes, and ERTs for use in error reporting, but
they have so many other uses as well. The wonderful thing about it is
that you only need to add one method to every inset - the Accept method.
From then on, you are free to define new operations upon insets without
touching the insets themselves...
Note that the operations contained within the visitor classes can only
utilise public interfaces on the insets they manipulate. This means that
the Inset interface must be complete. - no fiddling with private innards
may be done this way.
This pattern does have a disadvantage: If you keep adding new insets
types, you have to go and add methods for them all to all the different
kinds of inset visitors. This may be overcome by creating an inset
visitor class which does nothing - ie all abstract methods from the base
class are implemented as no-ops. Actual operation visitors would then
inherit from this and only override the methods that they need. However,
this leads to 'forgetting' to add the required methods to the visitors
in the few cases where they are really necessary, as the compiler will
no longer complain... you will just get a silent nop where perhaps you
expected to spellcheck the contents of a caption. These kinds of
problems are easy to fix, just not so easy to detect.
Anyway, I found that using this pattern gave me incredible flexibility
in implementing my extended error handling code, and I wondered if
anyone else thought there might be applications for it in the current
LyX code base.
Ben.
Re: Undo leaking
Lars Gullik Bjønnes wrote: ref_ptr-obj-ref_ptr-obj-ref_ptr-obj and run reset(0) on the first, the refcount is decremented on all the rest as well and if the refcount reach zero the paragraph is deleted, just like we would expect. I think it would work. In the case you have above, it would work. But that is not the case in the LyX code. From paragraph.h: private: /// if anything uses this we don't want it to. Paragraph(Paragraph const ); /// Paragraph * next_; /// Paragraph * previous_; So Paragraphs form a doubly linked list... this is a self-referencing structure, and reference counted pointers don't work there. (The offending data will never be deleted.) In general, reference counted pointers do not work in cyclical structures. They work fine in acyclic structures (ones that don't reference themselves). However, if you were to remove the doubly linked list structure from Paragraph and insted place reference counted paragraph pointers into a vector (as previously pointed out), then this would work fine. (I do this sort of thing all the time in my own code.) this would also allow you to keep a (reference counted) paragraph pointer in the undo code until such time as it was no longer required, and it would all `magically' figure itself out correctly. The original post referred to manually unlinking from the list before expecting the reference counted stuff to do it's magic - that may also work, but is not as clean... Ben.
Re: Inset Visitors...
On Fri, Dec 14, 2001 at 11:02:51AM +1100, Ben Stanley wrote:
class InsetA : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetA(*this); }
};
class InsetVisitor {
// blah blah
virtual void VisitInsetA( InsetA ) = 0;
};
what's the point in calling back like this ? This looks like it requires
an VisitInsetX for every class X ? And furthermore, one that must be
public.
What is wrong with :
for (InsetIterator i = insets.begin(); i != insets.end(); ++i) {
if (i-allowSpellcheck()) {
spellcheckInset(*i); // private method of Spell class
} else if (i-somethingSpecial()) {
spellcheckSpecialInset(*i);
}
}
exactly ?
this centralises the spellchecking code, and reduces public code.
Note: everyone agrees the current method of not using an iterator isn't good ...
(I usually define some fancier ways of doing this so that information
can be passed to the spell checker object, but this is simplest for
illustration.)
which is another disadvantage of your scheme ...
that you only need to add one method to every inset - the Accept method.
From then on, you are free to define new operations upon insets without
touching the insets themselves...
I think this is a dubious advantage. Explain to me again why it is better
that the information an inset should not be spellchecked is part of the
Spell class rather than part of the MyInset class ?
regards
john
--
Of all manifestations of power, restraint impresses the most.
- Thucydides
Re: Undo leaking
On Fri, Dec 14, 2001 at 12:20:57PM +1100, Ben Stanley wrote: So Paragraphs form a doubly linked list... this is a self-referencing structure, and reference counted pointers don't work there. (The offending data will never be deleted.) this is true in general, but we explicitly break a chain when we don't want the paragraph any more. So the actually unused data no longer forms a cycle, and ref counting is OK. Think about removing a paragraph from a chain : it starts with a count of 2, then 1 as prev's pointer is reset, then 0 as next's pointer is reset. At least I assume that's how we manage the list right now ... regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: Inset Visitors...
John Levon wrote:
On Fri, Dec 14, 2001 at 11:02:51AM +1100, Ben Stanley wrote:
class InsetA : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetA(*this); }
};
class InsetVisitor {
// blah blah
virtual void VisitInsetA( InsetA ) = 0;
};
what's the point in calling back like this ? This looks like it requires
an VisitInsetX for every class X ? And furthermore, one that must be
public.
The point of calling back is that it gives you the virtual dispatch.
It's the whole point of the scheme. Yes, it does require a VisitInsetX
for every class X, but if you inherit from an InsetVisitorNOP class
which provides default implementations for VisitInsetX for every class X
which are empty, then this point is moot.
What is wrong with :
for (InsetIterator i = insets.begin(); i != insets.end(); ++i) {
if (i-allowSpellcheck()) {
spellcheckInset(*i); // private method of Spell class
} else if (i-somethingSpecial()) {
spellcheckSpecialInset(*i);
}
}
exactly ?
Well, firstly you have to typecast the inset in
spellcheckInset(typecast-here(*i))...
It also means that every time you want to add a new fandangled operation
on an inset, you have to
a) modify Inset to have an allowX() method
b) modify the class(es) of interest to support the new fandangled operation.
This way, all the mods are done in one place, without ever touching the
Inset classes (apart from adding the visitor support infrastructure in
the first place).
this centralises the spellchecking code, and reduces public code.
Note: everyone agrees the current method of not using an iterator isn't good ...
The iterator isn't the point, but this scheme can be used to support a
global recursive inset iterator as well, without hacking the insets
themselves.
(I usually define some fancier ways of doing this so that information
can be passed to the spell checker object, but this is simplest for
illustration.)
which is another disadvantage of your scheme ...
Not really...
Here it is:
class InsetVisitorNOP : public InsetVisitor {
virtual void VisitInsetA( InsetA ) {}
virtual void VisitInsetB( InsetB ) {}
};
class SpellCheckInsetVisitor : public InsetVisitorNOP {
result_type operator()( Inset i, FancyType _someSpellCheckInfo ) {
someSpellCheckInfo = _someSpellCheckInfo;
i.Accept(*this);
return result;
}
virtual void VisitInsetA( InsetA i ) {
// use someSpellCheckInfo with InsetA
// set result
}
private:
FancyType someSpellCheckInfo;
result_type result;
};
that you only need to add one method to every inset - the Accept method.
From then on, you are free to define new operations upon insets without
touching the insets themselves...
I think this is a dubious advantage. Explain to me again why it is better
that the information an inset should not be spellchecked is part of the
Spell class rather than part of the MyInset class ?
Well, I thought that one was rather obvious actually...
It means that you can tell at a glance (ie in one place) what classes
are affected by the operation, without having to chase all over the
header files etc.
It also makes it very quick to define a new kind of operation, and to
add it (even just locally for testing) without having to make changes
everywhere else. The new operation is only kept locally.
This scheme can also be used for constructing an Inset iterator which
iterates over all of the insets held by an Inset class (one level). You
define an InsetVisitor which has the capacity to visit an Inset and
return the correct kind of iterator to traverse it's contained Insets.
If the inset contains no other insets, it just returns an empty
iterator. Of course this could also be implemented the other way, ie by
modifiying the individual insets, but this way keeps all of the iterator
creation code in one place.
I find it much easier to work with the Visitor pattern than modifying
every class in a hierarchy because I don't have to jump around every
file to add a new operation - I onlyl have to define one new class,
usually above the bit that needs to use it. Much easier - also helps to
reduce the need for re-compilation.
Ben.
Re: Inset Visitors...
On Fri, Dec 14, 2001 at 12:48:23PM +1100, Ben Stanley wrote:
what's the point in calling back like this ? This looks like it requires
an VisitInsetX for every class X ? And furthermore, one that must be
public.
The point of calling back is that it gives you the virtual dispatch.
It's the whole point of the scheme. Yes, it does require a VisitInsetX
for every class X, but if you inherit from an InsetVisitorNOP class
which provides default implementations for VisitInsetX for every class X
which are empty, then this point is moot.
this also applies to an iterator scheme with allowSpellCheck().
for (InsetIterator i = insets.begin(); i != insets.end(); ++i) {
if (i-allowSpellcheck()) {
spellcheckInset(*i); // private method of Spell class
} else if (i-somethingSpecial()) {
spellcheckSpecialInset(*i);
}
}
exactly ?
Well, firstly you have to typecast the inset in
spellcheckInset(typecast-here(*i))...
OK, ugly, but we are doing RTTI here. Having inner spell code public (or friended,
which is not much nicer) is also ugly ...
It also means that every time you want to add a new fandangled operation
on an inset, you have to
a) modify Inset to have an allowX() method
b) modify the class(es) of interest to support the new fandangled operation.
This way, all the mods are done in one place, without ever touching the
Inset classes (apart from adding the visitor support infrastructure in
the first place).
iterator way: for new operations, add a new Accept() (or similar) for each inset
that wants it (also use virtual where possible to avoid this)
your way: for new operations, add a new Accept() for inset that needs it (also use
virtual where possible to avoid this) PLUS a new thing in the calling class for
every type
It just looks like more typing to me.
The iterator isn't the point, but this scheme can be used to support a
global recursive inset iterator as well, without hacking the insets
themselves.
and this is easy to hack on top of ParIterator and Paragraph::InsetIterator
anyway.
Well, I thought that one was rather obvious actually...
It means that you can tell at a glance (ie in one place) what classes
are affected by the operation, without having to chase all over the
header files etc.
you would have to come up with some actual example where this really
makes a difference. Besides, this can be done the normal-style iterator
way EXACTLY the same (plus the ugly casts, but as both you and I have
mentioned, neither scheme is un-ugly).
It also makes it very quick to define a new kind of operation, and to
add it (even just locally for testing) without having to make changes
everywhere else. The new operation is only kept locally.
um, for each new operation, I need to specify the special cases for each
inset. So you have to change code somewhere, and I still don't see the
advantage over the visitor instead of iterator + RTTI, but I do see
the disadvantages.
This scheme can also be used for constructing an Inset iterator which
iterates over all of the insets held by an Inset class (one level). You
define an InsetVisitor which has the capacity to visit an Inset and
return the correct kind of iterator to traverse it's contained Insets.
If the inset contains no other insets, it just returns an empty
iterator. Of course this could also be implemented the other way, ie by
modifiying the individual insets, but this way keeps all of the iterator
creation code in one place.
and WHY is this complex Visitor thing needed for that ? You can make an iterator
that does this easily, without need for visitor code - just iterate along
the contained paragraphs and ue inset_iterator_begin/end() on each one.
I find it much easier to work with the Visitor pattern than modifying
every class in a hierarchy because I don't have to jump around every
file to add a new operation - I onlyl have to define one new class,
usually above the bit that needs to use it. Much easier - also helps to
reduce the need for re-compilation.
Again, irrelevant to using Visitor ...
regards
john
--
Of all manifestations of power, restraint impresses the most.
- Thucydides
Re: Inset Visitors...
John Levon wrote: On Fri, Dec 14, 2001 at 12:48:23PM +1100, Ben Stanley wrote: what's the point in calling back like this ? This looks like it requires an VisitInsetX for every class X ? And furthermore, one that must be public. The point of calling back is that it gives you the virtual dispatch. It's the whole point of the scheme. Yes, it does require a VisitInsetX for every class X, but if you inherit from an InsetVisitorNOP class which provides default implementations for VisitInsetX for every class X which are empty, then this point is moot. this also applies to an iterator scheme with allowSpellCheck(). *** With the visitor scheme, the spell check method would actually be done in the visitor, not the Inset. This removes all spell check code from the inset. *** All the inset needs to provide is a way of accessing it's characters. This also facilitates other external methods anyway. If, for some strange reason, you had to build a LyX without spellchecking code, it would be easy - just don't include the spell check visitor file in the compilation, and it's gone. So this scheme allows you to easily add/remove features without changing the inset code (once you've added Accept methods to every inset). This allows for easier addition of new features without touching/breaking unrelated code. OK, ugly, but we are doing RTTI here. Having inner spell code public (or friended, which is not much nicer) is also ugly ... I'm saying the spell check code doesn't belong in the inset, it belongs in the visitor. That way, all the different ways of spell checking insets are in the same place (if any insets need to have it done differently). It also means that every time you want to add a new fandangled operation on an inset, you have to a) modify Inset to have an allowX() method b) modify the class(es) of interest to support the new fandangled operation. This way, all the mods are done in one place, without ever touching the Inset classes (apart from adding the visitor support infrastructure in the first place). iterator way: for new operations, add a new Accept() (or similar) for each inset that wants it (also use virtual where possible to avoid this) and modify the base class, and have to re-compile the whole inset tree, and anything else that uses it. your way: for new operations, add a new Accept() for inset that needs it (also use virtual where possible to avoid this) PLUS a new thing in the calling class for every type No, Add Accept once only per inset. Subsequently only add a method to your visitor class. Only re-compile the visitor class - test quickly.
Re: Bugs in Debian BTS
On 13 Dec 2001, Jean-Marc Lasgouttes wrote: Baruch == Baruch Even [EMAIL PROTECTED] writes: [...] Baruch too large menu fonts cause segfault with german locale Baruch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120450 I think this one is known. What has been done about it (tab too long in german == crash). That was why I reorganized the Preferences dialog into nested tabs. That fix is in 1.1.6 also but I'm not sure if the german translations are still too long. Allan. (ARRae)
Re: Bugs in Debian BTS
On Thu, Dec 13, 2001 at 03:59:36AM -0500, Baruch Even wrote: There are quite a few bugs in the debian BTS which neither me nor Jules know if they are valid or not, I'd be happy if someone more knowledgeable in this bugs can let me know their status. The whole bug lists cant be found at: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=lyxrepeatmerged=no http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=69483 is interesting. We often have people complain of this. Do you know why the bug occurs ? Is it definitely an X config problem ? regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: Inset Visitors...
John Leveon asked me how you would specify that one kind of inset is
searchable but not spell-checkable, and that another kind of inset is
spell-checkable and not searchable. Here is a complete self-contained
example.
class InsetVisitor;
class Inset {
// blah blah
virtual void Accept(InsetVisitor) = 0;
};
class InsetSpellCheckable : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetA(*this); }
};
class InsetSearchable : public Inset {
// blah blah
virtual void Accept(InsetVisitor iv ) { iv.VisitInsetB(*this); }
};
class InsetVisitor {
// blah blah
virtual void VisitInsetSpellCheckable( InsetSpellCheckable ) = 0;
virtual void VisitInsetSearchable( InsetSearchable ) = 0;
};
// Once-off infrastructure
class InsetVisitorNOP : public InsetVisitor {
virtual void VisitInsetSpellCheckable( InsetSpellCheckable ) {}
virtual void VisitInsetSearchable( InsetSearchable ) {}
};
class SpellCheckInsetVisitor : public InsetVisitorNOP {
// blah blah
public:
virtual void VisitInsetSpellCheckable( InsetSpellCheckable i ) {
// Carry out spellcheck on contents of InsetSpellcheckable
}
};
class SearchableInsetVisitor : public InsetVisitorNOP {
// blah blah
public:
virtual void VisitInsetSearchable( InsetSearchable i ) {
// Carry out search on contents of InsetSearchable
}
};
Note that only one set of Accepts methods is necessary in the Insets to
support both (and any other) kinds of visitors.
Furthermore, you may define a modular exporter:
// Export to text file
class WriteAsTextInsetVisitor
: public InsetVisitor // Compiler will give errors if new class is
added that we didn't visit.
{
public:
virtual void VisitInsetSearchable( InsetSearchable i ) {
// Write out an InsetSearchable as text format, including any
sub-insets...
}
virtual void VisitInsetSpellCheckable( InsetSpellCheckable i ) {
// Write out an InsetSpellCheckable as text format, including
any sub-insets...
}
};
Note that this visitor could be placed into a dynamic link library if
required, or conditionally compiled, or whatever... it has completely
removed the export code from all of the insets. It could be a new
feature you are adding for testing (without touching any existing inset
code).
Ben.
Re: Inset Visitors...
On Fri, Dec 14, 2001 at 02:07:05PM +1100, Ben Stanley wrote: John Leveon asked me how you would specify that one kind of inset is searchable but not spell-checkable, and that another kind of inset is spell-checkable and not searchable. Here is a complete self-contained example. OK, I get it now, the method lookup does the type inspection via the parameter type matching. That was the crucial point I was missing :) And I like it, I think. Not sure about the other example though ... regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: Inset Visitors...
John Levon wrote: On Fri, Dec 14, 2001 at 02:07:05PM +1100, Ben Stanley wrote: John Leveon asked me how you would specify that one kind of inset is searchable but not spell-checkable, and that another kind of inset is spell-checkable and not searchable. Here is a complete self-contained example. OK, I get it now, the method lookup does the type inspection via the parameter type matching. Uh, by the function name, but could name them all the same and do it by parameter type. The type lookup is really by the virtual Accept function in all the insets. That was the crucial point I was missing :) And I like it, I think. Not sure about the other example though ... Oh, didn't you like it? The contents of the visitor's methods would be pretty much the same as the current WriteAsText (or equivalent) methods dotted all over the Inset code... It just collects it all into one place. And where the WriteAsText method would call a sub-inset's WriteAsText method to get it to write itself out, the Visitor's method would call inset.Accept(*this); to do the same thing and correctly virtually dispatch it. Then all the WriteAsText code is collected into one file, all together, easier to maintain and make sure it's all consistent. Ben.
Re: XListFonts question
On Thu, Dec 13, 2001 at 10:24:03PM +0200, Dekel Tsur wrote: When I call to XListFonts with the pattern -*-cmsy-* (or equivalently, when typing xlsfonts -fn -*-cmsy-* in the shell), I get only one result as expected: -bluesky-cmsy-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific However, when I use the pattern -*-cmsy-*-*-*-*-*-*-*-*-*-*-*-*, I get two results: -bluesky-cmsy-medium-r-normal--0-0-0-0-m-0-adobe-fontspecific -bluesky-cmsy-medium-r-normal--12-120-75-75-m-0-adobe-fontspecific man xlsfonts : -o This option indicates that xlsfonts should do an OpenFont (and QueryFont, if appropriate) rather than a ListFonts. This is useful if ListFonts or ListFontsWithInfo fail to list a known font (as is the case with some scaled font systems). The behaviour you are seeing looks perhaps a little odd ... but it is related to the fact that listing all the available font specifications with scalable fonts makes no sense. My X book says : The X server and font server are only required to match scalable fonts when the font name pattrern they are passed is a well-formed one. A well-formed font name is one that contains all 14 hyphens specified in the XLFD convention. Wildcards are permitted for any field, but may not replace multiple fields. If XListFonts() is passed a pattrern that is not well-formed, it may not include scalable fonts in the search at all. - A.3.1 of Xlib Programming Manual , Adrian Nye
Visitor ...
here's a working example of what Ben had designed (did this so I
could work out what he was saying :)
Dunno about others, but I prefer the name of visitInset to stay
the same no matter what ...
the two problems ben has been trying to fix with this (accompanied
by stupid questions from myself) are :
1) each inset has to be listed in InsetVisitor
2) each inset HAS to have an acceptVisitor() method
I still think it's worth it, even better if anyone can solve either
of these problems ...
regards
john
#include iostream
class Inset;
class InsetERT;
class InsetVisitor {
// blah blah
public:
// need every possible inset listed here
// for dynamic dispatch based on inset type,
// to be robust against future visitor classes
virtual void visitInset(Inset ) {};
virtual void visitInset(InsetERT ) {};
};
class Inset {
// blah blah
public:
virtual void acceptVisitor(InsetVisitor iv) {
iv.visitInset(*this);
}
};
class InsetERT : public Inset {
// blah blah
private:
// need this here to get the right type for visitInset
virtual void acceptVisitor(InsetVisitor iv) {
iv.visitInset(*this);
}
};
class SpellCheckInsetVisitor : public InsetVisitor {
public:
virtual void visitInset(Inset ) {
// do default spellcheck
std::cout default spellcheck std::endl;
}
virtual void visitInset(InsetERT ) {
// don't do any spellcheck !!
std::cout ert no spellcheck std::endl;
}
// this is the top-level code
void doSpellcheck() {
//for_each(bv.inset_iterator_begin(), bv.inset_iterator_end(),
acceptVisitor(this));
Inset * ie = new InsetERT;
ie-acceptVisitor(*this);
}
};
int main() {
SpellCheckInsetVisitor v;
v.doSpellcheck();
}
--
Of all manifestations of power, restraint impresses the most.
- Thucydides
Re: Visitor ...
On Fri, 14 Dec 2001, John Levon wrote: here's a working example of what Ben had designed (did this so I could work out what he was saying :) Dunno about others, but I prefer the name of visitInset to stay the same no matter what ... the two problems ben has been trying to fix with this (accompanied by stupid questions from myself) are : 1) each inset has to be listed in InsetVisitor 2) each inset HAS to have an acceptVisitor() method I still think it's worth it, even better if anyone can solve either of these problems ... I'll check my copy of, of, ummm, I've forgotten the name. It's about implementing patterns as templates. Allan. (ARRae)
TOC crash
Anyone else noticed a crash when opening a TOC dialog in current CVS? Allan. (ARRae)
Re: Visitor ...
Allan Rae wrote: I'll check my copy of, of, ummm, I've forgotten the name. It's about implementing patterns as templates. Allan. (ARRae) Been there, tried that, but John and I didn't succeed. Good luck. I thought that we could use the Barton and Nackman trick (see Scientific and Engineering C++, by same authors, named after a pattern that was used extensively in that book), but you can't re-define a virtual method by inheriting it through another base class. Ben.
Re: TOC crash
On Fri, Dec 14, 2001 at 03:33:42PM +1000, Allan Rae wrote: Anyone else noticed a crash when opening a TOC dialog in current CVS? looks like my bad code. will fix ... john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: TOC crash
Allan Rae wrote: Anyone else noticed a crash when opening a TOC dialog in current CVS? no problem here, latest cvs Herbert -- http://www.lyx.org/help/
Re: TOC crash
Anyone else noticed a crash when opening a TOC dialog in current CVS? it crashes on an empty document. fix attached. regards john -- Of all manifestations of power, restraint impresses the most. - Thucydides
Re: [noreply@sourceforge.net: [ lyxbugs-Feature Requests-439373 ] Support \intertext in mathed]
On Thu, Dec 13, 2001 at 07:44:09PM +, John Levon wrote: 1) if someone else closes a bug, you will get an email from bugzilla 2) if you fix a bug and want it closed, mention on the list and someone (me, michael k., someone else) will pick it up and close the bug for you I had a look myself on that bugtracker but could not work out way to get a list of e.g. all mathed bugs. The closest think I got was a list bugs assigned to engineers. The search field seemed only to accept bug numbers and I do not really like the idea to iterate from 1 to 90 there. What did I miss? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Row * - Row , part I
On Thu, Dec 13, 2001 at 09:30:59PM +0100, Lars Gullik Bjønnes wrote: The kind of patches I like but is this the right time to do this? Probably not... I just wanted to tease you ;-} (I must admit that I am likely to try out the shared_ptrParagraph idea pretty soon... only in my local tree of course) Lucky me that I picked the Row and not the Paragraph... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: [martin.vermeer@hut.fi: Re: Patches waiting]
On Thu, Dec 13, 2001 at 11:16:50PM +0200, Martin Vermeer wrote: Item 1. does make the key sequences a little longer, but so what? People won't like it. I think there are still more mathematicians or physisists who use LyX than people from the poetry fraction... There are many others already of the same length, and we all type happily M-m g D to get a \Delta etc. etc. No, I type \Delta. Actually, I type most math exactly the way I would do when writing LaTeX in vi, so every additional difference annoys me... I don't think it will make a typical formula much longer/harder to type as this is offset by the greater consistency. I suspect it may be possible (but you should know best :-) to change LyX thus that being in mathed always implicitly prepends M-m to keysequences typed. This should make that easier. Yes, we seem to need some context sensitive keybindings. Soonish... Maybe it's not even too hard... -- André Pönitz .. [EMAIL PROTECTED]
Re: CVS Update: lyx-devel
On Thu, Dec 13, 2001 at 11:06:14PM +, [EMAIL PROTECTED] wrote: Modified files: lyx-devel/src/mathed/: ChangeLog math_support.C Log message: Fix handling of \mathfrak font. Out of pure curiosity: what was broken and how does your patch fixed it? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: TOC crash
On Fri, 14 Dec 2001, John Levon wrote: Anyone else noticed a crash when opening a TOC dialog in current CVS? it crashes on an empty document. fix attached. My case is a multipart document and chapters are in separate docs. So this is the same as an empty doc? But sadly the unattached fix doesn't work for me. Allan. (ARRae)
Some bugs
Hi! I have found a few new bugs. Please have a look. Michael Place a paragraph that is aligned to the right and has a line above into a minipage - the line is not drawn correctly (in order to observe this, there must be some text in front/after the minipage and the size of the minipage should be set to 50% of page width) In math mode, enter a, ^, _, cursorleft, cursorleft. The subscript of the superscript is deleted correctly but a small dot remains as the superscript of a on screen. Adding a column after the last column of a table still causes a freed memory access error! (Use njamd, a fast memory checker, to check this) #0 0x080f522e in LyXTabular::AppendColumn (this=0x45b76f88, cell=0) at tabular.C:310 #1 0x0818378e in InsetTabular::tabularFeatures (this=0x446a6f70, bv=0x44796fec, feature=APPEND_COLUMN, value=@0xb254) at insettabular.C:1731 #2 0x081e95f6 in FormTabular::input (this=0x444d2f00, ob=0x46120f00) at FormTabular.C:558 #3 0x08210894 in FormBaseDeprecated::InputCB (ob=0x46120f00, data=0) at FormBaseDeprecated.C:212 #4 0x0820ff5e in C_FormBaseDeprecatedInputCB (ob=0x46120f00, d=0) at FormBaseDeprecated.C:54 ... This one should be really simple to fix; I guess it is just an out-of-bounds errors. * Insert one line of text into a note; delete the line and undo the deletion - freed memory access error! #0 Paragraph::id (this=0x446b8fdc) at paragraph.C:2073 #1 0x0818feb4 in InsetText::getParFromID (this=0x460feef8, id=1) at insettext.C:2345 #2 0x08194264 in InsetCollapsable::getParFromID (this=0x460fee9c, id=1) at insetcollapsable.C:570 #3 0x080efc80 in Paragraph::Pimpl::getParFromID (this=0x45dbbfac, id=1) at paragraph_pimpl.C:539 #4 0x080ede8e in Paragraph::getParFromID (this=0x45cd1fdc, id=1) at paragraph.C:2165 #5 0x0809c555 in Buffer::getParFromID (this=0x45b4ae60, id=1) at buffer.C:3765 #6 0x0811dbe1 in LyXText::ownerParagraph (this=0x45cade70, id=1, p=0x447b0fdc) at text2.C:2595 #7 0x08121d5d in textHandleUndo (bv=0x44796fec, undo=0x4619afe4) at undo_funcs.C:151 #8 0x08121991 in textUndo (bv=0x44796fec) at undo_funcs.C:48 #9 0x080524e8 in BufferView::menuUndo (this=0x44796fec) at BufferView2.C:241 #10 0x080cafce in LyXFunc::dispatch (this=0x41909f7c, ac=16, do_not_use_this_arg=@0xbfffee98) at lyxfunc.C:827 -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Patches waiting
On 12-Dec-2001 Jean-Marc Lasgouttes wrote: > I have to admit that I am not sure. Harcoding SUBSCRIPT SUPERSCRIPT to > output ^ and _ in text mode is not better than hardcoding them in math > as we had before. Maybe these functions could be changed in text to > insert the character they have been bound to, but this is really > hackish. Well as much as I know ^ may be a deadkey and if it IS a deadkey it can be used to put it over a character! But if it's no deadkey then it definitely in textmode should input a ^ character. For the _ (underscore) in text mode it definitively should input a _ character always. As for mathmode I don't know (and don't really care ;) but the problem is if we want be 100% compatible with the behaviour in 1.1.6 or if we don't. Anyway IMO ^ can be used to go in subscript (in mathed) and if ^ is a deadkey it should anyway go into subscript (if we get the token otherwise it can handle it only after the " " (space). For _ it's never a deadkey so there seems to be no problem. In mathmode go in subscript in math-text mode insert a _ character. > I do not know what the right solution is, but we have to find one... I was just thinking out aloud above, but that's what I think is most resonable. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "OK, now let's look at four dimensions on the blackboard." -- Dr. Joy
Re: Herbert's problems with large documents loading time
On 12-Dec-2001 Lars Gullik Bjønnes wrote: > Found a LyXText that fits: > Buffer: 0x84d0aa0 Width: 667 > TextCache: resizeCurrentBuffer > Buffer: 0x84d06b8 Width: 667 Why does it a resize if the sizes are the same??? A resize has to recalculate ALL of the insettext! Are you sure we do a resize REALLY or are we just outputting the text? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Can you program?" "Well, I'm literate, if that's what you mean!"
