World: r3wp

All right.  Two Brians...We win.

But Pekr;  RT has to be careful with this.  Giving it out to too 
many will just generate

too much noise...  I'd gladly take my name off the list and wait, 
as to not overwhelm

those in more appropriate positions...I'd rather get handed Government 
Reject Unfit

for Normal Training work.  Not that it isn't a nice shiny carrot 
dangling ever so close

to the nose.  And, being a little schizoid, I also agree with you.

I surely hope you allow us to nominate you for Secretary of the (proposed) 

REBOL User Group. The (proposed) Executive Summary could definitely 
use your
candor.  :)

petr, remember the open view 1.3 project? the problem it didn't get 
anywhere (despite producing a lot of good code) is that Carl does 
not work that way. we can only aknowledge it.

r3 will be open enough that people will be able to work on it without 
Carl's intervention. but for things that require Carl's intervention 
we follow Carl's rules.

btiffin - only if group takes some sensible name :-) all those RUGs 
etc. remind me of linux or amiga groups, noone can depict the acronym 
and it sounds ugly, actually nothing I would like to wear on my T-shirt 
:-)

Gabriele - you talk about two distinctive things, but we shold probably 
move from this group.

Gabriele,
Can you please take a look at these 2 submissions:

http://www.rebol.net/cgi-bin/rambo.r?id=4274&
http://www.rebol.net/cgi-bin/rambo.r?id=4161&


I am desperate because center and left aligned text can not be edited.

Ca you please help?

I convinced myself and 2 others to go REBOL with a small but important 
app I need, but simple stuff like this kills the idea.

Have to agree with Pekr about naming issues!! Let find something 
sexier that anyone would be attracted to 8-).

You meant, center and *right* aligned text can not be edited.

But yes, this is a long-standing bug, and it's annoyed me a few times.
Actually, this is something that *could* be worked around.

We just need to figure out how caret-to-offset and offset-to-caret 
work, then write mezzanines to replace them. I've been meaning to 
do this for a while.

Dear Anton,

A mezzanine, that's it. 
I can not tell you how frustrated I am.

See my response to Gabriele below:
Thanks for the info.


It is so sad to see that "little" things are not fixed in a reasonable 
fashion.

Here I am, 99% of my stuff is Center aligned and I find myself "regretting" 
that I go for a "not so established" language.
(never thought that entering text in a box will be a problem)


I have to actually ask 1000 people to klick 4 times more often, just 
to overcome a stupid bug.
So I ask them to:

Change to left align
Edit
Go back to Center align

Repeat as long as needed and pardon, I used "REBOL"

Best regards


So, what is needed to fix this, please let's include Ashley

Thanks a ton for the shimmer of light I see at the end of the tunnel
Peter

Forgot to include Gabriele's response.
The short form is 
Yes, known for ages
No will not be fixed (in 2.7 there is)
Yes the glorious R3 will (probably) fix it

Known for ages and won't be fixed .... :(

;Not perfect, but less clicky
view layout [
    style cfield field center feel [
        redraw: func [face act pos] bind [
            if all [in face 'colors block? face/colors] [
                face/color: pick face/colors face <> focal-face
            ]
            foc?: same? face system/view/focal-face
            face/font/align: either foc? ['left] ['center]
        ] system/view
    ]
    cfield "hello" with [focus self]
    cfield "cflied2"
    cfield "cfield3"
]

Volker, 
Thanks that saves a few, indeed.

My frustation is that we have to be to "REBOLish", a text box is 
as simple as it gets (maybe excluding a label), one can not be forced 
to adapt to the bugs and "adapt" to a new enforced way of editing 
text !!!

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)