[IPython-dev] New ipythonqt console questions/feedback

[Brian Granger]

On Wed, Oct 6, 2010 at 1:37 PM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> Thanks for the quick response!  I have a few responses in-line below
> (also a question about the issue tracker), but I also thought of one
> more thing that I was unclear about:
>
> As I understand it, the new 2-process model is in place to decouple
> the console from the execution kernel.  Given this, is there a
> straightforward way to close the ipythonqt terminal (or a standard
> ipython terminal) while leaving the execution kernel operating?  I was
> able to connect to the kernel with a second ipythonqt console, but
> don't see a way to disconnect the first terminal from the execution
> kernel without killing the execution kernel... Or is that conversion
> process for the parallel computing work that you said was still in
> progress? It seems like this is a valuable capability that would
> finally let me get away from using gnu screen whenever I want to be
> able to check in on a python process remotely (a common use-case for
> me)...
>
>
>>> * Is it possible to execute the new-style ipython profiles when
>>> ipythonqt starts?  Looking at the ipythonqt main, it doesn't look to
>>> me like it's in there, but seems potentially pretty straightforward.
>>> This is the most crucial change for me as I have a lot of things that
>>> I want loaded by default (especially "from __future__ import division"
>>> !)
>>
>> Not yet, it's very high on the todo list.  We simply haven't
>> implemented *any* configurability yet, I'm afraid.
>
> Ok, I might take a crack at this if I have a chance - seems pretty
> straightforward.

Erik,

I just wanted to let you know that I am planning on working on this
(the configuration stuff) over the next few weeks.  We implemented a
new configuration system last summer and it needs some updating and
cleanup that I am planning on doing as part of this work.  I will keep
you posted on the progress.

Cheers,

Brian

>>> * If not, is it possible to tie ctrl-D to the exit() function?  I
>>> think a lot of people used to the python terminal expect ctrl-D to be
>>> available to quit the terminal, so it might be a nice option to add
>>> in.  Ideally, it would also just quit, skipping over the yes/no dialog
>>> that exit() triggers with an automatic yes.  I understand, though, if
>>> that is just to be too easy to accidentally do.
>>
>> Well, since the environment is now much more of a multiline editing
>> system, we made the keybindings mimic the Emacs ones, so C-D does
>> character delete.  I imagine it would be possilbe to see if it's at
>> the end of the buffer and trigger exit in that case, but I don't know
>> how easy that will be on the Qt side.
>
> Perhaps come other key combination might be easier (perhaps C-c is the
> next-most-natural choice?) - mainly I just want a single-keystroke way
> of exiting...
>
>>
>> As for confirmation, we definitely want to refine the exit code to
>> allow unconditional exiting.  My take on it is that exit from a close
>> window event should ask (an accidental mis-click can easily happen)
>> but exit from typing explicitly 'exit' should be unconditional (nobody
>> types a full word by accident).
>>
>> Would you mind making a ticket for this?  I think I know roughly how
>> to do it, but I don't have time for it right now.  I made a
>> 'qtconsole' label to apply to these tickets so we can sort them
>> easily.
>
> Done (ticket 161)... Although I can't figure out how to apply the
> "qtconsole" label to an issue - do I have to include it in the text of
> the issue somehow?  Or do I need some sort of elevated access
> privileges?
>
>>
>>> * Unlike the terminal ipython, it seems that command history does not
>>> persist if I close out of ipythonqt and come back in.  Is this
>>> intentional?  I find it to be a highly useful feature...
>>
>> Please file a ticket so we don't forget this one also, it's important
>> and I miss it too.
>
> Done (ticket 162), although see my comment above about some confusion
> with the issue tracker.
>
>
> --
> Erik Tollerud
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com