World: r3wp

chris, there is no purpose, it's just that internally path! = block!, 
so path! behaves exactly like block! does. it probably should strip 
newlines when converting though, or at least ignore them when molding... 
(that is, i'm saying this is a bug.)

perhaps it's a good idea to check on any char that does not belong 
in a path! R3 has a bug where it includes none! as part of a path.

Chris, you raised a good point when you said "Why would you possibly 
want to retain that behavior?".  We wouldn't - add it to RAMBO please.

Gab: just want to be sure, I know that one man's bug is another man's 
feature...

I'll RebIT to that!

sorry I didn't reply sooner.  The version of round I was using was 
on a linux box so it was the latest debian rebol release.  It does 
round up correctly on the windows version I have.

>> build-tag [input type checkbox value test checked] 
== <input type="checkbox" value="test" checked> ; OK

>> build-tag [input type checkbox value test checked /]

== <input type="checkbox" value="test" checked="/"> ; Not OK, but 
required in all XHTM Lstandards.

I'm not sure if it's the best way, but could it be solved by checking 
for /, "/" or #"/" as well as tail position in the block.

What do you mean?

what I mean is that for single-standing tags, like <br>, XHTML 1.0 
and upwards requires them to end with a slash. This creates a correct 
tag for this case:

>> build-tag [input type checkbox value test /]
== <input type="checkbox" value="test" />

But this is not correct:

>> build-tag [input type checkbox value test checked /]
== <input type="checkbox" value="test" checked="/">

build-tag was probably adapted to support the earlier specification.

The correct tag required by XHTML is:
>> build-tag [input type checkbox value test checked checked /]
== <input type="checkbox" value="test" checked="checked" />

is checked="checked" really correct?

interesting. it is correct.

Yep, xhtml requires paired attributes.

>> f: %"test dir"
== %test dir
>> make-dir f
== %test dir/
>> read f
** Access Error: Cannot open /d/rebol/test dir
** Near: read f

I'd say it's a bug

a very old bug

but good it was found. that revealed 4 bugs in R3 there. :-)

eeek!

I make a habit of testing R2 bugs in R3 as well.

I think i've seen this bug before too ....

I have to work around it in my database system.

I'm trying to rename a few 100 directories to conform to a naming 
scheme

It's annoying having to work round this .. and also that rename doesn't 
work except in the current directory.

yes, it's quite annoying

I've been telling my clients for years not to install REBOL applications 
in folders that have a space in the name -- like "program files/rebol"
It just creates too many problems.

My virtual filesystem (in QM) simply doesn't allow them.  Same reason 
-- too many problems...

what problems?

I use them all the time.

There are three ways to handle such directories that I'm aware of:

you can use the short directory format:

change-dir %/c/progra~1/

you can use the long directory format:

change-dir %/c/program files/

or you can just use the native format:

change-dir to-rebol-file "c:/program files/"

If you want to the know the short format for a directory just use 
the dir/x command from the command prompt.

All three of which are a pain.

(one is platform dependent)

Pain as compared to what?

Not dealing with spaces.

option 1 above is even better than that.

And is limited to Windows.

All I'm saying is that if you make the assumption that none of your 
filenames have spaces (where you have such control), then it removes 
some of the pain of having to deal with them.

I'm not saying there aren't workarounds (which you need particularly 
if you don't control the filespace)

there are also problems with using non-english characters at times. 
it backfires when you type a directory name in a macOSX script that 
makes a directory on a windows machine. results in chaos, because 
the dir name is read differently depending on the platform and whether 
you are reading it across the network.

Yeah Chris, I guess it depends on what your going.  For example, 
if you collecting directory information and must parse thru it then 
the spaces are obviously a pain.

Does read/direct/skip not work?  It always starts at the beginning 
of the file.  read/skip works, but with the direct it doesn't seem 
to.

It's been a longstanding problem, Tim.

These two blog posts discuss it and a solution. I do not know if 
the solution has been implemented:
http://www.rebol.com/article/0198.html

http://www.rebol.com/article/0199.html

thanks!

i have about 50,000 word strings in a single block.  I would like 
to do a find/any wordsblock "sear?ch*" ;on it but no go - am i missing 
some fundamental feature of Core or is this broken?

i was expecting it to return the index of the first found match within 
the block

example:
a: ["one" "two" "once" "twice" "three" "thrice"]
find/any a "on*"

isn't there an /only refinement?