Re: Bugs and comments for LyX 1.5.0 beta 2
Abdelrazak Younes wrote: I'm also annoyed by this and the reason is that LyX1.5svn scans all directories before opening the dialog. LyX 1.4.4 doesn't do this so the dialog pops up immediately. I'm sure that this is the reason because on my home PC, the dialog opens in 1.5svn after 1-2 seconds but at work 5-10 seconds are needed when I have connected network drives and also only 1-2 seconds when I disconnected the network drives. When using LyX 1.4.4 it makes no difference if the network drives are connected. I don't understand why LyX scans all directories because the network drives don't contain any LyX or third-party stuff needed by LyX or could this be a Qt bug in the file open dialog routine? Not a bug but perhaps a feature. Maybe there is some settings to pass in our use of QFileDialog to disable this behaviour. Somebody ought to read the docs... I don't see any such option, but then I don't see this behavior on Linux, either. The dialog opens up pretty much immediately, and I do have a networked directory under /home/rgheck/. By the way, in experimenting, I tried opening the kluwer.lyx template, and I got a lyx2lyx error. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Screencast of new math macro implementation
Abdelrazak Younes wrote: Stefan Schimanski wrote: Am 11.05.2007 um 14:24 schrieb Abdelrazak Younes: Stefan Schimanski wrote: I work on a better implementation of math macros for some time now. Accidently I was playing around with some screencast tools and made a demonstration of the current state of the system: http://www.youtube.com/watch?v=68Gys4rp3u4 Make the video fullscreen to see what's going on. Mainly it shows the design choice how math macros look to the user, like the possibility to fold/unfold, add and removing parameters greedily and non-greedily, and the flexibility coming from position awareness of the macro definitions, including support for master documents. That's a bit complicated at first glance but it sure looks *impressive*. What exactly is complicated? Yes, all of that gives the feeling of complicatedness ;-) I think it probably seems complicated the way anything powerful is complicated. This can obviously be used to do about a billion things. But wow, it looks amazing. I hereby volunteer to help test it. I'd love to be able to use this in my own work. (I was the one who filed the child docs bug.) Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Beta 3 (preparation)
Bennett Helm wrote: I wish I had a patch; I at least have a special plea: could someone fix this bug? -- http://bugzilla.lyx.org/show_bug.cgi?id=3544 Down-arrow in main text skips lines (on Mac, at least) (Do other platforms not have this problem?) It would be embarrassing to release the beta with this bug still present. I don't see this on Linux. I'm afraid I can't fix it therefore Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: ps2pdf fails
This is very unlikely to be a LyX error, though it could be. I just ran ps2pdf on a file of my own, and it worked fine. Here's how to debug your problem: Export the file to LaTeX; then run LaTeX manually on the file to produce thesis.dvi, running BibTeX etc as necessary; run dvips -o thesis.ps; then run ps2pdf thesis.ps thesis.pdf, and see what happens. You'll likely get a more informative error message that way. Richard Darren Freeman wrote: Hi all, I select View-PDF (ps2pdf) and get the error: An error occurred whilst running ps2pdf13 'thesis.ps' 'thesis.pdf' This doesn't really help me find the problem. There is definitely a ps2pdf13 installed. The other output options, DVI, PS, other ways of generating a PDF, HTML, all work as expected. I don't have much to go on so hoping it is easy to reproduce. I suspect that those filenames are too short since I normally see long ones referring to the temp dir. Or possibly it forgets to generate the PS first. Latest svn. Have fun, Darren -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Scrolling lag in 1.5svn again.
Pavel Sanda wrote: I'll try, but how do I do this? Is there some svn command for reverting to a specific version? i'm not aware of any direct revert command of svn. however you can checkout particular revision of the svn tree (i.e. the 18265 revision). svn up -r VERSION -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: LyX aborts unless run from build tree
Darren Freeman wrote: Hi all, I have a Mandrake 10.0 (gasp!) machine which I just built LyX (latest svn) on with Qt 4.2.3 compiled from source also. What follows also applied to earlier svn and earlier Qt, I tried rebuilding everything with latest versions out of confusion. When I run it as src/lyx from the build tree, it works. When I run it as lyx, which refers to /usr/local/bin/lyx (an identical copy placed there by make install), it stops with the line Aborted. Try running: lyx -dbg, and see if you get any more help. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: LyX aborts unless run from build tree
Can you get a backtrace from this? Just run it under gdb. It'll help if you compile with -enable-debug. Darren Freeman wrote: On Wed, 2007-05-16 at 01:48, Richard Heck wrote: Darren Freeman wrote: Hi all, I have a Mandrake 10.0 (gasp!) machine which I just built LyX (latest svn) on with Qt 4.2.3 compiled from source also. What follows also applied to earlier svn and earlier Qt, I tried rebuilding everything with latest versions out of confusion. When I run it as src/lyx from the build tree, it works. When I run it as lyx, which refers to /usr/local/bin/lyx (an identical copy placed there by make install), it stops with the line Aborted. Try running: lyx -dbg, and see if you get any more help. lyx -dbg 4294967295 Setting debug level to 4294967295 Debugging `info' (General information) Debugging `init' (Program initialisation) Debugging `key' (Keyboard events handling) Debugging `gui' (GUI handling) Debugging `parser' (Lyxlex grammar parser) Debugging `lyxrc' (Configuration files reading) Debugging `kbmap' (Custom keyboard definition) Debugging `latex' (LaTeX generation/execution) Debugging `mathed' (Math editor) Debugging `font' (Font handling) Debugging `tclass' (Textclass files reading) Debugging `lyxvc' (Version control) Debugging `lyxserver' (External control interface) Debugging `roff' (Keep *roff temporary files) Debugging `action' (User commands) Debugging `lyxlex' (The LyX Lexxer) Debugging `depend' (Dependency information) Debugging `insets' (LyX Insets) Debugging `files' (Files used by LyX) Debugging `workarea' (Workarea events) Debugging `insettext' (Insettext/tabular messages) Debugging `graphics' (Graphics conversion and loading) Debugging `changes' (Change tracking) Debugging `external' (External template/inset messages) Debugging `painting' (RowPainter profiling) Checking whether LyX is run in place... no ... followed by abort. -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: crash tex2lyx
I'm not getting a crash with this, though I do see some warnings:
[EMAIL PROTECTED] tmp]$ ~/dev/bin/tex2lyx internal.tex
Creating file /tmp/internal.lyx
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
Warning: Could not find graphics file 'grdteach.eps'.
unexpected dummy size: 2 content:
unexpected dummy size: 2 content: \hline\hline
unexpected dummy size: 2 content:
dropping extra hline
unexpected dummy size: 2 content: \hline
dropping extra hline
But looking at the backtrace, I wonder whether the problem is that
TextClass::layoutlist_ is for some reason empty or, worse,
uninitialized. It looks like that is what is triggering the assertion.
That would mean, I think, that do_readStyle (called at TextClass.cpp,
line 293) is always failing, which means that Layout::read() is always
failing. But it's hard to debug it without seeing the error
Richard
Leuven, E. wrote:
with attached doc.
backtrace:
tex2lyx.exe!boost::assertion_failed(const char *
expr=0x005b6c44, const char * function=0x005b6c50, const char *
file=0x005b6cc0, long line=315) Line 39 + 0x8 bytes C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-() Line
315 + 0x23 bytes C++
tex2lyx.exe!lyx::TextClass::read(const lyx::support::FileName
filename={...}, bool merge=false) Line 455 + 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser p={...},
std::basic_ostreamchar,std::char_traitschar os={...}, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
forceclass=) Line 502 C++
tex2lyx.exe!lyx::`anonymous
namespace'::tex2lyx(std::basic_istreamchar,std::char_traitschar
is={...}, std::basic_ostreamchar,std::char_traitschar
os={...}) Line 428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const
lyx::support::FileName infilename={...},
std::basic_ostreamchar,std::char_traitschar os={...}) Line 462
+ 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
infilename=C:/_projects/profs3/internal.tex, const
lyx::support::FileName outfilename={...}) Line 494 + 0x38 bytes C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8) Line
554 + 0x35 bytes C++
tex2lyx.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
tex2lyx.exe!mainCRTStartup() Line 403 C
kernel32.dll!7c816fd7()
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
QListings Encoding
It looks to me as if QListings.cpp is encoded differently from the other files. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Scrolling lag in 1.5svn again, more details.
Abdelrazak Younes wrote: Martin Vermeer wrote: I seem to recall that there was some code in the Qt X event handling code, precisely to handle this problem. Lars wrote this. But then it was decided that it could be removed... anyone remember? Something with coalescing of multiple keystroke events. Yes there is a patch in bugzilla for _key_ events but this is independent issue: Helge's problem is about the scrollbar. About Lars patch I hoped that someone on Linux (Richard?) would continue with this patch... Point me in the right direction. I have a vague memory of this rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: http://bugzilla.lyx.org/show_bug.cgi?id=3320 There's a patch mostly ready for the key release problem. The only problem with the patch is that it uses specific X11 event; it would be better to do something similar with Qt only API. But this is not a big problem because the bug is only visible on certain version of X11 apparently, not for Windows or Mac. I've found a simpler solution. See attached patch. [snip] but I forgot that it would also eat other key events. So when you type text faster than the GUI could update, what should be possible with ten fingers, some will be lost. We must check for the page up/down key. I update the patch. There are other keys that this happens with. It can happen with the arrow keys, for example. So we don't want to check for just those keys, I don't think, but for various navigation keys. And you can see the same kind of behavior about which Helge originally complained even when pressing, say, x and holding it down: if the system is under load, you can keep getting x's for a while after you release the key. So I think what we need to do is check for release events in general---key releases, mouse button releases, and clear the event cache when we get them. Or will the key release event arrive too late? Anyway, I'll leave it to you. I'm on the trail of a different bug at the moment. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Scrolling lag in 1.5svn again, more details.
Andre Poenitz wrote:
On Wed, May 16, 2007 at 11:57:51PM +0200, Peter Kümmel wrote:
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
+// do nothing if there are other events
+// (the auto repeated events come too fast)
+if(QCoreApplication::hasPendingEvents()) {
+LYXERR(Debug::KEY) BOOST_CURRENT_FUNCTION
+ endl key ignored endl;
+e-ignore();
+return;
+}
Have you tried typing _really_ fast?
Do all keys still come through? If so, the idea looks good, although
I'd restrict it to PageUp/Down events.
As I said in a different message, the original bug report did not
concern PgUp/Down but the scrollbar, and you see identical behavior with
the up and down arrow keys as well as with other keys.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Fix for Bugs 3630 and 3461
Whoops. Another of those really easy fixes...and sent to the wrong list,
too. Bad day
=
The attached patch addresses these two bugs. The problem was that
Text::setFont was not updating the current font (real_current_font, etc)
when a selection (implicit or explicit) was active. This appeared with
the emphasis toolbar button but on examination affected much more.
I've tested this and see no issues with it.
Waiting to commit until I get the OK.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: Text2.cpp
===
--- Text2.cpp (revision 18373)
+++ Text2.cpp (working copy)
@@ -437,29 +437,29 @@
void Text::setFont(Cursor cur, Font const font, bool toggleall)
{
BOOST_ASSERT(this == cur.text());
- // if there is no selection just set the current_font
- if (!cur.selection()) {
- // Determine basis font
- Font layoutfont;
- pit_type pit = cur.pit();
- if (cur.pos() pars_[pit].beginOfBody())
- layoutfont = getLabelFont(cur.buffer(), pars_[pit]);
- else
- layoutfont = getLayoutFont(cur.buffer(), pit);
+ // Set the current_font
+ // Determine basis font
+ Font layoutfont;
+ pit_type pit = cur.pit();
+ if (cur.pos() pars_[pit].beginOfBody())
+ layoutfont = getLabelFont(cur.buffer(), pars_[pit]);
+ else
+ layoutfont = getLayoutFont(cur.buffer(), pit);
- // Update current font
- real_current_font.update(font,
- cur.buffer().params().language,
- toggleall);
+ // Update current font
+ real_current_font.update(font,
+ cur.buffer().params().language,
+ toggleall);
- // Reduce to implicit settings
- current_font = real_current_font;
- current_font.reduce(layoutfont);
- // And resolve it completely
- real_current_font.realize(layoutfont);
+ // Reduce to implicit settings
+ current_font = real_current_font;
+ current_font.reduce(layoutfont);
+ // And resolve it completely
+ real_current_font.realize(layoutfont);
+ // if there is no selection that's all we need to do
+ if (!cur.selection())
return;
- }
// Ok, we have a selection.
recordUndoSelection(cur);
[PATCH] Improved Fix for Bug 3461
I've discussed this with Abdel already but am sending the fix to the list before committing. The problem is that hitting escape (which emits the rejected() signal) bypasses such closeEvent() and the like. Unfortunately, Abdel's suggestion that we should call slotRestore() here, although sensible, doesn't work. We could call that additionally, but since the dialog is being hidden and will be updated on show(), there's no real reason to do so. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto Index: QRef.cpp === --- QRef.cpp (revision 18373) +++ QRef.cpp (working copy) @@ -51,6 +51,7 @@ connect(applyPB, SIGNAL(clicked()), form_, SLOT(slotApply())); connect(closePB, SIGNAL(clicked()), form_, SLOT(slotClose())); connect(closePB, SIGNAL(clicked()), this, SLOT(reset_dialog())); + connect(this, SIGNAL(rejected()), this, SLOT(reset_dialog())); connect(typeCO, SIGNAL(activated(int)), this, SLOT(changed_adaptor())); Index: QCitationDialog.cpp === --- QCitationDialog.cpp (revision 18373) +++ QCitationDialog.cpp (working copy) @@ -190,6 +190,8 @@ textBeforeLA-setEnabled(!basic_engine); string const command = form_-params().getCmdName(); + + lyxerr command std::endl; // Find the style of the citekeys vectorbiblio::CiteStyle const styles =
[PATCH] Add originaldir,needaux to Word -- HTML htlatex conversion
As described. This is already there for the non-Word version. Absent these settings, (a) we lose reference info and (b) only the main .html file is copied to the result directory, with the other files (e.g., .css) remaining in the temporary directory. OK to commit? There are, by the way, also some issues with the originaldir flag, namely, that child documents are not handled appropriately. I've filed a bug report about this: http://bugzilla.lyx.org/show_bug.cgi?id=3632. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Add originaldir,needaux to Word -- HTML htlatex conversion
DANG IT!!
As described. This is already there for the non-Word version. Absent
these settings, (a) we lose reference info and (b) only the main .html
file is copied to the result directory, with the other files (e.g.,
.css) remaining in the temporary directory.
OK to commit?
There are, by the way, also some issues with the originaldir flag,
namely, that child documents are not handled appropriately. I've filed a
bug report about this: http://bugzilla.lyx.org/show_bug.cgi?id=3632.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: configure.py
===
--- configure.py (revision 18380)
+++ configure.py (working copy)
@@ -347,7 +347,7 @@
rc_entry = [ r'\converter word latex %% ' ])
#
checkProg('a LaTeX - MS Word converter', [htlatex $$i 'html,word' 'symbol/!' '-cvalidate'],
-rc_entry = [ r'\converter latex wordhtml %% ' ])
+rc_entry = [ r'\converter latex wordhtml %% originaldir,needaux' ])
#
checkProg('an OpenOffice.org - LaTeX converter', ['w2l -clean $$i'],
rc_entry = [ r'\converter sxwlatex %% ' ])
Bug?
Can someone take a look at this code from Exporter.cpp? It seems to me
that we ought to be returning where I've indicated below. Is this wrong?
// Plain text backend
if (backend_format == text)
writePlaintextFile(*buffer, FileName(filename), runparams);
// no backend
else if (backend_format == lyx)
buffer-writeFile(FileName(filename));
// Docbook backend
else if (buffer-isDocBook()) {
runparams.nice = !put_in_tempdir;
buffer-makeDocBookFile(FileName(filename), runparams);
}
// LaTeX backend
else if (backend_format == format) {
runparams.nice = true;
if (!buffer-makeLaTeXFile(FileName(filename), string(), runparams))
return false;
///
//FIXME: shouldn't this just return if the file has been created? Isn't
this case
//the one where we're just being asked to export LaTeX?
///
} else if (!lyxrc.tex_allows_spaces
contains(buffer-filePath(), ' ')) {
Alert::error(_(File name error),
_(The directory path to the document cannot contain
spaces.));
return false;
} else {
runparams.nice = false;
if (!buffer-makeLaTeXFile(FileName(filename),
buffer-filePath(), runparams))
return false;
}
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Bug?
Abdelrazak Younes wrote: Richard Heck wrote: Can someone take a look at this code from Exporter.cpp? It seems to me that we ought to be returning where I've indicated below. Is this wrong? You mean return true? Maybe yes. On looking closer, no, there are some things that happen later, even though the run through the converters is pointless. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
oolatex File Format Issue
The default OpenOffice format is presently sxw, but oolatex now seems to produce odt by default. As a result, LyX thinks the conversion always fails, because it's looking for filename.sxw and can't find it. I think there are ways to make oolatex produce sxw (I'm trying to find out how), so one option would be to change the command. Another would be to change the format to odt. By the way, it's VERY unclear how to add a new file format. It took me quite a while to figure it out. Perhaps a tooltip on the add button (Enter a new GUI name) would do. But even then, it's very unintuitive. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: oolatex File Format Issue
OK. I'll take care of this later. Right now, I have to go to a baseball game José Matos wrote: On Thursday 17 May 2007 8:06:43 pm Abdelrazak Younes wrote: By the way, it's VERY unclear how to add a new file format. It took me quite a while to figure it out. Perhaps a tooltip on the add button (Enter a new GUI name) would do. But even then, it's very unintuitive. I agree. +1 Abdel. -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Work plan for release candidate 1
I'm working on a patch that addresses several problems with the converters. This will hopefully address bugs 643, 2807, and 3047. I should be sending to the list shortly. José Matos wrote: Hi, a common share of LyX release managers is that we have the memory and span attention of a gold fish (I could cite Lars on this subject). ;-) If you have bugfixes that you like me to consider for inclusion please reply here. I will appreciate those with bugzilla numbers associated. :-) So from now on until the stable release I would like that any bug fix is sent first to the list. The only exception to this rule are Uwe's commits to the Alt windows installer. ;-) Just to remember the list of current lyx bugs rated by severity is in the wiki, http://wiki.lyx.org/Devel/BuglistsForLyX150 I would like to welcome contributions from translators to avoid last minute commits. Michael you are welcome to coordinate this process, if you want to. Regards, -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bugs 643, 3047, and 3090
The attached patch addresses these bugs, all of which have to do with
export, viewing, and the like---ultimately, with the conversion
routines. The patch introduces a new conversion flag, usetempdir, which
forces the converter to do all its work in a temporary directory created
under the lyx_tmpbuf directory. On export, this directory is copied to
the directory in which the LyX file is contained. So, if you open
/path/file.lyx and FileExportFormat, you will get a directory
/path/file.format.conversion/ in which all the files generated by the
converter will be found (e.g. the mess that htlatex generates ends up in
/path/file.html.conversion/). If you're just viewing, however, you get
$LYXTMPDIR/lyx_tmpbufN/format/, and of course that will get deleted when
LyX exits (gracefully).
As a result, the originaldir flag does not need to be used by any of our
converters, and it may be redundant, though there's no harm leaving it,
so far as I can see.
As you will note, doing this involved adding a new signature to the
Converters::convert() routine. I have not changed any of the other calls
to this: these are in Importer.cpp, insets/InsetGraphics.cpp, and
insets/ExternalSupport.cpp. At least some of these will need modifying
before the patch is applied, probably all of them, as I suppose
usetempdir could be set for importers and graphics converters and such.
There are a few other clean-up type things to be done still, too,
including fixing indentation, but I haven't done that yet as it would
make the diff hard to read.
Comments of course welcome. Will wait to commit for a bit, targeting for
RC1??
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/Converter.h
===
--- src/Converter.h (revision 18380)
+++ src/Converter.h (working copy)
@@ -59,6 +59,9 @@
bool original_dir;
/// This converter needs the .aux files
bool need_aux;
+ /// This converter should put its files in a separate temporary
+ /// directory
+ bool use_temp_dir;
/// If the converter put the result in a directory, then result_dir
/// is the name of the directory
std::string result_dir;
@@ -123,6 +126,14 @@
support::FileName const orig_from,
std::string const from_format, std::string const to_format,
ErrorList errorList, int conversionflags = none);
+ /// used_tmp_dir is a flag that signals whether our output files were put into
+ /// a temporary directory. Note also that to_file will be changed so that it points
+ /// at the converted file in this case.
+ bool convert(Buffer const * buffer,
+ support::FileName const from_file, support::FileName to_file,
+ support::FileName const orig_from, bool used_temp_dir,
+ std::string const from_format, std::string const to_format,
+ ErrorList errorList, int conversionflags = none);
///
void update(Formats const formats);
///
Index: src/Converter.cpp
===
--- src/Converter.cpp (revision 18380)
+++ src/Converter.cpp (working copy)
@@ -31,7 +31,6 @@
#include support/Path.h
#include support/Systemcall.h
-
namespace lyx {
using support::addName;
@@ -118,7 +117,8 @@
string const c, string const l)
: from(f), to(t), command(c), flags(l),
From(0), To(0), latex(false), xml(false),
- original_dir(false), need_aux(false)
+ original_dir(false), need_aux(false),
+ use_temp_dir(false)
{}
@@ -135,6 +135,8 @@
xml = true;
else if (flag_name == originaldir)
original_dir = true;
+ else if (flag_name == usetempdir)
+ use_temp_dir = true;
else if (flag_name == needaux)
need_aux = true;
else if (flag_name == resultdir)
@@ -293,15 +295,30 @@
string const from_format, string const to_format,
ErrorList errorList, int conversionflags)
{
+ FileName tmp_to_file = to_file;
+ bool trash;
+ return convert(buffer, from_file, tmp_to_file, orig_from, trash,
+ from_format, to_format, errorList, conversionflags);
+}
+
+
+bool Converters::convert(Buffer const * buffer,
+ FileName const from_file, FileName to_file,
+ FileName const orig_from, bool used_temp_dir,
+ string const from_format, string const to_format,
+ ErrorList errorList, int conversionflags)
+{
if (from_format == to_format)
return move(from_format, from_file, to_file, false);
- if ((conversionflags try_cache)
-
Re: Restarting httpd?
Jean-Marc Lasgouttes wrote: José == José Matos [EMAIL PROTECTED] writes: José On Friday 18 May 2007 12:05:32 pm Jean-Marc Lasgouttes wrote: Is it just a sudo /etc/init.d/httpd restart ? José Or the same sudo service httpd restart And you also often have: sudo apachectl restart. I've never seen that fail except when I've made some error in httpd.conf. Richard
Re: Work plan for release candidate 1
Abdelrazak Younes wrote: Jürgen Spitzmüller wrote: José Matos wrote: 3637 is attached. (Get label from parameter string and push to label list). Jürgen is this OK with you? Hm, I missed this and did something similar. Bo's patch is generally better, but lacks changeRefsIfUnique. I propose to put in the attached (which is a synthesis of Bo's and my patch). This string params encoding/decoding is really horrible (not your fault, nothing we can change now). There it is again. Whaddaya say we clean this up early in the 1.6.x development process? Or maybe even on the way to 1.5.1? rh
[PATCH-again] Bugs 643, 3047, and 3090
Any comments on this? Anyone care to test it? If you like ExportHTML or
ViewHTML, you are going to like this
The attached patch addresses these bugs, all of which have to do with
export, viewing, and the like---ultimately, with the conversion
routines. The patch introduces a new conversion flag, usetempdir, which
forces the converter to do all its work in a temporary directory created
under the lyx_tmpbuf directory. On export, this directory is copied to
the directory in which the LyX file is contained. So, if you open
/path/file.lyx and FileExportFormat, you will get a directory
/path/file.format.conversion/ in which all the files generated by the
converter will be found (e.g. the mess that htlatex generates ends up in
/path/file.html.conversion/). If you're just viewing, however, you get
$LYXTMPDIR/lyx_tmpbufN/format/, and of course that will get deleted when
LyX exits (gracefully).
As a result, the originaldir flag does not need to be used by any of our
converters, and it may be redundant, though there's no harm leaving it,
so far as I can see.
As you will note, doing this involved adding a new signature to the
Converters::convert() routine. I have not changed any of the other calls
to this: these are in Importer.cpp, insets/InsetGraphics.cpp, and
insets/ExternalSupport.cpp. At least some of these will need modifying
before the patch is applied, probably all of them, as I suppose
usetempdir could be set for importers and graphics converters and such.
There are a few other clean-up type things to be done still, too,
including fixing indentation, but I haven't done that yet as it would
make the diff hard to read.
Comments of course welcome. Will wait to commit for a bit, targeting for
RC1??
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/Converter.h
===
--- src/Converter.h (revision 18380)
+++ src/Converter.h (working copy)
@@ -59,6 +59,9 @@
bool original_dir;
/// This converter needs the .aux files
bool need_aux;
+ /// This converter should put its files in a separate temporary
+ /// directory
+ bool use_temp_dir;
/// If the converter put the result in a directory, then result_dir
/// is the name of the directory
std::string result_dir;
@@ -123,6 +126,14 @@
support::FileName const orig_from,
std::string const from_format, std::string const to_format,
ErrorList errorList, int conversionflags = none);
+ /// used_tmp_dir is a flag that signals whether our output files were put into
+ /// a temporary directory. Note also that to_file will be changed so that it points
+ /// at the converted file in this case.
+ bool convert(Buffer const * buffer,
+ support::FileName const from_file, support::FileName to_file,
+ support::FileName const orig_from, bool used_temp_dir,
+ std::string const from_format, std::string const to_format,
+ ErrorList errorList, int conversionflags = none);
///
void update(Formats const formats);
///
Index: src/Converter.cpp
===
--- src/Converter.cpp (revision 18380)
+++ src/Converter.cpp (working copy)
@@ -31,7 +31,6 @@
#include support/Path.h
#include support/Systemcall.h
-
namespace lyx {
using support::addName;
@@ -118,7 +117,8 @@
string const c, string const l)
: from(f), to(t), command(c), flags(l),
From(0), To(0), latex(false), xml(false),
- original_dir(false), need_aux(false)
+ original_dir(false), need_aux(false),
+ use_temp_dir(false)
{}
@@ -135,6 +135,8 @@
xml = true;
else if (flag_name == originaldir)
original_dir = true;
+ else if (flag_name == usetempdir)
+ use_temp_dir = true;
else if (flag_name == needaux)
need_aux = true;
else if (flag_name == resultdir)
@@ -293,15 +295,30 @@
string const from_format, string const to_format,
ErrorList errorList, int conversionflags)
{
+ FileName tmp_to_file = to_file;
+ bool trash;
+ return convert(buffer, from_file, tmp_to_file, orig_from, trash,
+ from_format, to_format, errorList, conversionflags);
+}
+
+
+bool Converters::convert(Buffer const * buffer,
+ FileName const from_file, FileName to_file,
+ FileName const orig_from, bool used_temp_dir,
+ string const from_format, string const to_format,
+ ErrorList errorList, int conversionflags)
+{
if
Re: [PATCH-again] Bugs 643, 3047, and 3090
José Matos wrote: On Friday 18 May 2007 7:42:56 pm Richard Heck wrote: Any comments on this? Anyone care to test it? If you like ExportHTML or ViewHTML, you are going to like this I did not forgot it, I was thinking. I am slow at times. ;-) No problem. I know you have a few things to do. [snip] This area looks a mess and I have never quite understood it completely. :-) That is I why I am asking for Georg's help to decide on this. The same applies to Jürgen. I'll wait for them to look at it. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Scrolling lag in 1.5svn again, more details.
Peter Kümmel wrote: What hasPendingEvents returns makes no sense to me. Isn't it that there is a queue for all events, and when one is handled (event-accept()) it is done and removed from the queue? The truth isin the Qt source code, but who could read it? Could this be part of the problem? The QAbstractEventDispatcher class manages Qt's event queue, /excluding/ GUI-related events. QAbstractEventDispatchers has a hasPendingEvents(), and so does QApplication, that being inherited from QCoreApplication. So it's critical to call the right one. Are we? -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bug 3650
The attached addresses http://bugzilla.lyx.org/show_bug.cgi?id=3650. The
issues were two. (i) When the old inset was erased, the iterator became
invalid, and the attempt to increment it caused an abort; (ii) after
clearing that up, a different abort made it clear that the cursor
position needed to be updated so it wouldn't be past the end of the text.
Testing requested, as well as two commit OKs if it seems all right.
NOTE: Some other issues I noticed here, which I'll put in bugzilla if it
seems a good idea. (i) Take the same example file and open it. I get all
labels as [1], at least with the patch. (ii) Put the cursor at the end
and hit return. The new InsetBibitem has label [1] rather than [4],
which is what it seems it should have. (iii) Change the layout of one of
these paragraphs to Standard. Shouldn't the bibitem be erased? (This
could be handled in checkBiblio without too much effort.)
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: Paragraph.h
===
--- Paragraph.h (revision 18413)
+++ Paragraph.h (working copy)
@@ -359,9 +359,11 @@
///
bool hfillExpansion(Row const row, pos_type pos) const;
- /// Check if we are in a Biblio environment.
- /// \retval true if the cursor needs to be moved right.
- bool checkBiblio(bool track_changes);
+ /// Check if we are in a Biblio environment and insert or
+ /// delete InsetBibitems as necessary.
+ /// \retval int 1 to move cursor right; -1 to move it left;
+ /// 0 to leave it where it is.
+ int checkBiblio(bool track_changes);
public:
///
Index: Paragraph.cpp
===
--- Paragraph.cpp (revision 18413)
+++ Paragraph.cpp (working copy)
@@ -2592,7 +2592,7 @@
}
-bool Paragraph::checkBiblio(bool track_changes)
+int Paragraph::checkBiblio(bool track_changes)
{
// Add bibitem insets if necessary
if (layout()-labeltype != LABEL_BIBLIO)
@@ -2606,33 +2606,51 @@
docstring oldkey;
docstring oldlabel;
- // remove bibitems in pos != 0
- // restore them later in pos 0 if necessary
+ // remove a bibitem in pos != 0
+ // restore it later in pos 0 if necessary
// (e.g. if a user inserts contents _before_ the item)
- InsetList::const_iterator it = insetlist.begin();
- InsetList::const_iterator end = insetlist.end();
+ // we're assuming there's only one of these, which there
+ // should be.
+ bool erasedInset = false;
+ InsetList::iterator it = insetlist.begin();
+ InsetList::iterator end = insetlist.end();
for (; it != end; ++it)
if (it-inset-lyxCode() == Inset::BIBITEM_CODE
it-pos 0) {
InsetBibitem * olditem = static_castInsetBibitem *(it-inset);
oldkey = olditem-getParam(key);
oldlabel = olditem-getParam(label);
- eraseChar(it-pos, track_changes);
+ erasedInset = eraseChar(it-pos, track_changes);
+ break;
}
- if (hasbibitem)
- return false;
-
+ //There was an InsetBibitem at the beginning, and we didn't
+ //have to erase one.
+ if (hasbibitem !erasedInset)
+ return 0;
+
+ //There was an InsetBibitem at the beginning and we did have to
+ //erase one. So we give its properties to the beginning inset.
+ if (hasbibitem) {
+ InsetBibitem * inset =
+ static_castInsetBibitem *(insetlist.begin()-inset);
+ if (!oldkey.empty())
+ inset-setParam(key, oldkey);
+ inset-setParam(label, oldlabel);
+ return -1;
+ }
+
+ //There was no inset at the beginning, so we need to create one with
+ //the key and label of the one we erased.
InsetBibitem * inset(new InsetBibitem(InsetCommandParams(bibitem)));
// restore values of previously deleted item in this par.
if (!oldkey.empty())
inset-setParam(key, oldkey);
- if (!oldlabel.empty())
- inset-setParam(label, oldlabel);
+ inset-setParam(label, oldlabel);
insertInset(0, static_castInset *(inset),
Change(track_changes ? Change::INSERTED : Change::UNCHANGED));
- return true;
+ return 1;
}
} // namespace lyx
Index: TextMetrics.cpp
===
--- TextMetrics.cpp (revision 18413)
+++ TextMetrics.cpp (working copy)
@@ -190,10 +190,16 @@
main_text_ = (text_ == buffer.text());
bool changed = false;
- // FIXME: this has nothing to do here and is the reason why text_ is not
- // const.
- if (par.checkBiblio(buffer.params().trackChanges))
+ // FIXME This check ought to be done somewhere else. It is the reason
+ // why text_ is not const. But then, where else to do it?
+ // Well, how can you end up with either (a) a biblio environment that
+ // has no InsetBibitem or (b) a biblio environment
Re: [PATCH] Bug 3650
Richard Heck wrote: NOTE: Some other issues I noticed here, which I'll put in bugzilla if it seems a good idea. (iii) Change the layout of one of these paragraphs to Standard. Shouldn't the bibitem be erased? (This could be handled in checkBiblio without too much effort.) Never mind that suggestion. That would mean too many such checks. It ought to be done where the layout might be changed. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3650
Bernhard Roider wrote:
In general enums are more explicative:
enum CursorMove {
NoMove,
MoveRight,
MoveLeft
}
I did not take a closer look at the code, but shouldn't it be forward
and backward instead of right and left?
I don't think so. The `right' and `left' don't actually move right or
left but just updates the internal counter pos_. That said, it might be
clearer if these were named posForward() and posBackward(). I can make
that simple change if people wish.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3650
Abdelrazak Younes wrote:
Richard Heck wrote:
Index: Paragraph.h
===
--- Paragraph.h(revision 18413)
+++ Paragraph.h(working copy)
@@ -359,9 +359,11 @@
///
bool hfillExpansion(Row const row, pos_type pos) const;
-/// Check if we are in a Biblio environment.
-/// \retval true if the cursor needs to be moved right.
-bool checkBiblio(bool track_changes);
+/// Check if we are in a Biblio environment and insert or
+/// delete InsetBibitems as necessary.
+/// \retval int 1 to move cursor right; -1 to move it left;
+/// 0 to leave it where it is.
+int checkBiblio(bool track_changes);
In general enums are more explicative:
enum CursorMove {
NoMove,
MoveRight,
MoveLeft
}
It occurred to me I actually should do something slightly different,
namely, return the position where the inset was deleted (though it'll be
minus-position) and then check if the cursor was beyond that. If not, it
doesn't need to be moved.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3650
Jürgen Spitzmüller wrote: Richard Heck wrote: The attached addresses http://bugzilla.lyx.org/show_bug.cgi?id=3650. The issues were two. (i) When the old inset was erased, the iterator became invalid, and the attempt to increment it caused an abort; (ii) after clearing that up, a different abort made it clear that the cursor position needed to be updated so it wouldn't be past the end of the text. Testing requested, as well as two commit OKs if it seems all right. This is getting more and more a mess. However, I don't have a better solution. We really should clean up this bibitem issue for 1.6. Yes. I'll leave some notes in the source about this. (iii) Change the layout of one of these paragraphs to Standard. Shouldn't the bibitem be erased? (This could be handled in checkBiblio without too much effort.) As Uwe pointed out, this would break the bibliography. So there's really a larger issue. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-again] Bugs 643, 3047, and 3090
Thanks, Georg, for the comments. I'll take these into account and re-work the code a bit. If you can point me towards the resultfile flag in your playground, I'll have a look at that, too, though perhaps not immediately, as there are more pressing bugs to fix before 1.5.rc1. Richard Georg Baum wrote: Am Freitag, 18. Mai 2007 21:14 schrieb José Matos: On Friday 18 May 2007 7:42:56 pm Richard Heck wrote: The attached patch addresses these bugs, all of which have to do with export, viewing, and the like---ultimately, with the conversion routines. The patch introduces a new conversion flag, usetempdir, which forces the converter to do all its work in a temporary directory created under the lyx_tmpbuf directory. On export, this directory is copied to the directory in which the LyX file is contained. So, if you open /path/file.lyx and FileExportFormat, you will get a directory /path/file.format.conversion/ in which all the files generated by the converter will be found (e.g. the mess that htlatex generates ends up in /path/file.html.conversion/). A flag for the name of that directory does already exist: resultdir. Please use that instead of /path/file.html.conversion/. If you're just viewing, however, you get $LYXTMPDIR/lyx_tmpbufN/format/, and of course that will get deleted when LyX exits (gracefully). As a result, the originaldir flag does not need to be used by any of our converters, and it may be redundant, though there's no harm leaving it, so far as I can see. IMHO it should be removed. It does not fit into the copy everything to temp dir strategy, and complicates the code. In the cases when it was formerly needed (a converter needed to access files in the original dir) a specialized mover can be used nowadays (as is done e.g. for xfig). As you will note, doing this involved adding a new signature to the Converters::convert() routine. I have not changed any of the other calls to this: these are in Importer.cpp, insets/InsetGraphics.cpp, and insets/ExternalSupport.cpp. At least some of these will need modifying before the patch is applied, probably all of them, as I suppose usetempdir could be set for importers and graphics converters and such. IMHO there should only be one interface, and I don't like the new one: If the resulting file name is determined by the converter in some cases, then why not do this always? AFAIK the callers of the converter determine the result from the old name and the format extension anyway, so this should be easy to change. Then there is some error checking missing: If the caller can't deal with a converted directory (e.g. for preview) then it should check that the result is indeed a file and act appropriately if that is not the case. BTW there is another problem in this area that I solved in my playground branch: Some converters don't accept a commandline argument to set the resulting file name, but determine it using their own rules. They only work if these rules match the naming given by LyX, but will fail if a user changes e.g. the extension of a format. I solved this by a new resultfile flag. There are a few other clean-up type things to be done still, too, including fixing indentation, but I haven't done that yet as it would make the diff hard to read. This area looks a mess and I have never quite understood it completely. :-) This area is a big mess indeed. AFAIK the originaldir flag never really worked, and HTML export has been broken for all but the most simple cases for ages. I don't want to look at the patch in detail, but the general direction is sound. Georg -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH-updated] Bug 3650
Attached is a slightly updated version of this patch. OK to commit?
A proper clean-up of this will have to wait a bit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: Paragraph.h
===
--- Paragraph.h (revision 18422)
+++ Paragraph.h (working copy)
@@ -359,9 +359,14 @@
///
bool hfillExpansion(Row const row, pos_type pos) const;
- /// Check if we are in a Biblio environment.
- /// \retval true if the cursor needs to be moved right.
- bool checkBiblio(bool track_changes);
+ /// Check if we are in a Biblio environment and insert or
+ /// delete InsetBibitems as necessary.
+ /// \retval int 1, if we had to add an inset, in which case
+ /// the cursor will need to move cursor forward; -pos, if we deleted
+ /// an inset, in which case pos is the position from which the inset
+ /// was deleted, and the cursor will need to be moved back one if it
+ /// was previously past that position. Return 0 otherwise.
+ int checkBiblio(bool track_changes);
public:
///
Index: Paragraph.cpp
===
--- Paragraph.cpp (revision 18422)
+++ Paragraph.cpp (working copy)
@@ -2592,11 +2592,15 @@
}
-bool Paragraph::checkBiblio(bool track_changes)
+int Paragraph::checkBiblio(bool track_changes)
{
+ //FIXME From JS:
+ //This is getting more and more a mess. ...We really should clean
+ //up this bibitem issue for 1.6. See also bug 2743.
+
// Add bibitem insets if necessary
if (layout()-labeltype != LABEL_BIBLIO)
- return false;
+ return 0;
bool hasbibitem = !insetlist.empty()
// Insist on it being in pos 0
@@ -2606,33 +2610,52 @@
docstring oldkey;
docstring oldlabel;
- // remove bibitems in pos != 0
- // restore them later in pos 0 if necessary
+ // remove a bibitem in pos != 0
+ // restore it later in pos 0 if necessary
// (e.g. if a user inserts contents _before_ the item)
- InsetList::const_iterator it = insetlist.begin();
- InsetList::const_iterator end = insetlist.end();
+ // we're assuming there's only one of these, which there
+ // should be.
+ int erasedInsetPosition = -1;
+ InsetList::iterator it = insetlist.begin();
+ InsetList::iterator end = insetlist.end();
for (; it != end; ++it)
if (it-inset-lyxCode() == Inset::BIBITEM_CODE
it-pos 0) {
InsetBibitem * olditem = static_castInsetBibitem *(it-inset);
oldkey = olditem-getParam(key);
oldlabel = olditem-getParam(label);
- eraseChar(it-pos, track_changes);
+ erasedInsetPosition = it-pos;
+ eraseChar(erasedInsetPosition, track_changes);
+ break;
}
- if (hasbibitem)
- return false;
-
+ //There was an InsetBibitem at the beginning, and we didn't
+ //have to erase one.
+ if (hasbibitem erasedInsetPosition 0)
+ return 0;
+
+ //There was an InsetBibitem at the beginning and we did have to
+ //erase one. So we give its properties to the beginning inset.
+ if (hasbibitem) {
+ InsetBibitem * inset =
+ static_castInsetBibitem *(insetlist.begin()-inset);
+ if (!oldkey.empty())
+ inset-setParam(key, oldkey);
+ inset-setParam(label, oldlabel);
+ return -erasedInsetPosition;
+ }
+
+ //There was no inset at the beginning, so we need to create one with
+ //the key and label of the one we erased.
InsetBibitem * inset(new InsetBibitem(InsetCommandParams(bibitem)));
// restore values of previously deleted item in this par.
if (!oldkey.empty())
inset-setParam(key, oldkey);
- if (!oldlabel.empty())
- inset-setParam(label, oldlabel);
+ inset-setParam(label, oldlabel);
insertInset(0, static_castInset *(inset),
Change(track_changes ? Change::INSERTED : Change::UNCHANGED));
- return true;
+ return 1;
}
} // namespace lyx
Index: TextMetrics.cpp
===
--- TextMetrics.cpp (revision 18422)
+++ TextMetrics.cpp (working copy)
@@ -190,10 +190,20 @@
main_text_ = (text_ == buffer.text());
bool changed = false;
- // FIXME: this has nothing to do here and is the reason why text_ is not
- // const.
- if (par.checkBiblio(buffer.params().trackChanges))
+ // FIXME This check ought to be done somewhere else. It is the reason
+ // why text_ is not const. But then, where else to do it?
+ // Well, how can you end up with either (a) a biblio environment that
+ // has no InsetBibitem or (b) a biblio environment with more than one
+ // InsetBibitem? I think the answer is: when paragraphs are merged;
+ // when layout is set; when material is pasted.
+ int const moveCursor = par.checkBiblio(buffer.params().trackChanges);
+ if (moveCursor 0)
Re: [PATCH-again] Bugs 643, 3047, and 3090
Georg Baum wrote: So, if you open /path/file.lyx and FileExportFormat, you will get a directory /path/file.format.conversion/ in which all the files generated by the converter will be found (e.g. the mess that htlatex generates ends up in/path/file.html.conversion/). A flag for the name of that directory does already exist: resultdir. Please use that instead of /path/file.html.conversion/. I could be wrong, but this seems to do something else. /path/file.html.conversion/ is where the files end up if you're exporting, and the copying happens in Exporter.cpp. The resultdir flag operates in Converter.cpp and seems (though it's hard to tell, since it's not actually used in any of our converters) to inform us where the external converter will have put its output, and then things get moved in Converter.cpp, and then they get moved again in Exporter.cpp, if we're exporting. I also don't think we want to require resultdir to be set whenever usetempdir is. It may well be though (I haven't tried) that setting resultdir with usetempdir is possible and works as one would hope. As a result, the originaldir flag does not need to be used by any of our converters, and it may be redundant, though there's no harm leaving it, so far as I can see. IMHO it should be removed. Have done. When I looked more closely, it caused massive problems: The existing code copies all HTML files found in the original directory to the temporary directory, whether they were created by the converter or not! It's amazing there's no bug report for that. As you will note, doing this involved adding a new signature to the Converters::convert() routine. I have not changed any of the other calls to this: these are in Importer.cpp, insets/InsetGraphics.cpp, and insets/ExternalSupport.cpp. At least some of these will need modifying before the patch is applied, probably all of them, as I suppose usetempdir could be set for importers and graphics converters and such. IMHO there should only be one interface, and I don't like the new one: If the resulting file name is determined by the converter in some cases, then why not do this always? AFAIK the callers of the converter determine the result from the old name and the format extension anyway, so this should be easy to change. Here's an idea: Instead of Converter::convert() returning a boolean, have it return a the location of the converted file as a FileName. It can return an empty one (checkable with FileName::empty()) on error. I'll still need the used_temp_dir boolean as a flag, though, ... Then there is some error checking missing: If the caller can't deal with a converted directory (e.g. for preview) then it should check that the result is indeed a file and act appropriately if that is not the case. as I do NOT want to return a directory. The HTML converter, for example, dumps about a billion files but there is going to be one that the viewer wants, and it's that FileName I want to return, since there's no general way in which to recover it. The temporary directory, on the other hand, can be recovered as the path portion of the file name. Then again, I suppose I could return a std::pairFileName, bool or a std::pairFileName, FileName, with the latter being the temporary directory if one was created, rather than have a bool as an argument. Advice welcome. My intuitions aren't always great here. (I tend to think Perl. Just make it work.) BTW there is another problem in this area that I solved in my playground branch: Some converters don't accept a commandline argument to set the resulting file name, but determine it using their own rules. They only work if these rules match the naming given by LyX, but will fail if a user changes e.g. the extension of a format. I solved this by a new resultfile flag. I think you might have committed this. I see the resultfile flag in the exiting code and was wondering exactly what it did. Again, there's no converter that ships with LyX (i.e., that is configured by configure.py) that sets this. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-updated] Bug 3650
Committed...thanks Uwe and Jurgen
Richard Heck wrote:
Attached is a slightly updated version of this patch. OK to commit?
A proper clean-up of this will have to wait a bit.
Richard
Index: Paragraph.h
===
--- Paragraph.h (revision 18422)
+++ Paragraph.h (working copy)
@@ -359,9 +359,14 @@
///
bool hfillExpansion(Row const row, pos_type pos) const;
- /// Check if we are in a Biblio environment.
- /// \retval true if the cursor needs to be moved right.
- bool checkBiblio(bool track_changes);
+ /// Check if we are in a Biblio environment and insert or
+ /// delete InsetBibitems as necessary.
+ /// \retval int 1, if we had to add an inset, in which case
+ /// the cursor will need to move cursor forward; -pos, if we deleted
+ /// an inset, in which case pos is the position from which the inset
+ /// was deleted, and the cursor will need to be moved back one if it
+ /// was previously past that position. Return 0 otherwise.
+ int checkBiblio(bool track_changes);
public:
///
Index: Paragraph.cpp
===
--- Paragraph.cpp (revision 18422)
+++ Paragraph.cpp (working copy)
@@ -2592,11 +2592,15 @@
}
-bool Paragraph::checkBiblio(bool track_changes)
+int Paragraph::checkBiblio(bool track_changes)
{
+ //FIXME From JS:
+ //This is getting more and more a mess. ...We really should clean
+ //up this bibitem issue for 1.6. See also bug 2743.
+
// Add bibitem insets if necessary
if (layout()-labeltype != LABEL_BIBLIO)
- return false;
+ return 0;
bool hasbibitem = !insetlist.empty()
// Insist on it being in pos 0
@@ -2606,33 +2610,52 @@
docstring oldkey;
docstring oldlabel;
- // remove bibitems in pos != 0
- // restore them later in pos 0 if necessary
+ // remove a bibitem in pos != 0
+ // restore it later in pos 0 if necessary
// (e.g. if a user inserts contents _before_ the item)
- InsetList::const_iterator it = insetlist.begin();
- InsetList::const_iterator end = insetlist.end();
+ // we're assuming there's only one of these, which there
+ // should be.
+ int erasedInsetPosition = -1;
+ InsetList::iterator it = insetlist.begin();
+ InsetList::iterator end = insetlist.end();
for (; it != end; ++it)
if (it-inset-lyxCode() == Inset::BIBITEM_CODE
it-pos 0) {
InsetBibitem * olditem = static_castInsetBibitem
*(it-inset);
oldkey = olditem-getParam(key);
oldlabel = olditem-getParam(label);
- eraseChar(it-pos, track_changes);
+ erasedInsetPosition = it-pos;
+ eraseChar(erasedInsetPosition, track_changes);
+ break;
}
- if (hasbibitem)
- return false;
-
+ //There was an InsetBibitem at the beginning, and we didn't
+ //have to erase one.
+ if (hasbibitem erasedInsetPosition 0)
+ return 0;
+
+ //There was an InsetBibitem at the beginning and we did have to
+ //erase one. So we give its properties to the beginning inset.
+ if (hasbibitem) {
+ InsetBibitem * inset =
+ static_castInsetBibitem *(insetlist.begin()-inset);
+ if (!oldkey.empty())
+ inset-setParam(key, oldkey);
+ inset-setParam(label, oldlabel);
+ return -erasedInsetPosition;
+ }
+
+ //There was no inset at the beginning, so we need to create one with
+ //the key and label of the one we erased.
InsetBibitem * inset(new InsetBibitem(InsetCommandParams(bibitem)));
// restore values of previously deleted item in this par.
if (!oldkey.empty())
inset-setParam(key, oldkey);
- if (!oldlabel.empty())
- inset-setParam(label, oldlabel);
+ inset-setParam(label, oldlabel);
insertInset(0, static_castInset *(inset),
Change(track_changes ? Change::INSERTED :
Change::UNCHANGED));
- return true;
+ return 1;
}
} // namespace lyx
Index: TextMetrics.cpp
===
--- TextMetrics.cpp (revision 18422)
+++ TextMetrics.cpp (working copy)
@@ -190,10 +190,20 @@
main_text_ = (text_ == buffer.text());
bool changed = false;
- // FIXME: this has nothing to do here and is the reason why text_ is not
- // const.
- if (par.checkBiblio(buffer.params().trackChanges))
+ // FIXME This check ought to be done somewhere
Re: [Cvslog] r18419 - in /lyx-devel/trunk/src: frontends/qt4/QLPainter...
Looks sensible to me.
Stefan Schimanski wrote:
STL's vector doesn't give access to the data required by Qt, but
QVector does. So this slight variation of your proposed patch:
// double the size if needed
static QVectorQPoint points(32);
if (np points.size())
points.resize(2 * np);
Will commit if nobody complains.
Stefan
On Sat, May 19, 2007 at 06:51:17PM +0200, Stefan Schimanski wrote:
Here is the patch. Comments?
Wonder if there is something like that in Boost, but didn't find it.
Stefan
Index: src/frontends/qt4/QLPainter.cpp
===
--- src/frontends/qt4/QLPainter.cpp(Revision 18423)
+++ src/frontends/qt4/QLPainter.cpp(Arbeitskopie)
@@ -114,8 +114,15 @@
if (!isDrawingEnabled())
return;
-// Must use new as np is not known at compile time.
-boost::scoped_arrayQPoint points(new QPoint[np]);
+// double the size if needed
+static size_t size = 32;
+static QPoint * points = new QPoint[size];
+if (size_t(np) size) {
+delete[] points;
+while (size_t(np) size)
+size *= 2;
+points = new QPoint[size];
+}
Simpler:
static std::vectorQPoint points;
if (np points.size())
points.resize(2 * np)
Andre'
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bug 1474: Recursive Input
The attached patch partially addresses this bug. Not completely, because
it only checks if a file is including itself and not if a file includes
a file that includes it (etc). The places where the more general check
would need to be done are identified with FIXME RECURSIVE INPUT so that
this can be done later, but I don't have any sense what to do here, and
it's not a terribly common issue, so I'm not going to pursue it now.
As for what to do about recursive includes, I'm issuing a warning when
there's an attempt to output LaTeX or Docbook and then ignoring the
inset. Something similar could be done at the other places, too, so that
the user would be alerted ASAP to the problem. But maybe that should
just be done when the more general fix is in place rather than littering
the code with this kind of warning.
Comments welcome, as always. Seeking OK to commit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: Buffer.cpp
===
--- Buffer.cpp (revision 18423)
+++ Buffer.cpp (working copy)
@@ -1621,7 +1621,10 @@
if (!params().parentname.empty()
theBufferList().exists(params().parentname)) {
Buffer const * buf = theBufferList().getBuffer(params().parentname);
- if (buf)
+ //We need to check if the parent is us...
+ //FIXME RECURSIVE INCLUDE
+ //This is not sufficient, since recursive includes could be downstream.
+ if (buf buf != this)
return buf-getMasterBuffer();
}
Index: insets/InsetInclude.cpp
===
--- insets/InsetInclude.cpp (revision 18423)
+++ insets/InsetInclude.cpp (working copy)
@@ -363,7 +363,12 @@
if (!isLyXFilename(included_file))
return 0;
- return theBufferList().getBuffer(included_file);
+ Buffer * childBuffer = theBufferList().getBuffer(included_file);
+
+ //FIXME RECURSIVE INCLUDES
+ if (childBuffer == buffer)
+ return 0;
+ else return childBuffer;
}
@@ -405,6 +410,18 @@
return 0;
FileName const included_file(includedFilename(buffer, params_));
+
+ //Check we're not trying to include ourselves.
+ //FIXME RECURSIVE INCLUDE
+ //This isn't sufficient, as the inclusion could be downstream.
+ //But it'll have to do for now.
+ if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+ Alert::error(_(Recursive input),
+ bformat(_(Attempted to include file %1$s in itself!
+ Ignoring inclusion.), from_utf8(incfile)));
+ return 0;
+ }
+
Buffer const * const m_buffer = buffer.getMasterBuffer();
// if incfile is relative, make it relative to the master
@@ -560,6 +577,17 @@
string const included_file = includedFilename(buffer, params_).absFilename();
+ //Check we're not trying to include ourselves.
+ //FIXME RECURSIVE INCLUDE
+ //This isn't sufficient, as the inclusion could be downstream.
+ //But it'll have to do for now.
+ if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+ Alert::error(_(Recursive input),
+ bformat(_(Attempted to include file %1$s in itself!
+ Ignoring inclusion.), from_utf8(incfile)));
+ return 0;
+ }
+
// write it to a file (so far the complete file)
string const exportfile = changeExtension(incfile, .sgml);
DocFileName writefile(changeExtension(included_file, .sgml));
@@ -629,7 +657,11 @@
if (loadIfNeeded(buffer, params_)) {
// a file got loaded
Buffer * const tmp = theBufferList().getBuffer(included_file);
- if (tmp) {
+ // make sure the buffer isn't us
+ // FIXME RECURSIVE INCLUDES
+ // This is not sufficient, as recursive includes could be
+ // more than a file away. But it will do for now.
+ if (tmp tmp != buffer) {
// We must temporarily change features.buffer,
// otherwise it would always be the master buffer,
// and nested includes would not work.
[Bug 3561] Comments
I've been studying this bug a bit and think I know where the problem is,
more or less. The attached file is as minimal as I can get it. The
change of font is crucial. Without it, there is no crash.
Font::writeLatexEndChanges we have this code:
if (open_encoding_) {
// We need to close the encoding even if it does not change
// to do correct environment nesting
Encoding const * const ascii = encodings.getFromLyXName(ascii);
int const c = switchEncoding(os, bparams,
runparams.moving_arg, *(runparams.encoding),
*ascii);
BOOST_ASSERT(c 0);
count += c;
runparams.encoding = ascii;
open_encoding_ = false;
}
It's the c0 assertion that's triggering the crash. Now look at the
switchEncoding code that it hits:
int switchEncoding(odocstream os, BufferParams const bparams,
bool moving_arg, Encoding const oldEnc,
Encoding const newEnc)
{
[snip]
docstring const inputenc(from_ascii(newEnc.latexName()));
switch (newEnc.package()) {
case Encoding::none:
return 0;
case Encoding::inputenc: {
[snip]
}
case Encoding::CJK: {
[snip]
}
}
This is going to return 0, since the call to switchEncoding()
essentially hardcoded newEnc as ascii =
encodings.getFromLyXName(ascii), and ascii-package() is
Encoding::none. That's clearly not what was wanted. The comment in
latexWriteEndChanges was: We need to close the encoding even if it does
not change to do correct environment nesting. Passing *ascii doesn't do
that. You could pass a null pointer as a flag to force the encoding
closed, but there are other ways you COULD return 0. But maybe if we put
this right at the very beginning:
if (!newEnc) {
if (oldEnc.package() == Encoding::CJK) {
os \\end{CJK};
return 9;
}
os {}; // ugly hack
return 2;
}
Or something like that.
There's other weirdness here. Why do we get here anyway? This is above:
if (oldEnc.package() == Encoding::none
|| newEnc.package() == Encoding::none)
return 0;
I'm guessing that ought to have more parentheses.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
encoding.lyx
Description: application/lyx
Re: [PATCH] Bug 1474: Recursive Input
This also addresses the new bug 3659.
Richard Heck wrote:
The attached patch partially addresses this bug. Not completely, because
it only checks if a file is including itself and not if a file includes
a file that includes it (etc). The places where the more general check
would need to be done are identified with FIXME RECURSIVE INPUT so that
this can be done later, but I don't have any sense what to do here, and
it's not a terribly common issue, so I'm not going to pursue it now.
As for what to do about recursive includes, I'm issuing a warning when
there's an attempt to output LaTeX or Docbook and then ignoring the
inset. Something similar could be done at the other places, too, so that
the user would be alerted ASAP to the problem. But maybe that should
just be done when the more general fix is in place rather than littering
the code with this kind of warning.
Comments welcome, as always. Seeking OK to commit.
Richard
Index: Buffer.cpp
===
--- Buffer.cpp(revision 18423)
+++ Buffer.cpp(working copy)
@@ -1621,7 +1621,10 @@
if (!params().parentname.empty()
theBufferList().exists(params().parentname)) {
Buffer const * buf =
theBufferList().getBuffer(params().parentname);
- if (buf)
+ //We need to check if the parent is us...
+ //FIXME RECURSIVE INCLUDE
+ //This is not sufficient, since recursive includes could be
downstream.
+ if (buf buf != this)
return buf-getMasterBuffer();
}
Index: insets/InsetInclude.cpp
===
--- insets/InsetInclude.cpp (revision 18423)
+++ insets/InsetInclude.cpp (working copy)
@@ -363,7 +363,12 @@
if (!isLyXFilename(included_file))
return 0;
- return theBufferList().getBuffer(included_file);
+ Buffer * childBuffer = theBufferList().getBuffer(included_file);
+
+ //FIXME RECURSIVE INCLUDES
+ if (childBuffer == buffer)
+ return 0;
+ else return childBuffer;
}
@@ -405,6 +410,18 @@
return 0;
FileName const included_file(includedFilename(buffer, params_));
+
+ //Check we're not trying to include ourselves.
+ //FIXME RECURSIVE INCLUDE
+ //This isn't sufficient, as the inclusion could be downstream.
+ //But it'll have to do for now.
+ if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+ Alert::error(_(Recursive input),
+
bformat(_(Attempted to include file %1$s in itself!
+
Ignoring inclusion.), from_utf8(incfile)));
+ return 0;
+ }
+
Buffer const * const m_buffer = buffer.getMasterBuffer();
// if incfile is relative, make it relative to the master
@@ -560,6 +577,17 @@
string const included_file = includedFilename(buffer,
params_).absFilename();
+ //Check we're not trying to include ourselves.
+ //FIXME RECURSIVE INCLUDE
+ //This isn't sufficient, as the inclusion could be downstream.
+ //But it'll have to do for now.
+ if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+ Alert::error(_(Recursive input),
+
bformat(_(Attempted to include file %1$s in itself!
+
Ignoring inclusion.), from_utf8(incfile)));
+ return 0;
+ }
+
// write it to a file (so far the complete file)
string const exportfile = changeExtension(incfile, .sgml);
DocFileName writefile(changeExtension(included_file, .sgml));
@@ -629,7 +657,11 @@
if (loadIfNeeded(buffer, params_)) {
// a file got loaded
Buffer * const tmp = theBufferList().getBuffer(included_file);
- if (tmp) {
+ // make sure the buffer isn't us
+ // FIXME RECURSIVE INCLUDES
+ // This is not sufficient, as recursive includes could be
+ // more than a file away. But it will do for now.
+ if (tmp tmp != buffer) {
// We must temporarily change features.buffer,
// otherwise it would always be the master buffer,
// and nested includes would not work.
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http
[Fwd: Re: superscript]
Richard Heck wrote: Can you be more specific about the problem? What kind of keyboard are you using? What language encoding? etc? Gyorgy Pota wrote: Dear Users, It has already been raised that, for example, textdegree symbol did not work in the early Lyx 1.5 beta(s). Now I can report that for me there is a number of keyboard symbols, including carets, degree etc. that do not work. They do not appear on the screen either. These are usually inserted using Altgr. I tried Lyx betas 2 and 3 for Windows. What should I do or is this still a bug? With best wishes, Gyorgy Pota I am using an IBM R50e laptop with Hungarian keyboard. The language of the article document is English, the Use language's default encoding option is on. The Use keyboard map option in the Preferences is off, as in the case of Lyx 1.4.4 where everything worked. Many characters can be entered with the use of Altgr key. In the uppermost row of the keybard the key wave line ~ and the accent character ` appear with Altgrey but the others, including the carets up ^ and down ˇ and the degree ° do not. These latters, of course, appear in other software as you perhaps see in this message too. Let me draw your attention to the message lyx-1.5: textdegree http://www.mail-archive.com/[EMAIL PROTECTED]/msg55755.html Bernd Sellentin in the Lyx user's list. Thank you very much for your help. Gyorgy Pota -- Dr. Gyorgy Pota associate professor Institute of Physical Chemistry University of Debrecen H-4010 Debrecen, P. O. Box 7, Hungary Tel.: (36) 52-512-90022383 Fax: (36) 52-512-915 homepage: http://dragon.unideb.hu/~wwwphch/potae.htm private homepage: puma.unideb.hu/~potagy -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3561] Comments
Jürgen Spitzmüller wrote: Richard Heck wrote: I've been studying this bug a bit and think I know where the problem is, more or less. The attached file is as minimal as I can get it. The change of font is crucial. Without it, there is no crash. I think the real problem is really just the view-source widget requesting an invalid encoding change. This whole bug only occurs if that widget is open, with some debug output, you can see that the encodings involved are bogus. Yes, you're right. I'm trying to figure out then why the encoding change is invalid then. This is happening on the update after ControlDocument::dispatchParams() has called setLanguage() and before the other stuff has happened. So there's something that hasnt' happened then that needs to happen. What? One thought, though this would be a pretty extensive change in some ways. I wonder if kernel().dispatch() couldn't take an optional boolean update that, if false, would prevent the updating from being done. It seems as if there are various times when we get sequences of updates right in a row that are pretty pointless. For example, in this very function, there might be several calls to kernel().dispatch(), and every one of them is going to trigger a complete update cycle. That's a waste of time. Probably a lot of time in some cases. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3561] Comments
Jürgen Spitzmüller wrote: Richard Heck wrote: I've been studying this bug a bit and think I know where the problem is, more or less. The attached file is as minimal as I can get it. The change of font is crucial. Without it, there is no crash. I think the real problem is really just the view-source widget requesting an invalid encoding change. This whole bug only occurs if that widget is open, with some debug output, you can see that the encodings involved are bogus. Yes, you're right. I'm trying to figure out then why the encoding change is invalid then. This is happening on the update after ControlDocument::dispatchParams() has called setLanguage() and before the other stuff has happened. So there's something that hasnt' happened then that needs to happen. What? It seems that the problem is that, when the update happens and view source is open oldEnc is Encoding::inputenc, whereas it is Encoding::CJK when you do a normal LaTeX export later. This is ultimately coming from Buffer::params(). So it looks like the answer to my question is that the buffer params haven't been updated at this point, and that is what is causing the invalid output. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: crash tex2lyx
what a weird bug. nice work.
Edwin Leuven wrote:
great detective work!!
this fixes the crash on my side, so this gets an ok from me.
Stefan Schimanski wrote:
The following patch fixes this problem for the cmake build system. I
have not checked the other build systems, maybe similar fixes are
needed there.
The problem basically is that in the inline functions a different
Font class was used than in the .cpp files. This was leading to these
very strange errors.
Stefan
@Peter: ok to commit? Any comment?
with attached doc.
backtrace:
tex2lyx.exe!boost::assertion_failed(const char *
expr=0x005b6c44, const char * function=0x005b6c50, const char *
file=0x005b6cc0, long line=315) Line 39 + 0x8 bytes C++
tex2lyx.exe!boost::shared_ptrlyx::Layout::operator-()
Line 315 + 0x23 bytes C++
tex2lyx.exe!lyx::TextClass::read(const
lyx::support::FileName filename={...}, bool merge=false) Line 455
+ 0x12 bytesC++
tex2lyx.exe!lyx::parse_preamble(lyx::Parser p={...},
std::basic_ostreamchar,std::char_traitschar os={...}, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
forceclass=) Line 502 C++
tex2lyx.exe!lyx::`anonymous
namespace'::tex2lyx(std::basic_istreamchar,std::char_traitschar
is={...}, std::basic_ostreamchar,std::char_traitschar
os={...}) Line 428 + 0x3e bytesC++
tex2lyx.exe!lyx::`anonymous namespace'::tex2lyx(const
lyx::support::FileName infilename={...},
std::basic_ostreamchar,std::char_traitschar os={...}) Line
462 + 0x10 bytesC++
tex2lyx.exe!lyx::tex2lyx(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
infilename=C:/_projects/profs3/internal.tex, const
lyx::support::FileName outfilename={...}) Line 494 + 0x38 bytes
C++
tex2lyx.exe!main(int argc=2, char * * argv=0x003d52f8) Line
554 + 0x35 bytes C++
tex2lyx.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
tex2lyx.exe!mainCRTStartup() Line 403 C
kernel32.dll!7c816fd7()
internal.tex
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-again] Bugs 643, 3047, and 3090
Georg Baum wrote: Am Samstag, 19. Mai 2007 18:45 schrieb Richard Heck: So resultdir should be set if and only if the converter creates a directory by itself. Please make sure that this does work in combination with usetempdir, or make these two flags mutually exclusive (since usetempdir is not really needed if the converter creates a directory itself one could ignore usetempdir if resultdir is set). I'll ignore usetempdir and send a note to lyxerr. The HTML converter, for example, dumps about a billion files but there is going to be one that the viewer wants, and it's that FileName I want to return, since there's no general way in which to recover it. The temporary directory, on the other hand, can be recovered as the path portion of the file name. Then again, I suppose I could return a std::pairFileName, bool or a std::pairFileName, FileName, with the latter being the temporary directory if one was created, rather than have a bool as an argument. Advice welcome. My intuitions aren't always great here. If you do that I think the FileName, bool would be better. But I also think that the simple bool as return value is expressive. What confused me was the fact that there were two signatures. If there is only one, and the name of the converted file is always set by the converter, then I think it is clear. The two signatures were really a temporary thing, allowing me not to mess with the other calls while fixing this one. I wonder whether I should just commit the patch as-is, thus fixing HTML output and ViewHTML for 1.5.0, and do something about cleaning this code up more generally after 1.5.0 is out. My thought is just that changing how convert() works more extensively could lead to problems and would need testing, whereas I know that the current patch only changes the behavior of originaldir/usetempdir and so is safe. Thoughts? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Ctrl-B toggles bold state of a mixed selection
I think this is a matter of getting used to how LyX works. It's true that people coming from other programs will expect the behavior you expected, but that's not the only way it can sensibly work. We can discuss here which way it should work. I can tell what your vote is. ;-) What is definitely a problem is that the Text Styles dialog, which is where I was going to send you for help on this, doesn't work as it should. I've filed a bug report about that: http://bugzilla.lyx.org/show_bug.cgi?id=3680. rh Darren Freeman wrote: Hi all, contrary to the behaviour a user would expect, hitting ctrl-B on a selection with a mixture of bold/non-bold, simply toggles the state leaving the opposite boldness on each character. One normally expects a mixture to first go all bold, then on the next press it all goes non-bold. Otherwise if you have a mixture you have to first go through and select the parts individually to get them all the same. This is particularly annoying where you have included a non-bold period when selecting a word and expected to remove the bold status of that word - you get a bold period which is hard to spot. I guess in this case my above rule should be broken, if the mixture contains everything bold except punctuation the next state should be everything not-bold. Have fun, Darren -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Word count includes notes
Confirmed. I've filed a bug report. Note that Comments and Greyed Out probably should be included, since they are visible in the output. Darren Freeman wrote: Hi all, I believe the word count feature is including text within notes. I think this is incorrect behaviour as notes aren't normally part of the visible output. If you were trying to make up a certain word count you'd be off without knowing it. Have fun, Darren -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH-again] Bugs 643, 3047, and 3090
Abdelrazak Younes wrote: Richard Heck wrote: I wonder whether I should just commit the patch as-is, thus fixing HTML output and ViewHTML for 1.5.0, and do something about cleaning this code up more generally after 1.5.0 is out. My thought is just that changing how convert() works more extensively could lead to problems and would need testing, whereas I know that the current patch only changes the behavior of originaldir/usetempdir and so is safe. Thoughts? I think your approach is sound if you promise to do the proper cleanup after 1.5.0 ;-) Yes, sir. I promise. ;-/ I would really like to have a fully functional html export in 1.5.0. I always have to export to LateX first and run htlatex on it. This is very annoying. Very. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Word count includes notes
I'll try to do it today. Jean-Marc Lasgouttes wrote: Darren == Darren Freeman [EMAIL PROTECTED] writes: Darren Hi all, I believe the word count feature is including text Darren within notes. I think this is incorrect behaviour as notes Darren aren't normally part of the visible output. If you were trying Darren to make up a certain word count you'd be off without knowing Darren it. This is bug 2566: http://bugzilla.lyx.org/show_bug.cgi?id=2566 The fix is not difficult, but I did not find the time to do it. JMarc -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Documentation for Converters, Etc
To get ViewHTML working (to be committed soon), I had to change one of the flags. I took the opportunity then to expand the very minimal documentation about this. I've pasted it below as text. Comments welcome. I'd like to make sure in particular that this is correct, especially the bits about $$s, etc. rh = 3.5 Converters, Formats, and Copiers LyX has a powerful mechanism to convert to and from any file format using external programs. 3.5.1 Formats The first step is to define your file formats, e.g. PDF, if they are not already defined. To do so, open the ToolsPreferences:Converters dialog. Enter a new format name; a new GUI name (used in, e.g., the View and Export menus); and a file extension. These are required. There are also two flags that can be set using the checkboxes in the dialog. The document flag tells LyX that a format is suitable for document export. If this flag is set for a format, and if a suitable conversion route exists, then the format will appear in the FileExport menu. The format will also appear in the View menu if it has a viewer associated with it. (See below.) Pure image formats (e.g.png) should not have this flag set; formats that can both represent vector graphics and documents (e.g.pdf) should have it set. The vector flag tells LyX whether a format can contain vector graphics. This information is used to determine the target format of included graphics for pdflatex export. Included graphics may need to be converted to either pdf, png or jpg, since pdflatex cannot handle other image formats. If an included graphic is not already in pdf, png or jpg format, it is converted to pdf if the vector flag of the format is set, and otherwise to png. A Format can have a Viewer associated with it. For example, you might want to use ghostview to look at PostScript® files, or xdvi to preview the LaTeX output. You can enter the program to use as a viewer (and what options to pass to it) in the Viewer field. You can also modify the viewer associated with a pre-defined format simply by changing what you find in this field, clicking the Modify button, and then (if you're sure you want to do this) clicking the Apply or Save button. For example, to change the dvi viewer, select the DVI format in the dialog, change the viewer to be kdvi (or whatever), and hit Modify. If the operating system has a default viewer associated to a format, this viewer is used instead of the one defined here in the Windows® and OS X versions of LyX. (It is planned to implement this feature on other platforms.) Editors are like viewers: Each Format can have an Editor associated to it, entered in the Editor field, and the editor associated with a format can be altered via the ToolsPreferences:Converters dialog. LyX will launch the associated editor whenever an included file needs to be edited. 3.5.2 Copiers Each Format can have a Copier associated with it. These are defined in the ToolsPreferences:Copiers dialog. Since all conversions from one Format to another take place in a temporary directory, it is sometimes necessary to modify a file before copying it to the temporary directory in order that the conversion may be performed. This is done by the Copier: It copies a file to (or from) the temporary directory and may modify it in the process. 3.5.3 Converters To define a converter from one format to another---e.g., LaTeX to PDF---select the Converters panel. Choose the `From' and `To' formats, and then enter the program to be used in the conversion in the Converter field. You do not have to define converters between all the Formats between which you want to convert. For example, you will note that there is no `LyX to PostScript®' converter, but LyX will export PostScript®. It does so by first creating a LaTeX file (no converter needs to be defined for this) which it then converts to DVI using the `LaTeX to DVI' converter, and then it converts the resulting DVI file to PostScript®. LyX finds such `chains' of converters automatically, and it will always choose the shortest chain possible. You can, though, still define multiple conversion methods between file formats. For example, the standard LyX configuration provides three ways to convert LaTeX to PDF: Directly, using pdflatex; via (DVI and) PostScript®, using ps2pdf; or via DVI, using dvipdfm. To define such alternate chains, you must define multiple target `file formats'. In the standard configuration, for example, formats named `pdf', `pdf2', and `pdf3' are defined, all of which share the extension `pdf'. Several variables can be used in the definition of converters: 00.00. $$s The LyX system directory (e.g., /usr/share/lyx). 00.00. $$i The input file 00.00. $$o The output file 00.00. $$b The base filename of the input file 00.00. $$p The path to the input file In the `Extra Flag' field you can enter as many of the following flags as you wish, separated by commas: 00.00. latex Needs a LaTeX run before conversion.
[Bug 3561] Silly Question
So the crash here is being caused by the assertion BOOST_ASSERT(c0) on line 941 of Font.cpp. Doesn't this seem like overkill? I mean, yes, we'll get invalid LaTeX output, but why the assertion? There's no danger of a crash here. So if I replace the assertion with this: lyxerr Warning: invalid encoding switch in BOOST_CURRENT_FUNCTION endl; the crash goes away and, even better, the ViewSource output is CORRECT. This is because, as I noted earlier, we actually go through several updates in a row here, and it is only the first one that gives incorrect LaTeX, but the user never sees that. Longer term, something more extensive might be done. But will this do for now? rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[Bug 3561] Silly Question
Georg, It was suggested I ask you about this. rh = So the crash here is being caused by the assertion BOOST_ASSERT(c0) on line 941 of Font.cpp. Doesn't this seem like overkill? I mean, yes, we'll get invalid LaTeX output, but why the assertion? There doesn't seem to be any danger of a crash here. So if I replace the assertion with this: lyxerr Warning: invalid encoding switch in BOOST_CURRENT_FUNCTION endl; the crash goes away and, even better, the ViewSource output is CORRECT. This is because, as I noted earlier, we actually go through several updates in a row here, and it is only the first one that gives incorrect LaTeX, but the user never sees that. Longer term, something more extensive might be done. But will this do for now? rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Word count includes notes
Jean-Marc Lasgouttes wrote: Richard I'll try to do it today. This is the kind of stuff that can wait for after 1.5.0... If it were trivial, I'd do it, but it's not. You can't just check for the inset type, as an InsetNote will need to be counted if it's anything but a Type::Note. We could check for that explicitly in countWords, but that'd be hard to maintain. The best solution is probably to have the inset tell us whether we should count it. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Warning Question
Just wanted to bring this to people's attention: #ifdef WITH_WARNINGS #warning This will not work anymore when we have multiple views of the same buffer // In this case, we will have to correct also the cursors held by // other bufferviews. It will probably be easier to do that in a more // automated way in CursorSlice code. (JMarc 26/09/2001) #endif This is from Text2.cpp, around line 1220. Since we do now have multiple views, either there is a bug here or else the warning can be removed. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[Bug 3676] Patch Coming
http://bugzilla.lyx.org/show_bug.cgi?id=3676
Just so no-one else works on it...I've got this fixed but have to do
some cleanup before sending the patch to the list (as well as making the
diff file, since this involved several files). This turns out to be a
very bad bug, one I'm amazed we haven't seen before. The problem is that
the existing code parses a long string of keys and values to find, e.g.,
the year, but to find the year, it's basically just looking for the word
year. You can see the potential issue, which happened to be triggered
by the file posted with the bug but could have been triggered by
@article{dangerous,
title = {The year of living dangerously},
year = 1957, ...}
That's why I'm so surprised we haven't seen this. Obviously, the same
bug could be triggered lots of other ways.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Warning Question
Andre Poenitz wrote: On Mon, May 21, 2007 at 05:59:45PM -0400, Richard Heck wrote: Just wanted to bring this to people's attention: #ifdef WITH_WARNINGS #warning This will not work anymore when we have multiple views of the same buffer Do we officially have multiple views now? I still don't think the core is ready for this. I'm pretty sure the 1.5.beta3 announcement said we did. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Word count includes notes
Darren Freeman wrote: This is the kind of stuff that can wait for after 1.5.0... It sounds trivial but IMHO it's really quite insidious. It's not so much that it's trivial as that there are bigger bugs to be squashed. And, unfortunately, the fix, though, as JMarc said, conceptually easy, involves a lot of work. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: BibTeX entries with similar names causes problems
Confirmed. Should be an easy fix. Darren Freeman wrote: Hi all, I have two BibTeX entries with the following names: IntroFIB, and IntroFIBch2. If I cite the second one, and then go to add the first one, I won't be able to because the Add button is disabled. It looks like the test for already being cited is too general, matching a prefix of what is already there. I think this is a minor bug :) Have fun, Darren -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bug 3692
A very simple patch to fix this bug. OK to commit?
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: QCitationDialog.cpp
===
--- QCitationDialog.cpp (revision 18444)
+++ QCitationDialog.cpp (working copy)
@@ -258,22 +258,25 @@
bool QCitationDialog::isSelected(const QModelIndex idx)
{
QString const str = idx.data().toString();
- return !form_-selected()-stringList().filter(str).isEmpty();
+ return form_-selected()-stringList().contains(str);
+ //return form_-selected()-stringList().indexOf(QRegExp(^ + str + $)) = 0;
}
void QCitationDialog::setButtons()
{
int const arows = availableLV-model()-rowCount();
- addPB-setEnabled(arows0 !isSelected(availableLV-currentIndex()));
+ addPB-setEnabled(arows 0
+ availableLV-currentIndex().isValid()
+ !isSelected(availableLV-currentIndex()));
int const srows = selectedLV-model()-rowCount();
int const sel_nr = selectedLV-currentIndex().row();
deletePB-setEnabled(sel_nr = 0);
upPB-setEnabled(sel_nr 0);
downPB-setEnabled(sel_nr = 0 sel_nr srows - 1);
- applyPB-setEnabled(srows0);
- okPB-setEnabled(srows0);
+ applyPB-setEnabled(srows 0);
+ okPB-setEnabled(srows 0);
}
[Bug 3676] Citation Problems
The attached patch addresses a reported problem with the citation
dialog, but the problem was much more extensive than the bug made
apparent. See:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg117655.html
for a bit more on the nature of the bug.
The fix involves re-working the internal representation of BibTeX data
so that it is not just a
mapstring, docstring
with the string being the key and the docstring being everything else but a
mapstring, mapdocstring, docstring
with the string being the key and the second map associating BibTeX
fields with their values. This simplifies a lot of what goes on
internally and was already suggested by Bernhard Roider in the new
parser code.
It's a biggish patch, but there's a lot less going on here than it seems
at first. Most of it is just a matter of changing the signature of some
method calls, and a lot of it is deleting, since this simplifies a lot
of code. The most substantial changes are in
src/frontends/controllers/frontend_helpers.cpp, with a bit more in
InsetBibtex::fillWithBibKeys().
I've tested this and it seems to work fine. But others should have a
look, too.
Note that this would make it quite trivial to improve the search
functionality of the citation dialog, say, by allowing something similar
to what JabRef does (title=...) or perhaps by including a separate text
field for the key, so you could, say, enter title and ^Frege to do a
regex search on the title field. That would presumably be for later,
though I'd love to go ahead and do this. It'd be great to have.
By the way, are we sure we want the search as you go functionality
currently in the citation dialog? There is notable slowness on my
machine (Athlon 2400+, 1GB), as I've got 500+ BibTeX keys in the dialog
and they all have to be searched on every keypress.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/Buffer.h
===
--- src/Buffer.h (revision 18444)
+++ src/Buffer.h (working copy)
@@ -12,10 +12,11 @@
#ifndef BUFFER_H
#define BUFFER_H
+#include DocIterator.h
#include ErrorList.h
#include InsetList.h
-#include DocIterator.h
+#include frontends/controllers/frontend_helpers.h
#include support/FileName.h
#include support/limited_stack.h
@@ -285,7 +286,7 @@
void validate(LaTeXFeatures ) const;
/// return all bibkeys from buffer and its childs
- void fillWithBibKeys(std::vectorstd::pairstd::string, docstring keys) const;
+ void fillWithBibKeys(biblio::BibKeyList keys) const;
/// Update the cache with all bibfiles in use (including bibfiles
/// of loaded child documents).
void updateBibfilesCache();
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 18445)
+++ src/Buffer.cpp (working copy)
@@ -1317,7 +1317,7 @@
// This is also a buffer property (ale)
-void Buffer::fillWithBibKeys(vectorpairstring, docstring keys)
+void Buffer::fillWithBibKeys(biblio::BibKeyList keys)
const
{
/// if this is a child document and the parent is already loaded
@@ -1343,11 +1343,12 @@
static_castInsetBibitem const (*it);
// FIXME UNICODE
string const key = to_utf8(inset.getParam(key));
- docstring const label = inset.getParam(label);
+ biblio::KeyValMap keyvalmap;
+ keyvalmap[from_ascii(label)] = inset.getParam(label);
DocIterator doc_it(it); doc_it.forwardPos();
- docstring const ref = doc_it.paragraph().asString(*this, false);
- docstring const info = label + TheBibliographyRef + ref;
- keys.push_back(pairstring, docstring(key, info));
+ keyvalmap [from_ascii(ref)] = doc_it.paragraph().asString(*this, false);
+ keyvalmap[biblio::TheBibliographyRef] = biblio::TheBibliographyRef;
+ keys[key] = keyvalmap;
}
}
}
@@ -1705,10 +1706,10 @@
vectordocstring labels;
if (code == Inset::CITE_CODE) {
- vectorpairstring, docstring keys;
+ biblio::BibKeyList keys;
fillWithBibKeys(keys);
- vectorpairstring, docstring ::const_iterator bit = keys.begin();
- vectorpairstring, docstring ::const_iterator bend = keys.end();
+ biblio::BibKeyList::const_iterator bit = keys.begin();
+ biblio::BibKeyList::const_iterator bend = keys.end();
for (; bit != bend; ++bit)
// FIXME UNICODE
Index: src/frontends/controllers/frontend_helpers.h
===
--- src/frontends/controllers/frontend_helpers.h (revision 18444)
+++ src/frontends/controllers/frontend_helpers.h (working copy)
@@ -28,8 +28,17 @@
/** Functions of use to citation and bibtex GUI
Re: [patch] Math macros not imported, Bug #21
I'm sure this would be most welcome to people who exchange LyX files with pure LaTeX users. Stefan Schimanski wrote: I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 Stefan -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3676] Citation Problems
Darren Freeman wrote: On Tue, 2007-05-22 at 02:21 -0400, Richard Heck wrote: By the way, are we sure we want the search as you go functionality currently in the citation dialog? There is notable slowness on my machine (Athlon 2400+, 1GB), as I've got 500+ BibTeX keys in the dialog and they all have to be searched on every keypress. You could make it a config option to turn it off... Or just a checkbox in the dialog. Can you sort the keys alphabetically first? Won't help with regex searches. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] HTML Export Bugs
This patch has been to the list previously and been more or less
approved. I'm sending it again, however, as I've made some additional
changes and it should be tested by at least one other person, I think,
before I commit. If you do test, please test: (i) ViewHTML; (ii)
FileExportHTML; (iii) FileExportHTML again, so that the original
export is over-written; and (iv) please make sure I didn't break
ViewDVI (which I temporarily managed to do on my own machine).
Oh, to get this to work, you'll need to reconfigure so that the
converter definition for Latex-HTML is updated.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: lib/configure.py
===
--- lib/configure.py (revision 18444)
+++ lib/configure.py (working copy)
@@ -348,7 +348,7 @@
rc_entry = [ r'\converter word latex %% ' ])
#
checkProg('a LaTeX - MS Word converter', [htlatex $$i 'html,word' 'symbol/!' '-cvalidate'],
-rc_entry = [ r'\converter latex wordhtml %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex wordhtml %% usetempdir,needaux' ])
#
checkProg('an OpenOffice.org - LaTeX converter', ['w2l -clean $$i'],
rc_entry = [ r'\converter sxwlatex %% ' ])
@@ -359,10 +359,6 @@
checkProg('a LaTeX - Open Document converter', ['oolatex $$i', 'oolatex.sh $$i'],
rc_entry = [ r'\converter latex odt%% latex' ])
#
-#FIXME Looking for the commands needed to make oolatex output sxw instad of odt...
-#checkProg('a LaTeX - OpenOffice.org (sxw) converter', ['oolatex $$i', 'oolatex.sh $$i'],
-#rc_entry = [ r'\converter latex odt%% latex' ])
-# On windows it is called latex2rt.exe
checkProg('a LaTeX - RTF converter', ['latex2rtf -p -S -o $$o $$i', 'latex2rt -p -S -o $$o $$i'],
rc_entry = [ r'\converter latex rtf%% needaux' ])
#
@@ -431,7 +427,7 @@
#
checkProg('a LaTeX - HTML converter', ['htlatex $$i', 'tth -t -e2 -L$$b $$i $$o', \
'latex2html -no_subdir -split 0 -show_section_numbers $$i', 'hevea -s $$i'],
-rc_entry = [ r'\converter latex html %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex html %% usetempdir,needaux' ])
#
path, lilypond = checkProg('a LilyPond - EPS/PDF/PNG converter', ['lilypond'])
if (lilypond != ''):
Index: src/Converter.h
===
--- src/Converter.h (revision 18444)
+++ src/Converter.h (working copy)
@@ -55,10 +55,11 @@
bool latex;
/// The converter is xml
bool xml;
- /// Do we need to run the converter in the original directory?
- bool original_dir;
/// This converter needs the .aux files
bool need_aux;
+ /// This converter should put its files in a separate temporary
+ /// directory
+ bool use_temp_dir;
/// If the converter put the result in a directory, then result_dir
/// is the name of the directory
std::string result_dir;
@@ -123,6 +124,14 @@
support::FileName const orig_from,
std::string const from_format, std::string const to_format,
ErrorList errorList, int conversionflags = none);
+ /// used_tmp_dir is a flag that signals whether our output files were put into
+ /// a temporary directory. Note also that to_file will be changed so that it points
+ /// at the converted file in this case.
+ bool convert(Buffer const * buffer,
+ support::FileName const from_file, support::FileName to_file,
+ support::FileName const orig_from, bool used_temp_dir,
+ std::string const from_format, std::string const to_format,
+ ErrorList errorList, int conversionflags = none);
///
void update(Formats const formats);
///
Index: src/Converter.cpp
===
--- src/Converter.cpp (revision 18444)
+++ src/Converter.cpp (working copy)
@@ -31,7 +31,6 @@
#include support/Path.h
#include support/Systemcall.h
-
namespace lyx {
using support::addName;
@@ -118,7 +117,8 @@
string const c, string const l)
: from(f), to(t), command(c), flags(l),
From(0), To(0), latex(false), xml(false),
- original_dir(false), need_aux(false)
+ need_aux(false),
+ use_temp_dir(false)
{}
@@ -133,8 +133,8 @@
latex = true;
else if (flag_name == xml)
xml = true;
- else if (flag_name == originaldir)
- original_dir = true;
+ else if (flag_name == usetempdir)
+ use_temp_dir = true;
Re: [Bug 3676] Citation Problems
Darren Freeman wrote: Maybe you could search as you go but in another thread? So the input box isn't slowed down while you touch-type. The search restarts every time you modify the search string. Or maybe it starts after a half-second delay of no typing. Yes, a timer would be an option. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] HTML Export Bugs
Herbert Voss wrote:
contains(buffer-filePath(), ' ')) {
Alert::error(_(File name error),
- _(The directory path to the document cannot contain
spaces.));
+ _(The directory path to the document cannot contain
spaces,
+ since your LaTeX installation does not allow them.));
LaTeX is the name of a format and not an installation. This is always called
TeX. All new TeX distributions use pdftex as basic machine, which can handle
spaces in a file name.
Thanks, I'll change the message. I'm not responsible for the test. I
just thought I'd make the message a bit more informative.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] HTML Export Bugs
This is the result of a problem that Uwe noticed the other day with the MikTeX implementation of the htlatex scripts: The scripts will not run properly unless they are run in the same directory as the original file. So you can't run e.g. htlatex C:/path/to/file.tex. You can only run htlatex file.tex. The reason is here: System call: dvips -E -Ppdf -mode ibmvga -D 110 -f C:/tmp/lyx_tmpdir2696a00632/l yx_tmpbuf1/teachers.idv -pp 1 zzC:/tmp/lyx_tmpdir2696a00632/lyx_tmpbuf1/teache rs.ps The filename, directory name, or volume label syntax is incorrect. --- Warning --- System return: 1 zzC:/... indeed isn't a valid path. The solution suggested in some earlier discussion was to ship a small shell script with LyX that would copy the .tex file to the temporary directory and then run htlatex on that file. Thoughts? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Bug 3692
José Matos wrote: On Tuesday 22 May 2007 6:24:41 am Richard Heck wrote: A very simple patch to fix this bug. OK to commit? OK. What do we loose with the removal of the regular expression? Sorry, the patch is confusing. There were no regular expressions there. The ones that appeared were commented out: My other idea for how to fix this if the simple version didn't work. Committed minus the comment. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3676] Citation Problems
Jean-Marc Lasgouttes wrote: Richard The attached patch addresses a reported problem with the Richard citation dialog, but the problem was much more extensive than Richard the bug made apparent. See: Richard http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg117655.html Richard for a bit more on the nature of the bug. I like the idea, but I would propose to keep this kind of patch for after 1.5.0 (apply early to 1.6 and maybe backport to 1.5.x). OK. I'll hold this for now. But I expect we'll see more bug reports about this. It's not that hard to trigger it, and it looks really bad in the dialog itself. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
LyX's Learning Curve [was: Bold toggle]
Darren Freeman wrote:
Secondly, the learning curve is quite steep! Try explaining to somebody that
the right way to type one-point-five-five-microns is to press {C-m, 1.55,
\ , \mu, , C-m, m}. They want to know why they can't just insert a
mu where they want it like in a real word processor. Then they accept it as
an experiment and want to know how the hell you worked it out.
Insertion of Greek characters can be done directly. It depends upon your
keyboard, input methods, and the like. There's a movement afoot to make
it more like it used to be. See here:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg114662.html
That said, part of the way you work it out is to RTFM, which, granted,
people hate to do. Of course that's why 99% of the people who use Word
use it wrongly and have no idea what 98% of the features are.
Don't forget that you also get to do this:
\newcommand\micron{\ \mu \textnormal{m}}
As a math macro of course.
I think it is very important for any features exposed at the UI level to
work in the most intuitive way possible.
Though it's a tribute to Microsoft's market dominance, to be sure, that
the way Word does it essentially defines what is intuitive for many
people, it just doesn't follow that the way Word does it is the best
way. Certainly the LyX developers don't subscribe to that attitude. If
learning to use LyX involves un-learning a lot of what one thought one
knew, well, that's just how it is. Bad habits die hard.
That said, there are undoubtedly improvements that can be made to the
UI, and there are plenty of bugs still to be fixed.
Remember when you were young
and taught yourself to use a computer.. you pushed everything to see
what it did. Most people are afraid of doing that after a number of
unexpected and counter-intuitive results. That's one reason I think
those Cancel buttons should be renamed to Close by 1.5.0 since
Cancel has a well-understood meaning of undo all the changes I made
to this dialog, which encourages experimentation. But when it doesn't
undo the changes... that violates trust like only data loss can.
Point taken. Please remind me which dialogs had this problem.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3676] Citation Problems
By the way, are we sure we want the search as you go functionality currently in the citation dialog? There is notable slowness on my machine (Athlon 2400+, 1GB), as I've got 500+ BibTeX keys in the dialog and they all have to be searched on every keypress. In svn, the search is restrained to the already searched list so only the first keypress search through the full list. Maybe this has changed with you patch. No, I didn't change that. I did mis-state this, though. So consider: Suppose I do a case-insensitive search and type an s. Then the search will narrow the list down to everything that contains s somewhere in the record. That is not likely to narrow it down very much. (Remember that it doesn't just search the keys. Maybe it should.) So now I type an a. That narrows it down to everything that contains sa. Again, little progress. Now I type m. That will weed out a few things, but possibly not very many, especially because I have a lot of annote, abstract, and review fields in the database. (Note here that the current BibTeX parser loads all fields and searches all fields.) So there are going to be three pretty much full DB searches, and the fourth one will likely be quite large as well. Of course, I've chosen a bad case. If I'd type fre, I'd have made more progress. But still it is slow. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3676] Citation Problems
José Matos wrote: On Tuesday 22 May 2007 4:38:23 pm Richard Heck wrote: OK. I'll hold this for now. But I expect we'll see more bug reports about this. It's not that hard to trigger it, and it looks really bad in the dialog itself. If you get one or two people, not necessarily developers, to test this patch and there are no problems it can go in before 1.5.0. With all the split attention right now, it might be best to wait until 1.5.0 is out and then commit this to svn so that it gets tested, early on, along with whatever other bugfixes turn up. But I'll see if anyone steps up to test it. Ricahrd -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
htlatex and Windows
Can someone see if using htlatex.bat rather than htlatex on Windows helps with the can't use pathnames problem? I've found some references to this on the web. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: htlatex and Windows
So does this seem to be the pathname problem? You can run htlatex
file.tex. Can you run htlatex path/file.tex? Can you run htlatex
c:/path/file.tex? If you can run the former, this is fixable, because we
can use the relative pathname.
I'm not sure what to do about this. HTML View and Export have been
broken for ages. They work now on Linux and (I believe) OSX. So one
possibility, absent a fix for Windows, is to alter configure.py so it
only installs the htlatex HTML converter on Linux. I suppose it could
still check for html2latex. The other option would be to try to ship
some python script or something that would fix the problem on Windows.
Richard
Edwin Leuven wrote:
Richard Heck wrote:
Can someone see if using htlatex.bat rather than htlatex on Windows
helps with the can't use pathnames problem? I've found some references
to this on the web.
no luck (works fine if i run htlatex on the .tex file)
C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.html.conversionlatex
\makeatle
tter\def\HCode{\futurelet\HCode\HChar}\def\HChar{\ifx\HCode\def\HCode##1{\Lin
[EMAIL PROTECTED]@mac
[EMAIL PROTECTED],html]{tex4ht}}\let\HCode\documentstyle\
def\documentstyle{\let\documentstyle\HCode\expandafter\def\csname
tex4ht\endcsna
me{#1,html}\def\HCode1{\documentstyle[tex4ht,[EMAIL PROTECTED]
tstyle[tex4ht]}}}\makeatother\HCode .a.b.c.\input
C:/tmp/lyx_tmpdir4220a04156/
lyx_tmpbuf0/classno.tex
This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5)
entering extended mode
LaTeX2e 2005/12/01
Babel v3.8g and hyphenation patterns for english, dumylang,
nohyphenation, fr
ench, dutch, norsk, loaded.
(C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.tex
C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.html.conversionlatex
\makeatle
tter\def\HCode{\futurelet\HCode\HChar}\def\HChar{\ifx\HCode\def\HCode##1{\Lin
[EMAIL PROTECTED]@mac
[EMAIL PROTECTED],html]{tex4ht}}\let\HCode\documentstyle\
def\documentstyle{\let\documentstyle\HCode\expandafter\def\csname
tex4ht\endcsna
me{#1,html}\def\HCode1{\documentstyle[tex4ht,[EMAIL PROTECTED]
tstyle[tex4ht]}}}\makeatother\HCode .a.b.c.\input
C:/tmp/lyx_tmpdir4220a04156/
lyx_tmpbuf0/classno.tex
This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5)
entering extended mode
LaTeX2e 2005/12/01
Babel v3.8g and hyphenation patterns for english, dumylang,
nohyphenation, fr
ench, dutch, norsk, loaded.
(C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.tex
C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.html.conversionlatex
\makeatle
tter\def\HCode{\futurelet\HCode\HChar}\def\HChar{\ifx\HCode\def\HCode##1{\Lin
[EMAIL PROTECTED]@mac
[EMAIL PROTECTED],html]{tex4ht}}\let\HCode\documentstyle\
def\documentstyle{\let\documentstyle\HCode\expandafter\def\csname
tex4ht\endcsna
me{#1,html}\def\HCode1{\documentstyle[tex4ht,[EMAIL PROTECTED]
tstyle[tex4ht]}}}\makeatother\HCode .a.b.c.\input
C:/tmp/lyx_tmpdir4220a04156/
lyx_tmpbuf0/classno.tex
This is pdfeTeX, Version 3.141592-1.30.6-2.2 (MiKTeX 2.5)
entering extended mode
LaTeX2e 2005/12/01
Babel v3.8g and hyphenation patterns for english, dumylang,
nohyphenation, fr
ench, dutch, norsk, loaded.
(C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.tex
C:\tmp\lyx_tmpdir4220a04156\lyx_tmpbuf0\classno.html.conversiontex4ht
\dirchar
C:/tmp/lyx_tmpdir4220a04156/lyx_tmpbuf0/classno.tex
-ic:\tex4ht\texmf\tex4ht\
ht-fonts\ -ec:\tex4ht\texmf\tex4ht\base\win32\tex4ht.env
tex4ht.c (2006-09-13-14:27 Windows MiKTeX)
tex4ht \dirchar
C:/tmp/lyx_tmpdir4220a04156/lyx_tmpbuf0/classno.tex
-ic:\tex4ht\texmf\tex4ht\ht-fonts\
-ec:\tex4ht\texmf\tex4ht\base\win32\tex4ht.env
(C:/Program Files/MiKTeX 2.5/tex4ht/base/win32/tex4ht.env)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/iso8859/1/charset/unicode.4hf)
(C:/Program Files/MiKTeX 2.5/fonts/tfm/adobe/times/ptmri8t.tfm)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/alias/adobe/times/ptmri8t.htf)
Searching `lm-ec.htf' for `ptmri8t.htf'
(C:/Program Files/MiKTeX 2.5/tex4ht/ht-fonts/unicode/lm/lm-ec.htf)
(C:/Program Files/MiKTeX 2.5/fonts/tfm/adobe/times/ptmr8t.tfm)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/alias/adobe/times/ptmr8t.htf)
Searching `lm-ec.htf' for `ptmr8t.htf'
(C:/Program Files/MiKTeX 2.5/tex4ht/ht-fonts/unicode/lm/lm-ec.htf)
(C:/Program Files/MiKTeX 2.5/fonts/tfm/adobe/times/zptmcm7y.tfm)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/alias/adobe/mathptmx/zptmcm7y.htf)
Searching `zpzccmry.htf' for `zptmcm7y.htf'
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/unicode/adobe/mathptm/zpzccmry.htf)
(C:/Program Files/MiKTeX 2.5/fonts/tfm/adobe/times/zptmcm7m.tfm)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/alias/adobe/mathptmx/zptmcm7m.htf)
Searching `zptmcmrm.htf' for `zptmcm7m.htf'
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts/unicode/adobe/mathptm/zptmcmrm.htf)
(C:/Program Files/MiKTeX 2.5/fonts/tfm/adobe/times/zptmcm7t.tfm)
(C:/Program Files/MiKTeX
2.5/tex4ht/ht-fonts
Re: [Bug 3676] Citation Problems
Edwin Leuven wrote:
one thing which should be done is to remove linebreaks in entries,
f.e. if i have an entry like this
@article{doe2000,
title = {My brilliant
new paper},
...}
then the newline in the title is visible in the citation dialog. it
wasn't like this before...
The attached version should fix this. The old code collapsed all
whitespace into a single space, and so I've re-implemented that here.
That wasn't done in the new parser but in the old one (which was still
being used, strangely enough, so that everything got parsed twice), but
I can't think of anything we'd be doing with the BibTeX data that would
prevent us from just doing this in the main parser. Anyway, what I've
done also removes whitespace from the end of an entry. In the existing
code, if you have:
@article(doe2001,
title = { My brilliant other paper };
...}
then the citation dialog will give something like, Jane Doe, My
brilliant other paper , pp. 1-2, with the space before the comma. I
have not removed whitespace from the beginning, though that is easy to
do and there is a comment in the code where it could be done. Thoughts?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/Buffer.h
===
--- src/Buffer.h (revision 18461)
+++ src/Buffer.h (working copy)
@@ -12,10 +12,11 @@
#ifndef BUFFER_H
#define BUFFER_H
+#include DocIterator.h
#include ErrorList.h
#include InsetList.h
-#include DocIterator.h
+#include frontends/controllers/frontend_helpers.h
#include support/FileName.h
#include support/limited_stack.h
@@ -285,7 +286,7 @@
void validate(LaTeXFeatures ) const;
/// return all bibkeys from buffer and its childs
- void fillWithBibKeys(std::vectorstd::pairstd::string, docstring keys) const;
+ void fillWithBibKeys(biblio::BibKeyList keys) const;
/// Update the cache with all bibfiles in use (including bibfiles
/// of loaded child documents).
void updateBibfilesCache();
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 18461)
+++ src/Buffer.cpp (working copy)
@@ -1317,7 +1317,7 @@
// This is also a buffer property (ale)
-void Buffer::fillWithBibKeys(vectorpairstring, docstring keys)
+void Buffer::fillWithBibKeys(biblio::BibKeyList keys)
const
{
/// if this is a child document and the parent is already loaded
@@ -1343,11 +1343,12 @@
static_castInsetBibitem const (*it);
// FIXME UNICODE
string const key = to_utf8(inset.getParam(key));
- docstring const label = inset.getParam(label);
+ biblio::KeyValMap keyvalmap;
+ keyvalmap[from_ascii(label)] = inset.getParam(label);
DocIterator doc_it(it); doc_it.forwardPos();
- docstring const ref = doc_it.paragraph().asString(*this, false);
- docstring const info = label + TheBibliographyRef + ref;
- keys.push_back(pairstring, docstring(key, info));
+ keyvalmap [from_ascii(ref)] = doc_it.paragraph().asString(*this, false);
+ keyvalmap[biblio::TheBibliographyRef] = biblio::TheBibliographyRef;
+ keys[key] = keyvalmap;
}
}
}
@@ -1705,10 +1706,10 @@
vectordocstring labels;
if (code == Inset::CITE_CODE) {
- vectorpairstring, docstring keys;
+ biblio::BibKeyList keys;
fillWithBibKeys(keys);
- vectorpairstring, docstring ::const_iterator bit = keys.begin();
- vectorpairstring, docstring ::const_iterator bend = keys.end();
+ biblio::BibKeyList::const_iterator bit = keys.begin();
+ biblio::BibKeyList::const_iterator bend = keys.end();
for (; bit != bend; ++bit)
// FIXME UNICODE
Index: src/frontends/controllers/frontend_helpers.h
===
--- src/frontends/controllers/frontend_helpers.h (revision 18461)
+++ src/frontends/controllers/frontend_helpers.h (working copy)
@@ -28,8 +28,17 @@
/** Functions of use to citation and bibtex GUI controllers and views */
namespace lyx {
+
namespace biblio {
+
+/// First entry is field, second is value
+typedef std::mapdocstring, docstring KeyValMap;
+/// First entry is the bibliography key, second the data
+typedef std::mapstd::string, std::mapdocstring, docstring BibKeyList;
+static const docstring TheBibliographyRef(from_ascii(@LyXInfo));
+static const docstring TheDataString(from_ascii(@BibTeXData));
+
enum CiteEngine {
ENGINE_BASIC,
ENGINE_NATBIB_AUTHORYEAR,
@@ -69,34 +78,31 @@
std::string const asValidLatexCommand(std::string const input,
CiteEngine const engine);
-/// First entry is the bibliography key, second the data
Re: Lyx to Docbook
Lars Olesen wrote: How do I translate a lyx document to docbook Open DocumentSettingsDocumentClass. In the Document Class drop box, choose DocBook (article) or whatever. Choose OK. (You may get some conversion errors depending upon the document.) Now look under FileExport. You should see DocBook... as an option. - and the other way around? FileImportDocBook Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: 1.5b3 grace-pdf problems
Neal Becker wrote:
Oh, I did get an answer. Unfortunately, I can't seem to find the message
right now, but the answer is, that I need to make that agr-pdf instead of
agr-pdf2.
There was also a discussion that the use of pdf{,2,3} was really a broken
design.
It is confusing, but the point is that there is a difference between a
format and a file type. Converters convert between formats, and
different formats may share a file type. True, one could also for the
definition of multiple converters between pairs of formats, but then
there would also need to be some mechanism for ordering them, since LyX
otherwise wouldn't know how to choose the right one in cases where it is
making that choice. Still, a bugzilla enchancement request nothing this
issue would be in order.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Bug 3676] Citation Problems
Abdelrazak Younes wrote: Richard Heck wrote: So now I type an a. That narrows it down to everything that contains sa. Again, little progress. Now I type m. That will weed out a few things, but possibly not very many, especially because I have a lot of annote, abstract, and review fields in the database. (Note here that the current BibTeX parser loads all fields and searches all fields.) So there are going to be three pretty much full DB searches, and the fourth one will likely be quite large as well. Of course, I've chosen a bad case. If I'd type fre, I'd have made more progress. But still it is slow. I see. I just want to say that I tested this extensively at the time I implemented it (that was before the new parser) and the speed was OK even with a _lot_ of entries. My test case was to load all Bibtex files that come with Miktex. If the speed is now a problem, I guess a check box Find as you type which default to yes is necessary. Yes. I'll do this when I do some other things with that dialog, after 1.5.0. As I said in an earlier message, now that we have parsed BibTeX data, it's trivial to implement the ability to search a particular field, say, title. The only question is what the UI should be: title=whatever, as in JabRef, or two text fields, or a dropbox (which could get its data from the parser), or what. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] HTML Export Bugs
Georg Baum wrote: Richard Heck wrote: This is the result of a problem that Uwe noticed the other day with the MikTeX implementation of the htlatex scripts: The scripts will not run properly unless they are run in the same directory as the original file. Several other converters (e.g. lilypond) have the same limitation. Therefore LyX changes to the temp dir before running the converter. It would even be possible to call the converter with relative filenames, I am not sure anymore why absolute paths are used. Don't know. It was that way before. IMHO if you create a subdirectory LyX should change to that subdirectory before running the converter. It does. The solution suggested in some earlier discussion was to ship a small shell script with LyX that would copy the .tex file to the temporary directory and then run htlatex on that file. Thoughts? The .tex file _is_ in the temporary direcory. All conversions are run in the temp dir, I hope you did not change that. I didn't. I meant it should copy it to the NEW temporary directory, e.g.: /tmp/lyx_098weras/lyx_tmpbuf0/file.html.conversion/ which is where the converted files will be dumped. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Quick test of listings, some small issues
Helge Hafting wrote: Bo Peng wrote: Issues: * The LyX document can't include its own source file as a listing, complaining that the document includes itself. A bit strange perhaps, but this is _not_ a problem with a listing, as the nothing more will be included from the listed source. Suggestion: skip the include loop test for listings. Easy to fix. Yes, that works now with the patch. The document can include itself. :-) I should have noticed this when (partially) fixing the `recursive includes' problem. I didn't. Richard
Re: Skipping lines on cursor down
Stefan Schimanski wrote: I removed the margin now completely and substract 1 in the cursorUp case. This works fine everywhere but the display math. In display math (i.e. a InsetMathHull) the cursor up/down keys are not handled properly. Instead Cursor::bruteFind is used to find the nearest inset. Unfortunately bruteFind uses the pure geometrical distance as a measure to find the nearest inset. This is not what one expects from cursorUp/Down because one only want a nearest inset in the row above. I am currently looking into this I'm glad you're doing this, Stefan. Cursor movement in display math has annoyed me for some time. But I don't understand the math stuff at all. I mean, AT ALL. Richard
symlinks
Is it safe to use the create_symlink function from boost::filesystems? Are there platforms on which we want LyX to run that don't handle symlinks? -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: symlinks
Jean-Marc Lasgouttes wrote: Richard Is it safe to use the create_symlink function from Richard boost::filesystems? Are there platforms on which we want LyX Richard to run that don't handle symlinks? Windows? I thought Windows did do symlinks but not hard links. Google tells me I was wrong---though Vista apparently does support true symlinks. I suppose that's one good thing about it. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: symlinks
Jean-Marc Lasgouttes wrote:
Richard Is it safe to use the create_symlink function from
Richard boost::filesystems? Are there platforms on which we want LyX
Richard to run that don't handle symlinks?
Windows?
So does this seems sensible?
namespace {
// A little helper for what follows
// Throws fs::filesystem_error
void forceSymlink(string const target, string const link)
{
if (fs::exists(link))
fs::remove(link);
#ifdef _WIN32
fs::copy_file(target, link);
#else
fs::create_symlink(target, link);
#endif
}
}
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Wiki Bug List
Should the critical and major bug lists also check the milestone? I've just reset 1474 to milestone 1.6.0, because I'm morally certainly no-one is going to fix such an obscure crash before 1.5.0. But it still shows up on the list rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Wiki Bug List
Abdelrazak Younes wrote: Richard Heck wrote: Should the critical and major bug lists also check the milestone? Yes IMO. OK, then. Done. I can't do it for regressions, as too many of those have no milestone set and maybe shouldn't. But I can try to go through these at some point. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: symlinks
Jean-Marc Lasgouttes wrote: Richard So does this seems sensible? Why do you want symlinks actually? It's not a big deal, but the solution I've worked out to various problems with the converter code (e.g., in the case of htlatex) involves copying the file we're converting from (infile, in the code), and possibly also the aux file and bbl file, into a (new) temporary directory LYXTMP/file.format.conversion and doing the conversion there. Copying is fine, but a waste if we can symlink to the files. As I said, not a big deal, but more efficient with symlinks. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Wiki Bug List
Jean-Marc Lasgouttes wrote: Richard Should the critical and major bug lists also check the Richard milestone? I've just reset 1474 to milestone 1.6.0, because Richard I'm morally certainly no-one is going to fix such an obscure Richard crash before 1.5.0. But it still shows up on the list We also have or should have a 1.5.x milestone for bugs that (c|s)hould be fixed in the 1.5 timeframe (because they look easy enough). And you're the guy who can add that, right? rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] HTML Export
Enrico (and anyone else who is interested),
Can you try one and let me know if it works properly on Windows? I
believe it should, even with the broken htlatex. The idea is to copy
whatever files we need to the temporary conversion directory. Then we
can do everything without paths.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: lib/configure.py
===
--- lib/configure.py (revision 18454)
+++ lib/configure.py (working copy)
@@ -348,7 +348,7 @@
rc_entry = [ r'\converter word latex %% ' ])
#
checkProg('a LaTeX - MS Word converter', [htlatex $$i 'html,word' 'symbol/!' '-cvalidate'],
-rc_entry = [ r'\converter latex wordhtml %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex wordhtml %% usetempdir,needaux' ])
#
checkProg('an OpenOffice.org - LaTeX converter', ['w2l -clean $$i'],
rc_entry = [ r'\converter sxwlatex %% ' ])
@@ -359,10 +359,6 @@
checkProg('a LaTeX - Open Document converter', ['oolatex $$i', 'oolatex.sh $$i'],
rc_entry = [ r'\converter latex odt%% latex' ])
#
-#FIXME Looking for the commands needed to make oolatex output sxw instad of odt...
-#checkProg('a LaTeX - OpenOffice.org (sxw) converter', ['oolatex $$i', 'oolatex.sh $$i'],
-#rc_entry = [ r'\converter latex odt%% latex' ])
-# On windows it is called latex2rt.exe
checkProg('a LaTeX - RTF converter', ['latex2rtf -p -S -o $$o $$i', 'latex2rt -p -S -o $$o $$i'],
rc_entry = [ r'\converter latex rtf%% needaux' ])
#
@@ -431,7 +427,7 @@
#
checkProg('a LaTeX - HTML converter', ['htlatex $$i', 'tth -t -e2 -L$$b $$i $$o', \
'latex2html -no_subdir -split 0 -show_section_numbers $$i', 'hevea -s $$i'],
-rc_entry = [ r'\converter latex html %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex html %% usetempdir,needaux' ])
#
path, lilypond = checkProg('a LilyPond - EPS/PDF/PNG converter', ['lilypond'])
if (lilypond != ''):
Index: src/Converter.h
===
--- src/Converter.h (revision 18461)
+++ src/Converter.h (working copy)
@@ -55,10 +55,11 @@
bool latex;
/// The converter is xml
bool xml;
- /// Do we need to run the converter in the original directory?
- bool original_dir;
/// This converter needs the .aux files
bool need_aux;
+ /// This converter should put its files in a separate temporary
+ /// directory
+ bool use_temp_dir;
/// If the converter put the result in a directory, then result_dir
/// is the name of the directory
std::string result_dir;
@@ -123,6 +124,14 @@
support::FileName const orig_from,
std::string const from_format, std::string const to_format,
ErrorList errorList, int conversionflags = none);
+ /// used_tmp_dir is a flag that signals whether our output files were put into
+ /// a temporary directory. Note also that to_file will be changed so that it points
+ /// at the converted file in this case.
+ bool convert(Buffer const * buffer,
+ support::FileName const from_file, support::FileName to_file,
+ support::FileName const orig_from, bool used_temp_dir,
+ std::string const from_format, std::string const to_format,
+ ErrorList errorList, int conversionflags = none);
///
void update(Formats const formats);
///
Index: src/Converter.cpp
===
--- src/Converter.cpp (revision 18461)
+++ src/Converter.cpp (working copy)
@@ -31,6 +31,7 @@
#include support/Path.h
#include support/Systemcall.h
+#include boost/filesystem/operations.hpp
namespace lyx {
@@ -63,8 +64,8 @@
using std::distance;
namespace Alert = lyx::frontend::Alert;
+namespace fs = boost::filesystem;
-
namespace {
string const token_from($$i);
@@ -118,7 +119,8 @@
string const c, string const l)
: from(f), to(t), command(c), flags(l),
From(0), To(0), latex(false), xml(false),
- original_dir(false), need_aux(false)
+ need_aux(false),
+ use_temp_dir(false)
{}
@@ -133,8 +135,8 @@
latex = true;
else if (flag_name == xml)
xml = true;
- else if (flag_name == originaldir)
- original_dir = true;
+ else if (flag_name == usetempdir)
+ use_temp_dir = true;
else if (flag_name == needaux)
need_aux = true;
else if (flag_name == resultdir)
@@ -145,6 +147,10 @@
Re: htlatex and Windows
Enrico Forestieri wrote: On Wed, May 23, 2007 at 12:00:58PM -0400, Richard Heck wrote: I tested the patch on linux and I found some quirks. The least important is that when exporting to html, the export dir is filled with byproduct files such as .dvi, .aux, .log, .idv, and others which have nothing to do with the export itself. These files are generated by htlatex, which is calling pplatex repeatedly, and they are therefore over-writing files that the previous latex conversion may have done. So they're actually new files, and the script should probably be checking not just for files that didn't exist but for ones newly generated, since (for all we know) they are part of the conversion. The most important is that dvipng cannot find graphics files, which are therefore left blank. I think that this is due to the fact that they are not in the directory which is the current one when htlatex is called. Yes, that would be the reason, and it is obviously a problem. Notice that both problems above are avoided when using the wrapper for htlatex that I posted previously. So, my proposal is to convert that script in python, place it in the lib/scripts directory and use it as the converter on all platforms when htlatex is detected. I'll think about this further. I'd like to have something more general than htlatex---something that would work whenever we need a bunch of files to be generated. So I think something like this should probably be put into the Converter.cpp code directly. I'll implement this when I get a chance, probably tonight. Should be pretty painless. Mmm... my impression is that this is less straightforward than it seems... Right you were. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] HTML Export
Never mind...see the other message.
Enrico Forestieri wrote:
On Wed, May 23, 2007 at 06:04:59PM -0400, Richard Heck wrote:
Enrico (and anyone else who is interested),
Can you try one and let me know if it works properly on Windows? I
believe it should, even with the broken htlatex. The idea is to copy
whatever files we need to the temporary conversion directory. Then we
can do everything without paths.
I get the following errors when compiling:
if g++ -DHAVE_CONFIG_H -I. -I../../src -I. -I../../boost -Wno-uninitialized
-O2 -MT Converter.o -MD -MP -MF .deps/Converter.Tpo -c -o Converter.o
../../src/Converter.cpp; \
then mv -f .deps/Converter.Tpo .deps/Converter.Po; else rm -f
.deps/Converter.Tpo; exit 1; fi
../../src/Converter.cpp: In member function `bool
lyx::Converters::convert(const lyx::Buffer*, const lyx::support::FileName,
lyx::support::FileName, const lyx::support::FileName, bool, const
std::string, const std::string, lyx::ErrorList, int)':
../../src/Converter.cpp:557: error: `auxname' undeclared (first use this
function)
../../src/Converter.cpp:557: error: (Each undeclared identifier is reported
only once for each function it appears in.)
../../src/Converter.cpp:558: error: `bblname' undeclared (first use this
function)
../../src/Converter.cpp:560: error: expected primary-expression before catch
../../src/Converter.cpp:560: error: expected `;' before catch
../../src/Converter.cpp:562: error: expected `catch' before res
../../src/Converter.cpp:562: error: expected `(' before res
../../src/Converter.cpp:562: error: `res' is not a type
../../src/Converter.cpp:562: error: invalid catch parameter
../../src/Converter.cpp:562: error: expected `)' before '=' token
../../src/Converter.cpp:562: error: expected `{' before '=' token
../../src/Converter.cpp:562: error: expected primary-expression before '='
token
../../src/Converter.cpp:591: error: invalid initialization of reference of
type 'const std::string' from expression of type 'lyx::support::FileName'
../../src/support/filetools.h:240: error: in passing argument 2 of `const
lyx::support::FileName lyx::support::makeAbsPath(const std::string, const
std::string)'
../../src/Converter.cpp:650: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:650: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:692: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:692: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:705: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:705: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:719: error: expected primary-expression before
namespace
../../src/Converter.cpp:719: error: expected `;' before namespace
../../src/Converter.cpp:737: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:737: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:780: error: expected primary-expression before void
../../src/Converter.cpp:780: error: expected `;' before void
../../src/Converter.cpp:795: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:795: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:810: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:810: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:821: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:821: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:832: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:832: error: expected `,' or `;' before '{' token
../../src/Converter.cpp:840: error: a function-definition is not allowed here
before '{' token
../../src/Converter.cpp:840: error: expected `,' or `;' before '{' token
../../src/Converter.cpp: At global scope:
../../src/Converter.cpp:845: error: expected `}' at end of input
make[3]: *** [Converter.o] Error 1
make[3]: Leaving directory `/usr/local/src/lyx/lyx-devel/build-cygwin/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/lyx/lyx-devel/build-cygwin/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/local/src/lyx/lyx-devel/build-cygwin/src'
make: *** [all-recursive] Error 1
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Fix crash 2199
The attached addresses http://bugzilla.lyx.org/show_bug.cgi?id=2199,
crash on inclusion of files on which lyx2lyx chokes. The problem seems
to have been with the logic generally. It seems to have been assumed
that a file that could not be loaded wasn't a LyX file at all, but the
buffer for it was left open.
There's another logic issue I've fixed along the way. I'd appreciate if
someone would look at this, too. It's the return statement I've put
after if (runparams.inComment || runparams.dryrun). It doesn't seem to
me that we should be doing all the other stuff in this case, but I could
be wrong.
Seeking two OKs to commit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: InsetInclude.cpp
===
--- InsetInclude.cpp (revision 18481)
+++ InsetInclude.cpp (working copy)
@@ -389,12 +389,14 @@
if (!fs::exists(included_file.toFilesystemEncoding()))
return false;
buf = theBufferList().newBuffer(included_file.absFilename());
- if (!loadLyXFile(buf, included_file))
+ if (!loadLyXFile(buf, included_file)) {
+ //close the buffer we just opened
+ theBufferList().close(buf, false);
return false;
+ }
}
- if (buf)
- buf-setParentName(parentFilename(buffer));
- return buf != 0;
+ buf-setParentName(parentFilename(buffer));
+ return true;
}
@@ -416,7 +418,9 @@
//FIXME RECURSIVE INCLUDE
//This isn't sufficient, as the inclusion could be downstream.
//But it'll have to do for now.
- if (!isListings(params_) buffer.fileName() == included_file.toFilesystemEncoding()) {
+ if (!isListings(params_)
+ buffer.fileName() == included_file.toFilesystemEncoding())
+ {
Alert::error(_(Recursive input),
bformat(_(Attempted to include file %1$s in itself!
Ignoring inclusion.), from_utf8(incfile)));
@@ -435,8 +439,9 @@
// write it to a file (so far the complete file)
string const exportfile = changeExtension(incfile, .tex);
- string const mangled = DocFileName(changeExtension(included_file.absFilename(),
- .tex)).mangledFilename();
+ string const mangled =
+ DocFileName(changeExtension(included_file.absFilename(),.tex)).
+ mangledFilename();
FileName const writefile(makeAbsPath(mangled, m_buffer-temppath()));
if (!runparams.nice)
@@ -447,8 +452,11 @@
if (runparams.inComment || runparams.dryrun)
// Don't try to load or copy the file
- ;
- else if (loadIfNeeded(buffer, params_)) {
+ return true;
+ else if (isLyXFilename(included_file.absFilename())) {
+ if (!loadIfNeeded(buffer, params_))
+ return false;
+
Buffer * tmp = theBufferList().getBuffer(included_file.absFilename());
if (tmp-params().textclass != m_buffer-params().textclass) {
[PATCH] Trivial patch to fix warning
The attached removes a few pointless calls from QInclude.cpp that do
nothing but cause a warning to be written to the console. OK to commit?
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/frontends/qt4/QInclude.cpp
===
--- src/frontends/qt4/QInclude.cpp (revision 18481)
+++ src/frontends/qt4/QInclude.cpp (working copy)
@@ -276,10 +276,8 @@
int const item = dialog_-typeCO-currentIndex();
if (item == 0) {
params.setCmdName(include);
- params.setOptions(string());
} else if (item == 1) {
params.setCmdName(input);
- params.setOptions(string());
} else if (item == 3) {
params.setCmdName(lstinputlisting);
// the parameter string should have passed validation
@@ -296,7 +294,6 @@
params.setCmdName(verbatiminput*);
else
params.setCmdName(verbatiminput);
- params.setOptions(string());
}
controller().setParams(params);
}
Re: symlinks
Andre Poenitz wrote: On Wed, May 23, 2007 at 04:09:50PM -0400, Richard Heck wrote: Is it safe to use the create_symlink function from boost::filesystems? Are there platforms on which we want LyX to run that don't handle symlinks? You mean Windows? Except Vista, as I've learned. I had thought Windows did do symlinks but not hard links, but apparently only by cheating. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Bug 3667
The attached patch fixes this bug: crash on attempt to load non-existent
included document. The problem was that the parent name of the current
buffer was being set even if the document was not loaded (hit cancel)
and, if the document is not loaded, then the current buffer doesn't
change, which means we're setting the parent name of the current buffer
to be that of the current buffer, which leads to a loop. The fix is
trivial once the problem is identified.
Seeking two OKs to commit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp (revision 18481)
+++ src/LyXFunc.cpp (working copy)
@@ -1413,18 +1413,20 @@
BOOST_ASSERT(lyx_view_);
FileName const filename =
makeAbsPath(argument, lyx_view_-buffer()-filePath());
- setMessage(bformat(_(Opening child document %1$s...),
- makeDisplayPath(filename.absFilename(;
view()-saveBookmark(false);
string const parentfilename = lyx_view_-buffer()-fileName();
if (theBufferList().exists(filename.absFilename()))
lyx_view_-setBuffer(theBufferList().getBuffer(filename.absFilename()));
else
-lyx_view_-loadLyXFile(filename);
- // Set the parent name of the child document.
- // This makes insertion of citations and references in the child work,
- // when the target is in the parent or another child document.
- lyx_view_-buffer()-setParentName(parentfilename);
+if (lyx_view_-loadLyXFile(filename)) {
+ // Set the parent name of the child document.
+ // This makes insertion of citations and references in the child work,
+ // when the target is in the parent or another child document.
+ lyx_view_-buffer()-setParentName(parentfilename);
+ setMessage(bformat(_(Opening child document %1$s...),
+ makeDisplayPath(filename.absFilename(;
+} else
+ setMessage(_(Document not loaded.));
break;
}
Re: [PATCH] HTML Export Bugs
Georg Baum wrote: I didn't. I meant it should copy it to the NEW temporary directory, e.g.: /tmp/lyx_098weras/lyx_tmpbuf0/file.html.conversion/ which is where the converted files will be dumped. Why not do that in LyX (with the copier to fix paths of included files) and call the converter with the copied file, with the current working directory being the new temp dir? In fact I assumed that you did that. In theory it wastes some disk space and time for copying, but I believe that you won't notice that in practice and the benefit of not having to create a wrapper script outweighs the disadvantage. That's the approach I'm now taking, more or less, as Enrico found yet further problems. He also suggested a simpler way, namely: note the time when we start the conversion; then look at the modification times of the files after the conversion to see which ones got generated. There could be an issue if the converter runs really fast, so I'll probably end up also having to keep a simple list of what files were there in the first place. In any event, the idea is then to have convert() return the list of generated files as a vectorFileName (thus implementing an earlier suggestion of yours, though more generally), and the Exporter can do with that list as it will. This is indeed simpler, since if we copy everything to the new tempdir, then we still need to know what we put there and what the converter put there, and of course it's possible the converter will over-write some of the files we put there, which may then need to be copied back to the tempdir for the next converter to use, so we need to check the modification times anyway. There is an issue here about the copiers, since they expect to get a single file to play with. (At this point, it seems pretty obvious this won't make 1.5.0, by the way. This was supposed to be a lot simpler! And there are other bugs to fix that are more pressing.) Files with the right extension can be passed to the copier for the relevant format. But other generated files---e.g., png's in the case of htlatex---would need either just to be copied directly or passed to copier for some format associated with that extension. I think the former may be enough, as associated files will probably not be the kinds of files that need internal stuff changed, though they could be, in principle. Thoughts? Input always welcome. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
[PATCH] Make View HTML Work
The attached simple patch makes ViewHTML work again on all platforms,
by removing the originaldir flag. Export does not work at this point,
but it didn't work anyway. A proper fix for this problem will appear
shortly after 1.5.0 goes out, but it's become clear that I'm not going
to get that working soon enough, as there are just too many issues.
(Note that this partially reverts an earlier patch that added the
originaldir flag to the LaTeX-Word converter.)
Seeking the OK to commit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Index: configure.py
===
--- configure.py (revision 18454)
+++ configure.py (working copy)
@@ -348,7 +348,7 @@
rc_entry = [ r'\converter word latex %% ' ])
#
checkProg('a LaTeX - MS Word converter', [htlatex $$i 'html,word' 'symbol/!' '-cvalidate'],
-rc_entry = [ r'\converter latex wordhtml %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex wordhtml %% needaux' ])
#
checkProg('an OpenOffice.org - LaTeX converter', ['w2l -clean $$i'],
rc_entry = [ r'\converter sxwlatex %% ' ])
@@ -431,7 +431,7 @@
#
checkProg('a LaTeX - HTML converter', ['htlatex $$i', 'tth -t -e2 -L$$b $$i $$o', \
'latex2html -no_subdir -split 0 -show_section_numbers $$i', 'hevea -s $$i'],
-rc_entry = [ r'\converter latex html %% originaldir,needaux' ])
+rc_entry = [ r'\converter latex html %% needaux' ])
#
path, lilypond = checkProg('a LilyPond - EPS/PDF/PNG converter', ['lilypond'])
if (lilypond != ''):
Re: [PATCH] Bug 1474: Recursive Input
José Matos wrote:
Richard The attached patch partially addresses this bug. Not
Richard completely, because it only checks if a file is including
Richard itself and not if a file includes a file that includes it
Richard (etc). The places where the more general check would need to
Richard be done are identified with FIXME RECURSIVE INPUT so that
Richard this can be done later, but I don't have any sense what to do
Richard here, and it's not a terribly common issue, so I'm not going
Richard to pursue it now.
This looks good, except for tabs in the snippet below (before the bformat):
+//Check we're not trying to include ourselves.
+//FIXME RECURSIVE INCLUDE
+//This isn't sufficient, as the inclusion could be downstream.
+//But it'll have to do for now.
+if (buffer.fileName() == included_file.toFilesystemEncoding()) {
+Alert::error(_(Recursive input),
+
bformat(_(Attempted to include file %1$s in itself!
+
Ignoring inclusion.), from_utf8(incfile)));
Is this in?
Yes, at 18445.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: symlinks
[EMAIL PROTECTED] wrote: On Thu, 24 May 2007, Richard Heck wrote: Andre Poenitz wrote: On Wed, May 23, 2007 at 04:09:50PM -0400, Richard Heck wrote: Is it safe to use the create_symlink function from boost::filesystems? Are there platforms on which we want LyX to run that don't handle symlinks? You mean Windows? Except Vista, as I've learned. I had thought Windows did do symlinks but not hard links, but apparently only by cheating. Windows can do something similar to symlinks, but only linking to a directory - not to a file. Some special software is needed to create these from the command line. I don't remember what these are called at the moment, but if you're interested I can find out. No, it's not that big a deal, and the approach to the export issues that used this idea died, anyway. But thanks. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Another cursor movement bug/feature
Abdelrazak Younes wrote: Stefan Schimanski wrote: Is it a bug or a feature that the cursor does not enter insets from the right in the text? Bug IMHO. But I seem to recall that if there is some text just after the inset in the same line, this works properly. Bug. And yes, the problem only arises when the inset is the last thing on the line. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] HTML Export Bugs
Georg Baum wrote: Richard Heck wrote: That's the approach I'm now taking, more or less, as Enrico found yet further problems. He also suggested a simpler way, namely: note the time when we start the conversion; then look at the modification times of the files after the conversion to see which ones got generated. There could be an issue if the converter runs really fast, I don't think so. Modification times are stored with a very fine precision (at least on ext3, but I don't believe that it is special here). How do I get at these highly precise times? The boost file_write_time() function returns a time_t, which seems to be in seconds. (As you say, this may not work anyway.) so I'll probably end up also having to keep a simple list of what files were there in the first place. In any event, the idea is then to have convert() return the list of generated files as a vectorFileName (thus implementing an earlier suggestion of yours, though more generally), and the Exporter can do with that list as it will. This is indeed simpler, since if we copy everything to the new tempdir, then we still need to know what we put there and what the converter put there, and of course it's possible the converter will over-write some of the files we put there, which may then need to be copied back to the tempdir for the next converter to use, so we need to check the modification times anyway. That sounds very complicated. Do usetempdir converters really need to be supported in the middle of the conversion chain? AFAIK we are only talking about html converters here, and those occur only at the end, so it would be enough to simply copy the whole directory (and issue some warnign if such a converter is used elsewhere). That directory will for sure contain too many files, but it is impossible anyway to tell which generated files are needed wnd which are not needed, so it is IMHO no problem if some files like the aux files are in the directory that is finally copied. The only converters I know of that generate multiple files are the HTML converters. But who knows what else people might want to use. What you suggest may be the only workable solution. And if you just do it all in the main temporary directory, then such converters will work in the middle of the chain, as long as they don't mess with the wrong files. As you say, copying all of that over will copy unneeded files, but there's no easy way to tell which ones are needed, and people will just have to sort that out for themselves. So I'm thinking the right flag is something like multifile, which signals that the converter generates multiple files. The associated behavior would then be copying the whole temporary directory over to a subdirectory of the buffer's file directory. At least then we don't litter /home/rgheck/files/ (or whatever) with garbage. (And then this maybe could make 1.5.0.) Seem reasonable? Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
