World: r3wp

I thought of this little idea regarding the editor: Currently, it's 
depending on running a script from file, if you want to test something. 
But I was wondering if it were possible to edit data directly with 
it and just store it in memory?


Sometimes I like to debug a function without having to save it to 
a file and then run a program stored in a different file to run the 
test, e.g. Ctrl-E is useless.


It would be nice to directly in the editor, create a big function, 
say from a paste and do a few edits, press Ctrl-<something> and have 
that evaluated directly. Then you could quit the editor and use the 
function directly in the console without having to save any files.


Also if you want to re-edit the function, type in something similar 
to:


editor 'my-big-function and the editor would pop up with the function 
source and the word its bound to.

why not using a scratch-file?

!> scratch: does[editor %scratch.r]

Cal Dixon's REM (editor for Core) can be started with /function refirement 
which does exactly what you said.

scratch: func[:value][save/header %scratch.r :value [] editor %scratch.r]

missed "and use the function directly in the console"

volker, it forgets the function as soon as I return to the console

one moment

ah :-)

scratch: func['value][
 save/header %console-scratch.r either word? :value[
  reduce[to-set-word :value get value]
 ][
  :value
 ][Title: "Console-scratch"]
 launch: func[file /secure-cmd][do file]
 editor %console-scratch.r    
]
halt

^e ^q and you are back to console

I see... works ok :-) I'll see if it turns out useful, thanks

;since nobody is perfect:
scratch: func['value][
 save/header %console-scratch.r either word? :value[
  reduce[to-set-word :value get value]
 ][
  :value
 ][Title: "Console-scratch"]
 launch: func[file /secure-cmd /local err][
  if error? set/any 'err try[do file][unview/all err]
 ]
 editor %console-scratch.r    
]
scratchme: func[][]
scratch scratchme

(error->closes window)

hmm... and to get this function available at startup? I remember 
a user.r file somewhere...

desktop http://polly.rebol.it/test/test/view-root/floor.r
the right-click on view-root/user.r

thanks

scratch without args reopens editor. To get back after error. http://polly.rebol.it/test/test/scratch-editor.r

This is pretty cool! I added do-events at the end of the scratch 
script.


Now I'm running a GUI program, and I can exit to the console though 
a "halt" button in the GUI. I 'SCRATCH the function I need and CTRL-E 
the changes and I can continue working with the GUI program with 
the new changes without quitting the editor. :-)

Anyone remind me why there is no binary support within the clipboard?

There is not!
(Is this a sufficient reason for you ;-)

could it be a compatibility issue? I'm not sure if binaries are supported 
in the XFree86 clipboard

WHy not saving as strings? with binaries you need type-information 
too i guess.

what I want to is right click on an image, copy to clipboard, and 
then paste it into a rebol application.

Yes, that would be nice.

Is there a way with an external app? save clipboard to file?

some apps support it... Directory Opus can paste an image directly 
to a file

depending on app you can also paste the filename/url instead? as 
workaround? But image-clipboard and drag/drop ae so comfortable.

paste .. I guess I mean that the rebol application would then read 
it from the clipboard

I am currently pasting urls in .. but I was hoping for a better solution.

So, is the lack of binary support a cross platform implementation 
issue rather than a technical one in windows ?

Cross platform I guess.

My guess as well. I have some win-clip stuff for images. Nothing 
fancy, but might save you a little effort. Let me know if you're 
interested.

sure ... I thought you had, but I think it was on another world.

load-thru/update http://www.lexicon.net/antonr/rebol/gui/scroll-panel.r

load-thru/update http://www.lexicon.net/antonr/rebol/gui/demo-scroll-panel.r

(bug fixes)

what is it exactly that 'WITH does in LAYOUT? I can assign variables 
to face data, but apparently not face data to variables... I'd like 
to bind the state of a toggle to an external variable in a toggle

oops... erase the "in a toggle" at the end

ok, it seems to be possible with text, using the first option, but 
not state:

f: "REBOL"

view layout [field with [text: f]] ; displays field with "REBOL" 
in it. If I edit the field, the contents of f is changed

g: true

view layout [toggle with [data: state: g]] ; displays a toggle that 
is set true. If I click it to false, the contents of g is _not_ changed

oh... it's because text is bound to a string, where you can't bind 
to TRUE and FALSE...

nitpicking: referenced, not bound :) 'with is simply a make of the 
face, before anything else.

grargh! this reminds me of Niels Bohr's statement on understanding 
quantum mechanics... I guess this can be applied to REBOL as well

:-)

You're dealing with objects. A face is an object. The WITH block 
assign values to the attributes within the object, or extend the 
object with new attributes. Just like:
o1: make object! [a: 0]

o2: make o1 [a: 1 b: 2]	; the attribute a gets the value 1, and a 
new attribute b is created and gets the value 2.


Some data types in REBOL are references, when used in objects, some 
are not. (Remember that data types are grouped as scalars, series, 
etc.)

If you wanna export some face attributes outside, you could do that 
with the action attribute (the action block following many styles 
in VID for example) or in the feel functions.
a: false
view layout [toggle [a: face/data]]

This will change a according to the state of the toggle.

that's also the solution I found...

Then you're not lost at all! It's not as complicated as quantum mechanics! 
;-)

it _would_ have been nice to be able to do the other thing, but the 
code is almost as streamlined as I wanted it to be now. I guess I 
need to study more on datatypes...

The data types in REBOL are one major cornerstone and reason, why 
so much functionality can be written with such little code.
(As I see it.)

Maybe new release is near :-) I just noticed there is few of nice 
bugfixes with comment like: Fixed in Core/SDK 2.6.2 and View 1.3.2 
....

I mean - rambo entries ...