[RkWard-devel] Send pre-defined block to R console

[Dan Dediu]

Hi, Thomas!

I'll try to get a coherent description of this (from the e-mails) and  
start working on it, as soon as I'll find some time :)

Cheers, Dan


On Tue, 06 Mar 2007 11:15:22 -0000, Thomas Friedrichsmeier  
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:

> On Monday 05 March 2007 11:03, Dan Dediu wrote:
>> > One thing I'm a little concerned about is the number of different
>> > actions we
>> > will need for this. Currently it looks to me, like three different
>> > actions
>> > might be needed:
>> > - Run current contiguous block (current==containing the cursor)
>> > - Run current non-contiguous block (current==color/number/letter of  
>> the
>> > block
>> > containing the cursor, and all other blocks marked up in the same way)
>> > - Run block... (with a dialog popping up, asking what to run)
>>
>> We must also add the actions needed to manage these, like:
>> - define segment;
>> - delete segment/block;
>> - merge segment into block or blocks together;
>> - cut a segment out of a block...
>
> I don't think we need to offer all of this. For advanced editing of  
> regions,
> one can use the icon border. For regular use, define region and delete  
> region
> should be good enough. For define region, I'd suggest the following:
> - This applies to the current selection (rounded to full lines). If  
> nothing is
> selected, a dialog will come up saying "Sorry, nothing selected".
> - If something is selected, a dialog will come up asking:
> "Should this region/segment be part of a non-contiguous region?
>  [X] No region
>  [ ] Region A
>  [ ] Region B
>  [ ] Region C
>  [ ] Region D"
> Delete for a segment that is part of a non-contiguous (named) region  
> would
> open a dialog asking, whether the entire region is to be deleted, or  
> only the
> current segment.
>
>> > Is there a way to trim this down any further? Perhaps the "Run  
>> block..."
>> > action (with the dialog) could be shown automatically, whenever there  
>> are
>> > several block around the current cursor position, and only then.
>>
>> An idea is to allow the user to define the current block and run it by
>> default (given that I don't think that they will switch that much  
>> between
>> current blocks during development), as well as allow her/him to make
>> current the one containing the cursor or to select it at runtime.
>
> OTOH, I think it's fairly reasonable to assume the current block of  
> interest
> will also always contain the cursor. After all, it's probably, where you  
> last
> edited something. Then there would not be much of a need for further  
> actions
> like "set active block", "run active block" (vs. the one with the
> cursor), "run specified block" etc.
>
> Perhaps this can be aided by highlighting the lines. Only the currently  
> active
> region (i.e. the one with the cursor) would be highlighted (and all  
> further
> regions belonging to the same block). Highlighting would be updated  
> whenever
> the cursor moves to a different line.
>
> I guess the highlighting is really something to experiment with, though.  
> I
> suggest you simply try something (or set it aside until later), then we  
> can
> see, whether it's a good solution or not.
>
>> I never used Kate's API, so it'll take a while until I get to a  
>> solution...
>
> Take your time.
>
>> Ok, if nothing happens by Tue, let's have a spec and I'll start working  
>> on
>> it (but it will take a while, as my time is rather limited at the moment
>> :( ).
>
> Well, we don't exactly have a specification, I'd say, but do you think  
> our
> discussion is conclusive enough to base an initial implementation on?
>
> Regards
> Thomas



-- 
Using Opera's e-mail client: http://www.opera.com/mail/