On Tue, Oct 28, 2008 at 4:34 PM, José Matos <[EMAIL PROTECTED]> wrote:
> Public release of LyX version 1.6.0 (release candidate 5)
> =
>
> We are pleased to announce the fifth release candidate of LyX 1.6.0.
I've placed the Mac binary here:
Jürgen Spitzmüller wrote:
rgheck wrote:
I think this patch will fix this bug. It outputs a newline before an
environment if there's a depth change. Should we do this only if the
depth increases, though? I'm not at all sure.
I guess this will work for the given bug. However, IMHO we nee
Andre Poenitz wrote:
On Sat, Nov 01, 2008 at 06:03:15PM +0100, Jürgen Spitzmüller wrote:
rgheck wrote:
I think this patch will fix this bug. It outputs a newline before an
environment if there's a depth change. Should we do this only if the
depth increases, though? I'm not at all sure.
Jürgen Spitzmüller wrote:
rgheck wrote:
No, I think the 4993 bug is more serious than this one. This one can be
worked around.
That's my opinion, too.
It only causes a problem when someone does [ERT]%[/ERT]
rather than (say) [ERT]{}[/ERT]. (Actually, do you have to have ANYTHING
Hopefully, the attached patch fixes the infinite loop on exit.
Also, it gets rid of ControlSearchAdv.{c,hpp}, but I don't know
how to make it evident in the `svn diff' output (except that they
are not compiled anymore because of the changes in qt4/Makefile.am).
Bye,
T.
--
Tommaso Cucinotta,
On Sat, Nov 01, 2008 at 06:03:15PM +0100, Jürgen Spitzmüller wrote:
> rgheck wrote:
> > I think this patch will fix this bug. It outputs a newline before an
> > environment if there's a depth change. Should we do this only if the
> > depth increases, though? I'm not at all sure.
>
> I guess this w
rgheck wrote:
> No, I think the 4993 bug is more serious than this one. This one can be
> worked around.
That's my opinion, too.
> It only causes a problem when someone does [ERT]%[/ERT]
> rather than (say) [ERT]{}[/ERT]. (Actually, do you have to have ANYTHING
> in the ERT? Won't an empty ERT w
rgheck wrote:
> I think this patch will fix this bug. It outputs a newline before an
> environment if there's a depth change. Should we do this only if the
> depth increases, though? I'm not at all sure.
I guess this will work for the given bug. However, IMHO we need a more general
fix: The whole
rgheck wrote:
Uwe Stöhr wrote:
Yesterday's changes to output_latex.cpp broke the PDF export. You can
view files as PDF but not export.
Please don't introduce code optimizations so short before the release.
I don't think that was the problem. The culprit seems to be r27209.
JMarc?
Note that
Uwe Stöhr wrote:
Yesterday's changes to output_latex.cpp broke the PDF export. You can
view files as PDF but not export.
Please don't introduce code optimizations so short before the release.
I don't think that was the problem. The culprit seems to be r27209. JMarc?
rh
Yesterday's changes to output_latex.cpp broke the PDF export. You can view
files as PDF but not export.
Please don't introduce code optimizations so short before the release.
regards Uwe
Philippe Charpentier wrote:
Recent changes (in output_latex.cpp, I suppose) introduce a new bug:
with the following lines in a lyx file
\begin_layout Itemize
aaa
\end_layout
\begin_deeper
\begin_layout Standard
aaa
\end_layout
\begin_layout Enumerate
aaa
\end_layout
\end_deeper
the Enumerate
Bo Peng wrote:
On Fri, Oct 31, 2008 at 8:59 PM, Konrad Hofbauer
<[EMAIL PROTECTED]> wrote:
2)
InsetInfo shortcut puts into the preamble:
\providecommand{\shortcut}[1]{\mbox{\textsf{#1}}}
3)
The Latex-output of InsetInfo shortcut contains another \textsf, even though
the above macros already i
Recent changes (in output_latex.cpp, I suppose) introduce a new bug:
with the following lines in a lyx file
\begin_layout Itemize
aaa
\end_layout
\begin_deeper
\begin_layout Standard
aaa
\end_layout
\begin_layout Enumerate
aaa
\end_layout
\end_deeper
the Enumerate environment does not appear i
Uwe Stöhr wrote:
> I think this patch will fix this bug. It outputs a newline before an
environment if there's a
> depth change. Should we do this only if the depth increases, though?
It sounds reasonable and it works so far.
But every change in this field is a risk, so perhaps it is better to
Dear list,
I'm trying to resolve Bug 5216
(http://bugzilla.lyx.org/show_bug.cgi?id=5216) in which double-byte char
between two insets is omit (which may not be resolved before 1.6.0).
The phenomenon seems to occur strangely only on FreeBSD. I confirmed
this on a few machines, but there seems no
> I assume you mean shortcuts.lyx: only in the (widest) Edit table. See
> attached.
>
> In the userguide there are several occurences (although it's probably worst
> on the Mac now). Certainely we should not put multiple shrotcutS into an
> mbox. Maybe make even the normal single-shorcut breakable
On 1 nov 2008, at 01.28, Konrad Hofbauer wrote:
José Matos wrote:
Public release of LyX version 1.6.0 (release candidate 5)
=
Compiles fine on the Mac.
For those not being able to wait, I have placed a zipped Mac
Universal Binary (wit
What is the purpose of the sef- and mutual- recursion between
GuiView::saveBuffer() and GuiView::renameBuffer() methods ?
I was wondering if it were possible to get rid of such recursion
at all, possibly by factoring the functionality into multiple
methods.
(actually, when focus is on searchArea
19 matches
Mail list logo
