World: r3wp

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. 
:)

but we want 2.7 to fix certain bugs, no?

of course. as i said, first we must remove the bugs introduced by 
the merge, then we start fixing bugs that were in 1.3.2 already.

Gabriele: I noticed that two ROUND test cases ceased to work in 2.7 
- this signals, that comparison in 2.7 isn't equivalent to comparison 
in 1.3.2

Is it better?

Brian: if your question is related to my post, then I would answer: 
it depends. The cases are:

not negative? 1E-8 - abs 0.9999999 - mod 99999999.9999999 1
0.1 == round/even/to 0.1 1E-16

Dang, I'd have to refresh my math memory to know what the answers 
to those should be. Still, my preference is to have comparison work 
correctly, and if it didn't before, break backwards compatibility 
and fix the code that depended on the bad comparisons. There can't 
be much of that...

Err on the side of more correct :)

my preference is to have comparison work correctly

 - this may be a matter of preference, as it looks. Both versions 
 yield:

0.1 + 0.1 + 0.1 = 0.3 ; == true
zero? 0.1 + 0.1 + 0.1 - 0.3 ; == false

:-)

Where are fixed-point or BCD numbers when you need them? :)

This is just madness. Why do we still put up with this ?

Because 0.1 is a floating-point value in REBOL, and for that matter 
one that can't be represented exactly, much like 1/3 in decimal.

anton, this is a problem in all floating point... I had serious issues 
in compiling earthquake data over a 30 second period... adding each 
change over and over could amount to moving a building a foot away 
 !

because all of the small discrepancies eventually add-up.

>> 0.1 + 0.1 + 0.1 - 0.3
== 5.55111512312578E-17

That's not zero! Anyone can see that! ;-)

I think, it's ok, because the way floating-point works. One could 
just do
>> 0.1 + 0.1 + 0.1 - 0.3 < 1e-10
== true
and that's almost zero, right? :-)

in high-end 3D and games you live with this imperfection daily.

Just like the real world. Imperfection!

hehe should we define an 'ALMOST func  ?

almost? #"a" "a"  
==true

i would prefer precision over speed.

>> almost-zero?: func [v][v < 1e-10]
>> almost-zero? 0.1 + 0.1 + 0.1 - 0.3
== true