[pyKDE] Eric3: Improving the shell.

[Detlev Offenbach]

Am Freitag 30 September 2005 23:59 schrieb Joshua Gilbert:
> I gave it a go at writing the code myself, but I got lost, I can't
> find where the event is actually handled. To trace execution I'm
> running eric.py (eric-snapshot-20050917) in eric (Debian testing).
>
>  Anyway, here are my points.
>
>  * Replace it with IPython?
> IPython rocks. Awesome shell, very interactive and it provides a bunch
> of profiles that can be very handy. http://ipython.scipy.org/

That will not happen because eric3 uses the debug client as it's shell. That 
means, that the eric3 shell is actually two shells, one for Python and one 
for Ruby. The shell window is simply a frontend.

>
>  * Can't paste more than one line
> Shame. Makes things harder than they should be

That will be in the next snapshot. Same for dropping multiple lines onto the 
shell.

>
>  * Can't select with shift+<arrow keys>
> Annoying. Eric just moves over without selecting anything.

That will be in the next snapshot.

>
>  * Middle click paste or typing should move focus to the current prompt
> Instead of just overwriting the history. I don't mean the actual
> history, I mean what's visible in the shell.

That will be in the next snapshot.

>
>  * Ctrl-c should kill the current line Instead it does nothing.

Ctrl-C is the copy action by default. Ctrl-U kills the current line.

>
> * Can't alter values in the code that's currently running.    test.py:
>  -----------------------------------
>  h = 5
>  print 'break here'
>  -----------------------------------
>  Now fire up eric, run the debugger and break at the second line. Try
>
> this in the shell:
>  >>> h
>
>  5
>
>  >>> h = 6
>  >>> h
>
>  6

Everything entered in the shell while debugging is executed in the current 
context. That means your a.m. statement actually changed the variable h. If 
you add an additional line after your break statement and perform a Step 
after your shell actions, you will see the changed value in the variables 
viewer.

>
>  * <arrow button up> doesn't match partials like my readline settings say
> to. So eric doesn't use readline. Already knew that. But still, the
>
> functionality is staggeringly useful. Use case:
>  >>> [x / 2.0 for x in range(10) if x % 2 == 0]
>
>  [0.0, 1.0, 2.0, 3.0, 4.0]
>
>  >>> h
>
>  6
>
>  >>> [<up arrow>
>
>  results in
>
>  >>> h
>
>  That's frustrating. Yes, this case was simple. In real usage I have
> lots in my history. Being able to search over some subset rather than
> the whole history makes things a lot faster. Especially when you're
> repeating some long sequence of actions to get some code to work
> right. Yes, you could define a function, but that requires that you
> expect it to not work. Also doesn't help when you're dealing with long
> obscure lines that you just need to change a little bit.

That will be in the next snapshot.

>
>  Again, I'm willing to help implement these features and fixes. But I
> need help, I don't see how to hack the shell code yet. A standalone
> version of the shell  would be very useful (an app with only the
> shell) as it would cut down on the depth and breadth of the problem. I
> tried, but I'm not familiar enough with pykde and friends to get it
> done.
>
>
> Thank you,
> Josh.

Regards,
Detlev
-- 
Detlev Offenbach
detlev at die-offenbachs.de