World: r3wp

Hmm, complicated . you may be  right. *thinking

would cost  much performance to keep track of all the data.

you are right, that it is *theoretically* possible, but in that case 
my IDENTICAL? function wouldn't be able to yield TRUE

It would if there is  an intemediate  structure. value -> intermediate 
-> bitsetdata.

then a and b point to that structure. the pointer in the structure 
is  changed. but a and b return the same still  the stuff.

.. return still the equal stuff.

I rather state it in a positive way: since my IDENTICAL? function 
correctly compares bitsets (can be tested), the model I am using 
is correct

IMHO  but  implementations would  have the same results, but mine 
is more silly;)

but -> both

as I said, I consider my claims proven. The IDENTICAL? function explores 
the identity by manipulating the data, so it actually is able to 
find out whether two bitsets share data or not

You modify the  a-node and  b points to the same node. if you check 
b you see the same changes.

yes, I found out, that A and B share data

in the same way I found out the A and C don't share data

They still  share the same data  if you point  a pointer in the node 
to something else. But - here is  rambo, move somewhere else. Your 
 version seems more  plausible from the  implementation effort, i 
want to makemy point  for  academical reasons.

understood, but you are missing an inconsistency in your reasoning

.. let us move somewhere else? (do not want to command you ;)

I am still not sure, whether this can or cannot be called a bug:

    #"a" = #"A" ; == false

Not a bug.

DESCRIPTION:
     Returns TRUE if the values are equal.

>> equal? #"a" #"A"
== false

and

>> to integer! #"a"
== 97
>> to integer! #"A"
== 65

Definitely not equal.

it is related to:

    difference [#"a"] [#"A"]

I think that case-sentisitivity does matter only with string! not 
with char!

looks so, but I don't think it is explicitely stated anywhere

but that's not true with FIND, hm.

yes, the situation is somewhat "mixed"

If FIND can be changed for R3, I'll be glad. I remember having problems 
with finding bytes in binary because of this inconsistency. I had 
to use find/case always.

unfortunately for you it seems to make sense, because the opposite 
refinement does not exist

yes, but it seems little bit strange, use find/case with pure binary 
data :)

But I though changing it only for char!, you can always use (find 
string "a") for case insensitive search.

Ladislav, I wonder if your task will be easier if you have an semantic 
model for the language instead of trying to create a coverage test 
set.

Another question worth asking: I can agree that it is useful to obtain 
TRUE from equal? 0.1 + 0.1 + 0.1 0.3, although zero? 0.1 + 0.1 + 
0.1 - 0.3 cannot yield TRUE due to the limitations of 64-bit IEEE754 
floating point format. On the other hand the STRICT-EQUAL? and/or 
SAME? functions may be stricter. E.g. my IDENTICAL? function (see 
above) is the most strict possible in that respect and yields FALSE.

AFAIK equal? in rebol is relaxed and does a range-check. For close-to-zero. 
And 'equal?  is the  relaxed version. 'strict-equal? should not. 
IMHO.

that is my understanding too. what about SAME?,  where would you 
like to see that in the strictness scale?

even more strict than 'strict-equal? :)

may break with  save/load because of conversion-errors, but if i 
use that i know what i do.

actually, e.g. for decimal! values there *is* a way how to suppress 
the conversion errors

(we only need 17 digits instead of 15)

AFAIK this  periodical things may clash. like 1/3. There  are values 
which work perfectly with one base and have periods in another. and 
then there are never enough digits. But i may thinking wrong.

I am going to submit a request to implement para/margin/y

any comments before I do ?

This is to allow a SCROLLER at the bottom, inside an AREA.

Currently, I suppose the text is clipped at the bottom edge of the 
face.

I propose to now clip the text at the bottom edge minus para/margin/y

para/margin/x currently works when para/wrap? == true, but not when 
false.

I would also propose that text is clipped when para/wrap? == false.

These changes together guarantee the margins whether the text is 
wrapped or not.

.. and so scrollers can be placed in the margins.

What do you mean by 'text is clipped'?  Would the margin not add 
on to the end of the longest line?

I suppose the View font rendering system does not render and more 
lines of text after the bottom edge of the face has been reached, 
and the result is clipped to the size of the face. I propose clipping 
the text back a bit more by para/margin/y, so that there is a visible 
gap between the last line of text and the bottom edge of the face.

oh I see what you mean....

Ah I remember now. It's a bugger. 

I keep reaching for an "inner-gap" to provide space for scrollers 
and then trying to bend the para/margin functionality to accomodate 
this. But my changes would probably break text-size calculation and 
other things....

Bug #4161 "Cursor movement screwed up if field is right aligned"
It would be great if this were fixed.

I want a new View 2.7 build with the home/end/page-up/down keys fixed.

I want R3 alfa to play with:) You must wait.

do load insert tail [] reduce ["12" 'to 'time!]

note that 'head is omitted on purpose. It crashes REBOL without 'head.