World: r3wp

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:

First run View 2.7.5.3.1 and do this:


 site: select load-thru http://www.rebol.net/reb/index.r[folder "Anton"]
	clear find site %index.r
	load-thru/update site/patch/caret-to-offset-patch.r

Do the main demo, showing patched AREA:

	do-thru site/patch/demo-caret-to-offset-patch.r

Three patched styles; AREA, FIELD, INFO:
	
	do-thru site/gui/demo-area.r
	do-thru site/gui/demo-field.r
	do-thru site/gui/demo-info.r

The initial experimental testing script:

	do-thru site/patch/test-caret-to-offset-patch.r

Advantages:

- middle and right aligned text is now usable and works as one would 
expect, with the caret appearing in the correct position.
- you can render the caret how you like
- you can render the highlighting how you like

  (I didn't show the above options clearly in the demos yet, you must 
  still get your programming fingers dirty)
Disadvantages:
- lots of code to achieve the above

- probably slow performance with large areas, because images are 
being created on every redraw

I should have announced that in the View group, sorry.

(oh well, I guess it's one big bug workaround)

Thanks Anton

Cool, let me know any problems.

To maybe fit in better with other styles, the caret colour can be 
changed. eg:

 area with [append init [named-colours: make named-colours [caret: 
 black]]]

rambo'd https posting bug.

Can I get someone to try this before I report it.

foreach [e s] to block! {thing 'word} [compose [e (get s)]]

segfaults 1.3.2.4.2 and 2.7.5.4.2

linux version

yep

crashes windows as well

+1  
1.3.2.4.2 and 2.7.5.4.2
Linux

is it recursive?

I'll check RAMBO add if not in there then...thanks Graham...I just 
reduced it to this so far...more experimenting to come.

How about this on your end...just trying to reduce the code for the 
RAMBO report.


foreach a to block! {'word} [print get a]  - this segfaults on Linux. 
too.

Got the same result... 1.3.2.4.2 and 2.7.5.4.2

get first to block! {'thing}  returns an error message  ** Script 
Error: thing word has no context
b: first to block! {'thing}
== 'thing
get b     segfaults.

windows REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3 goes boom

reported.

to block! does not bind. word is not included in system/words. sometimes 
that results in an error-mesage and sometimes in a crash.

Good one.

yeah , it's the normal behaviour for to block! , use load instead 
for binding

what happened to my https rambo report ?? :(

i haven't seen it. worst case it was deleted with the spam (i check 
them carefully, but i may have missed it)

yeah ... I think you nuked it :(

did you re-enter it?

No .. did you want me to ??

if it has been deleted, there's no way to recover it.

2.6.2 and 2.7.5, Windows and Linux (probably others too) : Encmd 
crashes if 'title keyword is used in 'encap header. It works correctly 
with enpro and enface.

Is rhis a bug, or just undocumented behavior?
   trim "  a  ^/  ^/  a  "
   == "a^/^/a"

The help says "Removes whitespace from a string. Default removes 
from head and tail." But in this case it seems to treat the string 
as a set of strings (separated  by  newline) and trims them all.
Compare with the expected behavior here:
   trim "  a  b  a  "
   == "a  b  a"

TRIM behaviour is strange.  Sometimes it removes too much as in your 
case, sometimes it removes too little as in (trim "^/a^/" == "a^/") 
. I would say it's a bug.