World: r3wp

Great way of "masking" the problem, I love it!

note, i didn't say "won't be fixed", i said that i find it unlikely 
that Carl will spend more time on 2.7 at this time (ie before july 
15th r3 release).

Gabriele - what's behind the date? :-) It is just that Carl decide 
to release R3 at that particular date, or has it any other internal 
meaning? :-)

What more meaning does it need than that Carl said he would do it?

ie before july 15th r3 ***release***
 :)

some mystical one, for e.g :-)

or some big announcement - e.g. MS buying RT on that date :-)

Wrong smiley :(

WOuld mean Carl never gets at apple. Maybe google. :)

Or sun. They promote half of the syntax currently.

Full REBOL instead of their partial FX? :-)

If incremental dependency-based evaluation is what i think it is 
they may have an edge.

+ platform + swing-widgets. But did not try yet.

>> probe info? %script.r/
make object! [
    size: 3405
    date: 12-Sep-2000/21:40:20+2:00
    type: 'file
]

>> read %script.r/
** Access Error: Cannot open /C/Dev/REBOL/script.r/
** Near: read %script.r/

Shoudn't INFO? return none (or an error) in this case ?

Yes, probably.
Which platform are you on ?

Umm is it the trailing slash?

If it's Windows, then I expect internally rebol just does this:
>> to-local-file %user.r/
== "user.r"

stripping the final slash before accessing the file-system.

I get the DocKimbel behaviour with 2.7.5.4.2 Linux.  But I see the 
point.  Something

weird in query...or make port!  on files disguised as dir specs...

Well I don't think it's weird anymore.   make port! on %file/  uses 
scheme: 'directory
make port! on %file  uses scheme: 'file

The issue I wanted to point out is just that if it's an existing 
file!, I should be able to read it ! So instead of letting the user 
wrongly think that's a file, and let 'read pop an error (which sounds 
illogical to me), I'm proposition to signal in 'info? that something 
is wrong with that file! value.

In my example above, the file! value is explicit, but in cases where 
it's not, it  produces an odd and illogical bug, IMHO. See this other 
example :

specs: info? a-file
if specs/type = 'file [
	probe read a-file
]

** Access Error: Cannot open /C/Dev/REBOL/script.r/
** Near: read a-file

Anton: yes, Windows

Doc, ah yes, I think I agree because I seem to remember doing the 
above sequence myself at some time.

It is with pleasure that I can announce that there is a workaround 
to the center / right aligned text highlighting issue. I have a working 
prototype. You can change the horizontal alignment of the face on 
the fly. Give me a day or two to clean it up and make a nice demo.

(and vertical alignment too !)

Good news, does it involve patching caret-to-offset and/or offset-to-caret 
(via mezz wrappers)?

There is a bug in decode-url:
>> probe decode-url http://test/path/target?text/something
make object! [
    user: none
    pass: none
    host: "test"
    port-id: none
    path: "path/target?text/"
    target: "something"
]

the target should be: target?text/something

the bug is in the URL-parser of course... there should not be ? char 
in path-chars

Is it so difficult to remove a char from charset or I forgot something?

why this is not working?

>> remove charset "abc" "a"
** Script Error: Invalid argument: none
** Near: remove charset "abc" "a"

when in doc is:

Character sets can also be modified with the insert and remove functions, 
or combinations of sets can be created with the union and intersect 
functions.

Charsets don't always respond the way you'd expect -- or support 
all the operators they could.
One way to remove a char: use difference:
    >> (charset "ac") = (difference charset "abc" charset "b")
    == true

yes.. that's what I forgot... but anyway... removing ? char is not 
enough:(

Try this:
remove/part charset "abc" "a"

The /part is necessary when removing from a bitset,

The "Invalid argument: none" is just the default value of the second 
parameter that never gets used if you don't specify /part.

Ashley, the patching is quite heavy;

- caret-to-offset  and  offset-to-caret  replaced by mezzanines (mainly 
dependent on the TEXTINFO native)

- in ctx-text, patched 10 functions and 2 feel objects (should be 
backwards compatible)

- replaced the View rendering of the highlight and caret using several 
intermediate images (which will be slow for large faces)

I was disappointed to find that merely patching caret-to-offset and 
offset-to-caret was not enough to fix the highlight and caret rendering. 
The View system does not appear to use them. (Maybe the View system 
keeps direct references to the native functions and does not refer 
to these global words to get to the native functions ?)

This means that ctx-text and focus/unfocus have to be patched to 
prevent system/view/caret and highlight-start/end being set and thus 
rendering the highlight and caret.

Could you post/email me just the caret-to-offset and offset-to-caret 
patches? That should be enough for me to get RebGUI working. Thanks.

Here's what I have so far. (Note, this code may end up in another 
file.)
http://anton.wildit.net.au/rebol/patch/caret-to-offset-patch.r

Also note, to get the caret and highlight handling / rendering working 
properly will require you to do in Rebgui the equivalent of the above 
ctx-text patching etc. That's quite a bit of work.

Oldes, regarding your multiple slashes ticket...

notice this behavior:

>> what-dir
== %/home/giesse/
>> read %/

== [%proc/ %initrd/ %sys/ %bin/ %initrd.img %media/ %Recycled/ %srv/ 
%usr/ %etc/ %boot/ %vmlinuz %lib/ %mnt/ %tmp/ %sbin/ %cdrom/ %...
>> read %//
== [%.directory %giesse/]
>> read %///

== [%Detective/ %.hplip.conf %.teamspeak2/ %.mythtv/ %.qt/ %.fontconfig/ 
%.clay/ %.Skype/ %.recently-used %.face.icon %.DCOPserver_...

REBOL does not ignore multiple slashes. However, this is not documented 
anywhere, so I'm not sure what the rules should be.

so it's bug here:
>> make-dir/deep %aaa//bb/
** Access Error: Cannot open aaa//
** Near: make-dir/deep %aaa//bb/

never mind, you can delete it, I already have a solution... anyway... 
it would be nice to replace the clean-path function with the Anton's 
simple-clean-path

any [get/any 'no-word "Alt"]
; should this return "Alt" ?

Chris;  Umm, not according to help any. It returns the first value 
that is not false or none. So I guess unset! counts.  :)  But you're 
right.  unset! should be more false than true.

I've finally done it. Here is an AREA/FIELD style which handles and 
renders the caret much better with center and right-aligned text: