World: r3wp

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.

do load tail ['a] 

Actually this seems to be enough to crash it.

I don't see this in RAMBO.

RAMBO'ed

Nice one. I seem to remember a bug like this a long time ago, though.

if you find anything that is broken in the 2.7 releases but worked 
fine on 1.3 please let me know.

(key events bug is already known)

the load "#[function! [] []]" bug is know too, but anyway, I am reminding 
it here

I haven't found much else wrong.

This is a problem that has occurred since View 1.2.100 or before 
(but seems not a problem in View 1.2.48 or 1.2.54)
I see a difference between these two:
	request-file/keep
	request-file/keep/file %hello

The first one remembers the directory of previous invocations, but 
the second one doesn't.

I think when the /FILE refinement is used, it just ignores the previous 
directory, reasoning that the user is passing in the "current directory" 
via %hello
That seems simplistic.

I would prefer if REQUEST-FILE would check the /FILE refinement's 
NAME argument to see if it contains a path or is just a single file.
When it is a path, then it is OK to use it.

When it is just a single file, then it should use the previous directory.

Anton, if that applies to 1.3.2 too, then please make sure it is 
in RAMBO.

is there going to be official 2.7 release soon or what?

dunno if RAMBOed, but there is a difference in callback! vs callback 
between 2.6 and 2.7

and I hope timezone gets fixed finally after all those years

Gabriele, yes it does apply to 1.3.2 and also 2.7.5

Ok, posted bug report.

Petr: first of all, we don't want 2.7 to introduce new bugs. (2.7 
is a merge of a number of branches of the code - Carl really needed 
to do this to simplify things - so there are many things that can 
break in such a scenario). Then, we want it to fix a few bugs too. 
:)