[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
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? Andre'
Re: [Bug 3676] Citation Problems
On Wed, May 23, 2007 at 07:51:31PM +0100, José Matos wrote: On Wednesday 23 May 2007 7:09:58 am Andre Poenitz wrote: I guess it would be enough to throw just once and make up the other five... I have made it finally using old methods. :-) You mean by killing the opponents? Is that still legal in Portugal? Andre'
Re: [PATCH] lstinputlisting in InsetInclude should also increase listing counter, bug 3708
José Matos wrote: I will wait for Jürgen's input on this one. :-) I cannot test now, but (apart from some formatting issues, i.e. line lengths) it looks sensible to me. Jürgen
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
Re: [PATCH] HTML Export Bugs
Richard Heck wrote: 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. I know, because it was me who changed it from relative to absolute paths ;-) What I don't know anymore are the reasons for doing so, and whether they do still exist. 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. 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. Georg
[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
Re: [patch] Partial fix for cursor position before Inset
On 5/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 08:51:20AM +0300, Elazar Leibovich wrote: I documented the problem in the patch itself. I suspect that the reason it didn't happen in previous releases is, that the boundary variable was setted correctly. I don't really understand what does the boundary variable do, but I think it means am I just in front of a math inset?. The boundary flag tells you whether you are conceptually 'behind the letter in front' or 'in front of the letter behind'. Can you give me a situation in which this matters, and explain me the difference. What you said was in the source documentation, but I don't understand the difference. I am not sure I like the concept (I'd rather have boxes in boxes in boxes) but simply removing the boundary stuff indroduces a lot of other problems that are not easily solved either. Andre'
Re: How can I compare two Insets?
On 5/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote: Well, I'm in cursorX() so I'm having BufferView bv, CursorSlice sl, and finally boundary. Which does nothing AFAIK, it's just always FALSE. I suspect that it's supposed to tell you whether or not the cursor is right in front of an inset, but not in it, apparently it's broken. Your suspicion is wrong. I case you'd stop top-posting I might even be tempted to give a longer explanation. One guy says be louder, other say stop top posting, what should I do then? Anyhow I'd love a longer explanation. Andre'
[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: 2007 LyX Meeting: Invitation
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Weather: probably rather warm, 20-28 C. May rain, but rarely Martin very long. So, what about those insects? JMarc
Re: [PATCH] Bug 3667
Richard == Richard Heck [EMAIL PROTECTED] writes: Richard The attached patch fixes this bug: crash on attempt to load Richard non-existent included document. The problem was that the Richard parent name of the current buffer was being set even if the Richard document was not loaded (hit cancel) and, if the document Richard is not loaded, then the current buffer doesn't change, which Richard means we're setting the parent name of the current buffer to Richard be that of the current buffer, which leads to a loop. The fix Richard is trivial once the problem is identified. Richard Seeking two OKs to commit. This looks good. JMarc
Re: [PATCH] Bug 3667
On Thursday 24 May 2007 08:55:31 Jean-Marc Lasgouttes wrote: Richard == Richard Heck [EMAIL PROTECTED] writes: Richard Seeking two OKs to commit. This looks good. +1 JMarc -- José Abílio
Re: [PATCH] Make View HTML Work
On Thursday 24 May 2007 08:41:26 Richard Heck wrote: 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. OK. Richard -- José Abílio
1.5.0 Pre 1 - When?
José, when are you going to release 1.5.0? I am asking because I won't be able to contact the translators before the weekend. Is June 8 still the deadline or did we change the schedule? Michael PS: Despite all the bug fixes, the total number of bug reports does not shrink but increases. Presently, there are 517 open bugs. Quite puzzling... http://bugzilla.lyx.org/buglist.cgi?short_desc_type=allwordssubstrshort_desc=target_milestone=---target_milestone=1.2.0target_milestone=1.2.0pre1target_milestone=1.2.0pre2target_milestone=1.2.1target_milestone=1.2.2target_milestone=1.3.0target_milestone=1.3.1target_milestone=1.3.2target_milestone=1.3.3target_milestone=1.3.4target_milestone=1.3.5target_milestone=1.3.6target_milestone=1.3.7target_milestone=1.4.0target_milestone=1.4.1target_milestone=1.4.2target_milestone=1.4.3target_milestone=1.4.4target_milestone=1.4.5target_milestone=1.4.6target_milestone=1.4.xtarget_milestone=1.5.0target_milestone=1.5.1long_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=keywords_type=nowordskeywords=fixedintrunkbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_severity=blockerbug_severity=criticalbug_severity=majorbug_severity=normalbug_severity=minorbug_severity=trivialemailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=changedin=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitnewqueryname=order=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0=
Re: [PATCH] Fixing cursors in multiview mode
Angus Leeming wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: The only simple solution I can think of right now is to emit a signal in the Inset destructor that we can connect to the CursorSlice. The CursorSlice will then invalidate itself. Here is what I came up with. In principle this should solve all problems of invalid cursors. Unfortunately it doesn't compile... somebody has an idea why? Compiling... MathMacroTemplate.cpp D:\devel\lyx\trunk\boost\boost/signals/detail/signal_base.hpp(150) : error C2248: 'boost::noncopyable_::noncopyable::operator =' : cannot access private member declared in class 'boost::noncopyable_::noncopyable' You can't copy boost::signals. That means that either you're going to have to define a copy constructor for the Inset holding the signal member or you need to define a NonCopyableSignal wrapper to boost::signal that defines a no-op copy constructor... I suspected something like that. Thanks Clark! Abdel.
Another cursor movement bug/feature
Hi! Is it a bug or a feature that the cursor does not enter insets from the right in the text? In Text::cursorLeft the checkAndActivateInset (cur, false) call comes before moving the cursor from the right. Though checkAndActivateInset expects the cursor to be left of the inset to enter. I guess that's not was is expected, right? Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: How can I compare two Insets?
Elazar Leibovich wrote: On 5/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote: Well, I'm in cursorX() so I'm having BufferView bv, CursorSlice sl, and finally boundary. Which does nothing AFAIK, it's just always FALSE. I suspect that it's supposed to tell you whether or not the cursor is right in front of an inset, but not in it, apparently it's broken. Your suspicion is wrong. I case you'd stop top-posting I might even be tempted to give a longer explanation. One guy says be louder, other say stop top posting, what should I do then? Learn how to behave with savage bears... Anyhow I'd love a longer explanation. Me too. Abdel.
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. Helge Hafting
Re: Another cursor movement bug/feature
Stefan Schimanski wrote: Hi! 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. Abdel.
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? Helge Hafting -- José Abílio
Re: Another cursor movement bug/feature
Stefan Schimanski schrieb: Hi! Is it a bug or a feature that the cursor does not enter insets from the right in the text? In Text::cursorLeft the checkAndActivateInset(cur, false) call comes before moving the cursor from the right. Though checkAndActivateInset expects the cursor to be left of the inset to enter. I guess that's not was is expected, right? Stefan This is now http://bugzilla.lyx.org/show_bug.cgi?id=3720 Michael
Re: 1.5.0 Pre 1 - When?
Michael Gerz wrote: José, when are you going to release 1.5.0? I am asking because I won't be able to contact the translators before the weekend. Is June 8 still the deadline or did we change the schedule? Michael PS: Despite all the bug fixes, the total number of bug reports does not shrink but increases. Presently, there are 517 open bugs. Quite puzzling... More bugs are coming because beta3 is more used... Let's say that this is a good sign :-) I guess also that the new listing stuff is the cause of many of the newer bugs. Abdel.
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Thursday 24 May 2007 09:48:58 Helge Hafting wrote: My problem is the exact opposite. If I run LyX from the source dir, then I can open documents. If I then run make install and run the (same) installed LyX, then I can't open documents, not even the help documents or a new document - because lyx2lyx fails me. I understand the reason, but it is strange. If you run lyx from the console what is the error output? First a messagebox: /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of lyx, but the lyx2lyx script failed to convert it. So - this will probably fix itself if I delete the old .lyx directory. But ordinary users won't understand this sort of thing. The old defaults.lyx is from an earlier 1.5svn. Now, this shouldn't happen if there is a policy of supporting even files written by beta versions. The console error message: Warning: 271: Format not supported. Warning: Quiting. Error: Conversion script failed /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. On the side: Perhaps the failed version (217) should be displayed in the dialog box too? Surely that would help if ever some confused user reports a problem? Looking at the defaults.lyx file, it is actually \lyxformat 263 The document type is my own layout. Of course that one might be buggy - but the same happens with the userguide. I notice that I get exactly the same messages for the userguide, so I wonder: Do lyx2lyx read defaults.lyx when other documents are processed too? If so - why? Also, why would lyx2lyx bother processing the userguide distributed with LyX, surely that one should be the right version to begin with? Or maybe not in a beta version. :-) Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: On Wednesday 23 May 2007 12:04:17 pm Helge Hafting wrote: I guess a different version of lyx2lyx ran when I ran lyx from the build directory instead of installing it. :-/ If you run lyx2lyx from the build dir instead of the source dir you have to add an environment variable to be able to run it: $ PYTHONPATH=../../lyx/lyx-devel/lib/lyx2lyx/ src/lyx Where path points to the source dir. The other option is to test the attached patch. Does it works for you? I cant do a useful test of the patch right now. I did a make install of the current source, and the problem just went away. I'll try if this starts happening again though. Even my own .layout works . Helge Hafting
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:19:11 Helge Hafting wrote: First a messagebox: /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of lyx, but the lyx2lyx script failed to convert it. So - this will probably fix itself if I delete the old .lyx directory. But ordinary users won't understand this sort of thing. The old defaults.lyx is from an earlier 1.5svn. Now, this shouldn't happen if there is a policy of supporting even files written by beta versions. The policy is there and is working. :-) The console error message: Warning: 271: Format not supported. Warning: Quiting. Error: Conversion script failed /home/helgehaf/.lyx/templates/defaults.lyx is from a different version of LyX, but the lyx2lyx script failed to convert it. This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) On the side: Perhaps the failed version (217) should be displayed in the dialog box too? Surely that would help if ever some confused user reports a problem? We can improve the error report but this is a 1.6 issue. Looking at the defaults.lyx file, it is actually \lyxformat 263 The document type is my own layout. Of course that one might be buggy - but the same happens with the userguide. I notice that I get exactly the same messages for the userguide, so I wonder: Do lyx2lyx read defaults.lyx when other documents are processed too? If so - why? As I said above the problem was that the lyx2lyx version was not up to date. Also, why would lyx2lyx bother processing the userguide distributed with LyX, surely that one should be the right version to begin with? Or maybe not in a beta version. :-) We update all the documentation to the latest stable format just before releasing the stable version as there is no guarantee before that format will stay fixed. Helge Hafting -- José Abílio
Re: Scrolling lag in 1.5svn again, processEvents - success
On Thursday 24 May 2007 10:37:37 Helge Hafting wrote: I cant do a useful test of the patch right now. I did a make install of the current source, and the problem just went away. I'll try if this starts happening again though. Those are the reports I like to read. :-) Even my own .layout works . Why shouldn't it? ;-) Helge Hafting -- José Abílio
Re: Another cursor movement bug/feature
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes: Stefan Hi! Is it a bug or a feature that the cursor does not enter Stefan insets from the right in the text? In Text::cursorLeft the Stefan checkAndActivateInset (cur, false) call comes before moving Stefan the cursor from the right. Though checkAndActivateInset Stefan expects the cursor to be left of the inset to enter. I guess Stefan that's not was is expected, right? This bug did not exist in 1.4. JMarc
Re: Scrolling lag in 1.5svn again, processEvents - success
José Matos wrote: This shows that lyx2lyx was not updated. :-) This can happen if you update the src directory but not from the root directory. This has happened before. :-) I guess that is what happened. I have to be more careful with the svn commands then. Thanks for the tip. Helge Hafting
Re: symlinks
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. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Please add short bug description to subject
[EMAIL PROTECTED] wrote: Hi, Paraphrasing what Stefan said in another post, I'd be grateful if people posting about bugs could: When you post something about a bug, please add the bug's short description to the subject of the post. This plus a link to the bug entry (so that I can click on it): http://bugzilla.lyx.org/show_bug.cgi?id= Abdel.
Please add short bug description to subject
Hi, Paraphrasing what Stefan said in another post, I'd be grateful if people posting about bugs could: When you post something about a bug, please add the bug's short description to the subject of the post. I don't think the reasons needs to be explained, or? Best regards, /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Please add short bug description to subject
Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Hi, Paraphrasing what Stefan said in another post, I'd be grateful if people posting about bugs could: When you post something about a bug, please add the bug's short description to the subject of the post. This plus a link to the bug entry (so that I can click on it): http://bugzilla.lyx.org/show_bug.cgi?id= Abdel. But I guess the mails would be classified as SPAM more often then... Stephan
RE: incorrect commit in changeset 18478
Uwe Stöhr wrote: http://www.lyx.org/trac/changeset/18481 thanks. i think the attached should also go in... Why did you remove the attic folder? Did you get an OK from two developers to do this; I can't find this in the list. If this was correct, then please also modify the makefile and SCons file to reflect this change. this can be reverted if people think i overstepped my authority here t.patch Description: t.patch
Re: incorrect commit in changeset 18478
On Thursday 24 May 2007 12:45:51 Leuven, E. wrote: Why did you remove the attic folder? Did you get an OK from two developers to do this; I can't find this in the list. If this was correct, then please also modify the makefile and SCons file to reflect this change. this can be reverted if people think i overstepped my authority here It is not much a question of authority but the fact that we have agreed to retain the directory in the discussion about icons some time ago. At least that is my understanding. :-) Could you please restore it? :-) -- José Abílio
Re: [PATCH] lstinputlisting in InsetInclude should also increase listing counter, bug 3708
On Thursday 24 May 2007 07:44:54 Juergen Spitzmueller wrote: I cannot test now, but (apart from some formatting issues, i.e. line lengths) it looks sensible to me. OK then. Jürgen -- José Abílio
Re: [PATCH] Trivial patch to fix warning
On Thursday 24 May 2007 07:28:40 Richard Heck wrote: 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? The purpose of the code seems to be resetting the options, if you are sure that it works without it then go ahead. rh -- José Abílio
RE: incorrect commit in changeset 18478
It is not much a question of authority i actually didn't give it a thought. was just cleaning up after myself (or so i thought)( but the fact that we have agreed to retain the directory in the discussion about icons some time ago. At least that is my understanding. :-) i thought we agreed to retain the icon, not the directory. (but my memory is notoriously bad, i even forgot my mothers birthday once... ;-) Could you please restore it? :-) no problem...
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__) __GNUC__ == 3 __GNUC_MINOR__ Abdelrazak 4 + #if 1 Koji, could you try that? JMarc
Re: incorrect commit in changeset 18478
On Thursday 24 May 2007 13:02:37 Leuven, E. wrote: It is not much a question of authority i actually didn't give it a thought. was just cleaning up after myself (or so i thought)( I know. :-) but the fact that we have agreed to retain the directory in the discussion about icons some time ago. At least that is my understanding. :-) i thought we agreed to retain the icon, not the directory. FWIW I don't have any problem with us deciding to remove the directory. :) (but my memory is notoriously bad, i even forgot my mothers birthday once... ;-) I don't have problems, most of the time. :-) At least that I remember. ;-) I used to remember Susana about our anniversary. Could you please restore it? :-) no problem... Thanks. -- José Abílio
Re: incorrect commit in changeset 18478
Leuven, E. schrieb: It is not much a question of authority i actually didn't give it a thought. was just cleaning up after myself (or so i thought)( but the fact that we have agreed to retain the directory in the discussion about icons some time ago. At least that is my understanding. :-) i thought we agreed to retain the icon, not the directory. (but my memory is notoriously bad, i even forgot my mothers birthday once... ;-) We agreed to move unused icons to the attic. Michael
Re: 1.5.0 Pre 1 - When?
On Thursday 24 May 2007 09:24:10 Michael Gerz wrote: José, when are you going to release 1.5.0? When it is ready. ;-) We had a delay of one week regarding the proposed schedule. I am asking because I won't be able to contact the translators before the weekend. Is June 8 still the deadline or did we change the schedule? I have created a page for it, feel free to improve it. :-) http://wiki.lyx.org/Devel/ReleaseSchedule Michael PS: Despite all the bug fixes, the total number of bug reports does not shrink but increases. Presently, there are 517 open bugs. Quite puzzling... I agree with Abdel the increase exposure of the beta release to our users is increasing the bug flow. I expect this to increase after we release rc1. -- José Abílio
Re: [PATCH] Bug 1474: Recursive Input
On Monday 21 May 2007 09:49:46 Jean-Marc Lasgouttes wrote:
Richard == Richard Heck [EMAIL PROTECTED] writes:
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?
If not then OK. :-)
--
José Abílio
RE: incorrect commit in changeset 18478
Michael Gerz wrote: Leuven, E. schrieb: i thought we agreed to retain the icon, not the directory. (but my memory is notoriously bad, i even forgot my mothers birthday once... ;-) We agreed to move unused icons to the attic. whatever. here you go: http://www.lyx.org/trac/changeset/18485
Re: 2007 LyX Meeting: Invitation
On Thu, May 24, 2007 at 09:48:50AM +0200, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin Weather: probably rather warm, 20-28 C. May rain, but rarely Martin very long. So, what about those insects? Yes, butterflies were a bit early this spring. - Martin
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
On Thu, May 24, 2007 at 02:15:35PM +0200, Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Maybe Koji could try to enable that unconditionally: Abdelrazak - #if SIZEOF_WCHAR_T != 4 defined(__GNUC__) Abdelrazak defined(__GNUC_MINOR__) __GNUC__ == 3 __GNUC_MINOR__ Abdelrazak 4 + #if 1 Koji, could you try that? I think that he has to tweak several files, namely: src/support/docstream.cpp src/support/docstring.cpp src/support/docstring.h src/support/types.h -- Enrico
Inline listings trouble
I don't know how inline listing is supposed to work. My guess would be typesetting of things like int i; in the middle of a text line. Everytime I turn inline listing on I get some kind of latex error though. Typing stuff in the box tend to make it worse - especially braces. Helge Hafting
[PATCH] Updated Norwegian translations
Updated translations for Norwegian. Particularly new stuff: * new menu entries * TOC dialog * listings dialog * Lots of tooltips that was invisible last time * Random changed texts all over the place Helge Hafting Index: nb.po === --- nb.po (revisjon 18483) +++ nb.po (arbeidskopi) @@ -1,5 +1,5 @@ # Norske oversettelser for LyX -# Copyright 1997-2005 +# Copyright 1997-2007 # Lars Gullik Bjønnes [EMAIL PROTECTED] # Helge Hafting [EMAIL PROTECTED] msgid @@ -7,7 +7,7 @@ Project-Id-Version: lyx 1.4.0\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2007-05-18 00:09+0100\n -PO-Revision-Date: 2007-02-26 23:42+0100\n +PO-Revision-Date: 2007-05-24 15:34+0200\n Last-Translator: Lars Gullik Bjønnes [EMAIL PROTECTED]\n Language-Team: norsk [EMAIL PROTECTED]\n MIME-Version: 1.0\n @@ -656,7 +656,6 @@ msgstr Valgte referanser: #: src/frontends/qt4/ui/CitationUi.ui:136 -#, fuzzy msgid Available Citations: msgstr Tilgjengelige referanser: @@ -669,7 +668,6 @@ msgstr Hvilken 'Natbib' referansestil som skal brukes #: src/frontends/qt4/ui/CitationUi.ui:192 -#, fuzzy msgid Citation style: msgstr Siteringsstil: @@ -678,7 +676,6 @@ msgstr Vis alle forfatterne #: src/frontends/qt4/ui/CitationUi.ui:205 -#, fuzzy msgid Full author list msgstr Komplett forfatterliste @@ -687,7 +684,6 @@ msgstr Store bokstaver i referansen #: src/frontends/qt4/ui/CitationUi.ui:215 -#, fuzzy msgid Force upper case msgstr Store bokstaver @@ -712,26 +708,22 @@ msgstr Bruk #: src/frontends/qt4/ui/CitationUi.ui:335 -#, fuzzy msgid Search Citation -msgstr Litteraturreferanse +msgstr Søk etter litteraturreferanser #: src/frontends/qt4/ui/CitationUi.ui:358 -#, fuzzy msgid Case Sensitive msgstr Skill mellom store og små bokstaver #: src/frontends/qt4/ui/CitationUi.ui:365 msgid Regular Expression -msgstr +msgstr Regulært uttrykk #: src/frontends/qt4/ui/CitationUi.ui:377 -#, fuzzy msgid - Clear msgstr - Tøm #: src/frontends/qt4/ui/CitationUi.ui:391 -#, fuzzy msgid Find: msgstr Finn: @@ -749,9 +741,8 @@ #: src/frontends/qt4/ui/DelimiterUi.ui:180 #: src/frontends/qt4/QDelimiterDialog.cpp:190 -#, fuzzy msgid TeX Code: -msgstr TeX-kode|X +msgstr TeX-kode: #: src/frontends/qt4/ui/DelimiterUi.ui:289 msgid Match delimiter types @@ -783,7 +774,7 @@ #: src/frontends/qt4/ui/ERTUi.ui:43 msgid Show ERT inline -msgstr Vis ERT i linjen +msgstr Vis ERT i linja #: src/frontends/qt4/ui/ERTUi.ui:46 msgid Inline @@ -791,7 +782,7 @@ #: src/frontends/qt4/ui/ERTUi.ui:53 msgid Show ERT button only -msgstr +msgstr Vis bare ERT-knappen #: src/frontends/qt4/ui/ERTUi.ui:56 msgid Collapsed @@ -1128,12 +1119,11 @@ #: src/frontends/qt4/ui/GraphicsUi.ui:240 msgid Sets height of graphic. Leave unchecked to set automatically. -msgstr +msgstr Sett bildehøyde. Automatisk om du ikke krysser av. #: src/frontends/qt4/ui/GraphicsUi.ui:243 -#, fuzzy msgid Set height: -msgstr Høyde på topptekst: +msgstr Sett høyde: #: src/frontends/qt4/ui/GraphicsUi.ui:250 msgid Scale Graphics (%): @@ -1141,12 +1131,11 @@ #: src/frontends/qt4/ui/GraphicsUi.ui:260 msgid Sets width of graphic. Leave unchecked to set automatically. -msgstr +msgstr Sett bildebredde. Automatisk om du ikke krysser av. #: src/frontends/qt4/ui/GraphicsUi.ui:263 -#, fuzzy msgid Set width: -msgstr Bredde: +msgstr Sett bredde: #: src/frontends/qt4/ui/GraphicsUi.ui:273 msgid Scale image to maximum size not exceeding width and height @@ -1222,18 +1211,16 @@ msgstr #: src/frontends/qt4/ui/IncludeUi.ui:76 -#, fuzzy msgid Caption: -msgstr Bildetekst: +msgstr Figurtekst: #: src/frontends/qt4/ui/IncludeUi.ui:89 -#, fuzzy msgid Label: -msgstr Merke: +msgstr Referansemerke: #: src/frontends/qt4/ui/IncludeUi.ui:99 msgid More parameters -msgstr +msgstr Fler parametre #: src/frontends/qt4/ui/IncludeUi.ui:173 msgid Underline spaces in generated output @@ -1265,16 +1252,15 @@ #: src/frontends/qt4/ui/IncludeUi.ui:282 src/insets/InsetInclude.cpp:313 msgid Input -msgstr +msgstr Input #: src/frontends/qt4/ui/IncludeUi.ui:287 lib/layouts/manpage.layout:122 msgid Verbatim -msgstr +msgstr Verbatim #: src/frontends/qt4/ui/IncludeUi.ui:292 src/insets/InsetListings.cpp:238 -#, fuzzy msgid Listings -msgstr Liste +msgstr Programlisting #: src/frontends/qt4/ui/IncludeUi.ui:326 msgid Load the file @@ -1314,76 +1300,64 @@ msgstr Liste #: src/frontends/qt4/ui/ListingsUi.ui:35 -#, fuzzy msgid Main Settings -msgstr Gren-innstillinger +msgstr Hovedinnstillinger #: src/frontends/qt4/ui/ListingsUi.ui:63 -#, fuzzy msgid Placement -msgstr Plassering: +msgstr Plassering: #: src/frontends/qt4/ui/ListingsUi.ui:78 -#, fuzzy msgid Placement: -msgstr Plassering: +msgstr Plassering: #: src/frontends/qt4/ui/ListingsUi.ui:88 -#, fuzzy msgid Float -msgstr Flytende (Float)|a +msgstr Flytende (Float) #:
Untranslateable strings in LyX (toolbar tooltip, TOC dialog, source preview)
Surprisingly, the tooltip Insert table for the upper toolbar isn't translateable. Every other toolbar tooltip is. The words Figure and Table in the TOC dialog, where we choose whether to show TOC, LOF or LOT. The string Preview source code for paragraph number that appear in the source code window when viewing source for a single paragraph. ' Helge Hafting
Re: r18371 - in /lyx-devel/branches/personal/sts/dynmacro/src...
Moreover I did some minor cleanup of the code, especially setting up the coordinate cache. I am pretty sure that without this can lead to crashes if your macros do not mention all the arguments. And a last fix included makes sure that the metrics are always in sync with the drawing. Before it was possible to go into the macro with the cursor in a way that the metrics were for the viewing mode, but the drawing was done for editing. All is OK for me. Good work! I nearly forgot this one. Need another OK for this one. Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [PATCH] lstinputlisting in InsetInclude should also increase listing counter, bug 3708
On 5/24/07, José Matos [EMAIL PROTECTED] wrote: On Thursday 24 May 2007 07:44:54 Juergen Spitzmueller wrote: I cannot test now, but (apart from some formatting issues, i.e. line lengths) it looks sensible to me. OK then. A slightly modified (formatting issues) version is committed. Bo
Re: Inline listings trouble
On 5/24/07, Helge Hafting [EMAIL PROTECTED] wrote: I don't know how inline listing is supposed to work. My guess would be typesetting of things like int i; in the middle of a text line. Everytime I turn inline listing on I get some kind of latex error though. Typing stuff in the box tend to make it worse - especially braces. Please send me a test file. It works fine here. Cheers, Bo
Re: Inline listings trouble
Bo Peng wrote:
On 5/24/07, Helge Hafting [EMAIL PROTECTED] wrote:
I don't know how inline listing is supposed to work. My guess
would be typesetting of things like int i; in the middle of a text
line.
Everytime I turn inline listing on I get some kind of latex error
though.
Typing stuff in the box tend to make it worse - especially braces.
Please send me a test file. It works fine here.
Cheers,
Bo
A lyx file and the resulting tex file.
latexing this:
No file listinginline.aux.
)
Runaway argument?
{test}^^M\end{document}^^M
! File ended while scanning use of [EMAIL PROTECTED]
inserted text
\par
* listinginline.tex
?
! Emergency stop.
inserted text
\par
* listinginline.tex
No pages of output.
Transcript written on listinginline.log.
Helge Hafting
listinginline.lyx
Description: application/lyx
%% LyX 1.5.0svn created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[a4paper,twoside,norsk,smallheadings]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{fancyhdr}
\pagestyle{fancy}
\setcounter{secnumdepth}{2}
\setcounter{tocdepth}{2}
\setlength{\parskip}{\medskipamount}
\setlength{\parindent}{0pt}
\usepackage{listings}
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
test
\lstinline{test}
\end{document}
Re: Inline listings trouble
On 5/24/07, Helge Hafting [EMAIL PROTECTED] wrote:
A lyx file and the resulting tex file.
latexing this:
No file listinginline.aux.
)
Runaway argument?
{test}^^M\end{document}^^M
! File ended while scanning use of [EMAIL PROTECTED]
inserted text
\par
* listinginline.tex
I can open and compile your test file perfectly. Maybe your listings
package is too old?
Uwe, can you open it there?
Bo
Re: Inline listings trouble
Helge Hafting wrote:
%% LyX 1.5.0svn created this file. For more info, see http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[a4paper,twoside,norsk,smallheadings]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{fancyhdr}
\pagestyle{fancy}
\setcounter{secnumdepth}{2}
\setcounter{tocdepth}{2}
\setlength{\parskip}{\medskipamount}
\setlength{\parindent}{0pt}
\usepackage{listings}
\makeatletter
\usepackage{babel}
\makeatother
\begin{document}
test
\lstinline{test}
change this line to \lstinline|test|
and run the latex file. What happens?
Herbert
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
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). 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. There is an issue here about the copiers, since they expect to get a single file to play with. Almost. It is assumed that there is a single 'main' file, and that all other needed files can be deduced from the main file. Those other files are not copied, though, the copiers only adjust the paths in the main file. If you really want to support usetempdir converters in the middle of a conversion chain then it gets indeed really complicated. How do you know which files to copy back from the new temp dir and which not? I don't believe that the approach based on modification times will work. For example, if the converter modifies the .aux file I don't think it should be copied back, because it would not correspond to the .dvi file in the main temp dir. (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. Copiers are _not_ associated to extensions, but to formats. Extensions do not matter at all in LyX. What matters is the format. Extensions are only used to suggest defaults in file dialog, and as a last resort if the format of a file cannot be determined from the contents (but this is done in utility code one never needs to call directly). If you don't know the format of a file, use formats.getFormatFromFile(filename) and don't care about extensions. 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? IMHO you don't need to make assumptions which files will have copiers and which will not, see above. Georg
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
Re: r18371 - in /lyx-devel/branches/personal/sts/dynmacro/src...
On Thursday 24 May 2007 15:07:01 Stefan Schimanski wrote: I nearly forgot this one. Need another OK for this one. OK. Stefan -- José Abílio
Re: [PATCH] Updated Norwegian translations
On Thursday 24 May 2007 14:44:46 Helge Hafting wrote: Updated translations for Norwegian. Particularly new stuff: * new menu entries * TOC dialog * listings dialog * Lots of tooltips that was invisible last time * Random changed texts all over the place Helge Hafting Committed. http://www.lyx.org/trac/changeset/18487 -- José Abílio
Re: [PATCH] Trivial patch to fix warning
José Matos wrote:
On Thursday 24 May 2007 07:28:40 Richard Heck wrote:
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?
The purpose of the code seems to be resetting the options, if you are sure
that it works without it then go ahead.
Hmm, I see. Let's ask Bo about this, as I think he must have added these
calls.
I haven't been able to cause a problem after deleting these lines. The
reason is that the InsetInclude::latex() routine just ignores the
options, anyway, if we're not dealing with a listings include. The
advantage to deleting them turns out to be that if you switch from
listings to verbatim and then go back, your options re-appear.
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/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);
}
[PATCH] Documentation for Converters, Etc
While working on the HTML view issues, I added some documentation about converters and such. Can this go in? 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. 00.00. needaux Needs the LaTeX .aux file for the conversion. 00.00. xml Output is XML. The following three variables are not really flags at all but take an argument in the key= value
Re: [PATCH] Trivial patch to fix warning
Hmm, I see. Let's ask Bo about this, as I think he must have added these calls. I haven't been able to cause a problem after deleting these lines. The reason is that the InsetInclude::latex() routine just ignores the options, anyway, if we're not dealing with a listings include. The advantage to deleting them turns out to be that if you switch from listings to verbatim and then go back, your options re-appear. I have not checked in details but the original idea is that when option is set for listings, it remains there if we switch to another type. This may or may not confuse users. Also, setOption may (not sure) be called to set options for other types, although they will not be used eventually. Because the 're-appearing' option seems to be a good thing to have, you can remove them if you can not see any bad side-effect. Cheers, Bo
Re: [PATCH] Bug 3667
José Matos wrote:
On Thursday 24 May 2007 08:55:31 Jean-Marc Lasgouttes wrote:
Richard Seeking two OKs to commit.
This looks good.
+1
I'd feel happiest committing this with or after the fix for 2199. I
don't believe it solves this crash all by itself. The 2199 one is
waiting approval. I'll attach a combined diff. It's one bug, more or less.
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 18489)
+++ 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;
}
Index: src/insets/InsetInclude.cpp
===
--- src/insets/InsetInclude.cpp (revision 18489)
+++ src/insets/InsetInclude.cpp (working copy)
@@ -393,12 +393,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;
}
@@ -420,7 +422,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_) !isVerbatim(params_) // not yet:
+ buffer.fileName() == included_file.toFilesystemEncoding())
+ {
Alert::error(_(Recursive input),
bformat(_(Attempted to include file %1$s in itself!
Ignoring inclusion.), from_utf8(incfile)));
@@ -439,8 +443,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)
@@ -451,8 +456,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) {
Re: [PATCH] Documentation for Converters, Etc
On Thursday 24 May 2007 17:25:50 Richard Heck wrote: While working on the HTML view issues, I added some documentation about converters and such. Can this go in? rh Yes. -- José Abílio
Re: [PATCH] Bug 3667
On Thursday 24 May 2007 17:35:01 Richard Heck wrote: I'd feel happiest committing this with or after the fix for 2199. I don't believe it solves this crash all by itself. The 2199 one is waiting approval. I'll attach a combined diff. It's one bug, more or less. Go on. :-) Richard -- José Abílio
Re: Scrolling lag in 1.5svn again, more details.
No ideas any more--also the last patch does not work (Helge's private reply). I've reverted the first patch, http://www.lyx.org/trac/changeset/18376 because it introduces this bug, http://marc.info/?l=lyx-develm=117944188219722w=2 detected by Dov. The event_1 patch gives better results on systems with a fast enough graphic card(?) but does not work an older systems. Jose feel free to do what you want. Peter
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
Georg Baum wrote: Jean-Marc Lasgouttes wrote: It was Georg who wrote Note that the iostreams library in boost 1.34.0 is an outdated version (older than the version in boost 1.33.1) with a memory leak, so watch for iostreams updates in the boost 1.34 branch, too. I am afraid I do not know what he means. Georg? See this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/159265. This (and the very late 1.34.0 release) is a sign that boost currently has severe problems with testing/the release procedure. I hope they can sort this out for the next release. Georg We could just wait for 1.34.1, upgrading to 1.34 is nearly a noop: http://www.lyx.org/trac/changeset/18458 Peter
Re: [PATCH] Trivial patch to fix warning
Bo Peng wrote: I haven't been able to cause a problem after deleting these lines. The reason is that the InsetInclude::latex() routine just ignores the options, anyway, if we're not dealing with a listings include. The advantage to deleting them turns out to be that if you switch from listings to verbatim and then go back, your options re-appear. I have not checked in details but the original idea is that when option is set for listings, it remains there if we switch to another type. This may or may not confuse users. Also, setOption may (not sure) be called to set options for other types, although they will not be used eventually. None of them have any options---at least, none that are handled that way. Because the 're-appearing' option seems to be a good thing to have, you can remove them if you can not see any bad side-effect. 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
small fixes for cmake merge
Here I need attached patch to compile
cmake and merged files. Could it go in?
Peter
Index: src/insets/InsetInclude.cpp
===
--- src/insets/InsetInclude.cpp (revision 18495)
+++ src/insets/InsetInclude.cpp (working copy)
@@ -233,7 +233,7 @@
bool isInputOrInclude(InsetCommandParams const params)
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
}
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp (revision 18495)
+++ src/frontends/qt4/QDocument.cpp (working copy)
@@ -891,7 +891,7 @@
params.quotes_language = lga;
int const pos = langModule-languageCO-currentIndex();
- params.language = languages.getLanguage(lang_[pos]);
+ params.language = ::lyx::languages.getLanguage(lang_[pos]);
// numbering
if (params.getTextClass().hasTocLevels()) {
Re: small fixes for cmake merge
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
}
Why is this? And what does this has to do with merged files?
--
José Abílio
Re: small fixes for cmake merge
José Matos wrote:
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
}
Why is this? And what does this has to do with merged files?
It also doesn't compile separate. The or is only available
with a other header on msvc.
Peter
Re: How can I compare two Insets?
On Thu, May 24, 2007 at 10:34:26AM +0300, Elazar Leibovich wrote: On 5/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote: Well, I'm in cursorX() so I'm having BufferView bv, CursorSlice sl, and finally boundary. Which does nothing AFAIK, it's just always FALSE. I suspect that it's supposed to tell you whether or not the cursor is right in front of an inset, but not in it, apparently it's broken. Your suspicion is wrong. I case you'd stop top-posting I might even be tempted to give a longer explanation. One guy says be louder, other say stop top posting, what should I do then? There is a non-empty intersection. Anyhow I'd love a longer explanation. There are cases where this information is useful. E.g. if you have /italics/[Cursor]BOLD, it is interesting whether typing 'x' gives you an italics x or a bold one. Also there is a visual difference between the last position in a display row and the first position in the row below, although there is only one logical position. The boundary flag tell you which one is meant. Andre'
Re: Using Qt/Mac Binary Distribution for LyX make Was: Qt4 binary
Hi, there is a pretty good instruction in development/cmake/README.cmake in the subversion tree. Altough it failed for me... I did a build exactly as in the README stated (tried both GNU make and Xcode) and both of them left me with an unusable binary (throwing some exception from boost during startup). Second point was that I didn't find an option to create a LyX.app, so its not ideal in this regard either. I will stick to the self built Qt 4.3 until futher notice. astifter (PS: Otherwise cmake does an impressive job, bet it works perfecly on linux.) On 22.05.2007, at 21:04, Bob Lounsbury wrote: On 5/22/07, Andreas Neustifter [EMAIL PROTECTED] wrote: On 22.05.2007, at 15:49, Abdelrazak Younes wrote: Why don't you use the CMake support instead? As a bonus it will generate an XCode project for you... At least that's what I understood from Stefan and Peter exchange. Abdel. Sorry, there was another post from which I assumed that cmake is a Microsoft/Windows thing. Big sorry for that, had to catch up on latest build technology. I have started a cmake build and it seems that it works, so i guess thats the way to go for new users. Details follow. astifter For those of us who are less technologically inclined. Could you explain your process of using cmake. I've heard that it is faster than the standard make commands, but I'm not sure what needs installed or how to use. So, hoping you could give a brief how-to. Thanks, Bob Lounsbury
QInclude Dialog Bug [was: Trivial patch to fix warning]
Bo Peng wrote: I haven't been able to cause a problem after deleting these lines. The reason is that the InsetInclude::latex() routine just ignores the options, anyway, if we're not dealing with a listings include. The advantage to deleting them turns out to be that if you switch from listings to verbatim and then go back, your options re-appear. I have not checked in details but the original idea is that when option is set for listings, it remains there if we switch to another type. This may or may not confuse users. Also, setOption may (not sure) be called to set options for other types, although they will not be used eventually. Because the 're-appearing' option seems to be a good thing to have, you can remove them if you can not see any bad side-effect. I've committed this. By the way, another problem I noticed with the QInclude dialog: If you enter a parameter in the caption field (say) and hit return, it's not recorded. Should be a simple matter, but I'm on the trail of other beasties. 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: small fixes for cmake merge
José Matos wrote:
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
}
Why is this? And what does this has to do with merged files?
Sorry, my bad. I just wrote a perl script for someone on the user's list
and had perl in my head. I'll fix 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
[PATCH] Bug 3488: Crash related to failed loads
http://bugzilla.lyx.org/show_bug.cgi?id=3488
The attached patch resolves this bug. The problem was that the current
buffer was being disconnected from the LyXView before the new buffer was
loaded. If the load failed, then, closing the current buffer would not
call LyXView::setBuffer(), and the `current buffer' would then be undefined.
Seeking two OKs
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: frontends/LyXView.cpp
===
--- frontends/LyXView.cpp (revision 18489)
+++ frontends/LyXView.cpp (working copy)
@@ -163,10 +163,12 @@
busy(true);
BOOST_ASSERT(work_area_);
- if (work_area_-bufferView().buffer())
+ bool const hadBuffer = work_area_-bufferView().buffer();
+ if (hadBuffer)
disconnectBuffer();
- bool loaded = work_area_-bufferView().loadLyXFile(filename, tolastfiles);
+ bool const loaded =
+ work_area_-bufferView().loadLyXFile(filename, tolastfiles);
updateToc();
updateMenubar();
@@ -177,7 +179,9 @@
if (loaded) {
connectBuffer(*work_area_-bufferView().buffer());
showErrorList(Parse);
- }
+ } else if (hadBuffer)
+ //Need to reconnect the buffer if the load failed
+ connectBuffer(*work_area_-bufferView().buffer());
updateStatusBar();
busy(false);
work_area_-redraw();
Re: small fixes for cmake merge
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
Index: src/frontends/qt4/QDocument.cpp
===
--- src/frontends/qt4/QDocument.cpp (revision 18495)
+++ src/frontends/qt4/QDocument.cpp (working copy)
@@ -891,7 +891,7 @@
params.quotes_language = lga;
int const pos = langModule-languageCO-currentIndex();
- params.language = languages.getLanguage(lang_[pos]);
+ params.language = ::lyx::languages.getLanguage(lang_[pos]);
// numbering
if (params.getTextClass().hasTocLevels()) {
Why is this needed only here?
Would not lyx::languages... be enough?
--
José Abílio
Re: [PATCH] HTML Export Bugs
On Thu, May 24, 2007 at 11:55:35AM -0400, Richard Heck wrote: 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.) I think that it is so because posix requires that file timestamps are given in seconds (http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html) 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? I don't think so as you would copy back all the graphics files (maybe converted to postscript from some bitmap format and thus huge) and all sort of things that gets copied to the tempdir. Why not implementing what I really proposed, i.e., 1) make a list of all file names which are present in the tempdir just before calling htlatex 2) call htlatex 3) get a new list of files and copy back only those not present in the first list In this way the cruft copied back would be greatly reduced as .log, .dvi, and .aux file would not be copied. Using your patch about usetempdir and the wrapper I posted in the other thread, I was able to successfully get an html export. So, if you think that the above is too much work to be done in C++, another option would be applying that patch and converting to python that shell script, such that it can be used in all platforms as the html converter. -- Enrico
Re: How can I compare two Insets?
On 5/24/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Thu, May 24, 2007 at 10:34:26AM +0300, Elazar Leibovich wrote: On 5/22/07, Andre Poenitz [EMAIL PROTECTED] wrote: On Tue, May 22, 2007 at 05:41:22PM +0300, Elazar Leibovich wrote: Well, I'm in cursorX() so I'm having BufferView bv, CursorSlice sl, and finally boundary. Which does nothing AFAIK, it's just always FALSE. I suspect that it's supposed to tell you whether or not the cursor is right in front of an inset, but not in it, apparently it's broken. Your suspicion is wrong. I case you'd stop top-posting I might even be tempted to give a longer explanation. One guy says be louder, other say stop top posting, what should I do then? There is a non-empty intersection. Anyhow I'd love a longer explanation. There are cases where this information is useful. E.g. if you have /italics/[Cursor]BOLD, it is interesting whether typing 'x' gives you an italics x or a bold one. Also there is a visual difference between the last position in a display row and the first position in the row below, although there is only one logical position. The boundary flag tell you which one is meant. Granted. However how do you determine that? Is it by the last cursor the user has clicked (if he pressed -, he'll be after character X, if he typed - he'll be before character Y)? Andre'
Re: [PATCH] HTML Export Bugs
Enrico Forestieri wrote: I don't think so as you would copy back all the graphics files (maybe converted to postscript from some bitmap format and thus huge) and all sort of things that gets copied to the tempdir. Why not implementing what I really proposed, i.e., 1) make a list of all file names which are present in the tempdir just before calling htlatex 2) call htlatex 3) get a new list of files and copy back only those not present in the first list In this way the cruft copied back would be greatly reduced as .log, .dvi, and .aux file would not be copied. OK. I'll have a go at this shortly. Shouldn't be too bad. 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
On Thu, May 24, 2007 at 11:55:35AM -0400, Richard Heck wrote: 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). Modification times have a granularity of two(!) seconds(!) on (V)FAT, which still happens to be a general-purpose format for media used for data exchange. 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.) Andre'
Re: small fixes for cmake merge
On Thu, May 24, 2007 at 07:32:15PM +0100, José Matos wrote:
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
+ return t == INPUT || t == INCLUDE;
Andre'
PS:
Why is this? And what does this has to do with merged files?
Broken compiler. 'or' is acceptale, even if not used usually.
Andre'
Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE
Peter == Peter Kümmel [EMAIL PROTECTED] writes: Peter We could just wait for 1.34.1, upgrading to 1.34 is nearly a Peter noop: Peter http://www.lyx.org/trac/changeset/18458 I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is released. JMarc
[patch] bug 3673: missing quotation characters in unicodesymbols
The attached patch fix bug 3673:
and adds some more unicode symbols according to
http://www.unicode.org/charts/PDF/U2000.pdf
and
ftp://ctan.tug.org/tex-archive/info/symbols/comprehensive/symbols-a4.pdf
Ok to go in?
regards Uwe
Index: unicodesymbols
===
--- unicodesymbols (revision 18479)
+++ unicodesymbols (working copy)
@@ -932,5 +932,13 @@
0x1ef9 \\~{y} # LATIN SMALL LETTER Y WITH TILDE
0x2013 -- # EN DASH
0x2014 ---# EM DASH
+0x201c {}`` # LEFT DOUBLE QUOTATION MARK
+0x201d '' # RIGHT DOUBLE QUOTATION MARK
+0x201e ,, # DOUBLE LOW-9 QUOTATION MARK
+0x2020 \\dag # DAGGER
+0x2021 \\ddag # DOUBLE DAGGER
+0x2026 \\dots # HORIZONTAL ELLIPSIS
+0x2030 \\textperthousandtextcomp # PER MILLE SIGN
+0x2031 \\textpertenthousand textcomp # PER TEN THOUSAND SIGN
0x20ac \\texteuro textcomp # EURO SIGN
Re: How can I compare two Insets?
Elazar == Elazar Leibovich [EMAIL PROTECTED] writes: Elazar Granted. However how do you determine that? Is it by the last Elazar cursor the user has clicked (if he pressed -, he'll be after Elazar character X, if he typed - he'll be before character Y)? There is something like that I think. JMarc
Re: [patch] bug 3673: missing quotation characters in unicodesymbols
On 5/24/07, Uwe Stöhr [EMAIL PROTECTED] wrote: The attached patch fix bug 3673: and adds some more unicode symbols according to http://www.unicode.org/charts/PDF/U2000.pdf and ftp://ctan.tug.org/tex-archive/info/symbols/comprehensive/symbols-a4.pdf Can not test it here (no windows), but if you can copy/paste single and double quotes from word to lyx, I will be happy to see it in svn. Cheers, Bo
Re: [patch] bug 3673: missing quotation characters in unicodesymbols
Bo Peng schrieb: Can not test it here (no windows), but if you can copy/paste single and double quotes from word to lyx, I will be happy to see it in svn. Yes, you can do this now, also from OpenOffice. regards Uwe
Re: Inline listings trouble
Bo Peng schrieb: I can open and compile your test file perfectly. Maybe your listings package is too old? Uwe, can you open it there? For me it also works fine. regards Uwe
Re: Inline listings trouble
Bo Peng wrote:
On 5/24/07, Helge Hafting
[EMAIL PROTECTED] wrote:
A lyx file and the resulting tex file.
latexing this:
No file listinginline.aux.
)
Runaway argument?
{test}^^M\end{document}^^M
! File ended while scanning use of [EMAIL PROTECTED]
inserted text
\par
* listinginline.tex
I can open and compile your test file perfectly. Maybe your listings
package is too old?
you cannot export \lstinline{foo}, ist must be something of
\lstinlinecharfoochar
where char is a free choosen delimiter. Otherwise you cannot write
something like \lstinline{\textbf{foo}}. Must be
\lstinline|\textbf{foo}| or any other character than |.
Herbert
Re: r18435 - /lyx-devel/branches/personal/sts/dynmacro/src/ma...
[EMAIL PROTECTED] writes:
| Author: sts
| Date: Mon May 21 08:27:32 2007
| New Revision: 18435
|
| URL: http://www.lyx.org/trac/changeset/18435
| Log:
| * cloned macros need an update because the argument proxies point to the old
macro
|
| Modified:
| lyx-devel/branches/personal/sts/dynmacro/src/mathed/MathMacro.cpp
|
| Modified: lyx-devel/branches/personal/sts/dynmacro/src/mathed/MathMacro.cpp
| URL:
http://www.lyx.org/trac/file/lyx-devel/branches/personal/sts/dynmacro/src/mathed/MathMacro.cpp?rev=18435
| ==
| --- lyx-devel/branches/personal/sts/dynmacro/src/mathed/MathMacro.cpp
(original)
| +++ lyx-devel/branches/personal/sts/dynmacro/src/mathed/MathMacro.cpp Mon May
21 08:27:32 2007
| @@ -88,7 +88,10 @@
|
| auto_ptrInset MathMacro::doClone() const
| {
| - return auto_ptrInset(new MathMacro(*this));
| + MathMacro * copy = new MathMacro(*this);
| + copy-needsUpdate_ = true;
| + copy-expanded_.cell(0).clear();
| + return auto_ptrInset(copy);
| }
Why not:
auto_ptrInset tmpInset(new MathMacro(*this));
tmpInset-needsUpdate_ = true;
tmpInset-expanded_.cell(0).clear();
return tmpInset;
?
A bit safer if it works.
--
Lgb
Re: Another cursor movement bug/feature
Stefan Schimanski wrote: Hi! Is it a bug or a feature that the cursor does not enter insets from the right in the text? In Text::cursorLeft the checkAndActivateInset(cur, false) call comes before moving the cursor from the right. Though checkAndActivateInset expects the cursor to be left of the inset to enter. I guess that's not was is expected, right? Stefan Hi! I'm almost certainly responsible for this --- I basically rewrote cursorLeft recently, in order to solve the crash we were having with RTL on (http://www.lyx.org/trac/changeset/18389). However, I'm not sure I understand what the problem is? It seems to be working for me? Dov
Re: r18489 - in /lyx-devel/trunk/src/mathed: MacroTable.h Mat...
[EMAIL PROTECTED] writes:
| Author: sts
| Date: Thu May 24 18:29:40 2007
| New Revision: 18489
|
| URL: http://www.lyx.org/trac/changeset/18489
| Log:
| * do not lookup the same macro all the time
| * only update the representation if anything was changed (this gives a
| huge speedup), fixes #2452
| * minor cleanup of the code, especially setting up the coordinate
| cache. Without this can lead to crashes if the macros do not mention
| all the arguments.
| * And a last fix included makes sure that the metrics are always in
| sync with the drawing. Before it was possible to go into the macro
| with the cursor in a way that the metrics were for the viewing mode,
| but the drawing was done for editing.
|
| Modified:
| lyx-devel/trunk/src/mathed/MacroTable.h
| lyx-devel/trunk/src/mathed/MathMacro.cpp
| lyx-devel/trunk/src/mathed/MathMacro.h
|
| Modified: lyx-devel/trunk/src/mathed/MacroTable.h
| URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/MacroTable.h?rev=18489
| ==
| --- lyx-devel/trunk/src/mathed/MacroTable.h (original)
| +++ lyx-devel/trunk/src/mathed/MacroTable.h Thu May 24 18:29:40 2007
| @@ -49,6 +49,16 @@
| ///
| void unlock() const { --lockCount_; BOOST_ASSERT(lockCount_ = 0); }
|
| + ///
| + bool operator==(MacroData const x) const {
| + return def_ == x.def_
| + numargs_ == x.numargs_
| + disp_ == x.disp_
| + requires_ == x.requires_;
| + }
| + ///
| + bool operator!=(MacroData const x) const { return !operator==(x); }
It is preferrable to have binary operators out-of-class. Make them
friends if they have to access private data.
bool operator==(MacroData const lhs, MacroData const rhs)
{
return lhs.def_ == rhs.def_
lhs.numargs_ == rhs.numargs_
lhs.disp_ == rhs.disp_
lhs.requires_ == rhs.requires_;
}
And then != gets nicer as well:
bool operator!=(MacroData const lhs, MacroData const rhs)
{
return !(lhs == rhs);
}
| Modified: lyx-devel/trunk/src/mathed/MathMacro.cpp
| URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/MathMacro.cpp?rev=18489
| ==
| --- lyx-devel/trunk/src/mathed/MathMacro.cpp (original)
| +++ lyx-devel/trunk/src/mathed/MathMacro.cpp Thu May 24 18:29:40 2007
| @@ -75,20 +76,24 @@
| void MathMacroArgumentValue::draw(PainterInfo pi, int x, int y) const
| {
| // unlock outer macro in arguments, and lock it again later
| - MacroTable::globalMacros().get(macroName_).unlock();
| - value_-draw(pi, x, y);
| - MacroTable::globalMacros().get(macroName_).lock();
| + MacroData const macro =
MacroTable::globalMacros().get(mathMacro_.name());
| + macro.unlock();
| + mathMacro_.cell(idx_).draw(pi, x, y);
| + macro.lock();
| }
|
|
| MathMacro::MathMacro(docstring const name, int numargs)
| - : InsetMathNest(numargs), name_(name)
| + : InsetMathNest(numargs), name_(name), editing_(false)
| {}
|
|
| auto_ptrInset MathMacro::doClone() const
| {
| - return auto_ptrInset(new MathMacro(*this));
| + MathMacro * x = new MathMacro(*this);
| + x-expanded_ = MathData();
| + x-macroBackup_ = MacroData();
| + return auto_ptrInset(x);
| }
Put new pointer into smart pointer as very first thing. Better
defensive programming.
--
Lgb
Re: r18496 - /lyx-devel/trunk/src/insets/InsetInclude.cpp
[EMAIL PROTECTED] writes:
| Author: rgheck
| Date: Thu May 24 21:19:23 2007
| New Revision: 18496
|
| URL: http://www.lyx.org/trac/changeset/18496
| Log:
| Fix stupid use of or.
|
| Modified:
| lyx-devel/trunk/src/insets/InsetInclude.cpp
|
| Modified: lyx-devel/trunk/src/insets/InsetInclude.cpp
| URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/InsetInclude.cpp?rev=18496
| ==
| --- lyx-devel/trunk/src/insets/InsetInclude.cpp (original)
| +++ lyx-devel/trunk/src/insets/InsetInclude.cpp Thu May 24 21:19:23 2007
| @@ -233,7 +233,7 @@
| bool isInputOrInclude(InsetCommandParams const params)
| {
| Types const t = type(params);
| - return (t == INPUT) or (t == INCLUDE);
| + return (t == INPUT) || (t == INCLUDE);
| }
Thanks.
--
Lgb
Re: How can I compare two Insets?
Jean-Marc Lasgouttes wrote: Elazar == Elazar Leibovich [EMAIL PROTECTED] writes: Elazar Granted. However how do you determine that? Is it by the last Elazar cursor the user has clicked (if he pressed -, he'll be after Elazar character X, if he typed - he'll be before character Y)? There is something like that I think. JMarc The example that Andre' gave of line breaks is where I've run into boundary actually being used. You can see it in action in cursorRight (in Text2.cpp) and cursorLeft (though the latter I just rewrote last week, based on cursorRight, without fully understanding, so take it with a grain if salt). Dov
Re: r18494 - in /lyx-devel/trunk/src: LyXFunc.cpp insets/Inse...
[EMAIL PROTECTED] writes:
| Author: rgheck
| Date: Thu May 24 19:17:04 2007
| New Revision: 18494
|
| URL: http://www.lyx.org/trac/changeset/18494
| Log:
| Fix for bugs 2199 and 3667. Most of the changes were to the logic. Buffers
| that were opened for possible included LyX files need to be closed if those
| files cannot be loaded, for example. A bit more work was needed to allow a
| LyX file to include itself as a verbatim or listings without trying to load
| itself and without relying upon loadIfNeeded() to report the problem.
|
| Modified:
| lyx-devel/trunk/src/LyXFunc.cpp
| lyx-devel/trunk/src/insets/InsetInclude.cpp
|
| Modified: lyx-devel/trunk/src/insets/InsetInclude.cpp
| URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/insets/InsetInclude.cpp?rev=18494
| ==
| --- lyx-devel/trunk/src/insets/InsetInclude.cpp (original)
| +++ lyx-devel/trunk/src/insets/InsetInclude.cpp Thu May 24 19:17:04 2007
| @@ -230,6 +230,13 @@
| }
|
|
| +bool isInputOrInclude(InsetCommandParams const params)
| +{
| + Types const t = type(params);
| + return (t == INPUT) or (t == INCLUDE);
| +}
We have not used 'or', 'and' until now, and I see no or little reason
to begin using them. Apart from making the code in-consistent that is.
Please change :-)
--
Lgb
