World: r3wp

I will try that at home, as here at work I run W2K ... thanks for 
the pointer ....

Many of these are installers wrapped around registry settings, no 
more complicated than that.

Using rebol as shell is quitge nice. I wrap my favorit commands in 
functions, tab-completion for filenames and commands is there, call/console. 
i can mix pure rebol in, and want wrappers anyway for some long options.

don't forget ATTRIB for fast file finds from DOS console.  Quickest 
way I know.

It is fast, but I don't think it's able to look inside file contents 
as well.

Did anyone try to patch the behaviour of area? Especially I'd like 
to have:
- autoindent

- doubleclick on words in the area to do something interesting - 
e.g. look up in dictionary, use like a wiki word, ...
- maybe add additional shortcut keys.


I've tried to patch ctx-text/edit-text, but only was able to get 
no change at all, or crashes. Seems to be a bind problem:
ctx-text/edit-text: func[][] ;no change

ctx-text/edit-text: func[] bind [] in ctx-text 'edit-text ; unknown 
word ...

You need to bind in ctx-text AND system/view (double bind)

Thanks Didier!

One of the challenges I am facing in expanding my EMR is how to capture 
the consultation.  At the moment I am using free text.  But some 
products use lots of check boxes and based upon those ... more check 
boxes appear.  And then a natural language sentence is constructed.

Another way is to have the sentence prebuilt .. and there are active 
words eg yes/no in the sentence you can click on to change, or to 
enter values eg. temperature of xxx C.

How feasible is it to do the latter in View?

In some ways I guess it is like trying to build a rich text display 
where the words are active.

Graham, you could use the link style to popup an option list when 
clicked. Though that will be tedious for data entry. alternately 
use the autofill style for text boxes when you want both free text 
and or a standard list.

I was thinking of the link style .. something unobtrusive.

>> get first [help.gif]
== make image! .....

how do I get the size of the image this way?

hmm, i guess you don't. you'll need a temp var.

>> img-size: func [img] [img/size]
>> img-size logo.gif
== 100x24

something that should be RAMBO'ed?

I don't think it's that important. It's a small inconvenience isn't 
it ?

But for some fun, you might be able to do something like this:
>> do to-path [help.gif size]
== 48x48

there probably are other cases like this.

well, sure. I just thought that there would be a way, like using 
first, second and third on objects

yes, but first etc have a different meaning already

what i really want, is the abilty to list the available refinements 
of a datatype.

Mmm.. in which context do you want that ? Autodocumentation ? Just 
quick console help ?

it should be part of reflexivity. you can access the components of 
an object; you should be able to access the components of everything.

(security and modules aside)

maybe the select action could be overloaded to do what Henrik wants. 
i'm not too much in favor of overloading functions though.

(that is, select something 'word would be always equivalent to something/word)

I think a separate function such as ACCESS should do that. SELECT 
should be left alone to do its series operations as usual.

How about expanding 'in to cover more than just objects?

I imagine:
	access help.gif 'size ; == 48x48

I think that might slow down IN... not sure.

i don't propose changing select. i propose enabling it for more datatypes.

in: you can't have a word bound to an image :)

(ie. same as Gabriele's comment about overloading.)

select is an action, so a method to the datatype. in is a native.

What I mean is, every time IN is used, it would then have to check 
if the argument is an image, right ?

yes, and it would behave like a completely different function in 
that case, which is bad imho

Ok, so we agree on IN.

select instead is already dispatched because it's an action, and 
it would not change its behaviour (returns a value)

A: From a tech pov, yes.

I can't think of an example where select is dispatched differently...

actually, select currently doesn't need being an action, afaik. as 
it is basically second find

so maybe it was made an action to allow things like this in the future 
:)

Ah ok.. yes.. mmm...

(though, there is an action that already does this: PATH. but it's 
not exposed.)

Ah yes, maybe that could be used.

i'd guess path is going to stay this way for speed (internal only), 
but select could be a good interface to it.

I guess so. :)