World: r3wp

I could really use a method for slowing down mouse events globally. 
I have a rather complex GUI with about 50 buttons, 2 listviews, fields 
and whatnot. If I accidentally click'n'drag above an empty area of 
the GUI, the interface stops responding for several seconds. I wonder 
how this could be done...

event filtering, or romano's eat function.

does not work anymore with new event handling of 1.3

shouldn't be hard to fix.

Event is still a "drak area" for me ;-)

drak=dark

I have a frustration about the View editor that I don't see in RAMBO. 
 When no text is selected and one hit's ctrl-C, then ctrl-V  it pasts 
the entire document wherever the caret is.  I'm not sure if this 
is supposed to be a feature, but does anyone else find it annoying?

I'm adding it to RAMBO though

The editor code is available at http://www.rebol.com/view/editor.r.
Shouldn't we try to fix this ourselves? The editor has so many bugs 
that should be relatively easy to fix.

Sure, I will try to look at it when I get home

This is not an issue of the editor, but of the way text is copied 
to the clipboard from (at least) an area

I will hunt around for a while, but I'm not sure where the clipboard 
code actually is.

It seems to be the behavior of text editable faces

interesting.... meanwhile, I'm cooking up a replace requester for 
the editor. maybe I'll have something ready by the weekend. (a bit 
busy right now)

The RAMBO ticket is outdated now.   Can anyone point me in the right 
direction as to whether this is just part of VID or something deeper 
than that?

The problem is here:
probe get in ctx-text 'copy-text
func [face][
    if not copy-selected-text face [
        hilight-all face
        copy-selected-text face
    ]
]

And this fixes it:

>> use [body][body: second get in ctx-text 'copy-text remove remove 
body remove back tail body]
== []
>> probe get in ctx-text 'copy-text
func [face][copy-selected-text face]
>> view layout [area "hello"]
>> view layout [field "hello"]

I thought COPY-TEXT might be used by  svv/vid-styles/field/access 
 or  area/access  but it is not (thus, it looks safe).

I think COPY-TEXT is trying to be too smart. I think probably that 
function should not exist. So it might be better to replace calls 
to COPY-TEXT with calls to COPY-SELECTED-TEXT, whose claimed functionality 
is more specific.

Thanks Anton, I'm poking around at all that

I'm not totally sure what this note from vid.r means:

	copy-text: func [face] [

   if not copy-selected-text [ ; copy all if none selected (!!! should 
   be line)
				system/view/highlight-start: face/text
				system/view/highlight-end: tail face/text
				copy-selected-text
			]
		]

Or at least I disagree.  I think the clipboard should be untouched 
if nothing is highlighted

Yeah. it sounds like the programmer didn't know a good user interface.

It's like one of those little cool things: "it'd be cool if it could 
also do this ..."

heh, yeah.  I agree with your solution, although it''s probably better 
to leave a shell of a function just to maintain backwards compatibility 
with scripts that perchance use copy-text

Yes, less changes required.

Scripts really shouldn't be using COPY-TEXT, at least not the "copy 
all" functionality. If that's what they wanted, they would more likely 
be accessing face/text directly or using access/get-face

It looks like the only thing on rebol.org that uses it is Volker's 
spell check style

What does his code use it for, though ? I'd be surprised if he uses 
it for the "copy all" functionality.

Its a patched clone of ctx-text, not my fault ;)

 ; copy all if none selected (!!! should be line

maybe it should not be "copy all", but "copy line with caret"? That 
would make sense, c-c c-v would double the current line.

Did a quick look through google, but only saw one thing.  I have 
not looked at RebGUI, but I assume Ashley has written his own copy-text 
functionality.

My preference would still be that it would not copy anything if nothing 
is selected.   I don't know what sort of behavior people would naturally 
expect from a text editor

I think the major annoyance is that it can't be undone....

Volker, aha not your fault !  Don't agree about copying the current 
line. It may look handy, but I still think if you want to copy the 
line, you should select the line first.   

Henrik, you mean undo as in the system clipboard should be able to 
go back to an older state ?

Or just that, since the system clipboard currently has no history, 
copying all text overwrites the clipboard too easily ?

anton, I just meant a plain undo in the editor to avoid destroying 
your text file, by accidental pasting.

I submitted a new ticket.   What are some of the other annoyances 
/ grievances people have with editor? or requested features?  I would 
like to join Henrik in fixing some of them.

it might not be a bug in the editor, but try to load a large file, 
and select text with the mouse. you can't push the text scrolling 
down, if you go beyond the upper or lower window edge

scrollling down or up

I think one of the French (Dide ?) made an AREA style with that functionality.

a simple line counter would be nice too

Didier Cadieu did make a nice area style.  It's available on the 
rebol.org site.  A year ago, I made some modifications to an earlier 
version of it, but I don't remember what I changed

Do you think editor should always start up with the last open file 
 (i.e. hit ctrl-E on desktop, open a file, close the editor, then 
hit ctrl-E again)

I would lean towards having it start blank each time

I don't think that behaviour should change...

Why do you think so?   My natural reaction is to expect something 
blank, or at least not have to close a file that I don't want open. 
  While you don't "close" a document in editor, I have to sit and 
think, "is this something that I want to be open right now or not?" 
   I find it disruptive from a UI standpoint

well, I always start the editor from the console, where I can type 
in a file name, a string, NONE or something else. that way I get 
always what I expect. :-)

I am strictly speaking of behavior using ctrl-E from the view desktop

haven't studied how that works...

Sorry, I wasn't clear from the start