| auto_ptr MathMacro::doClone() const
| {
| - return auto_ptr(new MathMacro(*this));
| + MathMacro * copy = new MathMacro(*this);
| + copy->needsUpdate_ = true;
| + copy->expanded_.cell(0).clear();
| + return auto_ptr(copy);
| }
Why not:
auto_ptr tmpInset(new MathM
On Mon, 2007-05-21 at 14:28 +0200, Jürgen Spitzmüller wrote:
> Darren Freeman wrote:
> > This is not very helpful! What if I don't want to change the encoding,
> > fearful as I am of needless change.
> > I have no idea where to start
> > looking for these characters pasted in from OOo.
>
> There'
Stefan Schimanski wrote:
The attached patch (also attached in bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3720) solves this issue. As I
explain there, I would really just as soon get rid of the condition
altogether (I tested both options, both seem to work)...
Stefan, I hope you don't mi
José Matos wrote:
On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
{
Types const t = type(params);
- return (t == INPUT) or (t == INCLUDE);
+ return (t == INPUT) || (t == INCLUDE);
}
Why is this?
You mean "_What_ is this?" It surely is not C++ at the first place :-)
Richard Heck wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=3488
The attached patch resolves this bug. The problem was that the current
buffer was being disconnected from the LyXView before the new buffer was
loaded. If the load failed, then, closing the current buffer would not
call LyXView::se
Helge Hafting wrote:
> Surprisingly, the tooltip "Insert table" for the upper toolbar
> isn't translateable. Every other toolbar tooltip is.
Strangely, it _is_ translated here (German l10n, latest svn).
> The words "Figure" and "Table" in the TOC dialog, where
> we choose whether to show TOC, LOF
Am 25.05.2007 um 08:55 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
The attached patch (also attached in bugzilla http://
bugzilla.lyx.org/show_bug.cgi?id=3720) solves this issue. As I
explain there, I would really just as soon get rid of the
condition altogether (I tested both opti
Richard Heck wrote:
> How do I get at these highly precise times? The boost file_write_time()
> function returns a time_t, which seems to be in seconds. (As you say,
> this may not work anyway.)
On BSD-like systems you could use
int utimes(const char *filename, const struct timeval tv[2]);
but
Darren Freeman wrote:
> If somebody could show me the "right" way to generate a link to a thread
in the archives that doesn't take up much time I'll do that in future
but it's pretty easy to copy-paste the subject and date so it's got to
be pretty competitive :)
If you look at the message's s
Bo Peng wrote:
>> you cannot export \lstinline{foo}, ist must be something of
>> \lstinlinefoo
>> where is a free choosen delimiter. Otherwise you cannot write
>> something like \lstinline{\textbf{foo}}. Must be
>> \lstinline|\textbf{foo}| or any other character than |.
>
> The listings manual sa
Darren Freeman wrote:
> I just got this on the command-line. I don't suppose it's helpful :)
>
> "Could not find LaTeX command for character 0xf0b4.
> LaTeX export will fail."
It's actually helpful. It is the code point of the problematic character.
In you case, it seems to be a "webdings" charact
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>> The string "Preview source code for paragraph " that appear
>> in the source code window when viewing source for a single
>> paragraph. '
Jürgen> Try the attached.
Looks good.
JMarc
Stefan Schimanski wrote:
Am 25.05.2007 um 08:55 schrieb Abdelrazak Younes:
But please shorten the comment a bit. It's not that tricky here
anyway.
Why shorten the comment? We should strieve for more comments not less.
Particularly in place like this where a _logical_ decision is made.
No,
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> As said. This seems a very sensible idea. Accidental
Richard> reversion is bad.
I like it. In the same vein, I would propose to add the following. It
is not an action that requires a shortcut.
JMarc
Index: lib/bind/cua.bind
=
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> The attached patch addresses this bug. The idea is to leave
Richard> the TOC (e.g.) open when closing one buffer, if there is
Richard> still one open.
What are the FIXME comments good for?
JMarc
Stefan
Stefan, I guess you're right --- I like comments, so I do tend to
be wordy...
Find attached a revised patch (cursor_left_2.diff) with a one-line
comment
Much better :)
(I don't want to get rid of it altogether).
However, I'm in favor of cursor_left_1.diff --- that solves the
lyx also complains about
‘
and
’
(0x2018 and 0x2019)
On Fri, 25 May 2007, Darren Freeman wrote:
[EMAIL PROTECTED] wrote:
I think you should at least file a bugzilla enhancement request, referring
to this thread.
This issue got absorbed into
http://bugzilla.lyx.org/show_bug.cgi?id=3680 where I've added a comment
referring to this thread.
If som
On Fri, 25 May 2007, Dov Feldstern wrote:
Darren Freeman wrote:
> If somebody could show me the "right" way to generate a link to a thread
in the archives that doesn't take up much time I'll do that in future
but it's pretty easy to copy-paste the subject and date so it's got to
be pretty c
Stefan Schimanski wrote:
Stefan
Stefan, I guess you're right --- I like comments, so I do tend to be
wordy...
Find attached a revised patch (cursor_left_2.diff) with a one-line
comment
Much better :)
(I don't want to get rid of it altogether).
However, I'm in favor of cursor_left_1.dif
On 5/25/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:
Elazar Leibovich wrote:
> This patch solves completely the issue of wrong display of the cursor
> when it is right in front of an RTL set.
> What I did is I added a better test for that. I tested whether or not
> the cursor slice (which I don'
On Friday 25 May 2007 07:03:55 Jürgen Spitzmüller wrote:
> Bo Peng wrote:
> > I am too lazy to create a bugzilla entry, and will commit it if Uwe or
> > Jurgen OKs it.
>
> OK.
>
> Jürgen
OK.
--
José Abílio
On Friday 25 May 2007 08:03:35 Abdelrazak Younes wrote:
> >
> > Seeking two OKs
>
> OK.
OK.
> Abdel.
--
José Abílio
On Friday 25 May 2007 09:09:20 Jean-Marc Lasgouttes wrote:
>
> Jürgen> Try the attached.
>
> Looks good.
OK.
> JMarc
--
José Abílio
On Friday 25 May 2007 09:21:31 Jean-Marc Lasgouttes wrote:
> > "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>
> Richard> As said. This seems a very sensible idea. Accidental
> Richard> reversion is bad.
>
> I like it. In the same vein, I would propose to add the following. It
> is not
Jean-Marc Lasgouttes schrieb:
Richard> As said. This seems a very sensible idea. Accidental
Richard> reversion is bad.
I like it. In the same vein, I would propose to add the following. It
is not an action that requires a shortcut.
+1
Michael
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> I don't like the reference to the BufferView cursor. cursorX
Stefan> gets a arbitrary CursorSlice. It shouldn't depend on the
Stefan> cursor or some other sideconditions.
I was about to send a message along the same lines, bu
I don't like the reference to the BufferView cursor. cursorX gets a
arbitrary CursorSlice. It shouldn't depend on the cursor or some
other sideconditions.
If I understand correctly: cursorX is called for the cursor itself
and for the selection anchor. For the latter it makes a difference if
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| José Matos wrote:
| > On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
| >> {
| >> Types const t = type(params);
| >> - return (t == INPUT) or (t == INCLUDE);
| >> + return (t == INPUT) || (t == INCLUDE);
| >> }
| > Why is
Richard Heck <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > [EMAIL PROTECTED] writes:
| >
| > | Author: rgheck
| > | Date: Fri May 25 00:17:04 2007
| > | New Revision: 18500
| > |
| > | URL: http://www.lyx.org/trac/changeset/18500
| > | Log:
| > | Forgot to restore this before comm
Stefan Schimanski <[EMAIL PROTECTED]> writes:
| > | auto_ptr MathMacro::doClone() const
| > | {
| > | - return auto_ptr(new MathMacro(*this));
| > | + MathMacro * copy = new MathMacro(*this);
| > | + copy->needsUpdate_ = true;
| > | + copy->expanded_.cell(0).clear();
| > | + return auto_ptr(copy
"Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| That's what Einstein said. "Documentation is more important than good
| coding". Someone *MUST* set up a decent overall documentation of the
| Lyx code.
Lean and Agile development says that you should only create
documentation that there is a real
http://bugzilla.lyx.org/show_bug.cgi?id=3723
attached.
Jürgen
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (Revision 18506)
+++ src/Buffer.cpp (Arbeitskopie)
@@ -427,6 +427,7 @@
params().headheight.erase();
params().headsep.erase
Stefan Schimanski wrote:
I don't like the reference to the BufferView cursor. cursorX gets a
arbitrary CursorSlice. It shouldn't depend on the cursor or some other
sideconditions.
This part I would tend to agree with, but I don't know what the correct
way to go about what we want to do is. El
Jean-Marc Lasgouttes wrote:
"Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> The cause is what Elazar explained: the piece of code which he
Dov> patched is the one moving the cursor to the end of inset, by
Dov> subtracting the inset's width. This subtraction *should* take
Dov> place insi
I noticed that:
1) in Bidi.cpp the computeTables method does not process the text inside
ERT-inset.
2) the language of the text of an ERT-inset is always "latex" and can not be
changed.
Therefore:
the RTL words inside an ERT-inset are not displayed correctly!
Is there any insist on not displa
On 25 May 2007 13:55:56 +0200, Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote:
"Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| That's what Einstein said. "Documentation is more important than good
| coding". Someone *MUST* set up a decent overall documentation of the
| Lyx code.
Lean
I heard
On 5/25/07, Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
I noticed that:
1) in Bidi.cpp the computeTables method does not process the text inside
ERT-inset.
2) the language of the text of an ERT-inset is always "latex" and can not be
changed.
Therefore:
the RTL words inside an ERT-inset are not d
Elazar Leibovich wrote:
> Maybe it's a problem with the code flow. Actually, the whole idea of
"patching" the cursor position in RtL paragraph seems wrong to me. One
should IMHO, to calculate the position it should've been if everything
was English, and then to reverse it (subtract the window wi
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> The cause is what Elazar explained: the piece of code which he
Dov> patched is the one moving the cursor to the end of inset, by
Dov> subtracting the inset's width. This subtraction *should* take
Dov> place inside the inset, because ins
On Friday 25 May 2007 13:08:00 Jürgen Spitzmüller wrote:
> http://bugzilla.lyx.org/show_bug.cgi?id=3723
>
> attached.
>
> Jürgen
Yes.
--
José Abílio
On 5/25/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> I don't like the reference to the BufferView cursor. cursorX
Stefan> gets a arbitrary CursorSlice. It shouldn't depend on the
Stefan> cursor or some other sidecondi
Helge Hafting wrote:
> > Strangely, it _is_ translated here (German l10n, latest svn).
> >
>
> Don't confuse it with "Insert table float" which is translateable.
See attached screenshot.
Jürgen
<>
Elazar Leibovich <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
> > I noticed that:
> > 1) in Bidi.cpp the computeTables method does not process
> > the text inside ERT-inset.
> > 2) the language of the text of an ERT-inset is always
> > "latex" and can not be c
Uwe Stöhr wrote:
I need the help of people using CJK-LyX or taking care it to test the
following patch:
http://bugzilla.lyx.org/attachment.cgi?id=1602
This patch makes it possible to set the document language from within
LyX's menu, the correct encoding for the document is then set
automatic
Helge Hafting wrote:
> "Insert table" (just a table, no float) is a string that
> don't exist in either nb.po or de.po.
Does the attached patch help?
Jürgen
Index: src/frontends/Toolbars.cpp
===
--- src/frontends/Toolbars.cpp (Revis
Mostafa Vahedi wrote:
I noticed that:
1) in Bidi.cpp the computeTables method does not process the text inside
ERT-inset.
2) the language of the text of an ERT-inset is always "latex" and can not be
changed.
Therefore:
the RTL words inside an ERT-inset are not displayed correctly!
Is there
Jürgen Spitzmüller wrote:
Helge Hafting wrote:
Surprisingly, the tooltip "Insert table" for the upper toolbar
isn't translateable. Every other toolbar tooltip is.
Strangely, it _is_ translated here (German l10n, latest svn).
Don't confuse it with "Insert table float" which is trans
Richard Heck wrote:
The attached patch addresses this bug. The idea is to leave the TOC
(e.g.) open when closing one buffer, if there is still one open.
This seems slightly dangerous, so I won't push to commit this now,
though if people think it's a good idea and it seems safe, then we
could. Fo
Dov Feldstern <[EMAIL PROTECTED]> wrote:
> Mostafa Vahedi wrote:
> > I noticed that:
> > 1) in Bidi.cpp the computeTables method does not
> > process the text inside ERT-inset.
> > 2) the language of the text of an ERT-inset is
> > always "latex" and can not be changed.
> >
> > Therefore:
> > t
Darren Freeman wrote:
On Mon, 2007-05-21 at 14:28 +0200, Jürgen Spitzmüller wrote:
Darren Freeman wrote:
This is not very helpful! What if I don't want to change the encoding,
fearful as I am of needless change.
I have no idea where to start
looking for these characters pasted in from OOo.
The
>> +0x201c "{}``" "" "" # LEFT DOUBLE QUOTATION MARK
>
> The {} breaks kerning.
This is correct because it is the beginning quote character.
> "\textquotedblleft" is better.
Why don't we use this then also in LyX? I exactly use what LyX currently uses for quotations, in
thi
Mostafa Vahedi wrote:
I have sent this email before but it was forgotten. I am sending the
patches again.
It was not. Jose promised to put it in before rc1. But it's good that
you recall him that ;-)
To add Farsi Support these four files are modified namely: Encoding.cpp,
Text.cpp, rowpaint
Stefan Schimanski wrote:
In this special case the comment isn't saying anything else than what is
visible in the if-statement directly already: "we're coming from the
front" = "front", "we are at the paragraph end" = "pos=lastpos", "we
don't check any further, we will not enter" = return false.
I have sent this email before but it was forgotten. I am sending the patches
again.
To add Farsi Support these four files are modified namely: Encoding.cpp,
Text.cpp, rowpainter.cpp, and languages.
--Mostafa
-
Take the Internet to Go: Yahoo!Go puts the I
Richard Heck wrote:
And now, with the actual patch.
The attached doesn't do much other than code cleanup, and I've inserted
some comments about how to fix bug 3440, which I don't propose to do
now. There's no actual change to the logic. Indentation will be fixed.
Makes the diff hard to read.
Se
On 5/25/07, Mostafa Vahedi <[EMAIL PROTECTED]> wrote:
Dov Feldstern <[EMAIL PROTECTED]> wrote:
> Mostafa Vahedi wrote:
> > I noticed that:
> > 1) in Bidi.cpp the computeTables method does not
> > process the text inside ERT-inset.
> > 2) the language of the text of an ERT-inset is
> > always "la
On 5/24/07, Bo Peng <[EMAIL PROTECTED]> wrote:
Bug:
1. set global listings parameters from settings->text layout
2. close and reopen dialog, remove the parameters
3. close and reopen dialog, the parameters are still there.
Cause:
In the current logic, listings_params is not written to a file if
Uwe Stöhr wrote:
> > The {} breaks kerning.
>
> This is correct because it is the beginning quote character.
Not in Slovak and Hungarian, for instance.
> > "\textquotedblleft" is better.
>
> Why don't we use this then also in LyX? I exactly use what LyX currently
> uses for quotations, in this c
On 5/25/07, Uwe Stöhr <[EMAIL PROTECTED]> wrote:
>> +0x201c "{}``" "" "" # LEFT DOUBLE QUOTATION MARK
>
> The {} breaks kerning.
This is correct because it is the beginning quote character.
> "\textquotedblleft" is better.
Why don't we use this then also in LyX? I exact
Elazar Leibovich <[EMAIL PROTECTED]> wrote:
> > Yes. The backend is OK. The problem is just the
> > presentation. I encounter the same problem when I want
> > to use "Box" (i.e. "\mbox{}" in LaTeX terms) inside
> > math formula.
> Just FYI, AFAIK at least in hebrew, latex doesn't support
> RT
On Friday 25 May 2007 14:55:55 Abdelrazak Younes wrote:
> OK.
+1
> Abdel.
--
José Abílio
Mostafa Vahedi wrote:
I have sent this email before but it was forgotten. I am sending the
patches again.
To add Farsi Support these four files are modified namely: Encoding.cpp,
Text.cpp, rowpainter.cpp, and languages.
--Mostafa
---
Jürgen Spitzmüller wrote:
> > This is correct because it is the beginning quote character.
>
> Not in Slovak and Hungarian, for instance.
Oh, and German, for that matter ...
Jürgen
Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | José Matos wrote:
> | > On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
> | >> {
> | >> Types const t = type(params);
> | >> - return (t == INPUT) or (t == INCLUDE);
> | >> + return (t == I
Hi,
are we ready for RC1, in the goals that I have stated to RC1 I had
proposed a
week between beta 3 and release candidate 1 to avoid any error that had
evaded our search us before.
We have bugs but nothing so glaring that we can not ship the first
release
candidate.
On Friday 25 May 2007 15:53:03 Peter Kümmel wrote:
> #include not there.
In C++ it should be
#include
And this file has:
/** @file ciso646
* This is a Standard C++ Library file. You should @c #include this file
* in your programs, rather than any of the "*.h" implementation files.
*
*
I wrote:
The attached patch fixes this too and adds more quotation characters
and misc symbols.
There was a typo, corrected in the attached patch.
More symbols can be added later, have a look at
http://www-sop.inria.fr/apics/tralics/auxdir/tdoc1uid1714.html
for all symbols supported by textc
Am 25.05.2007 um 16:57 schrieb José Matos:
Hi,
are we ready for RC1, in the goals that I have stated to RC1 I had
proposed a
week between beta 3 and release candidate 1 to avoid any error that
had
evaded our search us before.
We have bugs but nothing so glaring that we can not ship the
Uwe Stöhr wrote:
> OK, I did this in the attached patch.
Thanks.
> So I hope now everything is correct.
A few quirks:
> +0x0192 "textflorin" "textcomp" "" # LATIN SMALL LETTER
"\\textflorin"
> +0x2018 "\\textquoteleft" "" "" # LEFT SINGLE QUOTATION MARK
> +0x2019 "'"
José Matos wrote:
> On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
>> Index: src/frontends/qt4/QDocument.cpp
>> ===
>> --- src/frontends/qt4/QDocument.cpp (revision 18495)
>> +++ src/frontends/qt4/QDocument.cpp (working c
>> This is correct because it is the beginning quote character.
>
> Not in Slovak and Hungarian, for instance.
>
>> > "\textquotedblleft" is better.
OK, I did this in the attached patch. So I hope now everything is correct.
thanks and regards Uwe
--- unicodesymbols Mon May 07 19:02:06 2007
+++
Jean-Marc Lasgouttes wrote:
>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> Peter> We could just wait for 1.34.1, upgrading to 1.34 is nearly a
> Peter> noop:
>
> Peter> http://www.lyx.org/trac/changeset/18458
>
> I'd suggest to upgrade to 1.34 now, and consider 1.34.1 when it is
Peter,
I noticed your boost updates to 1.34.0. Only for the info, are you aware of
this?:
http://bugzilla.lyx.org/show_bug.cgi?id=3631
regards Uwe
By accident I've checked in this patch,
should I revert?
Index: src/frontends/qt4/QListings.cpp
===
--- src/frontends/qt4/QListings.cpp (revision 18508)
+++ src/frontends/qt4/QListings.cpp (working copy)
@@ -208,7 +208,7 @@
On 5/25/07, Peter Kümmel <[EMAIL PROTECTED]> wrote:
By accident I've checked in this patch,
should I revert?
Index: src/frontends/qt4/QListings.cpp
===
--- src/frontends/qt4/QListings.cpp (revision 18508)
+++ src/frontends/qt4/
Peter Kümmel wrote:
> Jean-Marc Lasgouttes wrote:
>>> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
>> Peter> We could just wait for 1.34.1, upgrading to 1.34 is nearly a
>> Peter> noop:
>>
>> Peter> http://www.lyx.org/trac/changeset/18458
>>
>> I'd suggest to upgrade to 1.34 now, and con
Uwe Stöhr wrote:
> Peter,
>
> I noticed your boost updates to 1.34.0. Only for the info, are you aware
> of this?:
> http://bugzilla.lyx.org/show_bug.cgi?id=3631
>
> regards Uwe
>
Yes, I know the bugzilla entry:
http://marc.info/?l=lyx-devel&m=117991216104349&w=2
But currently we have no prob
\lstinline{code} does not work for some listings version so I have to
choose a delimiter that is not in the code.
OK to commit?
Bo
Index: src/insets/InsetListings.cpp
===
--- src/insets/InsetListings.cpp (revision 18512)
+++ src/ins
On Friday 25 May 2007 16:23:33 Jürgen Spitzmüller wrote:
> If this is corrected, you have my OK as well.
+1
> Jürgen
--
José Abílio
On Friday 25 May 2007 16:36:28 Bo Peng wrote:
> \lstinline{code} does not work for some listings version so I have to
> choose a delimiter that is not in the code.
What happens if they are all used? :-)
> OK to commit?
I assume you have tested it exhaustively, if so yes. :-)
> Bo
--
José
On Fri, May 25, 2007 at 08:59:25AM +0200, Abdelrazak Younes wrote:
> José Matos wrote:
> >On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
> >> {
> >>Types const t = type(params);
> >>- return (t == INPUT) or (t == INCLUDE);
> >>+ return (t == INPUT) || (t == INCLUDE);
> >>
On 5/25/07, José Matos <[EMAIL PROTECTED]> wrote:
On Friday 25 May 2007 16:36:28 Bo Peng wrote:
> \lstinline{code} does not work for some listings version so I have to
> choose a delimiter that is not in the code.
What happens if they are all used? :-)
Then ! in the code snippet will be repl
As title. I found that they are both used in places like InsetListings::latex.
Bo
Bo Peng wrote:
> As title. I found that they are both used in places like
> InsetListings::latex.
>
> Bo
>
from_ascii is cheaper, just a cast:
docstring const from_ascii(char const * ascii)
{
docstring s;
for (char const * c = ascii; *c; ++c) {
BOOST_ASSERT(stati
> "Peter" == Peter Kümmel <[EMAIL PROTECTED]> writes:
Peter> Done, all files (also filesystem) are now from 1.34.
Thanks.
JMarc
> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
Dov> Jean-Marc Lasgouttes wrote:
>>> "Dov" == Dov Feldstern <[EMAIL PROTECTED]> writes:
>>
Dov> The cause is what Elazar explained: the piece of code which he
Dov> patched is the one moving the cursor to the end of inset, by
Dov> subtrac
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| >
| > | José Matos wrote:
| > | > On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
| > | >> {
| > | >> Types const t = type(params);
| > | >> - return (t
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> As title. I found that they are both used in places like
Bo> InsetListings::latex. Bo
from_ascii will assert if input contains non-7bit input.
JMarc
from_ascii is cheaper, just a cast:
docstring const from_ascii(char const * ascii)
{
docstring s;
for (char const * c = ascii; *c; ++c) {
BOOST_ASSERT(static_cast(*c) < 0x80);
s.push_back(*c);
}
return s;
}
This makes sense.
Thank
> "José" == José Matos <[EMAIL PROTECTED]> writes:
José> Hi, are we ready for RC1, in the goals that I have stated to RC1
José> I had proposed a week between beta 3 and release candidate 1 to
José> avoid any error that had evaded our search us before.
José> We have bugs but nothing so glari
> "Mostafa" == Mostafa Vahedi <[EMAIL PROTECTED]> writes:
Mostafa> For the second item currently I put the latex command and the
Mostafa> character "{" inside an ERT, then the parameter outside the
Mostafa> ERT, and finally put the character "}" inside another ERT.
That is the right thing to
Bo Peng wrote:
> On 5/25/07, Peter Kümmel <[EMAIL PROTECTED]> wrote:
>> By accident I've checked in this patch,
>> should I revert?
>>
>>
>> Index: src/frontends/qt4/QListings.cpp
>> ===
>> --- src/frontends/qt4/QListings.cpp (revi
I assume \\ is right when you wanna pass a back slash to QRegExp.
I could imagine that "\*" could be interpreted different by msvc and
gcc, because there is no \* character.
So you fixed a bug... :-)
Bo
"Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| On 25 May 2007 13:55:56 +0200, Lars Gullik Bjønnes <[EMAIL PROTECTED]> wrote:
| > "Elazar Leibovich" <[EMAIL PROTECTED]> writes:
| >
| > | That's what Einstein said. "Documentation is more important than good
| > | coding". Someone *MUST* set up a d
Lars Gullik Bjønnes wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> | >
> | > | José Matos wrote:
> | > | > On Thursday 24 May 2007 19:24:28 Peter Kümmel wrote:
> | > | >> {
> | > | >> Types const
> If this is corrected, you have my OK as well.
Thanks for proofreading. The corrected version is in SVN.
regards Uwe
are we ready for RC1, in the goals that I have stated to RC1 I had
proposed a
week between beta 3 and release candidate 1 to avoid any error that had
evaded our search us before.
There is no pending (listings) patch in my tree and the fact that
shift-page down no longer crashes lyx make
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Peter Kümmel <[EMAIL PROTECTED]> writes:
| >
| > | Lars Gullik Bjønnes wrote:
| > | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | >
| > | > | José Matos wrote:
| > | > | > On Thursday 24 May 2007 19:24:28 Peter KÃ
José Matos wrote:
> Hi,
> are we ready for RC1, in the goals that I have stated to RC1 I had
> proposed a
> week between beta 3 and release candidate 1 to avoid any error that had
> evaded our search us before.
>
> We have bugs but nothing so glaring that we can not ship the first
1 - 100 of 125 matches
Mail list logo
