Richard Heck [Thu, 12 May 2011 13:16:36 +0000 (13:16 +0000)]
Fix XHTML output for fractions and fix a crash reported on the list
by Jan Paul Imhoff. The problem was that we were assuming (as we still
do in some places) that there are always at least two cells.
Fix #7549, due to a problem in exporting to plaintext a
multicell inset, where we now export all of the cells
separated by "\t", instead of only the first cell.
Richard Heck [Wed, 11 May 2011 14:12:00 +0000 (14:12 +0000)]
Fix bug #7547. We need to check whether we are in a multirow here.
Otherwise, we were asking to construct strings of random size at a
certain point, e.g., two 2GB strings, in one case I saw.
Introduce the possibility of setting a prefix for the TEXINPUTS environment
variable. This is done in the preferences, much like as the PATH prefix.
A single '.' in the paths will get replaced with the current document dir
and also non-absolute paths will be prefixed with that dir.
The default semantics of TEXINPUTS apply, such that, for example, if a
path is terminated with a double slash, all subdirectories will be also
searched by both the TeX engine and ancillary programs such as dvi
previewers or dvips. As an example, if the prefix is set to ".:figs", the
TEXINPUTS variable will be set as ".:<docdir>:<docdir>/figs:$ORIGTEXINPUTS",
where <docdir> is the document directory.
The initial '.' is necessary to address the actual current dir (this will
be the temp dir at preview time), while if TEXINPUTS was initially unset,
such that $ORIGTEXINPUTS is empty, a colon (or semicolon on Windows) will
end the path list. This is very important, because we don't want to replace
the system directories but to complement them and, in order to do that, an
empty element has to be present in the list. Indeed, according to the
TEXINPUTS semantics, an empty element means the standard search path.
This works whether TEXINPUTS is originally set or not, because if the
original TEXINPUTS starts with a colon (meaning that the standard search
path is wanted there) we will have an empty element at that point,
otherwise the final colon will simply serve as a path separator.
Of course, on Windows a ';' has to be used as a path separator. LyX will
take care of transforming the platform path list into one understandable
by the TeX engine. For example, this will be the case for a Cygwin version
of LyX using a native Windows TeX engine or viceversa. I tested all of
this and it works for me.
Richard Heck [Mon, 9 May 2011 23:23:24 +0000 (23:23 +0000)]
Fix for bug #7319. This is an attempt to fix the bug cheaply.
We clear the refernce cache so that we won't get conflicts with labels
that get pasted into the buffer. We should update this before its being
empty matters. If not (i.e., if we encounter bugs), then this should
instead be:
cur.buffer().updateBuffer();
But we'll try the cheaper solution in trunk.
Richard Heck [Mon, 9 May 2011 18:05:31 +0000 (18:05 +0000)]
Fix crash reported by John Kennan.
We are missing the updateBuffer() call when we go through
mouseEventDispatch(). A consequence of the massive updateBuffer()
refactoring. Wish it had been caught before...
Still addressing #6560: instead of cloning the BufferParams, which might cause
a number of unforeseen issues (like the inheritance of the default master, as
pointed out in http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg168225.html),
now we simply set the language into the search & replace buffers.
MikTeX's kpsewhich doesn't mention "kpathsea emulation" anymore.
On Cygwin, the most reliable way to tell what is the right path
separator to use is a direct check.
Richard Heck [Sun, 8 May 2011 00:54:17 +0000 (00:54 +0000)]
Fix bug #7500: There is presently no way in the GUI to update local
layout to the current format.
This probably isn't needed for branch, since local layout was a
"hidden feature" prior to 2.0, and one can update local layout by:
(a) copying to a file
(b) running layout2layout on that file
(c) pasting back into LyX
So we should probably just leave this in trunk.
Richard Heck [Sat, 7 May 2011 23:02:53 +0000 (23:02 +0000)]
Fix bug #7499. The problem here is that there was no way for the
inset to know that the BibTeX data had changed. So we introduce a
Buffer-wide variable that we can query for that information.
Richard Heck [Thu, 5 May 2011 20:18:16 +0000 (20:18 +0000)]
Start the clean up of the updateMacros() calls by moving the necessary
calls into the file writing routines and out of doExport(). They were in
both places before: Called once in doExport, and then again in the e.g.
writeLaTeXSource()---and then again, actually, in validate().
It is possible this will reveal some missing updateBuffer() calls
somewhere. But it should somewhat speed up View>Source, since we now do
not do an extra set of such calls in that routine. Rather, we rely upon
the Buffer's having been made up to date first, by the updateBuffer()
call after dispatch.
Georg Baum [Wed, 4 May 2011 18:21:15 +0000 (18:21 +0000)]
Make .po string extraction more robust:
- Do not parse case insensitive tags case sensitive
- Reintroduce missing translations that were accidentally lost with the
introduction of the I18nPreamble and EndI18nPreamble tags
Some math font changing commands only work in math mode, so let's
assure to switch to math mode if needed. This helps avoiding latex
errors (see http://thread.gmane.org/gmane.editors.lyx.general/69580)
See r37176. Let's keep this a Windows only "feature".
Something went wrong with a script while previewing a document and now
I have to wait for 30 minutes for quitting LyX without killing it.
Richard Heck [Tue, 26 Apr 2011 22:41:48 +0000 (22:41 +0000)]
Fix bug #7490.
As the bug report notes, you do NOT get this crash if you move up or
down in the table a bit before you do the rest. The reason is that
moving up and down sets the cursor's x_target_, and it is because that
is not set that we enter the other code at all and eventually crash.
That is, in InsetTabular's dispatch, we have:
You can see the potential for trouble here already. cur.pit() is in the
NEW cell, i.e., the one to which we are moving; it was changed a few
lines previously, and cur.idx() points to the new cell, too. But we are
trying to calculate cur.pos(), which means that cur.pos() is currently
the one from the OLD cell. So the cursor is in an inconsistent state.
Calling cur.targetX() leads us to call Cursor::getPos(), and that is
what causes the crash.
We fix the problem by making sure we call targetX() on the original
cursor. The same problem clearly exists in the DOWN stuff, so we fix
that, too.
By the way, should we be setting x_target_ here once we have calculated
it?
Disable the option to run LyX from the finish page for now. This would run LyX using the Administrator account if installing for all users, resulting in a different user directory to be used with different preferences etc.