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

[Dan Dediu]

On Sun, 04 Mar 2007 15:25:25 -0000, Thomas Friedrichsmeier  
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:

> Hi Dan,
>
> On Friday 02 March 2007 22:20, Dan Dediu wrote:
>> Maybe even having 4? different "<" and ">" symbols (colors? numbers?  
>> small
>> letters) so that you can define more such "run blocks", each composed of
>> 1+ "run segments". When clicking the "send block to R..." button, you  
>> can
>> also select which color/number/letter to actually run or, by default,  
>> let
>> the IDE send the one block containing the caret. Again, the "send block  
>> to
>> R..." button sends the entire block (i.e. all its "run segments") to  
>> the R
>> console, concatenated.
>
> Having several different "<" and ">" symbols may be a good idea.  
> However, then
> even more than with my suggestion, we need to limit the number of  
> available
> symbols, as we'll need 2*(number of allowed sets) of them. Color coding  
> the
> symbols is probably a good idea, but we should also add a small number or
> letter, so make sure they are also differentiable for color-vision  
> impaired
> people.

You're right.

>
> 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...

>
> 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.

>
> Pretty difficult to tell what is best. Currently I feel the solution I
> suggested on Friday may still be a better option, but maybe you'd have to
> actually give one solution or the other a try, to see, how it works out  
> in
> practice.
>
>> Also, it would be good if the "run segments" are somehow highlighted
>> (color? - somehow reflecting the color/number/letter of the "run block")
>> so that it is easy to identify them. This way it would be easier to
>> identify the various "run segments" at a glance, as well...
>
> I suppose this should be possible by using "reserved" marks, without a  
> symbol,
> and not directly settable by the user. Somehow these can get different
> background colors (like e.g. a breakpoint in kdevelop will give the line  
> a
> pink background), but I'm not sure, how to set those colors.
>
> This would mean automatically marking all lines inside a block, anytime a
> block-symbol is added/removed, and anytime a line is added/removed (the
> editLineInserted/Removed() signals from KateDocument can probably be  
> used for
> this).

I never used Kate's API, so it'll take a while until I get to a solution...

>
>> > I think we do agree the feature is worth having. Let's think about the
>> > specs
>> > for another short while, to see if we can come up with a real nice
>> > solution.
>> > After that, if you'd like to give the implementation a shot, that  
>> would
>> > be
>> > very much appreciated!
>>
>> Let's see what happens :)
>
> Ok, I suggest the following plan: If there is no further feedback on this
> issue by Tuesday (or whenever you have time to work on it), start
> implementing something, according to which you feel is the best option
> discussed so far. When you're done, we'll try to get some testing on  
> this,
> and see, whether it can be refined any further.

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  
:( ).

>
> Regards
> Thomas

Cheers, Dan



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