Am Samstag, 30. Mai 2015 um 02:43:17, schrieb Uwe Stöhr
> Am 29.05.2015 um 07:55 schrieb Guenter Milde:
>
> >> What is the benefit of this file? This file oly checks one style and we
> >> already check for this style in another test file?
> >
> > However, i
Am 29.05.2015 um 07:55 schrieb Guenter Milde:
What is the benefit of this file? This file oly checks one style and we
already check for this style in another test file?
However, if the other test file tests not only for this style but for
different features, it is easier to find out the
Am Freitag, 29. Mai 2015 um 05:55:50, schrieb Guenter Milde
> On 2015-05-28, Uwe Stöhr wrote:
> > Am 24.05.2015 um 17:55 schrieb Kornel Benko:
>
> >>> delete test file verbatim.tex
>
> >>> because we already check for verbatim in test-structure.
On 2015-05-28, Uwe Stöhr wrote:
> Am 24.05.2015 um 17:55 schrieb Kornel Benko:
>>> delete test file verbatim.tex
>>> because we already check for verbatim in test-structure.tex
...
>> I'd prefer to have _more_ different tests, not only one BIG. So t
Am 26.05.2015 um 11:33 schrieb Kornel Benko:
There were discussions about it, see e.g.
http://lyx-devel.lyx.narkive.com/wPUh141b/make-distdir-is-failing-for-missing-test-documents
Also see commit b188e74cd6b089be3d63d905bf9db532e53f54c5
Thanks for the pointer.
So for the set of compilable fil
Am 24.05.2015 um 17:55 schrieb Kornel Benko:
delete test file verbatim.tex
because we already check for verbatim in test-structure.tex
Uwe please stop it.
I'd prefer to have _more_ different tests, not only one BIG. So that
searching for bugs may be easier.
Sorry Kornel.
Am Dienstag, 26. Mai 2015 um 01:25:42, schrieb Uwe Stöhr
> Am 24.05.2015 um 18:19 schrieb Kornel Benko:
>
> >> Dummy Document.tex: this file was missing but input in our test file
> >
> > It was by intent missing.
>
> Why? A file with spaces is a good te
Am 24.05.2015 um 18:19 schrieb Kornel Benko:
Dummy Document.tex: this file was missing but input in our test file
It was by intent missing.
Why? A file with spaces is a good testcase but we will only see if it
works if we have a real one.
regards Uwe
Am Sonntag, 24. Mai 2015 um 18:06:05, schrieb Uwe Stöhr
> commit 82c7669381fa95d00fa13e6cf70eae1bbc721875
> Author: Uwe Stöhr
> Date: Sun May 24 18:06:02 2015 +0200
>
> Dummy Document.tex: this file was missing but input in our test file
It was by intent missing.
Am Sonntag, 24. Mai 2015 um 17:20:59, schrieb Uwe Stöhr
> commit e1c04e56e1119af60cb7a4da552cba841dc5e83d
> Author: Uwe Stöhr
> Date: Sun May 24 17:20:55 2015 +0200
>
> delete test file verbatim.tex
>
> because we already check for verbatim in test-structu
> Why not using LyX.Embed.X for the drive letter under windows?
The logic in EmbeddedFIle::set() should be carefully examined. It
works like this now,
1. When a file is created, for example,
document path: /home/bpeng/doc/file.lyx
embedded file: /home/bpeng/figures/figure.png
Its relative
> I understand the path problem, but not why LyX crashes. When an embedded file
> could not be found (no
> matter if the path or what ever is the reason), LyX should display the error
> message as it already
> does, but then not crash.
In the implementation, I intentionally assumes the availabil
> The problem is clear: there is no unique representation of absolute
> path under different OS.
I understand the path problem, but not why LyX crashes. When an embedded file could not be found (no
matter if the path or what ever is the reason), LyX should display the error message as it already
Bo Peng wrote:
In the end, Joost's suggestion might be the only solution.
Joost's solution has its own features/problems. For example, when I
insert the same file twice, the current solution consider them as the
same file (both external and inzip). However, using UUID as inzip
filename, they wi
Bo Peng wrote:
The problem is clear: there is no unique representation of absolute
path under different OS. The absolute file in the test lyx file is
/home/bpeng/blah and its inzip name is LyX.Embed.Abs/home/bpeng/blah.
Under windows, the file is considered as
c:/home/bpeng/blah and its inzip na
> In the end, Joost's suggestion might be the only solution.
Joost's solution has its own features/problems. For example, when I
insert the same file twice, the current solution consider them as the
same file (both external and inzip). However, using UUID as inzip
filename, they will be different.
The problem is clear: there is no unique representation of absolute
path under different OS. The absolute file in the test lyx file is
/home/bpeng/blah and its inzip name is LyX.Embed.Abs/home/bpeng/blah.
Under windows, the file is considered as
c:/home/bpeng/blah and its inzip name is
LyX.embed.A
On Jan 8, 2008 5:38 PM, Uwe Stöhr <[EMAIL PROTECTED]> wrote:
> Bo Peng schrieb:
>
> > Did you see this right after lyx opens the file?
>
> Yes.
OK, I am building a windows version.
Bo
Bo Peng schrieb:
Did you see this right after lyx opens the file?
Yes.
Uwe
> I get:
>
> Failed to embed file C:/usr/local/share/icons/hicolor/48x48/apps/poedit.png.
> Please check whether this file exists and is readable.
>
> Because I don't have the poedit.png.
> But then LyX crashes!
I know absolute path would lead to problems...
Did you see this right after lyx opens
> I have uploaded a test file to
> http://www.lyx.org/~bpeng/test.lyx, which has several embedded insets.
> Please play with it and see if you like how embedding is done
> now.
I get:
Failed to embed file C:/usr/local/share/icons/hicolor/48x48/apps/poedit.png.
Please check wheth
> Maybe this has been discussed before but why don't we standardize on a
> .zlyx or .lyz extension?
If you are talking about blocking, extension does not matter.
In general, the problem of .lyz is that there is no easy logic for
'save' and 'save as' if two file extensions are used.
Bo
Bo Peng wrote:
Dear all,
With my last several commits, I have added embedding support for
InsetGraphics, InsetInclude, InsetExternal and InsetBibtex (any
more??). I have uploaded a test file to
http://www.lyx.org/~bpeng/test.lyx, which has several embedded insets.
Please play with it and see
Dear all,
With my last several commits, I have added embedding support for
InsetGraphics, InsetInclude, InsetExternal and InsetBibtex (any
more??). I have uploaded a test file to
http://www.lyx.org/~bpeng/test.lyx, which has several embedded insets.
Please play with it and see if you like how
On Monday 04 December 2000 18:45, Lars Gullik Bjønnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> | On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bjønnes wrote:
> | > Angus Leeming <[EMAIL PROTECTED]> writes:
> | > | This is dying in Buffer::isLatex()
> | >
> | > Are you sure that in
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bjønnes wrote:
| > Angus Leeming <[EMAIL PROTECTED]> writes:
| >
| > | This is dying in Buffer::isLatex()
| >
| > Are you sure that inlining is not playing tricks on you?
| >
| > Seems almost liek is
On Mon, Dec 04, 2000 at 03:56:53PM +0100, Lars Gullik Bj&resh;nnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | This is dying in Buffer::isLatex()
>
> Are you sure that inlining is not playing tricks on you?
>
> Seems almost liek isLatex is beeing called on a buffer that has just
>
On Monday 04 December 2000 14:56, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | This is dying in Buffer::isLatex()
>
> Are you sure that inlining is not playing tricks on you?
>
> Seems almost liek isLatex is beeing called on a buffer that has just
> been deleted...
B
Angus Leeming <[EMAIL PROTECTED]> writes:
| This is dying in Buffer::isLatex()
Are you sure that inlining is not playing tricks on you?
Seems almost liek isLatex is beeing called on a buffer that has just
been deleted...
Lgb
0xe, 0x12030ba34,
0x14
Can some guru explain to me why (this) should be (nil)?
Angus
On Monday 04 December 2000 10:12, Martin Vermeer wrote:
> > Here's a test file created in lyx-1.1.5fix1-1
> that makes the CVS LyX core dump. Apparently
> related to the table fo
Here's a test file created in lyx-1.1.5fix1-1
that makes the CVS LyX core dump. Apparently
related to the table format change.
Remove the ref from the table and the crash
goes away. This is the only thing keeping
me from upgrading.
Yst. Martin
--
Martin Vermeer [EMAIL PROTECTED]
Hel
On 23 Aug 2000, Lars Gullik Bjønnes wrote:
>
> /* This output manipulator gives the option to use Old style format
>specifications in ostreams. Note that this is done at the expense
>of typesafety, so if possible this manipulator should be avoided.
>When is it allowed to use this man
/// fmt.h
// -*- C++ -*-
#include
std::string fmt(char const * fmtstr ...);
/// fmt.C
#include
#include
#include "fmt.h"
/* This output manipulator gives the option to use Old style format
specifications in ostreams. Note that this is done at the expense
of typesafety, so if possibl
33 matches
Mail list logo
