> If I understand you correctly, you want us to use "string" in all
> places where we today uses "LString". Is that correct? If so I think
> we should make the switch right away.
Yes, please go ahead and do that change. (This is irrespective of the current
discussion about whether InsetChunk should use LString or not.)
> Concerning you comment in 2.1.1 about the lack of conversions from
> numbers and floats to strings: that is why we have stringstream.
Ok, I didn't notice that one.
> I would hope that some of the string mangling functions in lstrings
> could be removed. Hopefully all of them... ad. name change... yes
> perhaps, but before we do this and the paramterizing you mention is to
> try to get rid of all the unneeded functions therein.
Yes, that's reasonable.
> Also you say something about the ANSI C standard header <string.h>, it
> is a perfect valid header, but when used from ANSI C++ it should be
> called as <cstring>. Hopefully will we be able to use almost no
> functions from it.
Yes, we should use the headers without ".h". Those are the standard headers.
The ".h" headers are non-standardized and varies from compiler to compiler.
> Is your intention that LChar should be LString::value_type and not
> string::value_type? If so, a small change in LString.h is needed.
LChar should be either char or wchar_t according to our LString compilation
flag. So, yes, LChar should be LString::value_type.
> And: where is the Unicode.h you mention? And what is it supposed to
> decleare?
>
> glyphType()
> decomposeGlyph();
> lowercase();
> uppercase();
Yes. The titlecase() one was dropped again, because the memory overhead of the
thing is bigger than the benefit of it.
The Unicode.h file does not exist yet. Amir wrote an excellent script to
convert the unicode database to a C++ file, but the last iteration is missing.
Anyway, Amir, what was the link to the file once again? Then Lgb or I can hack
it up and put it into the tree.
> I want us to get the base for all this put firmly into place pretty
> soon, so that we can begin the implementation of the new buffer
> structure. (what remains to be discussed?)
The Inset base class. Unfortunately, I'm not feeling too well at the moment
(something with my throat), so I have not done my homework yet. Sorry to keep
you waiting for my proposal.
> We need to introduce namespaces rather soon.
I think we can delay this one a bit.
> It seems that the current devel lyx is not completely useless, as I
> used it to read the encodings.lyx.
Great.
Greets,
Asger
