Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: Well this is well known and as developer you should have looked at the buglist on SourceForge.net ;) I still think that this was a sly way to get help, but anyway I've played further. #:O) Well you won't believe it but I know since a long time the exact spot and code which is culpable for this. It is InsetTabular::resetPos()! It's just that something with that scrolling mechanism is wrong, but I don't have a good idea to fix it. So if someone has time to spare he can do some investigation and see what we can do there to fix the cycle. A fast fix would be to have a bool so that resetPos is not entered 2 times, but probably that wouldn't do the right scroll, but who knows :) Anyway I'll save the mail so that when I have time I can do this myself if noone beats me in it. I'm still working A LOT in making Find/Replace work correctly and I only have a really small bug to fix right now, but you know small bugs are hard to spot :). Anyway my local tree has in a lot of cleanups and IMO some of the bugs on SourceForge are gone now as I took the time to fix also other stuff I've seen when testing the Find/Replace stuff. One of them is the Cursor appearing outside the inset on some ocacions :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Penn's aunts made great apple pies at low prices. No one else in town could compete with the pie rates of Penn's aunts.
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: >> Well this is well known and as developer you should have looked at the > buglist >> on SourceForge.net ;) > > I still think that this was a sly way to get help, but anyway I've played > further. #:O) Well you won't believe it but I know since a long time the exact spot and code which is culpable for this. It is InsetTabular::resetPos()! It's just that something with that scrolling mechanism is wrong, but I don't have a good idea to fix it. So if someone has time to spare he can do some investigation and see what we can do there to fix the cycle. A fast fix would be to have a bool so that resetPos is not entered 2 times, but probably that wouldn't do the right scroll, but who knows :) Anyway I'll save the mail so that when I have time I can do this myself if noone beats me in it. I'm still working A LOT in making Find/Replace work correctly and I only have a really small bug to fix right now, but you know small bugs are hard to spot :). Anyway my local tree has in a lot of cleanups and IMO some of the bugs on SourceForge are gone now as I took the time to fix also other stuff I've seen when testing the Find/Replace stuff. One of them is the Cursor appearing outside the inset on some ocacions :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Penn's aunts made great apple pies at low prices. No one else in town could compete with the pie rates of Penn's aunts.
Re: Natbib announcement (and 666 inset gripes)
On 18-Jul-2001 Mike Ressler wrote: This is not a stunning example of WYSIWYM. Please, please, (Lars?) change the appearance back to the old behavior!!! I don't think this will happen. What will happen is that we will change the InsetERT to be inlined. What will NOT happen is that a inlined ERT inset breaks row, so this is really thought only for short stuff! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Might as well be frank, monsieur. It would take a miracle to get you out of Casablanca and the Germans have outlawed miracles. -- Casablanca
Re: Natbib announcement (and 666 inset gripes)
On Thu, 19 Jul 2001, Juergen Vigna wrote: On 18-Jul-2001 Mike Ressler wrote: This is not a stunning example of WYSIWYM. Please, please, (Lars?) change the appearance back to the old behavior!!! I don't think this will happen. What will happen is that we will change the InsetERT to be inlined. What will NOT happen is that a inlined ERT inset breaks row, so this is really thought only for short stuff! I don't care what the underlying mechanism is (insets, fonts, etc.). I would like the _appearance_ to resemble the old style. Having it appear like a math inset would be fine. Maybe that is the model: an inlined ERT box and a display ERT box, for longer chunks of LaTeX code. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Thu, 19 Jul 2001, Juergen Vigna wrote: On 19-Jul-2001 Mike Ressler wrote: like a math inset would be fine. Maybe that is the model: an inlined ERT box and a display ERT box, for longer chunks of LaTeX code. That's exactly what we plan to do :) Excellent! Why didn't you just say so :-) Sorry if I sounded overly loud - I was just shocked by the appearance of those 666 boxes, and hadn't really followed the previous discussion closely enough to realize what was going on. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 09:21:51AM +0200, Juergen Vigna wrote: On 18-Jul-2001 Mike Ressler wrote: This is not a stunning example of WYSIWYM. Please, please, (Lars?) change the appearance back to the old behavior!!! I don't think this will happen. What will happen is that we will change the InsetERT to be inlined. What will NOT happen is that a inlined ERT inset breaks row, so this is really thought only for short stuff! can't you un-inline the ert inset automagically when it extends beyond the right margin of the workarea ? john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 John Levon wrote: can't you un-inline the ert inset automagically when it extends beyond the right margin of the workarea ? Probably yes, but do I want to do this? Probably no, as then I would get complaints about this automatic behaviour someone surely doesn't like! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Life sucks, but death doesn't put out at all. -- Thomas J. Kopp
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 05:08:12PM +0200, Juergen Vigna wrote: On 19-Jul-2001 John Levon wrote: can't you un-inline the ert inset automagically when it extends beyond the right margin of the workarea ? Probably yes, but do I want to do this? Probably no, as then I would get complaints about this automatic behaviour someone surely doesn't like! Think about the alternative - I add a lot of ert into the inset, so it is drawn off the side, and I can't even read it ! Surely we dont really have/want a choice in this circumstance. john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:08, Juergen Vigna wrote: On 19-Jul-2001 John Levon wrote: can't you un-inline the ert inset automagically when it extends beyond the right margin of the workarea ? Probably yes, but do I want to do this? Probably no, as then I would get complaints about this automatic behaviour someone surely doesn't like! Well it seems like a good suggestion to me because it only affects the users ability to see what's on LyX's screen. Who's going to complain loudly about LyX won't let me write text off the end of the screen when I want to? Anyway, that's the joy of being an open source developer: you can tell the user to get used to this behaviour I've implemented or change it yourself if you decide they're being a PITA. As I probably am. Enough, Angus
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: Probably yes, but do I want to do this? Probably no, as then I would get complaints about this automatic behaviour someone surely doesn't like! Well it seems like a good suggestion to me because it only affects the users The only change to the above I would admit is making it displayed as soon as it is Larger then the screen, all other cases have to have a user interaction. Anyway before we have to implement the inlined stuff then we can discuss about this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Lots of folks are forced to skimp to support a government that won't.
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:14, Juergen Vigna wrote: On 19-Jul-2001 John Levon wrote: Think about the alternative - I add a lot of ert into the inset, so it is drawn off the side, and I can't even read it ! Surely we dont really have/want a choice in this circumstance. Well we have already the inset will scroll to the right if the cursor exits to the left ;) (try this in a tabular cell where the InsetText IS inlined). Oh you bugger! I've just done this and now I'm getting infinite redraws of the table and can do nothing useful at all. Phew! LyX has just crashed on me. Road test to infinite redraws: 1. Insert table, I row, 2 columns 2. Type in first (leftmost) column until the table gets bigger than the width Bingo! Actually, If you leave this on screen doing its stuff then you'll crash LyX in malloc. Presumably it just runs out of memory therefore. Angus
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: Road test to infinite redraws: 1. Insert table, I row, 2 columns 2. Type in first (leftmost) column until the table gets bigger than the width Well this is well known and as developer you should have looked at the buglist on SourceForge.net ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Your aim is high and to the right.
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 05:50:43PM +0200, Juergen Vigna wrote: On 19-Jul-2001 Angus Leeming wrote: Road test to infinite redraws: 1. Insert table, I row, 2 columns 2. Type in first (leftmost) column until the table gets bigger than the width Well this is well known and as developer you should have looked at the buglist on SourceForge.net ;) actually it's changed behaviour recently - a 1x2 table didn't used to trigger it ... john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:50, Juergen Vigna wrote: On 19-Jul-2001 Angus Leeming wrote: Road test to infinite redraws: 1. Insert table, I row, 2 columns 2. Type in first (leftmost) column until the table gets bigger than the width Well this is well known and as developer you should have looked at the buglist on SourceForge.net ;) I still think that this was a sly way to get help, but anyway I've played further. The infinite redraws are the result of a recursive cycling 18 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x28e, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] 19 resetPos__C12InsetTabularXP10BufferView(0x1401814b0, 0x1401e4938, 0x36, 0x1401e4968, 0x26a) [0x12034b330] 20 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x26a, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] 21 resetPos__C12InsetTabularXP10BufferView(0x1401814b0, 0x1401e4938, 0x1d, 0x1401e4968, 0x28e) [0x12034b330] 22 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x28e, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] Note that 18 and 22 are identical. As are 19 and 23 etc. So it's not just a simple oscillation between the two methods. Interestingly, if I create my table so that it reaches the width of the screen (just less) and then paste in some more text, then I CAN scroll. But doing so, I get a new problem. Effectively, I scroll off the end and into a segmentation fault. Backtrace below, but physically what happens is: Create a new document. Insert a table, 1row, 2cols Type e e e e e e in the first column until just before the table reaches screen width. Exit the table and on the line above type elephant elephant Cut this text, move the cursor around so only the line with the table on it exists. Paste the cut text into the leftmost column of the table so that the width is greater than the screen width. Scroll happily to the end of the first column (of two) with the right arrow key. Leave it and enter second column. Continue scrolling til we leave this column, continue scrolling (one more arrow press) to leave the table. The table is now redrawn with its left-most edge showing (fine), but the cursor is invisible. Pressing the arrow keys (some combination, any combo), to try and get the cursor visible again and eventually we get the segmentation fault and backtrace below. Angus signal Segmentation fault at *[GetCellNumber__C10LyXTabularXii, 0x1202aaa08] ldl r0, 0(r0) (dbx) where 0 GetCellNumber__C10LyXTabularXii(0x3ff801151ac, 0x, 0x12034ad68, 0x1401e2600, 0x397) [0x1202aaa08] 1 setPos__C12InsetTabularXP10BufferViewii(0x1401814b0, 0x397, 0xa, 0x0, 0x1400a80d8) [0x12034ad64] 2 edit__12InsetTabularXP10BufferViewiiUi(0x1201e83b8, 0x120348170, 0x1401e2600, 0x32, 0x1401814b0) [0x120348264] 3 Dispatch__Q110BufferView5PimplX9kb_actionRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x0, 0x0, 0x1201e56f0, 0x1400f6ed8, 0x1201dc100) [0x1201e83b4] 4 Dispatch__10BufferViewX9kb_actionRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x1201e56f0, 0x1400f6ed8, 0x1201dc100, 0x1400ac4c0, 0x120275bb0) [0x1201dc304] 5 dispatch__7LyXFuncXiRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x3ff801151ac, 0x1, 0x1ff51, 0x0, 0x1400f6e48) [0x120275bac] 6 processKeySym__7LyXFuncXUiUi(0x3ff801151ac, 0x1400a8000, 0x12042f700, 0x1400ac4c0, 0x120425108) [0x12027058c] 7 workAreaKeyPress__Q110BufferView5PimplXUiUi(0x12042f700, 0x1400ac4c0, 0x120425108, 0x140186658, 0x1201e02dc) [0x1201e288c] 8 (unknown)() [0x1201e02d8] 9 emit__Q14SigC38Signal2__Tv__TUiUiQ14SigC11Marshal__TvXRCUiRCUi(0x120219a30, 0x140186658, 0x61, 0x1400a5924, 0xcbff0c51) [0x120150a90] 10 work_area_handler__8WorkAreaXP7flobjs_Pv(0x540006f, 0xff51, 0xff51, 0xff51, 0x140186658) [0x120219a2c] 11 C_WorkArea_work_area_handler(0xff51, 0xff51, 0x140186658, 0x140178080, 0x3ffbff8c494) [0x120218370] 12 (unknown)() [0x3ffbff8c490] 13 fl_handle_object(0x140187600, 0x140187600, 0x3fc6300, 0xff51, 0x3ffbff51e90) [0x3ffbff8c584] 14 (unknown)() [0x3ffbff51e8c] 15 (unknown)() [0x3ffbff52504] 16 (unknown)() [0x3ffbff52970] 17 (unknown)() [0x3ffbff530fc] 18 fl_treat_interaction_events(0x13365100022641, 0x1336510001233d, 0x143954000d314c, 0x116320001233d, 0xa2c4500052a44) [0x3ffbff5386c] 19 fl_check_forms(0x143954000d314c, 0x116320001233d, 0xa2c4500052a44, 0x1233d00072739, 0x12037728c) [0x3ffbff538bc] 20 runTime__10GUIRunTimeXv(0x14019c260, 0x0, 0x14019c2c0, 0x3a017422, 0x140176690) [0x120377288] 21 runTime__6LyXGUIXv(0x14019c2c0, 0x3a017422, 0x140176690, 0x1400a8000, 0x120263e30) [0x12026047c] 22 __ct__3LyXXPiPPc(0x140065820, 0x3ffc00802a0, 0x12024cc6c, 0x140027148, 0x116c8) [0x120263e2c] 23 main(0x0, 0x80084600, 0x1400ecda0, 0x11748, 0x10001) [0x12028db2c]
Re: Natbib announcement (and 666 inset gripes)
On 18-Jul-2001 Mike Ressler wrote: > This is not a stunning example of WYSIWYM. Please, please, (Lars?) change > the appearance back to the old behavior!!! I don't think this will happen. What will happen is that we will change the InsetERT to be inlined. What will NOT happen is that a inlined ERT inset breaks row, so this is really thought only for short stuff! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Might as well be frank, monsieur. It would take a miracle to get you out of Casablanca and the Germans have outlawed miracles. -- Casablanca
Re: Natbib announcement (and 666 inset gripes)
On Thu, 19 Jul 2001, Juergen Vigna wrote: > On 18-Jul-2001 Mike Ressler wrote: > > This is not a stunning example of WYSIWYM. Please, please, (Lars?) change > > the appearance back to the old behavior!!! > > I don't think this will happen. What will happen is that we will change > the InsetERT to be inlined. What will NOT happen is that a inlined ERT > inset breaks row, so this is really thought only for short stuff! I don't care what the underlying mechanism is (insets, fonts, etc.). I would like the _appearance_ to resemble the old style. Having it appear like a math inset would be fine. Maybe that is the model: an inlined ERT box and a "display" ERT box, for longer chunks of LaTeX code. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Thu, 19 Jul 2001, Juergen Vigna wrote: > On 19-Jul-2001 Mike Ressler wrote: > > > like a math inset would be fine. Maybe that is the model: an inlined ERT > > box and a "display" ERT box, for longer chunks of LaTeX code. > > That's exactly what we plan to do :) Excellent! Why didn't you just say so :-) Sorry if I sounded overly loud - I was just shocked by the appearance of those 666 boxes, and hadn't really followed the previous discussion closely enough to realize what was going on. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 09:21:51AM +0200, Juergen Vigna wrote: > > On 18-Jul-2001 Mike Ressler wrote: > > > This is not a stunning example of WYSIWYM. Please, please, (Lars?) change > > the appearance back to the old behavior!!! > > I don't think this will happen. What will happen is that we will change > the InsetERT to be inlined. What will NOT happen is that a inlined ERT > inset breaks row, so this is really thought only for short stuff! can't you un-inline the ert inset automagically when it extends beyond the right margin of the workarea ? john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 John Levon wrote: > can't you un-inline the ert inset automagically when it extends beyond the right >margin > of the workarea ? Probably yes, but do I want to do this? Probably no, as then I would get complaints about this automatic behaviour someone surely doesn't like! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Life sucks, but death doesn't put out at all. -- Thomas J. Kopp
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 05:08:12PM +0200, Juergen Vigna wrote: > > On 19-Jul-2001 John Levon wrote: > > > can't you un-inline the ert inset automagically when it extends beyond the right >margin > > of the workarea ? > > Probably yes, but do I want to do this? Probably no, as then I would get > complaints about this automatic behaviour someone surely doesn't like! Think about the alternative - I add a lot of ert into the inset, so it is drawn off the side, and I can't even read it ! Surely we dont really have/want a choice in this circumstance. john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:08, Juergen Vigna wrote: > On 19-Jul-2001 John Levon wrote: > > > can't you un-inline the ert inset automagically when it extends beyond the right margin > > of the workarea ? > > Probably yes, but do I want to do this? Probably no, as then I would get > complaints about this automatic behaviour someone surely doesn't like! Well it seems like a good suggestion to me because it only affects the users ability to see what's on LyX's screen. Who's going to complain loudly about "LyX won't let me write text off the end of the screen when I want to"? Anyway, that's the joy of being an open source developer: you can tell the user to "get used to this behaviour I've implemented or change it yourself" if you decide they're being a PITA. As I probably am. Enough, Angus
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: >> Probably yes, but do I want to do this? Probably no, as then I would get >> complaints about this automatic behaviour someone surely doesn't like! > > Well it seems like a good suggestion to me because it only affects the users The only change to the above I would admit is making it displayed as soon as it is "Larger" then the screen, all other cases have to have a user interaction. Anyway before we have to implement the inlined stuff then we can discuss about this :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Lots of folks are forced to skimp to support a government that won't.
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:14, Juergen Vigna wrote: > On 19-Jul-2001 John Levon wrote: > > > Think about the alternative - I add a lot of ert into the inset, so it is drawn off > > the side, and I can't even read it ! > > > > Surely we dont really have/want a choice in this circumstance. > > Well we have already the inset will scroll to the right if the cursor exits to > the left ;) (try this in a tabular cell where the InsetText IS inlined). Oh you bugger! I've just done this and now I'm getting infinite redraws of the table and can do nothing useful at all. Phew! LyX has just crashed on me. Road test to infinite redraws: 1. Insert table, I row, 2 columns 2. Type in first (leftmost) column until the table gets bigger than the width Bingo! Actually, If you leave this on screen doing its stuff then you'll crash LyX in malloc. Presumably it just runs out of memory therefore. Angus
Re: Natbib announcement (and 666 inset gripes)
On 19-Jul-2001 Angus Leeming wrote: > Road test to infinite redraws: > 1. Insert table, I row, 2 columns > 2. Type in first (leftmost) column until the table gets bigger than the width Well this is well known and as developer you should have looked at the buglist on SourceForge.net ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Your aim is high and to the right.
Re: Natbib announcement (and 666 inset gripes)
On Thu, Jul 19, 2001 at 05:50:43PM +0200, Juergen Vigna wrote: > > On 19-Jul-2001 Angus Leeming wrote: > > > Road test to infinite redraws: > > 1. Insert table, I row, 2 columns > > 2. Type in first (leftmost) column until the table gets bigger than the width > > Well this is well known and as developer you should have looked at the buglist > on SourceForge.net ;) actually it's changed behaviour recently - a 1x2 table didn't used to trigger it ... john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On Thursday 19 July 2001 16:50, Juergen Vigna wrote: > On 19-Jul-2001 Angus Leeming wrote: > > > Road test to infinite redraws: > > 1. Insert table, I row, 2 columns > > 2. Type in first (leftmost) column until the table gets bigger than the width > > Well this is well known and as developer you should have looked at the buglist > on SourceForge.net ;) I still think that this was a sly way to get help, but anyway I've played further. The infinite redraws are the result of a recursive cycling 18 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x28e, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] 19 resetPos__C12InsetTabularXP10BufferView(0x1401814b0, 0x1401e4938, 0x36, 0x1401e4968, 0x26a) [0x12034b330] 20 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x26a, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] 21 resetPos__C12InsetTabularXP10BufferView(0x1401814b0, 0x1401e4938, 0x1d, 0x1401e4968, 0x28e) [0x12034b330] 22 updateLocal__C12InsetTabularXP10BufferView11UpdateCodesjb(0x28e, 0x0, 0x12034b334, 0x1401e4900, 0x1401814b0) [0x120348320] Note that 18 and 22 are identical. As are 19 and 23 etc. So it's not just a simple oscillation between the two methods. Interestingly, if I create my table so that it reaches the width of the screen (just less) and then paste in some more text, then I CAN scroll. But doing so, I get a new problem. Effectively, I scroll off the end and into a segmentation fault. Backtrace below, but physically what happens is: Create a new document. Insert a table, 1row, 2cols Type "e e e e e e" in the first column until just before the table reaches screen width. Exit the table and on the line above type "elephant elephant" Cut this text, move the cursor around so only the line with the table on it exists. Paste the cut text into the leftmost column of the table so that the width is greater than the screen width. Scroll happily to the end of the first column (of two) with the right arrow key. Leave it and enter second column. Continue scrolling til we leave this column, continue scrolling (one more arrow press) to leave the table. The table is now redrawn with its left-most edge showing (fine), but the cursor is invisible. Pressing the arrow keys (some combination, any combo), to try and get the cursor visible again and eventually we get the segmentation fault and backtrace below. Angus signal Segmentation fault at >*[GetCellNumber__C10LyXTabularXii, 0x1202aaa08] ldl r0, 0(r0) (dbx) where > 0 GetCellNumber__C10LyXTabularXii(0x3ff801151ac, 0x, 0x12034ad68, 0x1401e2600, 0x397) [0x1202aaa08] 1 setPos__C12InsetTabularXP10BufferViewii(0x1401814b0, 0x397, 0xa, 0x0, 0x1400a80d8) [0x12034ad64] 2 edit__12InsetTabularXP10BufferViewiiUi(0x1201e83b8, 0x120348170, 0x1401e2600, 0x32, 0x1401814b0) [0x120348264] 3 Dispatch__Q110BufferView5PimplX9kb_actionRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x0, 0x0, 0x1201e56f0, 0x1400f6ed8, 0x1201dc100) [0x1201e83b4] 4 Dispatch__10BufferViewX9kb_actionRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x1201e56f0, 0x1400f6ed8, 0x1201dc100, 0x1400ac4c0, 0x120275bb0) [0x1201dc304] 5 dispatch__7LyXFuncXiRCQ13std60basic_string__TcQ13std15char_traits__TcQ13std13allocator__Tv(0x3ff801151ac, 0x1, 0x1ff51, 0x0, 0x1400f6e48) [0x120275bac] 6 processKeySym__7LyXFuncXUiUi(0x3ff801151ac, 0x1400a8000, 0x12042f700, 0x1400ac4c0, 0x120425108) [0x12027058c] 7 workAreaKeyPress__Q110BufferView5PimplXUiUi(0x12042f700, 0x1400ac4c0, 0x120425108, 0x140186658, 0x1201e02dc) [0x1201e288c] 8 (unknown)() [0x1201e02d8] 9 emit__Q14SigC38Signal2__Tv__TUiUiQ14SigC11Marshal__TvXRCUiRCUi(0x120219a30, 0x140186658, 0x61, 0x1400a5924, 0xcbff0c51) [0x120150a90] 10 work_area_handler__8WorkAreaXP7flobjs_Pv(0x540006f, 0xff51, 0xff51, 0xff51, 0x140186658) [0x120219a2c] 11 C_WorkArea_work_area_handler(0xff51, 0xff51, 0x140186658, 0x140178080, 0x3ffbff8c494) [0x120218370] 12 (unknown)() [0x3ffbff8c490] 13 fl_handle_object(0x140187600, 0x140187600, 0x3fc6300, 0xff51, 0x3ffbff51e90) [0x3ffbff8c584] 14 (unknown)() [0x3ffbff51e8c] 15 (unknown)() [0x3ffbff52504] 16 (unknown)() [0x3ffbff52970] 17 (unknown)() [0x3ffbff530fc] 18 fl_treat_interaction_events(0x13365100022641, 0x1336510001233d, 0x143954000d314c, 0x116320001233d, 0xa2c4500052a44) [0x3ffbff5386c] 19 fl_check_forms(0x143954000d314c, 0x116320001233d, 0xa2c4500052a44, 0x1233d00072739, 0x12037728c) [0x3ffbff538bc] 20 runTime__10GUIRunTimeXv(0x14019c260, 0x0, 0x14019c2c0, 0x3a017422, 0x140176690) [0x120377288] 21 runTime__6LyXGUIXv(0x14019c2c0, 0x3a017422, 0x140176690, 0x1400a8000, 0x120263e30) [0x12026047c] 22 __ct__3LyXXPiPPc(0x140065820, 0x3ffc00802a0, 0x12024cc6c, 0x140027148, 0x116c8) [0x120263e2c] 23 main(0x0, 0x80084600, 0x1400ecda0, 0x11748, 0x10001) [0x12028db2c]
Re: Natbib announcement (and 666 inset gripes)
On Wed, 18 Jul 2001, Angus Leeming wrote: I believe that the NATBIB branch is now in a fit state to merge back into head. This is now your final chance to try it out before I completely screw up the CVS head by rolling the branch back in ;-) Woo hoo!!! Yes! Grabbed it, compiled it, already playing with it - even though I should go to bed since I just finished observing all night and need to get up in 6 hours to start all over again. The natbib stuff is working great. Great job, Angus! That said, I want to gripe about the 666 insets, since this is the first I've seen them. I don't care what goes on under the hood, but I want them to look and behave like the old ERT. I was playing around with converting a paper I had written. If a bit of ERT appeared midsentence (e.g. I often insert \microns, rather than doing the $\mu$m equivalent), the line before it was justified fully left to right: if there were only 3 words on the line, one would be on the left, one dead center, the third on the right margin. It looks TERRIBLE! Furthermore, instead of aiding reading, a sentence like We observed the source at 10 \microns, whenever the weather was good shows up as We observed the source at 10 666 \microns , whenever the weather was good This is not a stunning example of WYSIWYM. Please, please, (Lars?) change the appearance back to the old behavior!!! I still like the natbib though!!! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Wed, Jul 18, 2001 at 11:49:45AM -0700, Mike Ressler wrote: That said, I want to gripe about the 666 insets, since this is the first yes, everyone has this gripe. Lars and Juergen are doing things to get it nice again, but with out re-introducing latex font mode (something that needs updating in the docs). ert-inset is the new thing, and will probably be made inlineable (by default). regards john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
John Levon wrote: On Wed, Jul 18, 2001 at 11:49:45AM -0700, Mike Ressler wrote: That said, I want to gripe about the 666 insets, since this is the first yes, everyone has this gripe. Lars and Juergen are doing things to get it nice again, but with out re-introducing latex font mode (something that needs updating in the docs). ert-inset is the new thing, and will probably be made inlineable (by default). The nice thing is that there is a growing list of common uses of ERT that LyX could do without using ERT. And John, clicking on MathPanel Greek killed LyX for me also, so it is probably not your xforms. Garst
Re: Natbib announcement (and 666 inset gripes)
On Wed, Jul 18, 2001 at 05:05:42PM -0300, Garst R. Reese wrote: And John, clicking on MathPanel Greek killed LyX for me also, so it is probably not your xforms. hmm. I've tried it against an xforms with /definitely/ the right glibc and still get the problem too. I'll have to see what's going on. There doesn't appear to be anything relevant in the ChangeLog :/ john -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
On Wed, 18 Jul 2001, Angus Leeming wrote: > I believe that the NATBIB branch is now in a fit state to merge back into > head. This is now your final chance to try it out before I completely screw > up the CVS head by rolling the branch back in ;-) Woo hoo!!! Yes! Grabbed it, compiled it, already playing with it - even though I should go to bed since I just finished observing all night and need to get up in 6 hours to start all over again. The natbib stuff is working great. Great job, Angus! That said, I want to gripe about the 666 insets, since this is the first I've seen them. I don't care what goes on under the hood, but I want them to look and behave like the old ERT. I was playing around with converting a paper I had written. If a bit of ERT appeared midsentence (e.g. I often insert \microns, rather than doing the $\mu$m equivalent), the line before it was justified fully left to right: if there were only 3 words on the line, one would be on the left, one dead center, the third on the right margin. It looks TERRIBLE! Furthermore, instead of aiding reading, a sentence like We observed the source at 10 \microns, whenever the weather was good shows up as We observed the source at 10 666 \microns , whenever the weather was good This is not a stunning example of WYSIWYM. Please, please, (Lars?) change the appearance back to the old behavior!!! I still like the natbib though!!! Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Natbib announcement (and 666 inset gripes)
On Wed, Jul 18, 2001 at 11:49:45AM -0700, Mike Ressler wrote: > That said, I want to gripe about the 666 insets, since this is the first yes, everyone has this gripe. Lars and Juergen are doing things to get it nice again, but with out re-introducing latex font mode (something that needs updating in the docs). ert-inset is the new thing, and will probably be made inlineable (by default). regards john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: Natbib announcement (and 666 inset gripes)
John Levon wrote: > > On Wed, Jul 18, 2001 at 11:49:45AM -0700, Mike Ressler wrote: > > > That said, I want to gripe about the 666 insets, since this is the first > > yes, everyone has this gripe. Lars and Juergen are doing things to get it nice > again, but with out re-introducing latex font mode (something that needs updating > in the docs). ert-inset is the new thing, and will probably be made inlineable (by >default). The nice thing is that there is a growing list of common uses of ERT that LyX could do without using ERT. And John, clicking on MathPanel Greek killed LyX for me also, so it is probably not your xforms. Garst
Re: Natbib announcement (and 666 inset gripes)
On Wed, Jul 18, 2001 at 05:05:42PM -0300, Garst R. Reese wrote: > And John, clicking on MathPanel Greek killed LyX for me also, so it is > probably not your xforms. hmm. I've tried it against an xforms with /definitely/ the right glibc and still get the problem too. I'll have to see what's going on. There doesn't appear to be anything relevant in the ChangeLog :/ john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
