Am Sonntag, 25. Februar 2007 18:53 schrieb Abdelrazak Younes:
> 3203 maj possible to import non-utf8 text files
> I'd say non-blocker; Georg?
I have no idea. I personally don't have a problem if only utf8 text can be
imported, but I suspect that users will see that differently, especially
sinc
Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> "Blocker" is a function of the nature of the bug. A "Blocker"
Lars> bug is a bug that makes LyX completely unusable.
Lars> "pri 1" is more political. And we can f.ex. decide that all "pri
Lars> 1" bugs
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | >> We need to prioritize the bugs, I agree.
| > | > I propose that we promote some of the "major" bugs to "blocker".
| > | > Then only the critical (if possible) and blocker will have to be
| > | > fixed for 1.5.0. T
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> "Blocker" is a function of the nature of the bug. A "Blocker"
Lars> bug is a bug that makes LyX completely unusable.
Lars> "pri 1" is more political. And we can f.ex. decide that all "pri
Lars> 1" bugs _must_ be fixed before fi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Abdelrazak Younes wrote:
| > | > José Matos wrote:
| > | >> On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
| > | >>> Ah, and then there are 527 bugs left
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > José Matos wrote:
| >> On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
| >>> Ah, and then there are 527 bugs left (an all-time high?):
| >>> http://tinyurl.com/y7hdzc
| > Only 82 o
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>
Abdelrazak> 3204 maj file insertion cannot be undone
-> blocker?
>> Fix below. Committing now.
Abdelrazak> Good guy
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> 3204 maj file insertion cannot be undone
-> blocker?
Fix below. Committing now.
Good guy :-)
Abdel.
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
| > José Matos wrote:
| >> On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
| >>> Ah, and then there are 527 bugs left (an all-time high?):
| >>> http://tinyurl.com/y7hdzc
| > Only 82 of which are genuine to 1.5.0s
[EMAIL PROTECTED] writes:
| On Sun, 25 Feb 2007, Lars Gullik Bjønnes wrote:
|
| > | Instead of bugzilla + pmwiki + html-www (+ www-devel).
| >
| > I not sure it is _that_ nice.
| >
| > But for repository tasks I might agree. (even if mediawiki is a much
| > nicer wiki...)
|
| Out of curiosity, w
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> 3204 maj file insertion cannot be undone
-> blocker?
Fix below. Committing now.
JMarc
Index: src/lyx_cb.C
===
--- src/lyx_cb.C (révision 17343)
+++ src
On Sun, 25 Feb 2007, Michael Gerz wrote:
Lars Gullik Bjønnes schrieb:
| Instead of bugzilla + pmwiki + html-www (+ www-devel).
I not sure it is _that_ nice.
But for repository tasks I might agree.
(even if mediawiki is a much nicer wiki...)
The benefit of Trac is that everything is tight
On Sun, 25 Feb 2007, Lars Gullik Bjønnes wrote:
| Instead of bugzilla + pmwiki + html-www (+ www-devel).
I not sure it is _that_ nice.
But for repository tasks I might agree. (even if mediawiki is a much
nicer wiki...)
Out of curiosity, what is it about mediawiki that you like? Is it the
Abdelrazak Younes wrote:
José Matos wrote:
On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
Ah, and then there are 527 bugs left (an all-time high?):
http://tinyurl.com/y7hdzc
Only 82 of which are genuine to 1.5.0svn. I propose that we concentrate
on those.
We need to priori
José Matos wrote:
On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
Ah, and then there are 527 bugs left (an all-time high?):
http://tinyurl.com/y7hdzc
Only 82 of which are genuine to 1.5.0svn. I propose that we concentrate
on those.
We need to prioritize the bugs, I agree.
Lars Gullik Bjønnes schrieb:
| Instead of bugzilla + pmwiki + html-www (+ www-devel).
I not sure it is _that_ nice.
But for repository tasks I might agree.
(even if mediawiki is a much nicer wiki...)
The benefit of Trac is that everything is tightly integrated. I don't
see why this is not t
Michael Gerz <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes schrieb:
| > Michael Gerz <[EMAIL PROTECTED]> writes:
| >
| > | José Matos schrieb:
| > | > On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
| > | >
| > | >> I still can't see the announcement on our web site.
| > | >>
| > | >
Lars Gullik Bjønnes schrieb:
Michael Gerz <[EMAIL PROTECTED]> writes:
| José Matos schrieb:
| > On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
| >
| >> I still can't see the announcement on our web site.
| >>
| >
| > But you can now. :-)
| >
| > BTW IMHO without RSS a web announcement
Michael Gerz <[EMAIL PROTECTED]> writes:
| José Matos schrieb:
| > On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
| >
| >> I still can't see the announcement on our web site.
| >>
| >
| > But you can now. :-)
| >
| > BTW IMHO without RSS a web announcement is so 90's ;-) , it would be
|
On Sat, 24 Feb 2007, Michael Gerz wrote:
José, all,
of things are still subject to optimization (e.g.,
correct line indentation, label translation based on
par language etc.) but plain text output has become
good enough for my purposes (= grammar checking with MS
Word) and line breaking
José Matos schrieb:
On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
I still can't see the announcement on our web site.
But you can now. :-)
BTW IMHO without RSS a web announcement is so 90's ;-) , it would be nice if
we could support RSS in the page.
I said it multiple
On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
> Great! I hope you are actually using it :-)
In case it was not clear I am using it. :-)
> Michael
--
José Abílio
On Sunday 25 February 2007 8:39:31 am Michael Gerz wrote:
> I still can't see the announcement on our web site.
But you can now. :-)
BTW IMHO without RSS a web announcement is so 90's ;-) , it would be nice if
we could support RSS in the page.
--
José Abílio
José Matos schrieb:
Since the first beta has not been
announced yet, I guess there is no need to hurry. Expect something by
the end of the week.
This sentence I don't grok... :-)
At the time you sent this sentence 1.5.0beta1 had been announced.
I still can't see the announcement
On Saturday 24 February 2007 4:24:41 pm Michael Gerz wrote:
> José, all,
>
> I just wanted to tell you that I completed my work on plain text output.
> Unless I find a new bug, I won't touch this part of the code anymore. Of
> course, a lot of things are still subject
Am Samstag, 24. Februar 2007 16:12 schrieb Michael Gerz:
> Georg Baum schrieb:
> > No. Can you show me how the code path is? I don't understand it. AFAIK
the
> > only interface between text and math is InsetMathHull (even for
macros).
> > Therefore I don't understand why any other math inset need
Georg Baum schrieb:
Am Samstag, 24. Februar 2007 17:24 schrieb Michael Gerz:
I think we have to fix at least the most critical and most annoying ones
for 1.5.0 final. For instance, my productivity is really weakened by
#2843.
This one is fixed. Which one did you mean?
Oops... 24
Am Samstag, 24. Februar 2007 17:24 schrieb Michael Gerz:
> I think we have to fix at least the most critical and most annoying ones
> for 1.5.0 final. For instance, my productivity is really weakened by
> #2843.
This one is fixed. Which one did you mean?
Georg
José, all,
I just wanted to tell you that I completed my work on plain text output.
Unless I find a new bug, I won't touch this part of the code anymore. Of
course, a lot of things are still subject to optimization (e.g., correct
line indentation, label translation based on par languag
Georg Baum schrieb:
No. Can you show me how the code path is? I don't understand it. AFAIK the
only interface between text and math is InsetMathHull (even for macros).
Therefore I don't understand why any other math inset needs a plaintext
method (it is never called in mathed, only from outside).
On Fri, Feb 23, 2007 at 08:32:24AM +0100, Jean-Marc Lasgouttes wrote:
> > "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
>
> Michael> Georg, it turned out that InsetMathHull is not the only place
> Michael> where plaintext() is needed. Math macros are output in -
> Michael> surprise, su
Michael Gerz wrote:
> Georg,
>
> it turned out that InsetMathHull is not the only place where plaintext()
> is needed. Math macros are output in - surprise, surprise -
> InsetMathDim. Does this make sense to you?
No. Can you show me how the code path is? I don't understand it. AFAIK the
only int
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Georg, it turned out that InsetMathHull is not the only place
Michael> where plaintext() is needed. Math macros are output in -
Michael> surprise, surprise - InsetMathDim. Does this make sense to
Michael> you?
Michael> I am temp
OutputParams const & runparams) const
+ OutputParams const & runparams) const
{
MathStream ms(os);
int res = 0;
Index: InsetMath.h
=======
--- InsetMath.h (Revision 17306)
+++ InsetMath.h (Arbeit
Am Dienstag, 20. Februar 2007 20:21 schrieb Michael Gerz:
> Georg,
>
> how about plaintext() in mathed/InsetFormulaMacro.C and
> mathed/InsetMathRef.C ?
InsetFormulaMacro is not used at all. RefInset is used, but the plaintext
method is not used if I am right (see my other mail).
> At least th
Georg,
how about plaintext() in mathed/InsetFormulaMacro.C and
mathed/InsetMathRef.C ?
At least the latter one is presently broken because its signature is
different from the signature of all other plaintext() methods.
Should I try to fix these two methods or can I remove them completely?
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> I will align this, i.e. I will use "Foot" rather than "foot"
Michael> (this leads to less complaints when checking the plain text
Michael> in MS Word).
Michael> I will also use the capital names for labels on screen, if
Michael>
Jean-Marc Lasgouttes schrieb:
Michael> Hi, here comes the promised (long time ago) cleanup patch for
Michael> plain text output.
Would it be possible to set correctly the inset names and use this
globally for InsetText?
Good question. I will investigate later...
FYI: I noticed tha
Jean-Marc Lasgouttes schrieb:
Why are some labels ("foot") lowercase and some other ("Branch")
capitalized?
Would it be possible to set correctly the inset names and use this
globally for InsetText?
I will align this, i.e. I will use "Foot" rather than "foot" (this leads
to less complaints w
>>>>> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Hi, here comes the promised (long time ago) cleanup patch for
Michael> plain text output.
Why are some labels ("foot") lowercase and some other ("Branch")
capitalized?
On Wednesday 14 February 2007 4:43:19 pm Michael Gerz wrote:
> Hi,
>
> here comes the promised (long time ago) cleanup patch for plain text
> output.
>
> OK to commit?
Is anyone opposed to this patch?
> Michael
--
José Abílio
Hi,
here comes the promised (long time ago) cleanup patch for plain text output.
OK to commit?
Michael
Index: src/insets/insetenv.h
===
--- src/insets/insetenv.h (Revision 17187)
+++ src/insets/insetenv.h (Arbeitskopie)
@@ -32,6
Am Sonntag, 10. September 2006 10:40 schrieb Peter Kümmel:
> But there are warnings when compiling with msvc:
>
> stream6.cpp(252) : warning C4244: 'return' : conversion
from 'ascii_ctype_facet::char_type' to 'char', possible loss of data
> stream6.cpp(253) : warning C4244: 'argument' : conversio
Your code is correct! It were my wrong editor
settings, after enabling autodetection of UTF8
it looks correct, see png.
But there are warnings when compiling with msvc:
stream6.cpp(252) : warning C4244: 'return' : conversion from
'ascii_ctype_facet::char_type' to 'char', possible loss of data
s
On Sat, Sep 09, 2006 at 05:50:42PM +0200, Georg Baum wrote:
> I believe that this version should work on any OS.
I can confirm that with mingw and cygwin the same output as your
is generated.
--
Enrico
Georg Baum wrote:
> Am Dienstag, 5. September 2006 14:35 schrieb Abdelrazak Younes:
>> Peter Kümmel wrote:
>>> In my ordinary text editor (ultraedit) it doen't loock like a text
> file.
>> Same for me in wordpad... attached the file.
>
> Can you please try this updated test program? The screen ou
Am Dienstag, 5. September 2006 14:35 schrieb Abdelrazak Younes:
> Peter Kümmel wrote:
> > In my ordinary text editor (ultraedit) it doen't loock like a text
file.
>
> Same for me in wordpad... attached the file.
Can you please try this updated test program? The screen output should look
like in
On Tue, Sep 05, 2006 at 02:09:25PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > Georg, I tried your test program on cygwin and, after adding an
> > "#include " line, it fails to compile as follows:
> >
> > $ g++ stream2.cpp -o stream2
> > stream2.cpp: In function `int main()':
> > s
On Tue, Sep 05, 2006 at 02:26:55PM +0200, Peter Kümmel wrote:
> Georg Baum wrote:
[...]
> > std::wcerr should be declared in iostream. If gcc on cygwin does not have it
> > then it is not standard conforming.
Possibly. The wide stream versions are #ifdef'd out in iostream:
#ifdef _GLIBCXX_USE_WC
Peter Kümmel wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
Ah... with this change I have then the same output as yours:
test:
abcd
228246252
20 e4 f6 fc
196214220
20 c4 d6 dc
abcd
That looks good, but the generated file is more interesting. Does it contain
abcd
äöü
äöü
abcd
Georg Baum wrote:
> Enrico Forestieri wrote:
>
>> Georg, I tried your test program on cygwin and, after adding an
>> "#include " line, it fails to compile as follows:
>>
>> $ g++ stream2.cpp -o stream2
>> stream2.cpp: In function `int main()':
>> stream2.cpp:230: error: `wcerr' is not a member of
Enrico Forestieri wrote:
> Georg, I tried your test program on cygwin and, after adding an
> "#include " line, it fails to compile as follows:
>
> $ g++ stream2.cpp -o stream2
> stream2.cpp: In function `int main()':
> stream2.cpp:230: error: `wcerr' is not a member of `std'
> stream2.cpp:238: er
On Mon, Sep 04, 2006 at 10:46:43PM +0200, Georg Baum wrote:
> Peter and Abdel, can you please test whether the attached test program
> works (or could be made to work) on windows with lyx::char_type ==
> boost::uint32_t?
>
> If yes, then I'd like to put the attached patch in and proceed with
>
Peter Kümmel wrote:
> In my ordinary text editor (ultraedit) it doen't loock like a text file.
> Also firefox only shows numbers.
Both should recognize utf8 text files.
>> encoded in utf8?
> How do I check?
Please send it (in a .zip archive so that it does not get altered), I'll
have a look.
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Abdelrazak Younes wrote:
| >
| >> Ah... with this change I have then the same output as yours:
| >>
| >> test:
| >> abcd
| >> 228246252
| >> 20 e4 f6 fc
| >> 196214220
| >> 20 c4 d6 dc
| >> abcd
| >
| > That looks good, but
Georg Baum wrote:
> Abdelrazak Younes wrote:
>
>> Ah... with this change I have then the same output as yours:
>>
>> test:
>> abcd
>> 228246252
>> 20 e4 f6 fc
>> 196214220
>> 20 c4 d6 dc
>> abcd
>
> That looks good, but the generated file is more interesting. Does it contain
>
> abcd
>
Georg Baum wrote:
> Abdelrazak Younes wrote:
>
>> Ah... with this change I have then the same output as yours:
>>
>> test:
>> abcd
>> 228246252
>> 20 e4 f6 fc
>> 196214220
>> 20 c4 d6 dc
>> abcd
>
> That looks good, but the generated file is more interesting. Does it
> contain
>
> abc
Abdelrazak Younes wrote:
> Ah... with this change I have then the same output as yours:
>
> test:
> abcd
> 228246252
> 20 e4 f6 fc
> 196214220
> 20 c4 d6 dc
> abcd
That looks good, but the generated file is more interesting. Does it contain
abcd
äöü
äöü
abcd
encoded in utf8?
Geor
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Peter and Abdel, can you please test whether the attached test program
works (or could be made to work) on windows with lyx::char_type ==
boost::uint32_t?
If yes, then I'd like to put the attached patch in and proceed with
solution
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Peter and Abdel, can you please test whether the attached test program
>> works (or could be made to work) on windows with lyx::char_type ==
>> boost::uint32_t?
>>
>> If yes, then I'd like to put the attached patch in and proceed with
>> solution 2) a
Georg Baum wrote:
Peter and Abdel, can you please test whether the attached test program
works (or could be made to work) on windows with lyx::char_type ==
boost::uint32_t?
If yes, then I'd like to put the attached patch in and proceed with
solution 2) above.
With two modifications (include
Georg Baum wrote:
> Up to now there have been two proposals how to fix the plain text output:
>
> 1) from Abdel: Still use narrow streams
>
> virtual int InsetBase::plaintext(Buffer const &, std::ostream & os,
> OutputParams const &) const;
>
> and i
Up to now there have been two proposals how to fix the plain text output:
1) from Abdel: Still use narrow streams
virtual int InsetBase::plaintext(Buffer const &, std::ostream & os,
OutputParams const &) const;
and implement operators for docstring and char_type output that conv
On Sun, Aug 20, 2006 at 11:34:43AM +0200, Abdelrazak Younes wrote:
> >>There's an added benefit if we go the basic_string way: I think most
> >>compilers (gcc, msvc) now do implicit sharing on strings so passing
> >>parameters won't be as costly as with std::vector().
> >
> >I doubt any recent co
On Sun, Aug 20, 2006 at 03:06:25PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Wed, Aug 16, 2006 at 10:34:52PM +0200, Lars Gullik Bjønnes wrote:
> | > | I know it's a bit late to voice my opinion but I think it should have
> been:
> | >
> | > Yes. I hav
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Aug 16, 2006 at 05:05:53PM +0200, Abdelrazak Younes wrote:
| >> Abdelrazak Younes wrote:
| Here comes the next bit: I discovered that the result of
|
| std::vector ucs4_to_u
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Aug 16, 2006 at 05:05:53PM +0200, Abdelrazak Younes wrote:
| >> Abdelrazak Younes wrote:
| Here comes the next bit: I discovered that the result of
|
| std::vector ucs4_to_utf8(boost::uint32_t c)
|
On Fri, Aug 18, 2006 at 01:45:23AM +0200, Andre Poenitz wrote:
> On Wed, Aug 16, 2006 at 10:34:52PM +0200, Lars Gullik Bjønnes wrote:
> > | I know it's a bit late to voice my opinion but I think it should have
> > been:
> >
> > Yes. I have been calling on help on the unicode branch for months...
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Aug 16, 2006 at 10:34:52PM +0200, Lars Gullik Bjønnes wrote:
| > | I know it's a bit late to voice my opinion but I think it should have
been:
| >
| > Yes. I have been calling on help on the unicode branch for months...
|
| Could we take a not
Andre Poenitz wrote:
On Wed, Aug 16, 2006 at 05:05:53PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Here comes the next bit: I discovered that the result of
std::vector ucs4_to_utf8(boost::uint32_t c)
was never used as a vector. I changed it to std::string, and that
simplifies
On Wed, Aug 16, 2006 at 05:05:53PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> >>Here comes the next bit: I discovered that the result of
> >>
> >>std::vector ucs4_to_utf8(boost::uint32_t c)
> >>
> >>was never used as a vector. I changed it to std::string, and that
> >>simplifies
On Wed, Aug 16, 2006 at 10:34:52PM +0200, Lars Gullik Bjønnes wrote:
> | I know it's a bit late to voice my opinion but I think it should have been:
>
> Yes. I have been calling on help on the unicode branch for months...
Could we take a note for the future that working in branches does not
reall
Lars Gullik Bjønnes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
| > UTF-8 is a multi-byte encoding. It's useful for output to file
| > because the data are stored as characters (bytes). So, much of a
| > UTF-8 encoded file will be human readable; only the multi-byte
|
Helge Hafting <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
| > UTF-8 is a multi-byte encoding. It's useful for output to file
| > because the data are stored as characters (bytes). So, much of a
| > UTF-8 encoded file will be human readable; only the multi-byte
| > sequences will not.
| >
|
Angus Leeming wrote:
UTF-8 is a multi-byte encoding. It's useful for output to file because the
data are stored as characters (bytes). So, much of a UTF-8 encoded file will
be human readable; only the multi-byte sequences will not.
Actually, the multibyte sequences are human readable
too, if
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> If you give a nice name to ascii_guill I'd think that the code
Lars> could be even clearer than it is now.
Lars> I am not sure that you can have you cake and eat it at all
Lars> times... unicode is more cumbersome to work with.
Am Mittwoch, 16. August 2006 23:40 schrieb Lars Gullik Bjønnes:
> Georg Baum <[EMAIL PROTECTED]> writes:
>
> | Does this mean we have now agreed on using docstring always when
dealing
> | with multibyte strings?
>
> when not close to the converter itself, imho yes.
OK. I am currently working o
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Mittwoch, 16. August 2006 23:12 schrieb Lars Gullik Bjønnes:
| > Change the code so that those conversions os not needed, don't change
| > the conversions.
|
| Does this mean we have now agreed on using docstring always when dealing
| with multibyte st
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars> if (disp == ascii_guill) ...
|
| This I do not like much. This hides the meaning of the code,
| especially since I have a
| else if (disp == ">>")
| two lines after. A piece of trivial code is going to be changed to
| something not so nic
Am Mittwoch, 16. August 2006 23:12 schrieb Lars Gullik Bjønnes:
> Change the code so that those conversions os not needed, don't change
> the conversions.
Does this mean we have now agreed on using docstring always when dealing
with multibyte strings?
I have had a closer look, and noticed that we
Lars Gullik Bjønnes wrote:
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> So imho if docstring should change to anything as of now it is a
| Lars> std::vector
|
| Is it a threat? ;)
Yes. Stop bickering about the b
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
| >> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > Lars> So imho if docstring should change to anything as of now it is
| > a
| > Lars> std::vector
| > Is it a threat? ;)
|
| No, just Lars reinventing
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Here is a
Lars> different (related) question. In the insetquote code there | is
Lars> this | if (disp == "<<") | code. How should I change it if disp
Lars> is a docstring so tha
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > ucs-2 with qt.
| > | | so no utf8 here.
| > | | > utf-8/ucs-2 with pango.
| > | | So utf8 is not necessary there also as pango deals per
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> So imho if docstring should change to anything as of now it is a
| Lars> std::vector
|
| Is it a threat? ;)
Yes. Stop bickering about the basic_string already!
--
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > ucs-2 with qt.
| > | | so no utf8 here.
| > | | > utf-8/ucs-2 with pango.
| > | | So utf8 is not necessary there also as pango deals perfectly
| > with ucs2
| > | (a
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Here is a different (related) question. In the insetquote code there
| is this
| if (disp == "<<")
| code. How should I change it if disp is a docstring so that it still
| fits on one line. How do I change a C string to something that
| compares
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > ucs-2 with qt.
|
| so no utf8 here.
|
| > utf-8/ucs-2 with pango.
|
| So utf8 is not necessary there also as pango deals perfectly with ucs2
| (and 4?)
What is your point really?
My point is that you don't really
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I'd like to find a syntax such that the translation of our code to
| unicode does not transform every line into 3 lines (like the examples
| where we push \0 explicitely).
That is easy: just make everything use docstring and char_type.
Why do yo
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| That said, I'd appreciate to work on strings instead of vectors for
| utf-8...
Lars> Huh? Where do you plan to work on utf-8 at all?
OK, I got it wrong.
Here is a different (related) question. In the insetquote code there
is thi
Jean-Marc Lasgouttes wrote:
"Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> So imho if docstring should change to anything as of now it is a
Lars> std::vector
Is it a threat? ;)
No, just Lars reinventing basic_string with vector ;-)
If you look at the STL code basic_string i
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> However our internal interface is in message.C and from
| Lars> Message::get we can perfectly well output a docstring instead of
| Lars> a string. (and thus ucs-4)
|
| Yes
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > ucs-2 with qt.
|
| so no utf8 here.
|
| > utf-8/ucs-2 with pango.
|
| So utf8 is not necessary there also as pango deals perfectly with ucs2
| (and 4?)
What is your point really?
| > What aspell can use I have no
| > idea about. (it can use uc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> So imho if docstring should change to anything as of now it is a
Lars> std::vector
Is it a threat? ;)
JMarc
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> | why do we use unsigned short instead of boost::uint16_t here.
Lars> I know | they are the same, but wouldn't it be clearer?
Lars> Perhaps. (but of course we don't have a basic_string short> anyway...)
I thought about the vec
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | That's exactly what this means but, sure, that is just my opinion.
| > You
| > | obviously are in love with your vector solution ;-)
| > I
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> However our internal interface is in message.C and from
Lars> Message::get we can perfectly well output a docstring instead of
Lars> a string. (and thus ucs-4)
Yes, and if it is costly, we'll change it later on.
But if our po
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| Abdelrazak> I know it's a bit late to voice my opinion but I think it
| Abdelrazak> should have been:
|
| Off-topic questions:
|
| Abdelrazak> typedef std::basic_string ucs
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > Both ucs2 and ucs4 use a fixed number of bytes for one character
| > (2
| > | > and 4, respectively, surprise, surprise!). The problem i
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | That's exactly what this means but, sure, that is just my opinion.
| > You
| > | obviously are in love with your vector solution ;-)
| > If the only semantics are "bun
1 - 100 of 134 matches
Mail list logo
