Abdelrazak Younes wrote:
I'm also annoyed by this and the reason is that LyX1.5svn scans all
directories before opening the dialog. LyX 1.4.4 doesn't do this so
the dialog pops up immediately.
I'm sure that this is the reason because on my home PC, the dialog
opens in 1.5svn after 1-2
Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Am 11.05.2007 um 14:24 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
I work on a better implementation of math macros for some time now.
Accidently I was playing around with some screencast tools and made
a demonstration of the current
Bennett Helm wrote:
I wish I had a patch; I at least have a special plea: could someone
fix this bug? --
http://bugzilla.lyx.org/show_bug.cgi?id=3544
Down-arrow in main text skips lines (on Mac, at least)
(Do other platforms not have this problem?) It would be embarrassing
to release the
This is very unlikely to be a LyX error, though it could be. I just ran
ps2pdf on a file of my own, and it worked fine.
Here's how to debug your problem: Export the file to LaTeX; then run
LaTeX manually on the file to produce thesis.dvi, running BibTeX etc as
necessary; run dvips -o thesis.ps;
Pavel Sanda wrote:
I'll try, but how do I do this? Is there some svn command for
reverting to a specific version?
i'm not aware of any direct revert command of svn.
however you can checkout particular revision of the svn tree
(i.e. the 18265 revision).
svn up -r VERSION
--
Darren Freeman wrote:
Hi all,
I have a Mandrake 10.0 (gasp!) machine which I just built LyX (latest
svn) on with Qt 4.2.3 compiled from source also. What follows also
applied to earlier svn and earlier Qt, I tried rebuilding everything
with latest versions out of confusion.
When I run it
Can you get a backtrace from this? Just run it under gdb. It'll help if
you compile with -enable-debug.
Darren Freeman wrote:
On Wed, 2007-05-16 at 01:48, Richard Heck wrote:
Darren Freeman wrote:
Hi all,
I have a Mandrake 10.0 (gasp!) machine which I just built LyX (latest
svn
I'm not getting a crash with this, though I do see some warnings:
[EMAIL PROTECTED] tmp]$ ~/dev/bin/tex2lyx internal.tex
Creating file /tmp/internal.lyx
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
unexpected dummy size: 2 content:
It looks to me as if QListings.cpp is encoded differently from the other
files.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
Abdelrazak Younes wrote:
Martin Vermeer wrote:
I seem to recall that there was some code in the Qt X event handling
code, precisely to handle this problem. Lars wrote this. But then it
was decided that it could be removed... anyone remember? Something
with coalescing of multiple keystroke
Peter Kümmel wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3320
There's a patch mostly ready for the key release problem. The only
problem with the patch is that it uses specific X11 event; it would be
better to do something similar
Andre Poenitz wrote:
On Wed, May 16, 2007 at 11:57:51PM +0200, Peter Kümmel wrote:
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
+// do nothing if there are other events
+// (the auto repeated events come too fast)
+if(QCoreApplication::hasPendingEvents()) {
+
Whoops. Another of those really easy fixes...and sent to the wrong list,
too. Bad day
=
The attached patch addresses these two bugs. The problem was that
Text::setFont was not updating the current font (real_current_font, etc)
when a selection (implicit or explicit) was active. This
I've discussed this with Abdel already but am sending the fix to the
list before committing. The problem is that hitting escape (which emits
the rejected() signal) bypasses such closeEvent() and the like.
Unfortunately, Abdel's suggestion that we should call slotRestore()
here, although
As described. This is already there for the non-Word version. Absent
these settings, (a) we lose reference info and (b) only the main .html
file is copied to the result directory, with the other files (e.g.,
.css) remaining in the temporary directory.
OK to commit?
There are, by the way, also
DANG IT!!
As described. This is already there for the non-Word version. Absent
these settings, (a) we lose reference info and (b) only the main .html
file is copied to the result directory, with the other files (e.g.,
.css) remaining in the temporary directory.
OK to commit?
There are,
Can someone take a look at this code from Exporter.cpp? It seems to me
that we ought to be returning where I've indicated below. Is this wrong?
// Plain text backend
if (backend_format == text)
writePlaintextFile(*buffer, FileName(filename), runparams);
// no backend
else
Abdelrazak Younes wrote:
Richard Heck wrote:
Can someone take a look at this code from Exporter.cpp? It seems to me
that we ought to be returning where I've indicated below. Is this wrong?
You mean return true? Maybe yes.
On looking closer, no, there are some things that happen later, even
The default OpenOffice format is presently sxw, but oolatex now seems to
produce odt by default. As a result, LyX thinks the conversion always
fails, because it's looking for filename.sxw and can't find it.
I think there are ways to make oolatex produce sxw (I'm trying to find
out how), so one
OK. I'll take care of this later. Right now, I have to go to a baseball
game
José Matos wrote:
On Thursday 17 May 2007 8:06:43 pm Abdelrazak Younes wrote:
By the way, it's VERY unclear how to add a new file format. It took me
quite a while to figure it out. Perhaps a tooltip on the
I'm working on a patch that addresses several problems with the
converters. This will hopefully address bugs 643, 2807, and 3047. I
should be sending to the list shortly.
José Matos wrote:
Hi,
a common share of LyX release managers is that we have the memory and
span
attention of a
The attached patch addresses these bugs, all of which have to do with
export, viewing, and the like---ultimately, with the conversion
routines. The patch introduces a new conversion flag, usetempdir, which
forces the converter to do all its work in a temporary directory created
under the
Jean-Marc Lasgouttes wrote:
José == José Matos [EMAIL PROTECTED] writes:
José On Friday 18 May 2007 12:05:32 pm Jean-Marc Lasgouttes wrote:
Is it just a sudo /etc/init.d/httpd restart ?
José Or the same sudo service httpd restart
And you also often have: sudo
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
José Matos wrote:
3637 is attached. (Get label from parameter string and push to
label list).
Jürgen is this OK with you?
Hm, I missed this and did something similar. Bo's patch is generally
better, but lacks changeRefsIfUnique.
I propose
Any comments on this? Anyone care to test it? If you like ExportHTML or
ViewHTML, you are going to like this
The attached patch addresses these bugs, all of which have to do with
export, viewing, and the like---ultimately, with the conversion
routines. The patch introduces a new
José Matos wrote:
On Friday 18 May 2007 7:42:56 pm Richard Heck wrote:
Any comments on this? Anyone care to test it? If you like ExportHTML or
ViewHTML, you are going to like this
I did not forgot it, I was thinking. I am slow at times. ;-)
No problem. I know you have a few
Peter Kümmel wrote:
What hasPendingEvents returns makes no sense to me.
Isn't it that there is a queue for all events, and when one
is handled (event-accept()) it is done and removed from the
queue? The truth isin the Qt source code, but who could
read it?
Could this be part of the
The attached addresses http://bugzilla.lyx.org/show_bug.cgi?id=3650. The
issues were two. (i) When the old inset was erased, the iterator became
invalid, and the attempt to increment it caused an abort; (ii) after
clearing that up, a different abort made it clear that the cursor
position needed
Richard Heck wrote:
NOTE: Some other issues I noticed here, which I'll put in bugzilla if it
seems a good idea. (iii) Change the layout of one of
these paragraphs to Standard. Shouldn't the bibitem be erased? (This
could be handled in checkBiblio without too much effort.)
Never mind
Bernhard Roider wrote:
In general enums are more explicative:
enum CursorMove {
NoMove,
MoveRight,
MoveLeft
}
I did not take a closer look at the code, but shouldn't it be forward
and backward instead of right and left?
I don't think so. The `right' and `left' don't actually
Abdelrazak Younes wrote:
Richard Heck wrote:
Index: Paragraph.h
===
--- Paragraph.h(revision 18413)
+++ Paragraph.h(working copy)
@@ -359,9 +359,11 @@
///
bool hfillExpansion(Row const row, pos_type pos
Jürgen Spitzmüller wrote:
Richard Heck wrote:
The attached addresses http://bugzilla.lyx.org/show_bug.cgi?id=3650. The
issues were two. (i) When the old inset was erased, the iterator became
invalid, and the attempt to increment it caused an abort; (ii) after
clearing that up, a different
wrote:
Am Freitag, 18. Mai 2007 21:14 schrieb José Matos:
On Friday 18 May 2007 7:42:56 pm Richard Heck wrote:
The attached patch addresses these bugs, all of which have to do with
export, viewing, and the like---ultimately, with the conversion
routines. The patch introduces
Attached is a slightly updated version of this patch. OK to commit?
A proper clean-up of this will have to wait a bit.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
Georg Baum wrote:
So, if you open
/path/file.lyx and FileExportFormat, you will get a directory
/path/file.format.conversion/ in which all the files generated by the
converter will be found (e.g. the mess that htlatex generates ends up
in/path/file.html.conversion/).
A flag for the
Committed...thanks Uwe and Jurgen
Richard Heck wrote:
Attached is a slightly updated version of this patch. OK to commit?
A proper clean-up of this will have to wait a bit.
Richard
Index: Paragraph.h
Looks sensible to me.
Stefan Schimanski wrote:
STL's vector doesn't give access to the data required by Qt, but
QVector does. So this slight variation of your proposed patch:
// double the size if needed
static QVectorQPoint points(32);
if (np points.size())
The attached patch partially addresses this bug. Not completely, because
it only checks if a file is including itself and not if a file includes
a file that includes it (etc). The places where the more general check
would need to be done are identified with FIXME RECURSIVE INPUT so that
this can
I've been studying this bug a bit and think I know where the problem is,
more or less. The attached file is as minimal as I can get it. The
change of font is crucial. Without it, there is no crash.
Font::writeLatexEndChanges we have this code:
if (open_encoding_) {
// We need to
This also addresses the new bug 3659.
Richard Heck wrote:
The attached patch partially addresses this bug. Not completely, because
it only checks if a file is including itself and not if a file includes
a file that includes it (etc). The places where the more general check
would need
Richard Heck wrote:
Can you be more specific about the problem? What kind of keyboard are
you using? What language encoding? etc?
Gyorgy Pota wrote:
Dear Users,
It has already been raised that, for example, textdegree symbol did
not work in the early Lyx 1.5 beta(s). Now I can report
Jürgen Spitzmüller wrote:
Richard Heck wrote:
I've been studying this bug a bit and think I know where the problem is,
more or less. The attached file is as minimal as I can get it. The
change of font is crucial. Without it, there is no crash.
I think the real problem is really just
Jürgen Spitzmüller wrote:
Richard Heck wrote:
I've been studying this bug a bit and think I know where the problem is,
more or less. The attached file is as minimal as I can get it. The
change of font is crucial. Without it, there is no crash.
I think the real problem is really just
what a weird bug. nice work.
Edwin Leuven wrote:
great detective work!!
this fixes the crash on my side, so this gets an ok from me.
Stefan Schimanski wrote:
The following patch fixes this problem for the cmake build system. I
have not checked the other build systems, maybe similar fixes
Georg Baum wrote:
Am Samstag, 19. Mai 2007 18:45 schrieb Richard Heck:
So resultdir should be set if and only if the
converter creates a directory by itself. Please make sure that this does
work in combination with usetempdir, or make these two flags mutually
exclusive (since
I think this is a matter of getting used to how LyX works. It's true
that people coming from other programs will expect the behavior you
expected, but that's not the only way it can sensibly work. We can
discuss here which way it should work. I can tell what your vote is. ;-)
What is definitely
Confirmed. I've filed a bug report. Note that Comments and Greyed Out
probably should be included, since they are visible in the output.
Darren Freeman wrote:
Hi all,
I believe the word count feature is including text within notes. I think
this is incorrect behaviour as notes aren't normally
Abdelrazak Younes wrote:
Richard Heck wrote:
I wonder whether I should just commit the patch as-is, thus fixing HTML
output and ViewHTML for 1.5.0, and do something about cleaning this
code up more generally after 1.5.0 is out. My thought is just that
changing how convert() works more
I'll try to do it today.
Jean-Marc Lasgouttes wrote:
Darren == Darren Freeman [EMAIL PROTECTED] writes:
Darren Hi all, I believe the word count feature is including text
Darren within notes. I think this is incorrect behaviour as notes
Darren aren't normally part of the
To get ViewHTML working (to be committed soon), I had to change one of
the flags. I took the opportunity then to expand the very minimal
documentation about this. I've pasted it below as text. Comments
welcome. I'd like to make sure in particular that this is correct,
especially the bits about
So the crash here is being caused by the assertion
BOOST_ASSERT(c0)
on line 941 of Font.cpp. Doesn't this seem like overkill? I mean, yes,
we'll get invalid LaTeX output, but why the assertion? There's no danger
of a crash here. So if I replace the assertion with this:
lyxerr Warning:
Georg,
It was suggested I ask you about this.
rh
=
So the crash here is being caused by the assertion
BOOST_ASSERT(c0)
on line 941 of Font.cpp. Doesn't this seem like overkill? I mean, yes,
we'll get invalid LaTeX output, but why the assertion? There doesn't
seem to be any danger of a
Jean-Marc Lasgouttes wrote:
Richard I'll try to do it today.
This is the kind of stuff that can wait for after 1.5.0...
If it were trivial, I'd do it, but it's not. You can't just check for
the inset type, as an InsetNote will need to be counted if it's anything
but a Type::Note. We could
Just wanted to bring this to people's attention:
#ifdef WITH_WARNINGS
#warning This will not work anymore when we have multiple views of the
same buffer
// In this case, we will have to correct also the cursors held by
// other bufferviews. It will probably be easier to do that in a more
//
http://bugzilla.lyx.org/show_bug.cgi?id=3676
Just so no-one else works on it...I've got this fixed but have to do
some cleanup before sending the patch to the list (as well as making the
diff file, since this involved several files). This turns out to be a
very bad bug, one I'm amazed we haven't
Andre Poenitz wrote:
On Mon, May 21, 2007 at 05:59:45PM -0400, Richard Heck wrote:
Just wanted to bring this to people's attention:
#ifdef WITH_WARNINGS
#warning This will not work anymore when we have multiple views of the
same buffer
Do we officially have multiple views now? I still
Darren Freeman wrote:
This is the kind of stuff that can wait for after 1.5.0...
It sounds trivial but IMHO it's really quite insidious.
It's not so much that it's trivial as that there are bigger bugs to be
squashed. And, unfortunately, the fix, though, as JMarc said,
conceptually
Confirmed. Should be an easy fix.
Darren Freeman wrote:
Hi all,
I have two BibTeX entries with the following names: IntroFIB, and
IntroFIBch2.
If I cite the second one, and then go to add the first one, I won't be
able to because the Add button is disabled. It looks like the test for
A very simple patch to fix this bug. OK to commit?
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public
The attached patch addresses a reported problem with the citation
dialog, but the problem was much more extensive than the bug made
apparent. See:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg117655.html
for a bit more on the nature of the bug.
The fix involves re-working the
I'm sure this would be most welcome to people who exchange LyX files
with pure LaTeX users.
Stefan Schimanski wrote:
I backported my fix to trunk as proposed by Uwe. The patch is attached
to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21
Stefan
--
Darren Freeman wrote:
On Tue, 2007-05-22 at 02:21 -0400, Richard Heck wrote:
By the way, are we sure we want the search as you go functionality
currently in the citation dialog? There is notable slowness on my
machine (Athlon 2400+, 1GB), as I've got 500+ BibTeX keys in the dialog
This patch has been to the list previously and been more or less
approved. I'm sending it again, however, as I've made some additional
changes and it should be tested by at least one other person, I think,
before I commit. If you do test, please test: (i) ViewHTML; (ii)
FileExportHTML; (iii)
Darren Freeman wrote:
Maybe you could search as you go but in another thread? So the input box
isn't slowed down while you touch-type. The search restarts every time
you modify the search string. Or maybe it starts after a half-second
delay of no typing.
Yes, a timer would be an option.
Herbert Voss wrote:
contains(buffer-filePath(), ' ')) {
Alert::error(_(File name error),
- _(The directory path to the document cannot contain
spaces.));
+ _(The directory path to the document cannot contain
spaces,
This is the result of a problem that Uwe noticed the other day with the
MikTeX implementation of the htlatex scripts: The scripts will not run
properly unless they are run in the same directory as the original file.
So you can't run e.g. htlatex C:/path/to/file.tex. You can only run
htlatex
José Matos wrote:
On Tuesday 22 May 2007 6:24:41 am Richard Heck wrote:
A very simple patch to fix this bug. OK to commit?
OK. What do we loose with the removal of the regular expression?
Sorry, the patch is confusing. There were no regular expressions there.
The ones
Jean-Marc Lasgouttes wrote:
Richard The attached patch addresses a reported problem with the
Richard citation dialog, but the problem was much more extensive than
Richard the bug made apparent. See:
Richard http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg117655.html
Richard for a bit
Darren Freeman wrote:
Secondly, the learning curve is quite steep! Try explaining to somebody that
the right way to type one-point-five-five-microns is to press {C-m, 1.55,
\ , \mu, , C-m, m}. They want to know why they can't just insert a
mu where they want it like in a real word
By the way, are we sure we want the search as you go functionality
currently in the citation dialog? There is notable slowness on my
machine (Athlon 2400+, 1GB), as I've got 500+ BibTeX keys in the dialog
and they all have to be searched on every keypress.
In svn,
José Matos wrote:
On Tuesday 22 May 2007 4:38:23 pm Richard Heck wrote:
OK. I'll hold this for now. But I expect we'll see more bug reports
about this. It's not that hard to trigger it, and it looks really bad in
the dialog itself.
If you get one or two people, not necessarily
Can someone see if using htlatex.bat rather than htlatex on Windows
helps with the can't use pathnames problem? I've found some references
to this on the web.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
script or something that would fix the problem on Windows.
Richard
Edwin Leuven wrote:
Richard Heck wrote:
Can someone see if using htlatex.bat rather than htlatex on Windows
helps with the can't use pathnames problem? I've found some references
to this on the web.
no luck (works fine if i run
Edwin Leuven wrote:
one thing which should be done is to remove linebreaks in entries,
f.e. if i have an entry like this
@article{doe2000,
title = {My brilliant
new paper},
...}
then the newline in the title is visible in the citation dialog. it
wasn't like this before...
Lars Olesen wrote:
How do I translate a lyx document to docbook
Open DocumentSettingsDocumentClass. In the Document Class drop box,
choose DocBook (article) or whatever. Choose OK. (You may get some
conversion errors depending upon the document.) Now look under
FileExport. You should see
Neal Becker wrote:
Oh, I did get an answer. Unfortunately, I can't seem to find the message
right now, but the answer is, that I need to make that agr-pdf instead of
agr-pdf2.
There was also a discussion that the use of pdf{,2,3} was really a broken
design.
It is confusing, but the
Abdelrazak Younes wrote:
Richard Heck wrote:
So now I type an
a. That narrows it down to everything that contains sa. Again,
little progress. Now I type m. That will weed out a few things, but
possibly not very many, especially because I have a lot of annote,
abstract, and review fields
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
Helge Hafting wrote:
Bo Peng wrote:
Issues:
* The LyX document can't include its own source file as a listing,
complaining that the document includes itself. A bit strange perhaps,
but this is _not_ a problem with a listing, as the nothing more will
be included from the listed source.
Stefan Schimanski wrote:
I removed the margin now completely and substract 1 in the cursorUp
case. This works fine everywhere but the display math. In display math
(i.e. a InsetMathHull) the cursor up/down keys are not handled
properly. Instead Cursor::bruteFind is used to find the nearest
Is it safe to use the create_symlink function from boost::filesystems?
Are there platforms on which we want LyX to run that don't handle symlinks?
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
Jean-Marc Lasgouttes wrote:
Richard Is it safe to use the create_symlink function from
Richard boost::filesystems? Are there platforms on which we want LyX
Richard to run that don't handle symlinks?
Windows?
I thought Windows did do symlinks but not hard links. Google tells me I
was
Jean-Marc Lasgouttes wrote:
Richard Is it safe to use the create_symlink function from
Richard boost::filesystems? Are there platforms on which we want LyX
Richard to run that don't handle symlinks?
Windows?
So does this seems sensible?
namespace {
// A little helper for what
Should the critical and major bug lists also check the milestone?
I've just reset 1474 to milestone 1.6.0, because I'm morally certainly
no-one is going to fix such an obscure crash before 1.5.0. But it still
shows up on the list
rh
--
Abdelrazak Younes wrote:
Richard Heck wrote:
Should the critical and major bug lists also check the milestone?
Yes IMO.
OK, then. Done. I can't do it for regressions, as too many of those have
no milestone set and maybe shouldn't. But I can try to go through these
at some point.
rh
Jean-Marc Lasgouttes wrote:
Richard So does this seems sensible?
Why do you want symlinks actually?
It's not a big deal, but the solution I've worked out to various
problems with the converter code (e.g., in the case of htlatex) involves
copying the file we're converting from (infile, in the
Jean-Marc Lasgouttes wrote:
Richard Should the critical and major bug lists also check the
Richard milestone? I've just reset 1474 to milestone 1.6.0, because
Richard I'm morally certainly no-one is going to fix such an obscure
Richard crash before 1.5.0. But it still shows up on the list
Enrico (and anyone else who is interested),
Can you try one and let me know if it works properly on Windows? I
believe it should, even with the broken htlatex. The idea is to copy
whatever files we need to the temporary conversion directory. Then we
can do everything without paths.
Richard
--
Enrico Forestieri wrote:
On Wed, May 23, 2007 at 12:00:58PM -0400, Richard Heck wrote:
I tested the patch on linux and I found some quirks. The least important
is that when exporting to html, the export dir is filled with byproduct
files such as .dvi, .aux, .log, .idv, and others which
Never mind...see the other message.
Enrico Forestieri wrote:
On Wed, May 23, 2007 at 06:04:59PM -0400, Richard Heck wrote:
Enrico (and anyone else who is interested),
Can you try one and let me know if it works properly on Windows? I
believe it should, even with the broken htlatex
The 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
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
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
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
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
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
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
[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
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
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
1 - 100 of 9793 matches
Mail list logo
