I am asking because setAutoBreakRows calls Paragraph::erase() which
requires a trackChanges flags in the new CT code. I guess that the buffer
parameter (ct on/off) has to be passed to setAutoBreakRows but I would
like to know your opinion first.
Yes, it has to be passed. LyXText::autoBreakRows_
Michael Gerz wrote:
> Does it make sense that setAutoBreakRows marks linebreaks as (logically)
> deleted if they are disallowed? Is the user allowed to revert the deletion
> later?
No, he is not. Actually I did not think about that case.
> This may lead to inconsistent states.
Yes. It should
On Wed, May 24, 2006 at 08:19:33PM +0300, Martin Vermeer wrote:
> On Wed, May 24, 2006 at 06:26:18PM +0200, Michael Gerz wrote:
...
> In non-ct mode, you irreversibly lose the newlines. It would be nice to
> mark them "blue" under ct.
s/blue/red/
- martin
pgp4c4CqndxJe.pgp
Description: PGP
Jan> Just my 2 cents: The LyX toolbars should be not repeats Word's
Jan> mistakes but include nice equation editing feature like SWP or
Jan> Mathtype which are currently "hidden" in the math panel (which
Jan> either costs me half my screen or has to be activated every
Jan> time). Practical math
Martin,
given the fact that you are not allowed to revert logical deletions within
the inset (otherwise you run into an inconsistent state), I am tempted to
remove linebreaks without CT marking. I.e. setAutoBreakRow does not consider
the buffer's change tracking mode. Does this make sense to
On Wed, May 24, 2006 at 07:45:25PM +0200, Michael Gerz wrote:
> Martin,
>
> given the fact that you are not allowed to revert logical deletions within
> the inset (otherwise you run into an inconsistent state), I am tempted to
> remove linebreaks without CT marking. I.e. setAutoBreakRow does
Jan Peters wrote:
> 1) it should be possible to activate these without going into the text
> files, why is there not View->Toolbars->Math,Extra,MiniBuffer,etc
> menu which allows this?
Because nobody implemented it.
> 2) Why is it still a less pleasant experience to edit an equation in
> LyX
On Wed, May 24, 2006 at 09:39:00AM -0400, Bennett Helm wrote:
> OK. Simple stupidity, I guess: I had the dvi converter defined as
> latex rather than pplatex.
Perhaps you are another victim of the way path_prefix is (not) handled.
> Is this a change I should make to the default distribution?
On May 24, 2006, at 3:04 PM, Enrico Forestieri wrote:
On Wed, May 24, 2006 at 09:39:00AM -0400, Bennett Helm wrote:
OK. Simple stupidity, I guess: I had the dvi converter defined as
latex rather than pplatex.
Perhaps you are another victim of the way path_prefix is (not)
handled.
No. As
On May 24, 2006, at 12:28 PM, Bo Peng wrote:
That at least compiles (thanks again!). What do I need to do to test
to see if it's working correctly?
Under windows,
1. if gsview and acrobad readers are available, you should see pdf
(three of them) and ghostscript (dvi, html, update, view
On Wed, May 24, 2006 at 03:27:13PM -0400, Bennett Helm wrote:
> On May 24, 2006, at 3:04 PM, Enrico Forestieri wrote:
> > Sorry, cannot help here. I can only say that pplatex should call
> > latex passing to it any specified argument.
>
> Using "pplatex -src-specials $$i" as the LaTeX -> DVI
The result is that in the Preferences dialog, the right viewers/
editors show up as "auto" -- at least for the most part. However,
there are some oddities, which lead me to question whether it's
actually working as it should.
Yes. This means canAutoOpenFile is working.
1. The generated
Dear list,
lyx 1.4.2 cvs crashes when I try to view a file with eps figure. Here
is the gdb trace:
Assertion triggered in void ExportData::addExternalFile(const
std::string&, const std::string&, const std::string&) by failing check
"lyx::support::AbsolutePath(sourceName)" in file exporter.C:322
The problem is at line 683, insetgraphics.C
// source file is now full path
/tmp/lyx_tmpdir20237FyBZGA/lyx_tmpbuf0/4_home_bpeng_simuPOP_doc_log_LDdecay.eps
if (!runparams.nice && GetExtension(temp_file) != ext) {
// The LaTeX compiler will not be able to
101 - 114 of 114 matches
Mail list logo
