On 4 Oct 2000, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Incidentally, why does the return below (insetinclude.C) return
> Angus> ost.str().c_str() rather than ost.str()?
>
> Because ost.str() is always a basic_string, whereas string may
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Incidentally, why does the return below (insetinclude.C) return
Angus> ost.str().c_str() rather than ost.str()?
Because ost.str() is always a basic_string, whereas string maybe a
lyxstring.
JMarc
On Sun, Oct 01, 2000 at 10:38:38AM +0300, Dekel Tsur wrote:
> However, with few changes, I've managed to make export work with no gui.
> A patch is attached.
Before submitting tihs patch, I did some tests, but I didn't perform
"the test": exporting the user guide to Postscript. Of course, this t
On Sun, 1 Oct 2000, Kayvan A. Sylvan wrote:
> I've rolled some minor changed into Dekel's patch (simplify the
> build-listerrors process).
Applied in my tree will commit shortly.
Allan. (ARRae)
On Sun, Oct 01, 2000 at 10:38:39AM +0300, Dekel Tsur wrote:
> On Wed, Sep 27, 2000 at 06:12:20PM +0200, Andre Poenitz wrote:
> >
> > Ok, so gui = false; is safe now:
>
> I tried and it doesn't work (i.e. LyX crashes).
> For example, in Converter::runLaTeX we use a BufferView.
> However, with fe
On Wed, Sep 27, 2000 at 06:12:20PM +0200, Andre Poenitz wrote:
>
> Ok, so gui = false; is safe now:
I tried and it doesn't work (i.e. LyX crashes).
For example, in Converter::runLaTeX we use a BufferView.
However, with few changes, I've managed to make export work with no gui.
A patch is attach
On Fri, 29 Sep 2000, Nicolas Thiery wrote:
> SourceForge.net is providing support (CVS repository, anonymous ftp
> site, Web page, Bug tracking system, mailing lists, forums ) for any
> open-source project. I use it for my own projects. At least from the
> purely technical point of view, setting
Hello,
> as people pointed out last time I suggested such, like bugzilla, this
> would require people with a knowledge of the codebase to adminstrate and
> triage, prioritise etc.
>
> BUT this would be real advantage if people actually use it, especially for
> tracking developer's/user's
On 29 Sep 2000, Jean-Marc Lasgouttes wrote:
> Even better would be a real bug-tracking database...
>
> JMarc
>
as people pointed out last time I suggested such, like bugzilla, this
would require people with a knowledge of the codebase to adminstrate and
triage, prioritise etc.
BUT this would
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch> On 27 Sep 2000, Jean-Marc Lasgouttes wrote:
>> and fix session (I have several bug reports in my mail folder which
>> depend on this).
Baruch> How about updating a known bug list and a todo list on the
Baruch> developers website f
On 27 Sep 2000, Jean-Marc Lasgouttes wrote:
> and fix session (I have several bug reports in my mail folder which
> depend on this).
How about updating a known bug list and a todo list on the developers
website for all to see?
It will help development since we'll all be able to know what bugs a
Attached is a log file of ALL the warnings posted when compiling the insets
directory with DEC cxx -w0. I've editted this file so that each warning
occurs ONCE only. It should, therefore, be useful!
Angus
make.log.bz2
Ok, so gui = false; is safe now:
--- schnipp -
Index: lyx_main.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
retrieving revision 1.50
diff -u -r1.50 lyx_main.C
--- lyx_mai
Angus Leeming <[EMAIL PROTECTED]> writes:
| Attached is a patch that cleans up the code in InsetBibtex and InsetInclude
| as outlined earlier.
|
| Incidentally, why does the return below (insetinclude.C) return
| ost.str().c_str() rather than ost.str()?
Look for te same constuct other places
Attached is a patch that cleans up the code in InsetBibtex and InsetInclude
as outlined earlier.
Incidentally, why does the return below (insetinclude.C) return
ost.str().c_str() rather than ost.str()?
Angus
static inline
string unique_id() {
static unsigned int seed = 1000;
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> InsetInclude = A quick glance shows that Buffer *
Angus> master can be replaced in each of the Latex(), DocBook(),
Angus> Linuxdoc() methods.
Angus> Are InsetInclude::getMasterFilename() and
Angus> InsetInclude::Validate()
Further investigation:
InsetBibtex
In InsetBibtex::Latex(Buffer const *, ostream & os,
bool /*fragile*/, bool/*fs*/) const
use the buffer that is passed but not used.
InsetBibtex::getKeys() is called only from Buffer. Call it as getKeys(this)
No need, therefore t
> Angus> Incidentally, in the case of InsetQuote, we can find the
> Angus> language in other ways. Shall I do this (see other mail). It
> Angus> doesn't address André's question about whether it's necessary,
> Angus> but it'll work cleanly.
>
> Yes, for the case of InsetQuote, your solution seems
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Incidentally, in the case of InsetQuote, we can find the
Angus> language in other ways. Shall I do this (see other mail). It
Angus> doesn't address André's question about whether it's necessary,
Angus> but it'll work cleanly.
Yes,
On 27-Sep-2000 Angus Leeming wrote:
>
> This is a fair point that is valid not only in this case, but in all those
> insets that store Buffer * buffer directly. Perhaps we should really think
> hard about how to get rid of this store in all these cases.
>
Yes we should!
> Incidentally, in t
On 27-Sep-2000 Angus Leeming wrote:
[snip]
> features.bufferParams().language
[snip]
> why not use the Buffer * that is passed but not used?
Good spotted! I use this and now InsetQuotes does not have any current_view.
(as soon as I commit ;)
While the first one is not needed anymore as I
JMarc> And what happens when insets are copy/pasted to another document?
This is a fair point that is valid not only in this case, but in all those
insets that store Buffer * buffer directly. Perhaps we should really think
hard about how to get rid of this store in all these cases.
Incidentall
On 27-Sep-2000 Angus Leeming wrote:
> Several of the insets already store Buffer * buffer directly, this being
> passed to the inset through the constructor. If we do the same here and in
> insetref.[Ch], then NONE of the insets use current_view at all.
>
> Shall I do this?
Be aware that in g
Further investigation reveals alternative routes of finding the language:
In InsetQuotes::Validate(LaTeXFeatures & features)
use
features.bufferParams().language
in place of current_view->buffer()->GetLanguage()
int InsetQuotes::Latex(Buffer const *, ostream & os,
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Several of the insets already store Buffer * buffer directly,
Angus> this being passed to the inset through the constructor. If we
Angus> do the same here and in insetref.[Ch], then NONE of the insets
Angus> use current_view at all
> Several of the insets already store Buffer * buffer directly, this being
> passed to the inset through the constructor. If we do the same here and in
> insetref.[Ch], then NONE of the insets use current_view at all.
>
> Shall I do this?
I live under the impression that current_view is a Bad
Several of the insets already store Buffer * buffer directly, this being
passed to the inset through the constructor. If we do the same here and in
insetref.[Ch], then NONE of the insets use current_view at all.
Shall I do this?
Angus
On Wed, 27 Sep 2000, Andre Poenitz wrote:
> The _only_ _tw
The _only_ _two_ obstacles for batch export to any format without popping
up the GUI are around line 297 and line 236 in insets/insetquotes.C the use
of current_view to get the buffer's language
current_view->buffer()->GetLanguage().
If this is replaced by "default", it works!
Of course, "de
28 matches
Mail list logo
