AltME groups: search

the other is the fact that series are mutable, and many functions 
edit the input series directly.

rebol can be viewed also as Lisp without parentheses.. it can edit 
it's own code/data structures without any problem... so why doesn't 
rebol have something like macros ?? :)

To use it, double click on the blank canvas to create nodes, and 
double click on nodes to edit them.


Drag arrows from one node to another by click and drag from the left 
bottom corner.

Control-L to load a new map

Control-S to save a new map

-you open a tcp listen port
-edit the hosts file so your remote server points to 127.0.0.1

-and then just print out the data which the client would have sent 
to the server.


this works for just about every networked application I have tried 
and is a very powerfull way to learn how to build custom clients 
in rebol

Yeah, and the R3 CALL doesn't do anything like that yet. Time to 
edit the host code?

I would like to double click on the choices in the edit-list, but 
that then results in loss of the highlite on the selected word.

Also, I would like to see some way for the text to scroll following 
the highlite, and currently I have to move the slider manually.

A set-info func is in the works, but requires some rather extensive 
widget changes (e.g. drop-list and edit-list are different widgets 
at present).

something like 

    display "Edit Field" [
        margin 0x0

        at 0x0 button "Copy text" 20x6 green [unview/only face/parent-face 
        write clipboard:// f/text ]  

        at 0x6 button "Paste text" 20x6 green [unview/only face/parent-face 
        set-text f read clipboard:// f/text ] 

        at 0x12 button "Close" 20x5 gold [unview/only face/parent-face ] 
        do [face/options: [no-title no-border]]
    ]

but opening the window near where the mouse click occurs

display "" [ edit-list data [ "Mr." "Mrs." "Dr." "Miss" ] return 
field ] do-events

and of course this is a major impediment to using the keyboard.  
So, for an edit/drop list you have to click twice - once to choose, 
and then once to regain the focus.

this code is free to use  you can edit copy redistribute etc...

roam.r is Carl's object browser.


Specifically, what I want is to enter a record and see it listed 
in a window.  If I click on a record in that window, I want to see 
it back in the entry fields so I can edit it. Has anyone done this 
using RebGUI?

This is an odd one


display/dialog "test" [ edit-list "1" data [1 2 3]  return text "some 
space"] do-events

click on the edit-list, and tab out .. the window disappears

There's another thing with edit-list.  Unlike a drop-list, you can 
tab into it, and use the down arrow to cause the list to drop, but 
you can't use the keyboard to select a value.  You have to switch 
to using the mouse.

Tracked down the edit-list tab problem ... it's the on-unfocus handler 
it inherits from drop-list that is causing the problem. Need some 
way of conditionally wrapping the hide-popup so it only does it if 
the edit-list is actually active.

Other issues are noted.

just reporting this error ... no expectations

make object! [
   code: 300
   type: 'script
   id: 'no-value
   arg1: 'event
   arg2: none
   arg3: none
   near: [case [
           event/double-click [face/action/on-dbl-click face]
           act = 'up [face/action/on-click face]
           act = 'alt-up [face/action/on-alt-click face]

           act = 'key [face/action/on-key face event face/action/on-edit face]

           act = 'scroll-line [face/action/on-scroll face event/offset]

           act = 'scroll-page [face/action/on-scroll/page face event/offset]
       ]]
   where: 'wake-event
]

This isn't strictly a Rebgui question ... but here goes.  I want 
to double click on a word and perform an action.  That action involves 
interacting with some gui elements on the current screen.  Now, there 
is a function 'hilight-text inside the rebgui 'edit object which 
is inside the rebgui-ctx context.  So, I can hook in there with my 
dbl-click function.  But how to make it call my function which is 
defined for each window?

I can create a global dbl-click-edit function, but since the widgets 
have names all made local, I can't effect the changes I want unless 
I make the widget names global as well.

The problem with the grid widget was that it relied on custom changes 
in rebgui-edit.r (i.e. it wasn't self-contained) and it was just 
too big to easily "grok" (and hence port). A good grid widget should 
have as few features/options as possible IMHO (i.e. get something 
that handles the text-only 80% case before worrying about more complex 
sub-widget support).

Graham and Izkata, thanks for the help.  But I must be misunderstanding 
something, as it is still not working. Here is what I have:

CONNECT/create/flat %cl.db

if error? err: try [
	SQL "select * from projects"
][
	er: disarm err
	if find er/arg1 "no such table" [

  SQL "create table projects (Priority, ProjectName, ExchangeRate, 
  Objectives, Deliverables)"
	]
]

do show-cc: make function! [] [
	display "CRITICAL LINKS Version 1.0.0" compose/only/deep [
		;image %chain.jpg
		return

  group-box "Critical Chain and Theory of Constraints principles" #W 
  data [

   text "1. REMEMBER YOUR PURPOSE" font [color: blue size: 26 shadow: 
   1x1]
			return
			;bar
			;return

   text "2. Free Up Your Major Constraint" font [color: red size: 20 
   shadow: none]
			return

   text "3, Focus on one project at a time---don't multi-task." font 
   [color: black size: 12 shadow: none]
		]
		at 103x14
		image %critical-chain.jpg 30x6
		at 133x2
		group-box "Redeem the Time" #W data [
			after 2
			label "   System Clock Time:" my-time:    text 28x7 "0:00:00"
			return
			bar
			return
			label "Average session time:" my-session: text 28x7 "0:00:00" 
		]
		return


  ;******************************************************************
		tab-panel #HWLV data [

                           ;******************************************************************
			"Projects" [
				label "Project Name:" ProjectName: field  141x5 

    label "Priority:" Priority: drop-list 30 #W "1" data ["1" "2" "3" 
    "4" "5" "6" "7" "8" "9" "10"] 10x5
				return
				label "Objectives:" 
				pad 131
				label "Exchange Rate" ExchangeRate: field 20x5
				return
				Objectives: area 200x10 
				return
				label "Deliverables:" 
				return
				Deliverables: area 200x10
				return
				label "Current Projects:"
				return

    current-projects: table (tab-size + 80x35) #HWLV options ["Priority" 
    right .03 "ProjectName" left .2 "ExchangeRate" left .2 "Objectives" 
    left .3 "Deliverables" left .1] data [(SQL "select * from projects")]
				return

                                                     button "Save" [

                     SQL reduce ["insert into projects values (?,?,?,?,?)" Priority/text 
                     ProjectName/text ExchangeRate/text Objectives/text Deliverables/text]
				    current-projects/redraw
			              ]
                                                      pad 20

                                                      radio-group 60x5 data [1 "Add" "Edit"]
				pad 20
				button "Quit" [quit]
                                         ]

well, I mean I know it is coming from rebgui-edit.r and the 'into-widget 
function which has a recursive find ....

Yes, but make sure you use the updated versions of both %ctx-rebgui-edit.r 
and %set-focus.r. I've also uploaded build 122 to correct a typo 
in back-field.


With regards to the question as to "what key should escape from cyclic", 
I've come to the conclusion that the best way of handling this is 
to just "tab through" cyclic widgets, so:

	f1: field
	panel data [f2: field f3: field]
	f4: field

would tab as f1, f2, f3, f4, f1, etc. tab-panel would operate as:

	f1: field

 tab-panel data ["a" [f2: field f3: field] "b" [f4: field f5: field]]
	f6: field

with a tab sequence of f1, f2, f3, f4, f5, f6, f1, etc


This way we don't have to worry about what keystrokes to change tabs 
or exit grouping widgets. What do you think?

Yes and yes ... but the tree widget really needs to be totally rewritten 
to support that.


If I have tree data like this [ A [  B B B ] ] ...how can I tell 
which of the B's that I am clicking on?

 Isn't this the same issue with drop-lists, edit-lists, text-lists, 
 tables, radio-groups and check-groups? In what case does it make 
 sense to have user options (text strings) that appear identical but 
 have different "real" ID's behind the scenes?

RebGUI v2 RC1 (build 200) uploaded to SVN

Focus of this version has been:
	* Make it look good (color scheme based on Windows 7)

 * Take into account OS sensibilities (different corner rounding, 
 window colors, system fonts)

 * Get rid of the cruft (removal of little-used widgets and options)
	* Improve tabbing
	* Make it load and run faster



Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?



Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color



Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font



Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]


WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

hmm, SVN says:

RebGUI v2 RC1

Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?

Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color

Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font

Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]

WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

Yep, I need to rework the popup logic (drop-lists, edit-lists, menus) 
a bit. There was/is a lot of code to work around non-existant view 
bugs (which were present pre View 1.3). Most of the weird exceptions 
are now caused by the little-used tool-tip code! ;)

I hope I nailed down my table problem now.

It seems that one can select from all text-lists on display, but 
only one table is selected from - selecting next one deselects previous 
one. Tabbded on not is not the problem.


Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.

title-group and image RebDoc section depend upon image ...
 Fixed in next build
scrollbars are behing a little weirdly
 ... noted

basically when one specify [button 100] one get old [button 103] 
but that's ok if we know it
 ... ah, I understand the issue now. Fixed in next build.

I hope somebody else was using this feature so it's not only me using 
before and wanting it.

 ... don't worry, I think the issue is that table needs to differentiate 
 between a selected row and a row that has focus. This was not an 
 issue in previous versions as table was not a tabbable widget. Will 
 be fixed in a future build.

Drop-list and edit-list cannot be closed by clicking elswhere but 
this is still to be fixed, isn'i it.
 ... on the list to fix
Another little observation.

 ... that's an interesting bug and I have no idea at this stage why 
 the 2nd case doesn't work. Needs further investigation.


Good work marek (and others) ... we're slowly but surely ironing 
out the issues.

Build 211
- Moved base objects from ctx-rebgui to system/view
- Removed all dependencies on View/VID mezz code
- Rewrote and added show-popup & hide-popup functions
- Removed style widget
- Inlined popup logic
- Converted internal images from base 16 to base 64
- Cursor keys now work in choose (drop-list, edit-list & menu)
- pad option in layout enhanced to accept pair! (pixels)
- Added tooltips to tool-bar
- Added request-edit
- Improved resize logic
- Fixed request-dir (resize bug)
- Fixed slider (resize bugs)

Build 212
- set-title enhanced to search for parent
- fixed request-edit title bug
- removed append-widget
- removed set-values
- updated get-values
- improved tool-bar tooltip spacing

just that I was able to find 1px difference on our company website 
- 14 vs 15 pixel in one paragraph

 NP, I've actually been using DigitalColor Meter on my Mac to find 
 both pixel and RGB discrepancies ... so when you see something like 
 "pad 0x-1" in request-edit you now know its because I wanted to collapse 
 two 1 pixel edge borders into a single shared 1 pixel border. As 
 I mentioned elsewhere, its attention to trivial aesthetic details 
 like this that make the overall UI "look good".

Try request-edit instead.

Ashley - request-edit from RebDOC looks nice, it even scrolls, but 
it somehow misbehaves on my system. 

1) The Window could be smaller - does not even fit my 1280x800

2) When I try to resize it from the top, the window jumps around 
100pixels below

3) editing - only typing works ... e.g. hilighting by mouse does 
not work (strange, as it works for fields)
4) scroller misbehaves too ....

Autoscroll and request-edit issues noted.

Build 213
- layout moved to global context
- renamed request-edit to editor
- renamed set-enable to enable
- renamed set-disable to disable
- added in-widget function
- enable/disable now accept block of faces
- fixed arrow/list bug
- changed popup auto-hide from away to click
- fixed menu
- added toggle widget
- changed hard-coded green/red to use colors/true & false
- updated tour.r and RebDOC.r

edit the widget list?

easy way to determine which word has been hilighted in a text area
 ...

display "Sample" [
	a: area
	button [
		all [
			ctx-rebgui/edit/copy-selected-text
			print read clipboard://
		]
	]
	button [
		all [
			ctx-rebgui/edit/hilight?
			set [start end] ctx-rebgui/edit/hilight-range?
			print copy/part start end
		]
	]
]

I must have an old version of rebgui .. I aways get none on ctx-rebgui/edit/hilight? 
  and copy-selected-text is not working for me either.

There are at least 3 problems needing fixing in 214 (and 213) version.


When using drop-list or edit-list if one will hit <TAB> button when 
list line is hilighted stack overflow eventuates. One, of course, 
doesn't need to do that, but it may happen.


Slider button, as presented in RebDOC, bombes out for simple reason. 
Formula used is [slider] but minimum required seems to be [slider 
[]] - compulsory action needed.


In RebDOC editor requestor hitting "Open" or "Save" button triggers 
feature-na script error.

There is strange bug introduced in build 208 and still there. I checked 
and 207 seems to be OK.


When tabbing table and edit-list, edit-list becomes not accessible 
when first line of table gets selected. Selecting any other table 
line clears the problem.
I'm on linux Mint. Can anybody confirm my findings?
 

>>display "" [edit-list data [] table options ["a" left 1.0] data 
[1 2 3]] do-events  ;-- tab a bit, please

>>display/dialog "test" [drop-list data [1 2 3]]   ;; no problems, 
build 215, linux Mint  

>>display/dialog "test" [edit-list data [1 2 3]]   ;; big problem 
here 


When trying to enter text into edit-list widget the window magically 
disappears.

Can anybody confirm, please. Am I doing anyting wrong? Will it ever 
work? Ashley?

Build 216
- resized editor
- added /size refinement to editor
- fixed edit-list
- fixed request-file (returns full path)

Thanks Graham for confirming. Thanks Ashley for quick fix of the 
last problem.

Problem I tried to explain before still remains. Lets explain it 
better, if I can.


>>display "test" [table options ["a" left 1.0] data [11 22 33] field 
edit-list data [1 2 3] field] do-events

If one selects first line in table and tries to <TAB> around one 
gets stack on edit-list (drop-list too).

If, on the other hand, one selects any other line of table, edit-list 
gets focus and tabbing continue to work, but only after it reaches 
table again.
I hope it's not too hard to fix. Thanks.

I will try my luck again with this 2 items.


When using edit-list or drop-list, there is a way to crash it. Just 
click on the widget, hilight any line on the list and press <TAB>.

>>display "" [edit-list data [1 2]] do-events ;;-> stack-overflow 
error message pops up.


Table widget has different gap in the last column on the right without 
and with the scroller. It' only cosmetic thing and maybe it is customary 
to be like that.

>> display "" [table options ["a" right 1.0] data [1] table options 
["b" right 1.0] data [2 3 4 5 6]] do-events

Can anyone confirm, please. Ashley?

Another stumble block in my slow attempt to write my little program. 

Try to select edit-list and hit enter key.

>> display "" [table options ["a" left 1.0] data [] edit-list []] 
do-events ;-- works as it should

>> display/dialog [table options ["a" left 1.0] data [] edit-list 
[]] ;-- window disappears

It maybe related to the table problem I mentioned before.

I made a little mistake, but it makes no difference.


>>display/dialog "" [table options ["a" left 1.0] data [1 2 3] edit-list 
data []]  ;-- it still disappears, even if first line selected

It may be last one, I don't know.


display "" [table options ["a" left 1.0] data [1 2] [set-text el 
first face/selected] el: edit-list data []] do-events


Select row 1 and row 2. Build 205 works ok. Build 207 doesn't with 
first row of table - nothing shows on edit-list. Replacing edit-list 
with field makes it work ok in 207 (and up) again.

Serious bug introduced in build 218 or even 217.

Drop-list and edit-list widgets produce past-end error on list selection. 
Tested tour.r, RebDOC.r and in terminal. Nothing works.

This is interesting bug.


>>display/dialog "" [edit-list data ["a..." "b..."]] ;; try to enter 
something starting with "a" or "b"
** Script Error: Invalid path value: lines
** Where: wake-event
** Near: pf/lines: to integer! pf/size/y /


Any other start is OK. No modal mode is OK. Happens with 218 (less 
selection bug) and 216 as tested by me.

Bobik, to create a new widget:

	1. Add your new widget to the %Widgets/ directory

 2. Edit %rebgui-widgets.r to add an #include entry for your new widget

 3. Run %create-ditribution.r which will "compile" a new version of 
 %rebgui.r for you

box red 10x10 on-click [print mold get in face 'feel]

make object! [
    redraw: none
    detect: none
    over: none
    engage: func [face act event][
        case [
            event/double-click [face/action/on-dbl-click face]
            event/type = 'time [face/action/on-time face]
            act = 'up [face/action/on-click face]
            act = 'alt-up [face/action/on-alt-click face]
            act = 'key [
                face/action/on-key face event
                face/action/on-edit face
            ]

            act = 'scroll-line [face/action/on-scroll face event/offset]

            act = 'scroll-page [face/action/on-scroll/page face event/offset]
        ]
    ]
]


Now how to get into the feel, and hook somehow into 'engage method 
:-)

this doesn't seem to change much in edit-text

caret-to-offset face find/tail/last head view*/caret view*/caret

The current edit-list shows the matches where you are typing which 
is a little distracting.  How about the drop list appearing with 
the matches  instead?

I've posted my lookup-field as per my video here 

http://rebol.wik.is/RebGUI/Lookup-field


It uses a lot of code from the edit-list which I don't quite grok! 
 So, there's a bug which requires you to initialize the field with 
a backspace first.

So, I can feed this widget 18,000 entries which I don't think you 
can with the edit-list.

re: button colors. A QAD fix for b117 follows:


Edit rebgui.r and make the following changes to the button widget 
starting on line 1260:

	- Add a new attribute ... old-color: none
	- Add the following to the init function ... old-color: color

 - Change color references ... replace "colors/theme-dark" with "face/old-color" 
 (leave the "color = colors/theme-dark" ref though)

This trailing hover problem is not visible in build 218, but I need 
drop- and edit-list for my app, and these two are broken in b218. 
Thanks for the help!

On a Mac, no problem. On WinXP it appears that the events are being 
generated faster than they can be processed. Good test case, I've 
never seen this before! ;)


I don't have an immediate fix, but this is one more reason for me 
to get the 2.x series released. Are drop- and edit-list the only 
roadblocks for you?

This line give error when you select an item in drop-list, I tested 
on latest svn version (218): Is it a known bug? (same error for edit-list)

do %rebgui.r display "Test" [drop-list "Black" data ["Red" "Green" 
"Blue"]] do-events

I usually purge the directory when I'm not working on the files. 
Then when I want to work with them I get the specific files I want 
to edit, edit them, test them locally, submit the changes, then empty 
my work directory. If my submission sucks I deny it, if it is good 
I accept it.

well that's not a new thing Moon edit propose that kind of collaboration 
real time since some years already. what i like in wave is the modular 
aspect  you are not limited to a conversation you can create  "wavelets" 
to anykind of  use and extrapolating that system to the already existing 
rebol tools (rebol.org, view/desktop, ios etc...) would be really 
a big thing

I think proposing a collaborative real time tool for making rebol 
script is a good idea as a leading project to make every one acquiere 
or show high level skills. That's in my opinion more productive than 
having Gurus explaining to stupid morons like me things during weeks 
with no concrete result to it.  Sooooooooooo I propose to KEEP IT 
SIMPLE. Instead of explaining me the solution take half of the time 
you normally use to answer me to edit my script make the changes 
and then ofcourse we can have a nice chat on why you used that and 
not this and that will make my level progress a lot. And most important 
of all the problem and my project will be solved and working.

in an app I tried to build using R2 a single picture took 40MB.  
I need to edit 10000 of them and output them in a picture that take 
about 1GB of space.  saving 10kb... really I could care less.

oops noticed that I mismatched the bug number in the code examples 
of bug#928... I'll edit them.

just had an error in my code, try reloading, I won't edit for a few 
minutes.

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

Henrik, yes... please!  Every edit is saved.

Carl - R3 Chat is not nowhere, no? It was created to be a developer's 
tool too. But - we can make projects-plan.html a wiki page, so we 
can edit it and fill it with detail?

Pekr, I am not sure how the "community" can edit the project plan... 
It is better to simply mention what edits are needed, and we can 
updated it quite rapidly (it's built by a REBOL script.)

If you use the docs wiki, a trusted subset of the community (read: 
no spammers) can edit it.

Current project plan is here: http://www.rebol.com/r3/project-plans.html


Carl expressed his will to adapt the list and its priorities upon 
the needs of community ... I will ask him to wikify it, so that we 
might edit it ...

Carl wikified the project plan - http://rebol.com/r3/docs/project.html


I am now suggesting the following aproach - to create October plan, 
describing R3 beta release. My proposal is to discuss particular 
items here and on chat, but the main channel should be blog. There 
we can post our priority lists. Once agreed, we edit the doc.


So hopefully soon enough, we open the discussion. We might already 
start, but save your comments for the blog. This group is moving 
fast with discussions, maybe we could set-up (temporarily?) an R3 
priorities group, and each of us could post his numberred/bulleted 
list of requested features? It would be then easier for Carl to look, 
or for us to gather ideas and repost them to blog, etc.

What do you think?

I think, that we should go for the R3 priorities, or R3 priority 
group here. We should NOT edit the doc in the wild, unless we discuss 
requests. I think, that the table is also not suited for the small 
bits. If we e.g. want Security to be adressed, we should note  - 
Security - ticket x, y, z

yep.  The moment I can add the page to the wiki I will at least post 
what I have, even if I edit it often, based on everyone's comments.

I only use the IDE for debugging and compilation... I actually do 
all the coding within Ultra-Edit, its just sooooo much better for 
editing.

Graham - if you have sufficient R3 Chat ranking (IIRC 40), you can 
log-in and edit R3 Docs ... authentication database is shared ...

I agree, but its mainly on initial start where it bites you the most. 
 cause when you are doing development, you'll edit the config and 
re-start the server anyways to be sure its ok.  right now its easy 
to miss... and I've lost some time debugging issues which where simply 
caused by the config not having been updated according new options 
or changed resources.

@Doc: 

- I am not totally sure I correctly understand what you mean about 
webapp. I will need to process and try it some more.

- About code loading on on-page-start : yes I know of that, I am 
using it as dev setup so I know latest code is reloaded each pageload. 
I intend to set it on     on-application start when fully in production 
(But I have to admit the server is bgehaving really fast even with 
this setup all along)
- good catch, I will remove one simpauth.r

- I am aware of hosts file, but so far decided to edit the cfg file 
each time I switch ... which is in retrospect getting a little tiresome 
with more and more apps so I should think of  some naming convention 
for getting to all domains local and do it that way yes

- great for multi instance support . I also already ported site-assistant 
to 0919. it was much less work than I thought.. mostly just few things 
like do -> do/global and some 3 other tricks (no really aplication 
level changes were needed)

Now i can edit the test2.r script at will .  Im guessing this is 
still non-blocking?

this would simplify my life a lot.  I will have 4 servers to keep 
in sync and their setup will be mostly the same but their environments 
will be different.


A lot of the information is spread out in differrent tools and things... 
it would be nice if they could all share (loading) a single file 
when they start and I know I have just one "site" administration 
file to edit to contextualize all the configs of all my rebol-based 
tools.

doc, not really.  Thing is I have different computers with different 
OS / HW / Install environments.

but the systmems they are running are the same but under different 
paths or using different ports, domains, and stuff like that.  


since all of this is done via shell, its very tedious to xfer,  manage 
& edit the data properly for a few apps.  I can easily have a single 
configuration file which just stores values, but let all the apps 
use those values in the same setups.

Doc, you should edit this wikipedia article as well 

http://en.wikipedia.org/wiki/Comparison_of_lightweight_web_servers

At present I have to manually edit the httpd.cfg and restart ( maybe 
reloading works ) Cheyenne when I add a new user.

Graham: why do you need to edit httpd.cfg for each user?

You can change that easily if you're running it from a shortcut icon. 
Edit shortcut properties and set the "working folder" where you like 
it to be.

i had to edit config files when a new user joined the company

if i edit the file above while cheyenne is running, it starts to 
work; to-object is found

$ cat jar
# Netscape HTTP Cookie File
# http://curl.haxx.se/rfc/cookie_spec.html
# This file was generated by libcurl! Edit at your own risk.


#HttpOnly_guan-huat     FALSE   /       FALSE   0       RSPSID  MTXVGMVOMYMVGDZKFURKPQKK

Well, yes, but I'm only using a plain text .. so an editor that saves 
the current text regularly.

What I do at present is ... create an empty document on googledocs, 
and save the docid in the database.  I then browse to the doc on 
googledocs, edit it and save it.

I then go back to my rsp page and click on a button that imports 
the document as plain text.

In any case. You could program something with a timer that sends 
the edit field to the server via AJAX, but you'd have to program 
the server as well

About %httpd.cfg file, it will be written down on disk if not present, 
so if you want to avoid that, you need to patch the sources. For 
that, just edit %Cheyenne/misc/conf-parser.r and comment line 69:

        ; write file data

Ah, another important thing for encapping: you need to edit %Cheyenne/encap-paths.r 
and configure the paths to your local SDK folder.

It didn't happen during my mods, it happens when converted from edit 
to view mode every time. And it converts back when you go into edit 
mode (at least visibly).

but that means i edit all over the place, which i think is anti-usage 
for collab editors

I tossed a few up just now. Go ahead and add or edit as needed.

just wondering when we'll get edit access. typo reports are piling 
up.

From R3 chat it sounds like Graham can edit, but I wonder if he means 
the general pages or just the manual.

Anyway I was able to edit this page http://www.rebol.com/r3/docs/functions/read.html

because my r3 chat rating was 50

That's a manual page, so that looks OK. Can you edit a page like 
this one:

http://www.rebol.com/rebol3/

To edit a page, you need a "edit" menu on the page