Re: increase Sign
On Tue, Feb 17, 2004 at 12:58:48AM +0100, Ursula Andertsen spake thusly: > Hi > > i have a question about lyx, which is not answered by the tutorials or user > guides, or i haven't found the answer. > > I'm writing a bibliography and i need to increase a number (hoeherstellen > eines zeichens) to signal, that it is the second Edition or so. Munich second > edition 1998 = Munich 21998. And the 2 is increased. > > But i cannot find such a function in lyx and i'm sure, there is this > function. > > Please help me, Thanx > Urusla > > (Using Lyx 1.3.2 on Linux Suse 9.0) Insert->Special character->Superscript. Yes, it uses math mode... there are no text-mode super/subscripts :-( HTH Martin V pgp0.pgp Description: PGP signature
ugly latex code
Hi, I use LyX a lot to document what I have done or write short technical notes. It really saves time for me againts checking the grammar of latex code. However, there is a problem when it comes to submiting papers to journals. The equation part of the latex code exported by LyX is really ugly and hard to read. I don't dare to send the file to any journal directly but have to beautify it manually. I wonder if there is a way to do the work automatically? Thanks!. _ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx
increase Sign
Hi i have a question about lyx, which is not answered by the tutorials or user guides, or i haven't found the answer. I'm writing a bibliography and i need to increase a number (hoeherstellen eines zeichens) to signal, that it is the second Edition or so. Munich second edition 1998 = Munich 21998. And the 2 is increased. But i cannot find such a function in lyx and i'm sure, there is this function. Please help me, Thanx Urusla (Using Lyx 1.3.2 on Linux Suse 9.0) -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: LyX CVS compile error: insetlabel.C
On Mon, Feb 16, 2004 at 10:45:11PM +, Angus Leeming wrote: > Alfredo Braunstein wrote: > > There seems to be some kind of upper/lower case problem, > > src/insets/insetlabel.C should #include src/InsetList.h but it's > > wrongly including src/inset/insetlist.h in cwgwin. > > Why don't we (you) just remove this cruft from src/insets > (insettheorem too). They no longer compile, they aren't ver y complex > anyway and can always be retrieved from the Attic. Alfredo is right. Two files with the same name (except for case) don't quite work right in CygWin. I agree with Angus. Let's just remove the files. ---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: LyX CVS compile error: insetlabel.C
Alfredo Braunstein wrote: > There seems to be some kind of upper/lower case problem, > src/insets/insetlabel.C should #include src/InsetList.h but it's > wrongly including src/inset/insetlist.h in cwgwin. Why don't we (you) just remove this cruft from src/insets (insettheorem too). They no longer compile, they aren't ver y complex anyway and can always be retrieved from the Attic. -- Angus
Re: important features (2) from xforms version missing in qt version
On Mon, Feb 16, 2004 at 12:11:23PM -0800, Oliver Johns wrote: > (1) In the xforms version, the dialog box Insert:Cross_Reference has a > button Apply. It applies the reference, but does not close the dialog Done in lyx 1.4.0cvs > (2) In the xforms version, open the Insert:Cross_Reference dialog box, > select a reference and press OK. The dialog box closes. Now open the > same dialog box again. The box opens with the SAME reference selected > as just before it was closed the last time (persistance of user > > I also have a wish-list suggestion for the same dialog box. It would > be nice if the PrettyRef option selection was also persistent instead > of being reset to Ref on every re-open. That would save several > mouse clicks and drags for those of us who only use that selection. File two bugs for these. john -- "Spammers get STABBED by GOD." - Ron Echeverri
Re: Latest CVS lyx: " key does not insert quote inset
On Sat, Feb 14, 2004 at 11:06:34AM -0800, Kayvan A. Sylvan wrote:
> With the latest CVS, the quote key no longer inserts the correct
> quote inset.
>
> I always get the (") ordinary quotes, instead of the (``) and ('') quotes.
Does anyone have any leads on this one?
--
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: LyX CVS compile error: insetlabel.C
Kayvan A. Sylvan wrote: > Clean repository, Cygwin environment: > > g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src > -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include > -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF > .deps/insetlabel.Tpo -c ../../../lyx/src/insets/insetlabel.C In file > included from ../../../lyx/src/insets/insetlabel.C:19: > ../../../lyx/src/insets/InsetList.h:21: error: redefinition of `class > InsetList >' > ../../../lyx/src/InsetList.h:24: error: previous definition of `class > InsetList >' > ../../../lyx/src/insets/InsetList.h:28: error: syntax error before `::' > token ../../../lyx/src/insets/InsetList.h:30: error: semicolon missing > after >declaration of `InsetList' > ../../../lyx/src/insets/InsetList.h:30: error: extraneous `int' ignored > ../../../lyx/src/insets/InsetList.h:30: error: non-member function > `InsetList >latex(const Buffer&, std::ostream&, const OutputParams&)' cannot have >`const ' method qualifier > ../../../lyx/src/insets/InsetList.h:32: error: syntax error before `const' > In file included from ../../../lyx/src/insets/insetlabel.C:20: > ../../../lyx/src/iterators.h:40: error: `iterator' is not a member of type > ` >InsetList' > ../../../lyx/src/iterators.h:40: error: template argument 1 is invalid > ../../../lyx/src/iterators.h:40: error: ISO C++ forbids declaration of > `it' >with no type > ../../../lyx/src/insets/insetlabel.C: In function `void >::changeRefsIfUnique(BufferView&, const std::string&, const >std::string&)': > ../../../lyx/src/insets/insetlabel.C:77: error: `iterator' is not a member > of >type `InsetList' > ../../../lyx/src/insets/insetlabel.C:77: error: parse error before `=' > token ../../../lyx/src/insets/insetlabel.C:78: error: `it2' undeclared > (first use >this function) > ../../../lyx/src/insets/insetlabel.C:78: error: (Each undeclared > identifier is >reported only once for each function it appears in.) > ../../../lyx/src/insets/insetlabel.C:78: error: `end' undeclared (first > use >this function) > make[3]: *** [insetlabel.lo] Error 1 There seems to be some kind of upper/lower case problem, src/insets/insetlabel.C should #include src/InsetList.h but it's wrongly including src/inset/insetlist.h in cwgwin. Alfredo
Re: LyX CVS compile error: insetlabel.C
On Monday 16 February 2004 9:24 pm, Kayvan A. Sylvan wrote: > If these are not used, them how come they show up anyway? Because Lars was playing with them a year or so ago? > [EMAIL PROTECTED] ~/src/lyx] cvs update -dP 2>&1 | grep -v 'cvs > server' U src/insets/insetlist.C > U src/insets/insetlist.h Angus
Re: LyX CVS compile error: insetlabel.C
On Mon, Feb 16, 2004 at 12:56:41PM -0800, Kayvan A. Sylvan wrote: > On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: > > Kayvan A. Sylvan wrote: > > > > > Clean repository, Cygwin environment: > > > > Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you > > just remove them? > > That worked! > > After removing it, doing ./autogen.sh and compiling. > > Thanks, Angus. If these are not used, them how come they show up anyway? [EMAIL PROTECTED] ~/src/lyx] cvs update -dP 2>&1 | grep -v 'cvs server' U src/insets/insetlist.C U src/insets/insetlist.h ---Kayvan
Re: LyX CVS compile error: insetlabel.C
On Mon, Feb 16, 2004 at 07:31:05PM +, Angus Leeming wrote: > Kayvan A. Sylvan wrote: > > > Clean repository, Cygwin environment: > > Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you > just remove them? That worked! After removing it, doing ./autogen.sh and compiling. Thanks, Angus. ---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)
important features (2) from xforms version missing in qt version
Dear folks, These are some suggestions for your fantastically useful LyX program. If they are well-known, my apologies. The qt version seems slicker, but it has the following two unhappy differences from the xforms version. Using LyX 1.3.3 from the Debian distro. (1) In the xforms version, the dialog box Insert:Cross_Reference has a button Apply. It applies the reference, but does not close the dialog box or move the user's currently selected position in the reference list. The qt version does not have this button. (2) In the xforms version, open the Insert:Cross_Reference dialog box, select a reference and press OK. The dialog box closes. Now open the same dialog box again. The box opens with the SAME reference selected as just before it was closed the last time (persistance of user selection). In the qt version, re-opening the dialog box always resets the user selection to the top of the list. This is usually inconvenient. These two features are very important when editing long documents with a lot of references. The user often wants to enter references in a series that are close to each other in the document. The xforms version makes this easy. The qt version makes it hard. I also have a wish-list suggestion for the same dialog box. It would be nice if the PrettyRef option selection was also persistent instead of being reset to Ref on every re-open. That would save several mouse clicks and drags for those of us who only use that selection. Thank you for the program. Can't tell you how great it is! Oliver Johns
Re: LyX CVS compile error: insetlabel.C
Kayvan A. Sylvan wrote: > Clean repository, Cygwin environment: Kayvan, insets/insetlist.[Ch] are not compiled. What happens if you just remove them? -- Angus
LyX CVS compile error: insetlabel.C
Clean repository, Cygwin environment: g++ -DHAVE_CONFIG_H -I. -I../../../lyx/src/insets -I../../src -I../../../lyx/src/insets/../ -I../../../lyx/boost -I/usr/X11R6/include -O2 -fno-exceptions -W -Wall -mms-bitfields -MT insetlabel.lo -MD -MP -MF .deps/insetlabel.Tpo -c ../../../lyx/src/insets/insetlabel.C In file included from ../../../lyx/src/insets/insetlabel.C:19: ../../../lyx/src/insets/InsetList.h:21: error: redefinition of `class InsetList ' ../../../lyx/src/InsetList.h:24: error: previous definition of `class InsetList ' ../../../lyx/src/insets/InsetList.h:28: error: syntax error before `::' token ../../../lyx/src/insets/InsetList.h:30: error: semicolon missing after declaration of `InsetList' ../../../lyx/src/insets/InsetList.h:30: error: extraneous `int' ignored ../../../lyx/src/insets/InsetList.h:30: error: non-member function `InsetList latex(const Buffer&, std::ostream&, const OutputParams&)' cannot have `const ' method qualifier ../../../lyx/src/insets/InsetList.h:32: error: syntax error before `const' In file included from ../../../lyx/src/insets/insetlabel.C:20: ../../../lyx/src/iterators.h:40: error: `iterator' is not a member of type ` InsetList' ../../../lyx/src/iterators.h:40: error: template argument 1 is invalid ../../../lyx/src/iterators.h:40: error: ISO C++ forbids declaration of `it' with no type ../../../lyx/src/insets/insetlabel.C: In function `void ::changeRefsIfUnique(BufferView&, const std::string&, const std::string&)': ../../../lyx/src/insets/insetlabel.C:77: error: `iterator' is not a member of type `InsetList' ../../../lyx/src/insets/insetlabel.C:77: error: parse error before `=' token ../../../lyx/src/insets/insetlabel.C:78: error: `it2' undeclared (first use this function) ../../../lyx/src/insets/insetlabel.C:78: error: (Each undeclared identifier is reported only once for each function it appears in.) ../../../lyx/src/insets/insetlabel.C:78: error: `end' undeclared (first use this function) make[3]: *** [insetlabel.lo] Error 1 The configuration: Configuration Host type: i686-pc-cygwin Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.3.1) C++ Compiler flags: -O2 -fno-exceptions -W -Wall -mms-bitfields Linker flags:-Wl,--export-all-symbols XForms Frontend: libXpm version: 4.11 libforms version: 1.0.0 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx -- 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: [patch] tmp file stuff
Jean-Marc Lasgouttes wrote: > To be more precise, there are currently some bugs with for example dvi > or html export which can only be worked around by not using a tempdir. > So before forcing everyone to use a tempdir, I would like to > understand how are these things going to be handled. In particular, I > am not sure I understand what is the new philosophy for the include > inset. When I asked some time ago the only bug that somebody (you?) mentioned was dvi export. Bugzilla has bugs 643 and 1405 about html export. I thought that the "run in original dir" flag was used for html converters? I guess that if this flag is honoured correctly html export should also work with a temp dir, putting the generated files deliberately not in the tmp dir. > Georg, could you outline what will be before/after situation for the > various insets when using a temp dir? The current situation is a problem because in the case of not using a tempdir a) some files that are definitely temporary are created in the working directory (btw usually without checking if existing files are overwritten) and b) we have to handle too many combinations of "nice file" and "using a temp dir" at different places. The clean solution would be to have only "using a temp dir and no nice file" vs. "using no temp dir and nice file". I used your patch on http://bugzilla.lyx.org/show_bug.cgi?id=605 and adapted it. The basic idea is that include, external and graphic insets put their files into the master buffer's temp dir. This is possible if all filenames are mangled. Then these insets write relative pathnames to the .tex file. This makes it possible to copy the .dvi file + graphics afterwards. In addition, the external and graphics insets write their files into a list that in the case of dvi export is then used to copy all files from the master buffer's temp dir to the final destination. I have a working version of all this. The only known bug so far is that the dvi export fails if two included files include the same graphic, but I believe I know the source and that I can fix it. > Something we could maybe do for now is merge all the stuff in the > patch that is straightforward... I thought that sending everything at once makes it difficult to understand the whole thing. Applying first the tempdir part and after that the inset changes is easy, but the other way round would be more difficult, because the latter depends on the first. Georg
Re: [patch] tmp file stuff
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> I believe it can, if the disk is full. This happened to me two Georg> weeks ago, although I always thought that it never will ;-( I understand now why you insist that this should be done :) JMarc
Re: [patch] tmp file stuff
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >>> But can this really happen, or is it just a theoretical question? Angus> (Aside: as a mathematician, I though you found theory Angus> important?) Jean-Marc> Well as somebody who does modeling, I start by doing the Jean-Marc> computations in an informal way, and if it leads me to some Jean-Marc> interesting result, then I care about actually proving Jean-Marc> things. This is probably analog to the 'premature Jean-Marc> optimization' mantra for programming... To be more precise, there are currently some bugs with for example dvi or html export which can only be worked around by not using a tempdir. So before forcing everyone to use a tempdir, I would like to understand how are these things going to be handled. In particular, I am not sure I understand what is the new philosophy for the include inset. Georg, could you outline what will be before/after situation for the various insets when using a temp dir? Something we could maybe do for now is merge all the stuff in the patch that is straightforward... JMarc
Re: [patch] tmp file stuff
Angus Leeming wrote: > Georg Baum wrote: > >> Do you mean that exiting from within the buffer constructor is ok? >> This would be easy. > > Given the mantra "lyx should never crash", I'd prefer it if lyx just > refused to construct the buffer. We don't use exceptions, so I guess That was my initial plan. > that means that the buffer constructor must be wrapped inside a > function. > > I guess that this is a lot of work, right? I think so. Georg
Re: [patch] tmp file stuff
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Given the mantra "lyx should never crash", I'd prefer it if lyx > Angus> just refused to construct the buffer. We don't use exceptions, > Angus> so I guess that means that the buffer constructor must be > Angus> wrapped inside a function. > > But can this really happen, or is it just a theoretical question? I believe it can, if the disk is full. This happened to me two weeks ago, although I always thought that it never will ;-( But I agree that the probability is very small. Georg
Re: [patch] tmp file stuff
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: >> But can this really happen, or is it just a theoretical question? Angus> (Aside: as a mathematician, I though you found theory Angus> important?) Well as somebody who does modeling, I start by doing the computations in an informal way, and if it leads me to some interesting result, then I care about actually proving things. This is probably analog to the 'premature optimization' mantra for programming... JMarc
Re: [patch] tmp file stuff
On Mon, Feb 16, 2004 at 02:07:30PM +, Angus Leeming wrote: > Jean-Marc Lasgouttes wrote: > > But can this really happen, or is it just a theoretical question? > > (Aside: as a mathematician, I though you found theory important?) > > The simple answer is: I don't know. It's hard to imagine such a case > isn't it. Simple solution: Simply let it crash if we don't know how to fix it within LyX. Andre'
Re: [patch] tmp file stuff
Jean-Marc Lasgouttes wrote: > But can this really happen, or is it just a theoretical question? (Aside: as a mathematician, I though you found theory important?) The simple answer is: I don't know. It's hard to imagine such a case isn't it. -- Angus
Re: [patch] more coords
On Mon, Feb 16, 2004 at 02:05:54PM +0100, Alfredo Braunstein wrote: > Switch to absolute coordinates in LyXText::setCursorFromCoords > > actually cures a bit of problems as we assumed that this was done already in > some places. This certainly looks good. Andre'
[patch] more coords
Switch to absolute coordinates in LyXText::setCursorFromCoords
actually cures a bit of problems as we assumed that this was done already in
some places.
Alfredo
? ChangeLog-old
? PosIterator.C-save
? PosIterator.h-save
? bfri.C
? textcursor.C-save
? textcursor.h-save
? insets/insetcollapsable-save.C
? insets/insettext-save.C
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.548
diff -u -p -u -r1.548 text2.C
--- text2.C 16 Feb 2004 11:58:42 - 1.548
+++ text2.C 16 Feb 2004 12:36:44 -
@@ -1293,9 +1293,11 @@ pos_type LyXText::getColumnNearX(Paragra
}
-// x,y are coordinates relative to this LyXText
+// x,y are absolute coordinates
void LyXText::setCursorFromCoordinates(LCursor & cur, int x, int y)
{
+ x -= xo_;
+ y -= yo_;
CursorSlice old_cursor = cur.current();
ParagraphList::iterator pit;
Row const & row = *getRowNearY(y, pit);
@@ -1468,7 +1470,7 @@ void LyXText::cursorUp(LCursor & cur, bo
Row const & row = cur.textRow();
int x = cur.x_target();
int y = cursorY(cur.current()) - row.baseline() - 1;
- setCursorFromCoordinates(cur, x - xo_, y - yo_);
+ setCursorFromCoordinates(cur, x, y);
if (!selecting) {
InsetBase * inset_hit = checkInsetHit(cur.x_target(), y);
@@ -1483,7 +1485,7 @@ void LyXText::cursorDown(LCursor & cur,
Row const & row = cur.textRow();
int x = cur.x_target();
int y = cursorY(cur.current()) - row.baseline() + row.height() + 1;
- setCursorFromCoordinates(cur, x - xo_, y - yo_);
+ setCursorFromCoordinates(cur, x, y);
if (!selecting) {
InsetBase * inset_hit = checkInsetHit(cur.x_target(), y);
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.226
diff -u -p -u -r1.226 text3.C
--- text3.C 16 Feb 2004 11:58:45 - 1.226
+++ text3.C 16 Feb 2004 12:36:46 -
@@ -1147,7 +1147,7 @@ DispatchResult LyXText::dispatch(LCursor
// Clear the selection
cur.clearSelection();
- setCursorFromCoordinates(cur, cmd.x - xo_, cmd.y - yo_);
+ setCursorFromCoordinates(cur, cmd.x, cmd.y);
cur.resetAnchor();
finishUndo();
cur.x_target() = cursorX(cur.current());
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.239
diff -u -p -u -r1.239 insetcollapsable.C
--- insets/insetcollapsable.C 16 Feb 2004 11:58:46 - 1.239
+++ insets/insetcollapsable.C 16 Feb 2004 12:36:49 -
@@ -311,11 +311,6 @@ InsetBase * InsetCollapsable::editXY(LCu
//inset yet. I personally think it's ok. (ab)
return this;
}
-
-//if (y <= yo() + inset.ascent() + button_dim.y2)
-// y = yo();
-//else
-// y += inset.ascent() - height_collapsed();
return inset.editXY(cur, x, y);
}
Re: [patch] tmp file stuff
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Georg Baum wrote: >>> The buffer tmp dirs are sub directories of LyXTmpDir. If you can >>> create LyXTmpDir yet fail to create BufferTmpDir then I suspect >>> that lyx should refuse to open the buffer and should probably exit >>> with a very loud complaint. >> Do you mean that exiting from within the buffer constructor is ok? >> This would be easy. Angus> Given the mantra "lyx should never crash", I'd prefer it if lyx Angus> just refused to construct the buffer. We don't use exceptions, Angus> so I guess that means that the buffer constructor must be Angus> wrapped inside a function. But can this really happen, or is it just a theoretical question? JMarc
Re: [patch] tmp file stuff
Georg Baum wrote: >> The buffer tmp dirs are sub directories of LyXTmpDir. If you can >> create LyXTmpDir yet fail to create BufferTmpDir then I suspect >> that lyx should refuse to open the buffer and should probably exit >> with a very loud complaint. > > Do you mean that exiting from within the buffer constructor is ok? > This would be easy. Given the mantra "lyx should never crash", I'd prefer it if lyx just refused to construct the buffer. We don't use exceptions, so I guess that means that the buffer constructor must be wrapped inside a function. I guess that this is a lot of work, right? -- Angus
Re: [patch] tmp file stuff
On Sunday 15 February 2004 21:22, Georg Baum wrote: [...] > The patch furthermore makes some functions const (a leftover from some > earlier experiments, but it cannot hurt), some other minor changes and > removes the version check of insetgraphics. It is not needed anymore, > because lyx2lyx handles this. > > Things that might be wrong: > - Is it ok to read in the lyxrc use_tempdir flag for compatibility > reasons, and then ignore it silently? > - José, could you check that I got the docbook part in insetinclude > right? It seems so, I don't have time now to test the code but from reading the source I have no objections. > - The wording of the error message in lyx_main.C can probably be > improved. > > If this is ok, can somebody please apply it? > > > Georg -- José Abílio LyX and docbook, a perfect match. :-)
Re: Latest CVS lyx-xforms: crash on startup
On Mon, Feb 16, 2004 at 12:51:23PM +0100, Jean-Marc Lasgouttes wrote: > I can confirm this. Andre', here is a part of the relevant backtrace, > without debug info, but the problem seems clear enough: Fixed. Andre'
Re: [patch] tmp file stuff
Angus Leeming wrote: > Georg Baum wrote: >> I found no clean and easy way to make >> CreateBufferTmpDir() always succeed, so I gave up on that. However, >> I made CreateLyXTmpDir() always succeed by exiting if the temp dir >> could not be created. > > The buffer tmp dirs are sub directories of LyXTmpDir. If you can > create LyXTmpDir yet fail to create BufferTmpDir then I suspect that > lyx should refuse to open the buffer and should probably exit with a > very loud complaint. Do you mean that exiting from within the buffer constructor is ok? This would be easy. Georg
Re: Latest CVS lyx-xforms: crash on startup
On Mon, Feb 16, 2004 at 12:59:19PM +0100, Andre' Poenitz wrote: > On Mon, Feb 16, 2004 at 12:51:23PM +0100, Jean-Marc Lasgouttes wrote: > > > "Ling" == Ling Li <[EMAIL PROTECTED]> writes: > > > > Ling> On Fedora Linux 1, kernel 2.6, configured with --disable-debug > > Ling> --enable-compression-support --with-aspell --disable-warnings > > Ling> --disable-assertions --with-frontend="xforms qt" > > > > Ling> Compiled OK. lyx-xforms crashes several seconds after startup. > > Ling> Nothing needs to be done. > > > > I can confirm this. > > I can't. Opps, sorry. I can. I missed the 'no buffer' part. I'll fix this ASAP. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: Latest CVS lyx-xforms: crash on startup
On Mon, Feb 16, 2004 at 12:51:23PM +0100, Jean-Marc Lasgouttes wrote: > > "Ling" == Ling Li <[EMAIL PROTECTED]> writes: > > Ling> On Fedora Linux 1, kernel 2.6, configured with --disable-debug > Ling> --enable-compression-support --with-aspell --disable-warnings > Ling> --disable-assertions --with-frontend="xforms qt" > > Ling> Compiled OK. lyx-xforms crashes several seconds after startup. > Ling> Nothing needs to be done. > > I can confirm this. I can't. After what time will this happen? > Andre', here is a part of the relevant backtrace, > without debug info, but the problem seems clear enough: > > Program received signal SIGSEGV, Segmentation fault. > 0x08156065 in LyXText::bv() () > (gdb) bt > #0 0x08156065 in LyXText::bv() () > #1 0x0815d64e in LyXText::currentState(LCursor&) () > #2 0x080cc9bc in LCursor::currentState() () > #3 0x08334fdc in ControlCommandBuffer::getCurrentState() const () > #4 0x08296e68 in XMiniBuffer::idle_timeout() () > > So I guess that at some point the code needs to check whether there is > a document loaded. However, I do not know the philosophy of the new > code well enough to guess where to add a check. Probably in #3 or #4 above... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: Latest CVS lyx-xforms: crash on startup
> "Ling" == Ling Li <[EMAIL PROTECTED]> writes: Ling> On Fedora Linux 1, kernel 2.6, configured with --disable-debug Ling> --enable-compression-support --with-aspell --disable-warnings Ling> --disable-assertions --with-frontend="xforms qt" Ling> Compiled OK. lyx-xforms crashes several seconds after startup. Ling> Nothing needs to be done. I can confirm this. Andre', here is a part of the relevant backtrace, without debug info, but the problem seems clear enough: Program received signal SIGSEGV, Segmentation fault. 0x08156065 in LyXText::bv() () (gdb) bt #0 0x08156065 in LyXText::bv() () #1 0x0815d64e in LyXText::currentState(LCursor&) () #2 0x080cc9bc in LCursor::currentState() () #3 0x08334fdc in ControlCommandBuffer::getCurrentState() const () #4 0x08296e68 in XMiniBuffer::idle_timeout() () So I guess that at some point the code needs to check whether there is a document loaded. However, I do not know the philosophy of the new code well enough to guess where to add a check. JMarc
Re: [patch] IU...
On Mon, Feb 16, 2004 at 11:03:39AM +0100, Andre' Poenitz wrote: > This brings tabulars back from zombie state to 'staggering zombie' > state. Left/Right should work, even (partially) with selection, up/down > crashes (most of the time...) I forgot to add: This also removes almost all of the remaining 'update'-related scary parts (yes, there was some left...) from InsetTabular which means that tabular code should now be readable. Andre'
[patch] IU...
This brings tabulars back from zombie state to 'staggering zombie'
state. Left/Right should work, even (partially) with selection, up/down
crashes (most of the time...)
This also changes the signature of the InsetFoo::priv_dispatch
functions. By assuming a 'default return' of 'DispatchResult(true,
true)' quite a bit of clutter is removed from the funcition.
[Lots of 'return DispatchResult(true, true)' simply become 'break;']
Only InsetBase::priv_dispatch() and some 'semi-handled' events will
need to notify the dispatch mechanism that something was _not_ handled.
[In fact, I'd think most of the semi-handled stuff is currently handled
wrong. Look at InsetLabel, LFUN_INSET_MODIFY:
case LFUN_INSET_MODIFY: {
InsetCommandParams p;
InsetCommandMailer::string2params("label", cmd.argument, p);
if (p.getCmdName().empty()) {
// why should we act differently on empty labels? ***
cur.notdispatched();
break;
}
if (p.getContents() != params().getContents())
changeRefsIfUnique(cur.bv(), params().getContents(),
p.getContents());
setParams(p);
Reason for 'streamlining' priv_dispatch is to move the math specific
idxLeft/Up/Down etc from LCursor to 'proper' LFUN handling in the
individual math insets (currently, MathNestInset catches all cursor
movement and diverts them to LCursor math specific code. No good IU...]
Andre'
1.diff.gz
Description: application/gunzip
Re: Just in case this code leaks to the public...
On Sat, Feb 14, 2004 at 07:45:50PM +0200, Martin Vermeer wrote: > - // FIXME: goddamn InsetTabular makes us pass a Buffer > + // FIXME: InsetTabular makes us pass a Buffer What's wrong with precise decriptions of problems? Andre'
Re: [patch] selection inside insets
On Mon, Feb 16, 2004 at 10:18:07AM +0100, Alfredo Braunstein wrote: > intermediate lines are not showing blue. Thanks. Andre'
[patch] selection inside insets
intermediate lines are not showing blue. Alfredo Index: ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v retrieving revision 1.1807 diff -u -p -u -r1.1807 ChangeLog --- ChangeLog 15 Feb 2004 20:05:16 - 1.1807 +++ ChangeLog 16 Feb 2004 09:15:44 - @@ -1,3 +1,7 @@ +2004-02-16 Alfredo Braunstein <[EMAIL PROTECTED]> + + * rowpainter.C (paintSelection): coord fix + 2004-02-15 Georg Baum <[EMAIL PROTECTED]> * Spacing.C: compile fix Index: rowpainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v retrieving revision 1.117 diff -u -p -u -r1.117 rowpainter.C --- rowpainter.C11 Feb 2004 14:45:40 - 1.117 +++ rowpainter.C16 Feb 2004 09:15:45 - @@ -405,7 +405,7 @@ void RowPainter::paintSelection() RowList::iterator endrow = endpit->getRow(cur.selEnd().pos()); int const h = row_.height(); - int const row_y = pit_->y + row_.y_offset(); + int const row_y = text_.yo_ + pit_->y + row_.y_offset(); bool const sel_starts_here = startpit == pit_ && startrow == rit_; bool const sel_ends_here = endpit == pit_ && endrow == rit_;
