World: r3wp

workaround...

bye bye my rich-text engine

another one project fail, my speciality....

Drop and Off?  What are you talking about?

used to discard previous commands in rich-text blocks (like bold, 
underline, italic)

Ah...  I'm sure they'll fix that eventually...

eventually, mwahahahaha

I'm building my rich text editor on the gob/face level so that won't 
be bothering me. Getting this parser right is proving to be tricky 
though!

eh ? i don't understand why you are not impacted...

when i talk about rich-text, i mean gob/text, so you are impacted

me too, i create my own gobs

i don't use those Carl's style

I'm not impacted because each style change creates a separate face.

I'm not using Draw directly.

and ? 
How do you handle imbricated styles in the same line of text ?
Like:

 gob/text: [ bold "this is bold" italic "this is it talic and bold" 
 off "this is bold" ]

Especially if the line is wrapped

don'

Hehe, I'm not writing that kind of Rich Text editor...  It's really 
just a syntax highlighter so all of the formatting is implicit.

if you construct linked gobs for the same line of text (one gob = 
one style), i say good luck to manage wrapped lines.

hum ok, it's more simple

you just change colors

Managing wrapped lines isn't a concern at the moment.   What I will 
be able to do with the structure I've chosen far outweighs the extra 
cost dealing with wrapped lines if I ever decide to add that functionality.

No, not just colors.  You have full font control, bold, italic, etc

i'm fucked, my current development is about editing makedoc documents, 
i can't bypass this request

i need wrapped paragraphs

rich-text at gob level must work

yeah, for what you are doing Drop and Off definitely have to work!

posted question to rebdev, how far are we with March dev plan, in 
order to sync sources with Cyphre once again and let him fix few 
things.

Steeve, I think one gob per character may operate fast enough, if 
it's a modern machine. But then you have to do your own paragraph 
flowing etc.

argh, i was hoping you will not notice this

one gob per line is my aim

one gob per char, i don't ever try it. It will be slow and memory 
consumming

That's how I did my editor replacement in R2. But then I started 
wondering how to do my own flowing and I decided multiple gobs per 
line is the way to go. Needs some clever way of indexing lines and 
caching gobs so small near-constant number of gobs are produced and 
reused per window of text.

Sorry, I didn't mean per char, but per font / formatting change.

i can manage multiple gobs per line (depending of the grammar) but 
i don't want to use a gob per char, what a pain in ass when the text 
is scrolled or modified ...

yes but in that case, wrapped text, is hard to handle if it's not 
one gob per char

Yes, you would have to do the flow / wrapping algorithm yourself.

doubling the size of my script at least :-)

Yes, lots more fun.

pfff

Rejoining a massive block of strings after reading from the clipboard 
causes a crash...

---------------------------
REBOL System Error
---------------------------
REBOL System Error #1215: assertion failed

Program terminated abnormally.
This should never happen.
Please contact www.REBOL.com with details.
---------------------------
OK   
---------------------------

; pasting this code into the console seems to be just fine but if 
you

; do read clipboard:// it fails on the first or second attempt causing 
the above error...

blk: []
str: to string! to char! 0
repeat i 256 [insert str to char! i]

rdm-str: has [txt] [txt: copy "" repeat i random 80 [insert txt random/only 
str]]
repeat i 4020 [insert blk rdm-str]
probe length? blk
probe length? rejoin blk

and the length of the block appears to be key here. at 4019 I never 
see a crash but once you go over 4020 REBOL becomes unstable.

what a dummy test :-)

is that a real program ?

I was planning on using it to test my scrolling quality on a large 
chunk of text...

it's about 160k characters over 4k lines.

but it's much more memory overhead, cause your blocks and temp strings 
are expanded at each add

many many temporary strings are created and fill the memory

Memory overhead?  NOPE.   The console doesn't even increase 1MB memory 
use during or after execution of the above test.

hmmm