CVS lyx: insert math inset -> crash
Fresh CVS lyx compile. 1. Start lyx 2. C-n (New buffer) 3. C-m (Math inset) lyx crashes Here is the output on the console: [EMAIL PROTECTED] ~] lyx *** workAreaDispatch: request: action: 216 arg: '' x: 325 y: 217 *** workAreaDispatch: request: action: 217 arg: '' x: 325 y: 217 *** workAreaDispatch: request: action: 218 arg: '' x: 325 y: 217 top_y: 0 y: 0 Redraw screen BufferView::Pimpl::fitCursor. LCursor::getPos: x: 56 y: 13 LyXScreen::fitCursor: x: 56 y: 13 top_y: 0 top_y: 0 y: 0 Redraw screen LCursor::getPos: x: 56 y: 13 LCursor::getPos: x: 56 y: 13 trying to dispatch to main text 0x10212b60 Called FormulaBase::edit LCursor::push() inset: 0x10215f98 *** MathHullInset: request: action: 114 arg: 'simple' x: 0 y: 0 Hull: MUTATE: simple mutating from 'none' to 'simple' mutating from 'simple' to 'simple' *** MathHullInset: request: action: 103 arg: '' x: 0 y: 0 *** MathGridInset: request: action: 103 arg: '' x: 0 y: 0 *** MathNestInset: request: action: 103 arg: '' x: 0 y: 0 cursor: (inset: 0 text: 0 idx: 0 par: 0 pos: 0 | inset: 0 text: 0 idx: 0 par: 0 pos: 0 (inset: 0x10215f98 text: 0 idx: 0 par: 0 pos: 0 | inset: 0x10215f98 text: 0 idx: 0 par: 0 pos: 0 current: 1 text: 0 this: 0x10212b60 Assertion triggered in CursorSlice& LyXText::cursor() by failing check "false" in file ../../lyx/src/text.C:1943 Aborted (core dumped) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: [PATCH] lyx2lyx encoding warnings
Jose' Matos wrote: >> some time ago you fixed some python encoding warnings in lyx2lyx. >> However, it seems that the encoding needs to be specified not only in the >> main file, but also in the imported modules. >> The attached patch adds the encoding to every python file in lyx2lyx. >> The patch is against 1.4, but it probably applies to 1.3 with little >> modifications. > > The patch is ok and should also apply to 1.3, if can commit it or else I > will do it tomorrow afternoon as I'm busy now. Applied to 1.4cvs Alfredo
Fix bugs 605, 1231, and 1244
See http://bugzilla.lyx.org/show_bug.cgi?id=605,
http://bugzilla.lyx.org/show_bug.cgi?id=1231 and
http://bugzilla.lyx.org/show_bug.cgi?id=1244 for details of these bugs.
With help from discussion on this list and using Jean-Marcs old patch for
bug 605 I believe I have fixed bugs 605, 1231, and 1244. What I did was:
1. Remove the choice of having a tmp dir, use it always
2. Rework insetgraphics, insetinclude and insetexternal to
- output all generated files in the master buffer's tmp dir
- output relative filenames in latex if latex is run
and some minor supporting stuff.
I would like to get this in in two steps, but first the following problems
need to be solved:
I currently have in Buffer::Impl::Impl() after creating the tmp dir:
temppath = CreateBufferTmpDir();
if (temppath.empty()) {
Alert::error(_("Could not create a temporary directory"),
bformat(_("Could not create a temporary directory in\n"
"%1$s. Make sure that this\n"
"path exists and is writable "
"and try again."),
os::getTmpDir()));
// Don't load the document if we have no temp dir.
// FIXME: Does this work?
filename.erase();
filepath.erase();
}
I want to guarantee that temppath() is valid (this check is currently done
in some places where it is used, but in other places it is assumed that it
is valid). However, I am not sure wether the above works. Has anybody a
better idea?
Similar in LyX::init():
os::setTmpDir(CreateLyXTmpDir(lyxrc.tempdir_path));
if (os::getTmpDir().empty()) {
//FIXME: Better error message, don't exit but make sure that
//no files can be loaded.
Alert::error(_("Could not create temporary directory"),
bformat(_("Could not create a temporary directory in\n"
"%1$s. Make sure that this\n"
"path exists and is writable and try again."),
lyxrc.tempdir_path));
exit(1);
}
This is certainly too brutal. How can I make sure that no files can be
loaded, but for example the temp path setting can be corrected?
Georg
[patch] trivial fix
Index: lyxfind.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfind.C,v
retrieving revision 1.72
diff -u -p -u -r1.72 lyxfind.C
--- lyxfind.C 31 Jan 2004 15:30:21 - 1.72
+++ lyxfind.C 2 Feb 2004 20:40:58 -
@@ -123,7 +123,7 @@ void find(BufferView * bv, FuncRequest c
bool forward = parse_bool(howto);
bool const found = ::find(bv, search,
- forward, casesensitive, matchword);
+ casesensitive, matchword, forward);
if (!found)
bv->owner()->message(_("String not found!"));
[patch] re-add bv::dispatch call
it has been removed for some reason. Don't know if this is the correct place to put it though... Alfredo Index: BufferView_pimpl.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v retrieving revision 1.496 diff -u -p -u -r1.496 BufferView_pimpl.C --- BufferView_pimpl.C 2 Feb 2004 17:32:54 - 1.496 +++ BufferView_pimpl.C 2 Feb 2004 20:19:20 - @@ -1212,7 +1212,7 @@ bool BufferView::Pimpl::dispatch(FuncReq break; default: - return cur.dispatch(cmd).dispatched(); + return false; } return true; Index: lyxfunc.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v retrieving revision 1.565 diff -u -p -u -r1.565 lyxfunc.C --- lyxfunc.C 2 Feb 2004 11:07:50 - 1.565 +++ lyxfunc.C 2 Feb 2004 20:19:23 - @@ -1438,7 +1438,9 @@ void LyXFunc::dispatch(FuncRequest const break; default: - view()->cursor().dispatch(cmd); + DispatchResult res = view()->cursor().dispatch(cmd); + if (!res.dispatched()); +view()->dispatch(cmd); break; } }
Re: Lyx is overrideing Layout-Preferences
Juergen Spitzmueller wrote: > > I saw it too late! Could you experiment with those variables (also > > LC_MONETARY, maybe)? I cannot find any reference about what > > LC_MEASUREMENT does... > > Not very much ATM. Well I did it nevertheless. LC_NUMERIC is to blame AFAICS. Setting this variable to en_US solves the problem. All of the others I have tried do not change anything. Jürgen.
Re: Lyx is overrideing Layout-Preferences
Am Montag, 02. Februar 2004 17:36 schrieb Jean-Marc Lasgouttes: > Juergen> Yes, see my previous mail (i guess either LC_NUMERIC or > Juergen> LC_MEASUREMENT are to blame). > > I saw it too late! Could you experiment with those variables (also > LC_MONETARY, maybe)? I cannot find any reference about what > LC_MEASUREMENT does... Not very much ATM. I have to prepare a talk. But I can have a look after this week. What should I do? just set those variables to en_US and see which one triggers the bug? (I have no idea what we are looking for). Jürgen.
Re: Lyx is overrideing Layout-Preferences
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> Do you have any LC_* variables set? Juergen> Yes, see my previous mail (i guess either LC_NUMERIC or Juergen> LC_MEASUREMENT are to blame). I saw it too late! Could you experiment with those variables (also LC_MONETARY, maybe)? I cannot find any reference about what LC_MEASUREMENT does...
Re: Lyx is overrideing Layout-Preferences
Jean-Marc Lasgouttes wrote: > Do you have any LC_* variables set? Yes, see my previous mail (i guess either LC_NUMERIC or LC_MEASUREMENT are to blame). Jürgen
Re: Lyx is overrideing Layout-Preferences
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Jean-Marc Lasgouttes wrote: >> What are the environment variables that are set when you change >> your environment? Juergen> Which ones? Default LANG is [EMAIL PROTECTED] Do you have any LC_* variables set? >> I do not understand how LANG can change the writing of numbers? Juergen> Me neither. Note that this is an xforms specific problem. Yes, we had some of these in the past with xforms... It does the setting of locales, which IMO is a big mistake. JMarc
Re: Lyx is overrideing Layout-Preferences
Am Montag, 02. Februar 2004 15:57 schrieb Juergen Spitzmueller: > > What are the environment variables that are set when you change your > > environment? > > Which ones? OK, this is the output of locale before switching LANG to en_US: [EMAIL PROTECTED] LC_CTYPE="[EMAIL PROTECTED]" LC_NUMERIC="[EMAIL PROTECTED]" LC_TIME="[EMAIL PROTECTED]" LC_COLLATE=POSIX LC_MONETARY="[EMAIL PROTECTED]" LC_MESSAGES="[EMAIL PROTECTED]" LC_PAPER="[EMAIL PROTECTED]" LC_NAME="[EMAIL PROTECTED]" LC_ADDRESS="[EMAIL PROTECTED]" LC_TELEPHONE="[EMAIL PROTECTED]" LC_MEASUREMENT="[EMAIL PROTECTED]" LC_IDENTIFICATION="[EMAIL PROTECTED]" LC_ALL= and after: LANG=en_US LC_CTYPE="en_US" LC_NUMERIC="en_US" LC_TIME="en_US" LC_COLLATE=POSIX LC_MONETARY="en_US" LC_MESSAGES="en_US" LC_PAPER="en_US" LC_NAME="en_US" LC_ADDRESS="en_US" LC_TELEPHONE="en_US" LC_MEASUREMENT="en_US" LC_IDENTIFICATION="en_US" LC_ALL= HTH, Jürgen.
Re: Lyx is overrideing Layout-Preferences
Jean-Marc Lasgouttes wrote: > What are the environment variables that are set when you change your > environment? Which ones? Default LANG is [EMAIL PROTECTED] > I do not understand how LANG can change the writing of > numbers? Me neither. Note that this is an xforms specific problem. > What Linux is that? SUSE? Yes. SuSE 8.2 Jürgen.
Re: Lyx is overrideing Layout-Preferences
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Alfredo Braunstein wrote: >> Could it be a locale problem? Juergen> Yes, seems so. The problem disappears when I switch LANG to Juergen> en_US. What are the environment variables that are set when you change your environment? I do not understand how LANG can change the writing of numbers? What Linux is that? SUSE? JMarc
[PATCH] don't overwrite unzipped files for graphics preview
The graphics cache decompresses zipped files in place for preview, that
means it will overwrite a.eps without warning if a.eps.gz is included in
the LyX file.
The attached patch changes that: The unzipped file is put into the temp dir.
The patch is against 1.4, but a similar one should work for 1.3, too.
GeorgIndex: src/graphics/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/ChangeLog,v
retrieving revision 1.199
diff -u -r1.199 ChangeLog
--- src/graphics/ChangeLog 2004/01/31 15:30:23 1.199
+++ src/graphics/ChangeLog 2004/02/02 13:10:17
@@ -1,3 +1,8 @@
+2004-02-02 Georg Baum <[EMAIL PROTECTED]>
+
+ * GraphicsCacheItem.C (convertToDisplayFormat): unzip zipped files
+ to a temporary file
+
2004-01-31 Lars Gullik Bjonnes <[EMAIL PROTECTED]>
* PreviewLoader.C (FindFirst): inherit from std::unary_function
Index: src/graphics/GraphicsCacheItem.C
===
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsCacheItem.C,v
retrieving revision 1.60
diff -u -r1.60 GraphicsCacheItem.C
--- src/graphics/GraphicsCacheItem.C 2003/10/06 15:42:58 1.60
+++ src/graphics/GraphicsCacheItem.C 2004/02/02 13:10:17
@@ -35,6 +39,7 @@
using support::getExtFromContents;
using support::tempName;
using support::unlink;
+using support::unzippedFileName;
using support::unzipFile;
using support::zippedFile;
@@ -381,8 +387,13 @@
}
// Make a local copy in case we unzip it
- string const filename = zippedFile(filename_) ?
- unzipFile(filename_) : filename_;
+ string filename;
+ if ((zipped_ = zippedFile(filename_))) {
+ unzipped_filename_ = tempName(string(), filename_);
+ filename = unzipFile(filename_, unzipped_filename_);
+ } else
+ filename = filename_;
+
string const displayed_filename = MakeDisplayPath(filename_);
lyxerr[Debug::GRAPHICS] << "[GrahicsCacheItem::convertToDisplayFormat]\n"
<< "\tAttempting to convert image file: " << filename
@@ -412,6 +423,7 @@
remove_loaded_file_ = true;
// Remove the temp file, we only want the name...
+ // FIXME: This is unsafe!
unlink(to_file_base);
// Connect a signal to this->imageConverted and pass this signal to
Index: src/support/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.237
diff -u -r1.237 ChangeLog
--- src/support/ChangeLog 2004/02/01 12:46:13 1.237
+++ src/support/ChangeLog 2004/02/02 13:20:14
@@ -1,3 +1,7 @@
+2004-02-02 Georg Baum <[EMAIL PROTECTED]>
+
+ * filetools.[Ch] (unzipFile): add unzipped_file parameter
+
2004-02-01 Lars Gullik Bjonnes <[EMAIL PROTECTED]>
* lstrings.h (contains_functor): delete
Index: src/support/filetools.C
===
RCS file: /cvs/lyx/lyx-devel/src/support/filetools.C,v
retrieving revision 1.176
diff -u -r1.176 filetools.C
--- src/support/filetools.C 2003/10/16 16:41:32 1.176
+++ src/support/filetools.C 2004/02/02 13:10:28
@@ -1080,9 +1080,10 @@
}
-string const unzipFile(string const & zipped_file)
+string const unzipFile(string const & zipped_file, string const & unzipped_file)
{
- string const tempfile = unzippedFileName(zipped_file);
+ string const tempfile = unzipped_file.empty() ?
+ unzippedFileName(zipped_file) : unzipped_file;
// Run gunzip
string const command = "gunzip -c " + zipped_file + " > " + tempfile;
Systemcall one;
Index: src/support/filetools.h
===
RCS file: /cvs/lyx/lyx-devel/src/support/filetools.h,v
retrieving revision 1.53
diff -u -r1.53 filetools.h
--- src/support/filetools.h 2003/10/06 15:43:18 1.53
+++ src/support/filetools.h 2004/02/02 13:10:28
@@ -141,11 +141,18 @@
/// check for zipped file
bool zippedFile(std::string const & name);
-/// \return the name that LyX will give to the unzipped file.
+/** \return the name that LyX will give to the unzipped file \p zipped_file
+ if the second argument of unzipFile() is empty.
+ */
std::string const unzippedFileName(std::string const & zipped_file);
-/// unzip a file
-std::string const unzipFile(std::string const & zipped_file);
+/** Unzip \p zipped_file.
+ The unzipped file is named \p unzipped_file if \p unzipped_file is not
+ empty, and unzippedFileName(\p zipped_file) otherwise.
+ Will overwrite an already existing unzipped file without warning.
+ */
+std::string const unzipFile(std::string const & zipped_file,
+std::string const & unzipped_file = std::string());
/// Returns true is path is absolute
bool AbsolutePath(std::string const & path);
Re: Lyx is overrideing Layout-Preferences
Alfredo Braunstein wrote: > Could it be a locale problem? Yes, seems so. The problem disappears when I switch LANG to en_US. Jürgen.
[patch] findText
This replaces findText with BOOST_ASSERTs and even survives File->New.
Btw, is there a nicer way to write
+ if (this != bv()->cursor().text()) {
+ lyxerr << "cursor: " << bv()->cursor()
+ << "\ntext: " << bv()->cursor().text()
+ << "\nthis: " << this << endl;
+ BOOST_ASSERT(false);
+ }
Something like
+ BOOST_ASSERT(this != bv()->cursor().text())
+ << "cursor: " << bv()->cursor()
+ << "\ntext: " << bv()->cursor().text()
+ << "\nthis: " << this << endl;
or similar?
It seems to be a macro already, so why is it not "nice"?
Andre'
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.494
diff -u -p -r1.494 BufferView_pimpl.C
--- BufferView_pimpl.C 2 Feb 2004 11:07:48 - 1.494
+++ BufferView_pimpl.C 2 Feb 2004 12:55:14 -
@@ -905,7 +902,7 @@ bool BufferView::Pimpl::workAreaDispatch
if (inset) {
res = inset->dispatch(cur, cmd);
} else {
- res = cur.innerText()->dispatch(cur, cmd);
+ res = bv_->text()->dispatch(cur, cmd);
}
if (bv_->fitCursor() || res.update()) {
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.41
diff -u -p -r1.41 cursor.C
--- cursor.C30 Jan 2004 11:40:57 - 1.41
+++ cursor.C2 Feb 2004 12:55:14 -
@@ -474,6 +474,12 @@ void LCursor::clearTargetX()
}
+LyXText * LCursor::text() const
+{
+ return current_ ? current().text() : bv_->text();
+}
+
+
Paragraph & LCursor::paragraph()
{
return current_ ? current().paragraph() : *bv_->text()->getPar(par());
@@ -723,7 +729,7 @@ std::ostream & operator<<(std::ostream &
os << "\n";
for (size_t i = 0, n = cur.cursor_.size(); i != n; ++i)
os << " (" << cur.cursor_[i] << " | " << cur.anchor_[i] << "\n";
- return os;
+ return os << "current: " << cur.current_ << endl;
}
@@ -1705,7 +1711,7 @@ CursorSlice LCursor::normalAnchor()
}
//lyx::BOOST_ASSERT(Anchor_.size() >= cursor.depth());
// use Anchor on the same level as Cursor
- CursorSlice normal = anchor_[depth() - 1];
+ CursorSlice normal = anchor_[current_];
#if 0
if (depth() < anchor_.size() && !(normal < xx())) {
// anchor is behind cursor -> move anchor behind the inset
Index: cursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.h,v
retrieving revision 1.24
diff -u -p -r1.24 cursor.h
--- cursor.h30 Jan 2004 11:40:57 - 1.24
+++ cursor.h2 Feb 2004 12:55:14 -
@@ -201,6 +201,8 @@ public:
///
Paragraph const & paragraph() const;
///
+ LyXText * text() const;
+ ///
InsetBase * innerInsetOfType(int code) const;
///
InsetTabular * innerInsetTabular() const;
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.284
diff -u -p -r1.284 lyxtext.h
--- lyxtext.h 30 Jan 2004 11:40:59 - 1.284
+++ lyxtext.h 2 Feb 2004 12:55:14 -
@@ -391,10 +391,6 @@ public:
CursorSlice & cursor();
/// the topmost cursor slice
CursorSlice const & cursor() const;
- /// access to the selection anchor
- CursorSlice & anchor();
- /// access to the selection anchor
- CursorSlice const & anchor() const;
friend class LyXScreen;
Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.111
diff -u -p -r1.111 rowpainter.C
--- rowpainter.C30 Jan 2004 11:40:59 - 1.111
+++ rowpainter.C2 Feb 2004 12:55:14 -
@@ -136,8 +136,9 @@ RowPainter::RowPainter(BufferView const
paintBackground();
// paint the selection background
- if (bv_.cursor().selection() && &text_ == bv_.cursor().innerText())
- paintSelection();
+#warning look here for selection
+ //if (bv_.cursor().selection() && &text_ == bv_.cursor().innerText())
+ // paintSelection();
// vertical lines for appendix
paintAppendix();
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.528
diff -u -p -r1.528 text.C
--- text.C 31 Jan 2004 15:30:21 - 1.528
+++ text.C 2 Feb 2004 12:55:14 -
@@ -1933,46 +1933,26 @@ int LyXText::cursorY(CursorSlice const
Re: permanent loss of data during import of old LyX files
Andre Poenitz wrote:
> On Mon, Feb 02, 2004 at 12:02:22PM +0100, Georg Baum wrote:
>> The problem is that the mathed parser does not understand something like
>>
>> $a \displaystyle b$
>
> Well, it does (type it, mark it, press C-m).
That was from memory ;-)
> It does not understand $\begin{array}{cc}\isplaystyle a&b\end{array}$,
> though. The problem is that the & is not recognized as end-of-scope for
> \displaystyle.
I looked it up: this was exactly the problem.
Georg
Re: permanent loss of data during import of old LyX files
On Mon, Feb 02, 2004 at 12:02:22PM +0100, Georg Baum wrote:
> Just to clarify:
> The problem is not tex2lyx, since it spits out latex in math mode 1:1 (modulo
> some space changes IIRC).
Given that the tex2lyx and the mathed parser are pretty much the same
code (at least historically) we are talking about the same thing.
> The problem is that the mathed parser does not understand something like
>
> $a \displaystyle b$
Well, it does (type it, mark it, press C-m).
It does not understand $\begin{array}{cc}\isplaystyle a&b\end{array}$,
though. The problem is that the & is not recognized as end-of-scope for
\displaystyle.
Andre'
Re: permanent loss of data during import of old LyX files
Am Montag, 2. Februar 2004 11:55 schrieb Andre Poenitz:
> On Mon, Feb 02, 2004 at 11:43:56AM +0100, Georg Baum wrote:
> > Andre Poenitz wrote:
> > > On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> > >> Notice that the displaystyle there, it should probably be
> > >> {\displaystyle ...}, but here I am just guessing. :-)
> > >
> > > No, this usage is 'fine'. But a pain to get parsed right *sigh*.
> > >
> > > Georg, would you mind to have a look?
> >
> > Well, in fact I had a look some weeks ago, because I stumbled across the
> > same problem with tex2lyx generated files (I forgot to bugzilla this). I
> > tried to understand how it got parsed, but failed, and then decided to
> > "fix" my .tex files instead.
>
> Problem is I never really understood 'table mode' (or whatever it is
> called) in TeX, so tex2lyx's idea of it might be off by far.
Just to clarify:
The problem is not tex2lyx, since it spits out latex in math mode 1:1 (modulo
some space changes IIRC).
The problem is that the mathed parser does not understand something like
$a \displaystyle b$
Georg
Re: [patch] get rid of ParIterator::lockPath
Andre Poenitz wrote:
>> +void BufferView::setCursor(ParIterator const & par,
>> + lyx::pos_type pos)
>> +{
>> + LCursor & cur = cursor();
>> + cur.reset();
>> + ParIterator::PosHolder const & positions = par.positions();
>> + int const last = par.size() - 1;
>> + for (int i = 0; i < last; ++i)
>> + (*positions[i].it)->inset->edit(cur, true);
>> + cur.resetAnchor();
>> + LyXText * lt = par.text(*buffer());
>> + lt->setCursor(par.pit(), pos);
>> +}
>
> I wonder whether an CursorBase could replace that ParIterator/pos_type
> combo at some point of time...
Agreed... in fact we have three "equivalent but separate" structures now:
ParIterator, PosIterator and CursorBase that we should merge somehow. But I
don't think it's critical now, and it will be somehow automatic once we set
up for the good one...
> [Btw: An assert in LyXText::cursor() already crashes on File->New.
> I wonder whether there ever was some non-chaotic system for the order of
> initializing things in this area...]
;-)
Alfredo
Re: Lyx is overrideing Layout-Preferences
Juergen Spitzmueller wrote: > More debugging showed that the problem is in > updateWidgetsFromLengthString. This function passes a string const & str > as LyXLength(str) to update WidgetsFromLength. > But if I have a string str = 3.2cm, LyXLength(str).asString() returns 3cm. > Now the question is: why? Could it be a locale problem? It seems that lyx uses atof to convert a string to a number (so I presume the locale is used there), but I think there are some harcoded "." as decimal separators in the frontends validators. Alfredo
Re: permanent loss of data during import of old LyX files
On Mon, Feb 02, 2004 at 11:43:56AM +0100, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> >> Notice that the displaystyle there, it should probably be
> >> {\displaystyle ...}, but here I am just guessing. :-)
> >
> > No, this usage is 'fine'. But a pain to get parsed right *sigh*.
> >
> > Georg, would you mind to have a look?
>
> Well, in fact I had a look some weeks ago, because I stumbled across the
> same problem with tex2lyx generated files (I forgot to bugzilla this). I
> tried to understand how it got parsed, but failed, and then decided to
> "fix" my .tex files instead.
Problem is I never really understood 'table mode' (or whatever it is
called) in TeX, so tex2lyx's idea of it might be off by far.
Andre'
Re: permanent loss of data during import of old LyX files
Andre Poenitz wrote:
> On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
>> Notice that the displaystyle there, it should probably be
>> {\displaystyle ...}, but here I am just guessing. :-)
>
> No, this usage is 'fine'. But a pain to get parsed right *sigh*.
>
> Georg, would you mind to have a look?
Well, in fact I had a look some weeks ago, because I stumbled across the
same problem with tex2lyx generated files (I forgot to bugzilla this). I
tried to understand how it got parsed, but failed, and then decided to
"fix" my .tex files instead.
Georg
Re: [patch] get rid of ParIterator::lockPath
On Mon, Feb 02, 2004 at 11:07:56AM +0100, Alfredo Braunstein wrote:
> in favour of BufferView::setCursor(ParIterator &, lyx::pos_type)
>
> The lockPath name is really out of context now (remember *lock* ;-) ? ) and
> it doesn't belong really to ParIterator.
>
> Ok to go in?
Looks good.
> +void BufferView::setCursor(ParIterator const & par,
> + lyx::pos_type pos)
> +{
> + LCursor & cur = cursor();
> + cur.reset();
> + ParIterator::PosHolder const & positions = par.positions();
> + int const last = par.size() - 1;
> + for (int i = 0; i < last; ++i)
> + (*positions[i].it)->inset->edit(cur, true);
> + cur.resetAnchor();
> + LyXText * lt = par.text(*buffer());
> + lt->setCursor(par.pit(), pos);
> +}
I wonder whether an CursorBase could replace that ParIterator/pos_type
combo at some point of time...
Andre'
[Btw: An assert in LyXText::cursor() already crashes on File->New.
I wonder whether there ever was some non-chaotic system for the order of
initializing things in this area...]
Re: Lyx is overrideing Layout-Preferences
Juergen Spitzmueller wrote: > OK, this is a bug in the xforms frontend. The problem is that the length > widgets in the xforms frontend strip all values behind the dot (while > applying). I suspect that the bug is in xforms_helpers.C > (getLengthFromWidgets), but it didn't find it. > Any ideas? More debugging showed that the problem is in updateWidgetsFromLengthString. This function passes a string const & str as LyXLength(str) to update WidgetsFromLength. But if I have a string str = 3.2cm, LyXLength(str).asString() returns 3cm. Now the question is: why? Jürgen.
Re: booktabs/tableaux support in 1.3.x ?
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> My personal opinion is to change nothing in 1.3 that requires a Georg> file format change. The time needed for adjusting lyx2lyx is Georg> better spent with fixing 1.4 bugs. Not only that, but the policy is to make sure that all 1.3.x versions can produce/read the same file format. This is to encourage people to upgrade the new maintenance releases when they are released. To be fair, there has been an exception to this rule in 1.2.x, but this was to re-introduce a feature removed in 1.2.0. JMarc
[patch] get rid of ParIterator::lockPath
in favour of BufferView::setCursor(ParIterator &, lyx::pos_type)
The lockPath name is really out of context now (remember *lock* ;-) ? ) and
it doesn't belong really to ParIterator.
Ok to go in?
Alfredo
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.224
diff -u -p -u -r1.224 BufferView.C
--- BufferView.C28 Jan 2004 16:21:23 - 1.224
+++ BufferView.C2 Feb 2004 09:57:11 -
@@ -444,6 +444,19 @@ LyXText * BufferView::text() const
}
+void BufferView::setCursor(ParIterator const & par,
+ lyx::pos_type pos)
+{
+ LCursor & cur = cursor();
+ cur.reset();
+ ParIterator::PosHolder const & positions = par.positions();
+ int const last = par.size() - 1;
+ for (int i = 0; i < last; ++i)
+ (*positions[i].it)->inset->edit(cur, true);
+ cur.resetAnchor();
+ LyXText * lt = par.text(*buffer());
+ lt->setCursor(par.pit(), pos);
+}
/*
@@ -468,7 +481,8 @@ void BufferView::putSelectionAt(PosItera
cursor().clearSelection();
LyXText * text = par.text(*buffer());
- par.lockPath(this);
+ setCursor(par, cur.pos());
+
// hack for the chicken and egg problem
if (par.inset())
top_y(par.outerPar()->y);
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.161
diff -u -p -u -r1.161 BufferView.h
--- BufferView.h26 Jan 2004 10:13:06 - 1.161
+++ BufferView.h2 Feb 2004 09:57:11 -
@@ -15,6 +15,8 @@
#ifndef BUFFER_VIEW_H
#define BUFFER_VIEW_H
+#include "support/types.h"
+
#include
#include
@@ -32,6 +34,7 @@ class LyXText;
class LyXScreen;
class LyXView;
class Painter;
+class ParIterator;
class PosIterator;
class TeXErrors;
class UpdatableInset;
@@ -189,6 +192,8 @@ public:
LCursor const & cursor() const;
///
LyXText * text() const;
+ ///
+ void setCursor(ParIterator const & par, lyx::pos_type pos);
///
void putSelectionAt(PosIterator const & cur, int length, bool backwards);
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.493
diff -u -p -u -r1.493 BufferView_pimpl.C
--- BufferView_pimpl.C 30 Jan 2004 11:40:56 - 1.493
+++ BufferView_pimpl.C 2 Feb 2004 09:57:13 -
@@ -933,8 +933,8 @@ bool BufferView::Pimpl::workAreaDispatch
screen().hideCursor();
- // either the inset under the cursor or the surrounding LyXText will
- // handle this event.
+ // either the inset under the cursor or the
+ // surrounding LyXText will handle this event.
// built temporary path to inset
LyXText * text = bv_->text();
Index: iterators.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/iterators.C,v
retrieving revision 1.42
diff -u -p -u -r1.42 iterators.C
--- iterators.C 2 Feb 2004 08:55:44 - 1.42
+++ iterators.C 2 Feb 2004 09:57:13 -
@@ -221,17 +221,6 @@ ParIterator::ParIterator(PosIterator con
}
-void ParIterator::lockPath(BufferView * bv) const
-{
- LCursor & cur = bv->cursor();
- cur.reset();
- int const last = size() - 1;
- for (int i = 0; i < last; ++i)
- (*positions_[i].it)->inset->edit(cur, true);
- cur.resetAnchor();
-}
-
-
bool operator==(ParIterator const & iter1, ParIterator const & iter2)
{
return iter1.positions() == iter2.positions();
Index: iterators.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/iterators.h,v
retrieving revision 1.28
diff -u -p -u -r1.28 iterators.h
--- iterators.h 27 Jan 2004 15:14:34 - 1.28
+++ iterators.h 2 Feb 2004 09:57:13 -
@@ -78,8 +78,6 @@ public:
int index() const;
///
size_t size() const;
- ///
- void lockPath(BufferView *) const;
typedef std::vector PosHolder;
PosHolder const & positions() const
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.564
diff -u -p -u -r1.564 lyxfunc.C
--- lyxfunc.C 30 Jan 2004 11:40:57 - 1.564
+++ lyxfunc.C 2 Feb 2004 09:57:16 -
@@ -1164,11 +1164,9 @@ void LyXFunc::dispatch(FuncRequest const
<< " found." << endl;
}
- par.lockPath(view());
- LyXText * lt = par.text(*view()->buffer())
Re: crash when uncollapsing a collapsable
On Mon, Feb 02, 2004 at 10:05:11AM +0100, Andre' Poenitz wrote: > > (btw, why is that ::findText needed at all, didn't we agree that the > > current() slice is what is needed there? IMO for debugging wouldn't be > > enough to assert on current().text() == text) > > Sort of leftover from the transition. We should use the assert. Ah, I remember. findText came in just before the invention of the concept of the 'current' slice. We should indeed simply assert there. 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: crash when uncollapsing a collapsable
On Sun, Feb 01, 2004 at 01:08:37PM +0100, Alfredo Braunstein wrote: > the problem seems to consist in the following: > > - the click is dispatched through a temporary cursor cur to which this > collapsable's CUrsorSlice is pushed (the real cursor is still elsewhere); > so Yes. That's to raise the possibility of _not_ interpreting the click as cursor positioning (but, e.g. as 'pop up some menu') > - insetcollapsable::edit takes this cur argument; then > > - insettext::edit also takes this cur argument, but it calls > > - lyxtext::setCursor without the cur argument > > and LyXText::setCursor tries in vain to find itself in the *real* cursor > (using LyxText::cursor, and ::findText(LyXText *) both of which use the > real cursor). Ahja. > (btw, why is that ::findText needed at all, didn't we agree that the > current() slice is what is needed there? IMO for debugging wouldn't be > enough to assert on current().text() == text) Sort of leftover from the transition. We should use the assert. > André, can you have a look? Later today. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] fix lockpath + undo crash
On Monday 02 February 2004 09:25, Andre Poenitz wrote: > > 2) eliminating some (bogus) redundant cursor positioning code in > > undo > > Ah good. This was a _really_ old hack in undo as far as I can tell. I know... hopefully we can remove this ugly sort of things in more that one place thanks to your cleanup... Alfredo
Re: permanent loss of data during import of old LyX files
On Fri, Jan 30, 2004 at 07:09:55PM +, Jose' Matos wrote:
> On Friday 30 January 2004 10:55, Paul Stansell wrote:
> > >I will take a look into it, it shouldn't be too difficult to fix.
> >
> > Thanks!
> >
> > >Do you know what is the purpose of the displaystyle in the file? How
> > > would a present file look like?
> >
> > Yes, it prevents fractions from being displayed using small fonts.
>
> Ok, André I think that this is your department. ;-)
>
> You have the file in http://bugzilla.lyx.org/show_bug.cgi?id=1459
>
> The problem is the math parser that is not able to parse this:
> \begin{equation}
> \label{eq:BP_5.28}
> \begin{array}{ccc}
> \displaystyle S_{xx}(f) & = & \mathcal{F}\left[ R_{xx}(\tau )\right]
> ={\int_{-\infty }^{\infty }R_{xx}(\tau )e^{-i2\pi f\tau }d\tau },\\
> S_{yy}(f) & = & \mathcal{F}\left[ R_{yy}(\tau )\right]
> ={\int_{-\infty }^{infty}R_{yy}(\tau )e^{-i2\pi f\tau }d\tau },\\
> S_{xy}(f) & = & \mathcal{F}\left[ Rxy(\tau )\right]
> ={\int_{-\infty }^{\infty }R_{xy}(\tau )e^{-i2\pi f\tau }d\tau },
> \end{array}
> \end{equation}
>
> Notice that the displaystyle there, it should probably be
> {\displaystyle ...}, but here I am just guessing. :-)
No, this usage is 'fine'. But a pain to get parsed right *sigh*.
Georg, would you mind to have a look?
Andre'
Re: [PATCH] lyx2lyx encoding warnings
On Sunday 01 February 2004 19:45, Georg Baum wrote: > José, > > some time ago you fixed some python encoding warnings in lyx2lyx. > However, it seems that the encoding needs to be specified not only in the > main file, but also in the imported modules. > The attached patch adds the encoding to every python file in lyx2lyx. > The patch is against 1.4, but it probably applies to 1.3 with little > modifications. The patch is ok and should also apply to 1.3, if can commit it or else I will do it tomorrow afternoon as I'm busy now. > Georg -- José Abílio LyX and docbook, a perfect match. :-)
Re: [patch] fix lockpath + undo crash
On Saturday 31 January 2004 12:32, Lars Gullik Bjønnes wrote: > It it works it works. Seems to ;-) > As long as it does not introduce more errors go for it. okeydokey. Alfredo
Re: [patch] fix lockpath + undo crash
On Sat, Jan 31, 2004 at 11:50:19AM +0100, Alfredo Braunstein wrote: > zz > > gives a crash. > > This patch solves that by 1) fixing lockPath (the CursorSlice at level 0 was > missing) Thanks. > 2) eliminating some (bogus) redundant cursor positioning code in > undo Ah good. This was a _really_ old hack in undo as far as I can tell. > Ok? Sure. Andre'
Re: [patch] More IU
On Fri, Jan 30, 2004 at 01:30:59PM -0800, Kayvan A. Sylvan wrote: > The lyx crashes situation is better. Thanks. > > Lyx still crashes on: > > 1. C-N (New document) > 2. C-M (Insert math inset) > 3. type X^Y in the math inset > > The "^" causes the crash on some of my machines, but the C-m causes > the crash on my Solaris box. I see the first one but I am sort of clueless right now. Looks somehow like heap corruption to me. 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: Compile error
On Fri, Jan 30, 2004 at 01:54:37PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | This intention of this 'nucleus/operator->' pair instead of the usual > | 'nucleus/nucleus' pair was to be able to find the non-const accesses > | with grep. [They are sort of 'unwanted' in the light of potential > | shared_ptr usage and each use should be justified explicitly...] > > Not exacly documented in the sources... > > Ok... then operator-> should stay as it is and a operator* should be > added, so that the t.operator-> construct can be removed. > > But I don't really understand why non-const access is bad? I wanted to set up some kind of reference counted implementation for MathAtoms at some point of time so I thought I'd better try to prevent non-const accesses. The point may be completely mood, though. First of all, that waste of memory does not have a visible impact on mathed performance as far as I can tell, and then, one of the (semi-)standard shared pointers might do better than any home grown solution I'd have come up with in the end. Andre'
