World: r3wp

then it finds edit-text withut path. BTW you only need ctx-text/edit-text, 
not that system/words before.

field is defined inside system/view.

so it can shortcut system/view/focal-face too. bind to both.

In the sdk-source they are nested there.

hmm, that is guru stuff ... although I do seem to understnad the 
bind, I think I also understand, while less experienced user is in 
hell ... then stylize/master is insufficient imo

The other trick is to edit the feel to use full pathes.

system/view/focal-face, unlight-text, highlight-start, caret. and 
ctx-text/edit-text.

well, it is just - stylize/master is here for you to define new style 
... looking into other ones. It should not presume you know about 
where the stuff is bound ... the question is, if it could be cured 
:-) after all - touching stylize/master you are already touching 
the guru stuff, so you better know what you are going to do ... and 
how :-)

Its not stylize fault. its rebol and defining things in another context.

That style is not written to be probed and pasted. maybe it should. 
in the source it is inside the right context, so no guru-stuff needed. 
just a member of an object plugged elsewhere.

would it be different looking into SDK sources?

there is something like
ctx-edit: context[
  edit-text: func ..
  edit: make feel[..]
]

and system/view around that. At least thats the usual way.

No, for system/view %source/view-edit.r there is some bind-magic 
at the end.

Pekr, what does Bobik want to do ? It looks like he wants to capture 
the return key (which is #"^M" and not newline by the way).

Here is a quick  way to modify the engage function, maybe it does 
what he wants.
view layout [
	f: field feel [

  engage: func [face act event] head insert copy/deep second :engage 
  [
			if (probe event/key) = #"^M" [exit]
		]
	]
]

I will post it to him ... what does your function do in particular? 
:-)

Insert PROBE before    head insert ...  and you will know.

well, it seems to insert the code into body of engage which is used 
for our new engage function as a template, or something like that 
:-)

First it copies the body of engage (copy/deep second :engage). Copying 
the code this way keeps the binding of all the words.

Then it inserts some new code. INSERT leaves us after the insert, 
so we use HEAD to move back to the head of the block.

The copied and modified code is then used as the body of a new engage 
function. Because we are creating a function using FUNC, the body 
block is bound to the new function's context, as usual. This means 
that the 'event word is bound correctly and the new code works correctly. 
(That's what happens anytime we create a function.)

and if 'function would be used instead?

No difference there.

I didn't mean to stress "using FUNC", just pointing out that we are 
using FUNC in this case.

ok, thanks a lot .... for me the interesting part was 'head ...

Of course you can check each step using PROBE.

because .... copy/deep still returns block ... I thought the position 
does not matter

I know ....

It's only because INSERT returns the block at the position *after* 
the newly inserted part that we need HEAD.

I know - but I thought that func simply accepts the block, regardless 
of position ....

I thought ti would work without the head, but it does not ...

Well, most functions care about the series index. We can easily test 
if FUNC does:
>> body: tail [print "hello"]
== []
>> f: func [] body
>> f
<---- nothing is printed

it is imo bug :-)

Nah...

func accepts the second argument as a block ... not a block at certain 
position :-) it should automatically move to the head, but ... maybe 
not ...

no way, it would be bug if it worked differently

Blocks are series and series are fundamental to understanding rebol. 
You must understand this behaviour and be comfortable with it, because 
understanding it opens up a lot of the power of series.

Here's a different way, which puts the new code in the key handler 
part:
view layout [
	field feel [
		use [body blk][
			body: copy/deep second :engage 
			blk: next find select body [switch act][key]
			change/only blk compose/only [if event/key <> #"^M" (blk/1)]
			?? body
			engage: func [face act event] body
		]
	]
]

Ladislav - I do understand it from the series pov ... the code is 
surely ok .... but from the func specs, I am not so sure:

body -- The body block of the function (Type: block)

You probably don't spend enough time playing with function creation 
:)

I would expect pointer to the block, not to some concrete position 
inside that block

I don't, never :-)

Here's the "copy, paste and bind" way:

view layout [
	field feel [
		engage: func [face act event] bind bind [
			switch act [
				down [

     either equal? face focal-face [unlight-text] [focus/no-show face]
					caret: offset-to-caret face event/offset
					show face
				]
				over [
					if not-equal? caret offset-to-caret face event/offset [
						if not highlight-start [highlight-start: caret]
						highlight-end: caret: offset-to-caret face event/offset
						show face
					]
				]

    key [if event/key <> #"^M" [edit-text face event get in face 'action]]
			]		
		] system/view ctx-text
	]
]

Notice we are binding the code first to system/view, then to ctx-text. 
(Then it is also bound to the function context.)

why is there a difference?

>> body: [print "hello"]
== [print "hello"]
>> f: func [] body
>> same? body second :f
== false
>> probe second :f
[print "hello"]
== [print "hello"]

Obviously FUNC copies the body block.

Why is that good ? Probably because that's what people expect most 
of the time.

ah, ok, thanks

to your double bind example - what does it do internally? you first 
bind the block to system/View - what happens in that context, and 
what happens in next context - ctx-text?