From vivian at vdesmedt.com  Sun Oct  2 12:25:31 2005
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 02 Oct 2005 18:25:31 +0200
Subject: [IPython-dev] smart indent,
 multiline statement history and multiline statement edition
Message-ID: <434009FB.4020205@vdesmedt.com>

Fernando,

I suppose you didn't had the time to have look at the patch I submit 
that according to me at least improve the usability of the python 
debugger in the spirit of IPython but it is not for that that I write 
this mail.

In my quest to contribute I would like to improve IPython in two areas:
 - copy and paste
 - multiline edition

1.) By improving IPython for copy and paste I mean try to find a way to 
paste multiline statement when autoindent is on.
What I had in mind is the following:

Since autoindent is pretty enough to propose you identation each time 
you could need one or to say it differently when autoindent is on the 
tab touch is unnecessary I propose a smartindent mode (which could just 
the autoindent mode if you like it).

In that mode the autoindent proposition of leading space is forgotten if 
the first character of a line is a space or a tabulation.

In such mode autoindentation is working more or less the same way as 
before but if you copy a bunch of code from elsewhere it will be paste 
with the original indentation.

Let me know what you think about this proposition, if you did try such 
aproach in the paste and if so what was the techincal difficulties you 
faced (I guess here the various implementation of readline will play 
they role and I will have to test my patch against each of them before 
submision).

2.) I would like to improve multiline support. I have various ideas some 
modest some more ambitious.

The first is just about the history of the command. Now when you type a 
multiline statement each line of the statement is a separate entry in 
the command history.

def foo(bar):
    bar += 3
    return bar * 2

However the chance that you are interested by the line "    return bar * 
2" by itself is not big.

My proposition was that only the first "def foo(bar)" was visible in the 
command history and that when you choose it (hit return) the next one 
("    bar += 3", "    return bar * 2") appear in the forward part of the 
history such that you can quickly review a multiline statement.

Here is a small scenario illustration the usage of my proposition:

def foo(bar):
    bar += 3
    return bar * 2

[up-arrow]
edit the first line of the multiline statement
[return]
[down-arrow]
edit the second  line of the multiline statement
[return]
[down-arrow]
edit the third line of the multiline statement
[return]

Let me know if it is clear, if you like it, if you think it could be 
usefull if you think it is feasible.

Vivian.



From hans_meine at gmx.net  Mon Oct  3 09:00:32 2005
From: hans_meine at gmx.net (Hans Meine)
Date: Mon, 3 Oct 2005 15:00:32 +0200
Subject: [IPython-dev] smart indent, multiline statement history and
	multiline statement edition
In-Reply-To: <434009FB.4020205@vdesmedt.com>
References: <434009FB.4020205@vdesmedt.com>
Message-ID: <200510031500.42197.hans_meine@gmx.net>

On Sunday 02 October 2005 18:25, Vivian De Smedt wrote:
> Since autoindent is pretty enough to propose you identation each time
> you could need one or to say it differently when autoindent is on the
> tab touch is unnecessary I propose a smartindent mode (which could just
> the autoindent mode if you like it).
>
> In that mode the autoindent proposition of leading space is forgotten if
> the first character of a line is a space or a tabulation.
Nice idea indeed.

I wonder what we can do about another use case which I stumble over 
repeatedly:

Usually, I like tabs in my code files.  However, when cut&pasting from 
(X)Emacs into IPython, readline interprets the <tab>s as completion requests.  

AFAICS, a smart indent mode could help: It could simply interpret tabs at the 
beginning of the line different from tabs after some non-whitespace 
characters!?  (/me hopes that readline does not make this too difficult)

I am very much looking forward to such a thing indeed! :-)

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051003/96b5ff47/attachment.sig>

From vivian at vdesmedt.com  Tue Oct  4 12:20:02 2005
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 04 Oct 2005 18:20:02 +0200
Subject: [IPython-dev] smart indent, multiline statement history and
	multiline statement edition
Message-ID: <4342ABB2.8010205@vdesmedt.com>

Hans,

I understood your concern and suggestion. I did not yet dive  into the 
implementation of the solution but it seems that the difficulty of my 
proposition and your improvement is equivalent. When I'll start I'll try 
to do both.

I'm a windows user and can do test with the readline implementation for 
windows and the one of cygwin.

I'll be glad if you could test my patches for the Linux platform.

Vivian.



From Fernando.Perez at colorado.edu  Fri Oct  7 21:34:19 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 07 Oct 2005 19:34:19 -0600
Subject: [IPython-dev] I haven't forgotten...
Message-ID: <4347221B.9090006@colorado.edu>

Hi everyone,

(and in particular Vivian, Jorgen, Ville and others with patches in waiting)

this is just to explain a little why I've seemingly abandoned all contact when 
users are actually contributing serious patches.  First, a big apology, but it 
has simply been a matter of fitting things into 24 hour days.

A lot of 'real work', compounded with a very significant change in the SciPy 
project, has simply swamped me.  For those who don't follow that list, the 
core of that project is seeing major changes thanks to the efforts of a few 
committed developers, including our own Robert Kern.  What little 'open source 
time' I've had in the past few weeks has gone to Scipy, since right now the 
changes taking place there are fairly critical.  There was also the Scipy'05 
conference, for which we had two IPython talks which took time in various ways 
(though Robert presented one of them).

Finally, an extensive home renovation process has taken every remaining minute 
of my time (if you ever think of a time budget for home renovations, multiply 
it by 10 and you might be getting somewhere realistic...)

Things are settling back, though, and I've started to slowly grind away again. 
  I've updated the site with the slides for the Scipy'05 talks along with a 
few new links to ipython-related projects.

I will slowly work back up the queue, I promise.  I realize that you've all 
put time and effort into your contributions, and I certainly value them.  So 
please bear with me a little longer as I catch my breath and try to recover 
some momentum.  Thanks to new developer blood we are actually making deep 
changes now to ipython (in the chainsaw and notebook branches), and I'm very 
optimistic about ipython's future as something that will offer much more than 
just a hacked-up shell.

Best regards,

Fernando.



From bialix at ukr.net  Mon Oct 10 07:52:49 2005
From: bialix at ukr.net (Alexander Belchenko)
Date: Mon, 10 Oct 2005 14:52:49 +0300
Subject: [IPython-dev] [PATCH] make dump_pager more smart (on Windows)
Message-ID: <434A5611.9030602@ukr.net>

Attached patch provide clearing prompt "---Return to continue, q to
quit--- " after hitting the key so this prompt don't mix with printed text.

This solution intended for Windows users,
but I think for Linux can be done similar thing (instead of
msvcrt.getch() should be used more sophisticated read method from terminal).

BTW, on Windows 2K/XP also colud be used 'more' pager but only when
nocolor scheme used (because 'more' does not handle coloring escape
sequences).
May be it worth to put remark about this in hints?

Alexander.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: page_more.diff
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051010/14ca51b1/attachment.ksh>

From Fernando.Perez at colorado.edu  Mon Oct 10 14:33:10 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 10 Oct 2005 12:33:10 -0600
Subject: [IPython-dev] [PATCH] make dump_pager more smart (on Windows)
In-Reply-To: <434A5611.9030602@ukr.net>
References: <434A5611.9030602@ukr.net>
Message-ID: <434AB3E6.2060701@colorado.edu>

Alexander Belchenko wrote:
> Attached patch provide clearing prompt "---Return to continue, q to
> quit--- " after hitting the key so this prompt don't mix with printed text.

Thanks, this one looks like a no-brainer to me.  Any caveats from our win32 
experts, since I can't actually test it?  It looks pretty harmles on the 
surface...

> This solution intended for Windows users,
> but I think for Linux can be done similar thing (instead of
> msvcrt.getch() should be used more sophisticated read method from terminal).

*nix always has real, full featured pagers available, so there's no need for 
more.  The page_dumb routine is only there to try to work around the 
limitations of the Windows default environment.

> BTW, on Windows 2K/XP also colud be used 'more' pager but only when
> nocolor scheme used (because 'more' does not handle coloring escape
> sequences).
> May be it worth to put remark about this in hints?

If windows users want a real pager, I imagine they'd be better off using the 
cygwin toolkit, no?  That comes with the full-featured *nix console tools, 
which don't have all the limitations of the default windows ones.  At least 
that's been my understading from third-party information, perhaps I'm mistaken.

Regards,

f



From bialix at ukr.net  Mon Oct 10 17:38:29 2005
From: bialix at ukr.net (Alexander Belchenko)
Date: Tue, 11 Oct 2005 00:38:29 +0300
Subject: [IPython-dev] [PATCH] make dump_pager more smart (on Windows):
	rev.2
In-Reply-To: <434AB3E6.2060701@colorado.edu>
References: <434A5611.9030602@ukr.net> <434AB3E6.2060701@colorado.edu>
Message-ID: <434ADF55.7050807@ukr.net>

Fernando Perez wrote:
>>Attached patch provide clearing prompt "---Return to continue, q to
>>quit--- " after hitting the key so this prompt don't mix with printed text.
> 
> Thanks, this one looks like a no-brainer to me.  Any caveats from our win32 
> experts, since I can't actually test it?  It looks pretty harmles on the 
> surface...

My first patch have the bug (that masked if after paging prompt blank 
line is printed): every comma in print worth one space. As result next 
line is have extra (wrong) spaces at start. I fix this by using 
Term.cout.write() method instead of print statement.

In addition I try to create seamless coloring when page_dumb() is used. 
Problem appears because prompt between pages break coloring, and after 
prompt tail of long string or docstring is not colored. For avoiding 
this behaviour I store last escape sequence in variable last_escape and 
add this one to the start of next portion of lines. On Windows it works 
correct.

Use attached patch instead of my first one.

Alexander
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: page_more.diff
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051011/b24996f0/attachment.ksh>

From bialix at ukr.net  Tue Oct 11 17:30:32 2005
From: bialix at ukr.net (Alexander Belchenko)
Date: Wed, 12 Oct 2005 00:30:32 +0300
Subject: [IPython-dev] [PATCH] Further improvements of paging system
	(Windows-specific)
Message-ID: <dihaoc$pcp$1@sea.gmane.org>

  Another improvements of paging system (on Windows):
  - function get_console_size for Windows console
    returns size of current console as (sizex,sizey)
  - with function get_console_size() page_dumb can fit
    each page exactly on one full screen.

Added module winconsole.py with special function get_console_size(). 
This module needed only for Windows. Function get_console_size works 
only if ctypes installed. Otherwise it returns default values for size 
of console (80, 25).

In addition with my previous patch to page_dumb it makes dumb pager is 
not so dumb ;-)

Alexander.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: winconsole.diff
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051012/aab88f0b/attachment.ksh>

From Fernando.Perez at colorado.edu  Sat Oct 15 04:03:09 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Sat, 15 Oct 2005 02:03:09 -0600
Subject: [IPython-dev] wildcard-patch
In-Reply-To: <433C4EB3.60803@bostream.nu>
References: <43384403.6070505@bostream.nu>
	<200509271005.57986.hans_meine@gmx.net> <433C4EB3.60803@bostream.nu>
Message-ID: <4350B7BD.9080103@colorado.edu>

J?rgen Stenarson wrote:
> Hans Meine wrote:
> ...
> 
>>>usage:
>>>?PATTERN [OBJECT TYPE] [-NAMSPACE]+ [+NAMESPACE]+ [-a] [-c]
>>
>>If you put this into the docs somewhere, I would change [...]+ to [...]* to 
>>make it match the regular expression syntax.  Otherwise, one could read it as 
>>"at least one specification" which is probably not what you mean. :-)
>>
>>And BTW: One "E" is missing, but I guess that's just a typo in your mail.
>>
> 
> 
> I have improved the docstrings taking Hans's suggestions into account. 
> However I don't feel comfortable editing the manual since I don't have 
> lyx installed.

OK, as promised, I'm trying to (slowly) catch up with my horrid ipython 
backlog.  I've committed your patches for this,  with minor edits for 
readability.  I have yet to add this to the manual, but I'm going to sleep now.

Many thanks for this contribution, I think it's a great feature.  I've tested 
it a bit, but as with all new things,  anyone following SVN please report any 
problems.

Jorgen, only one thing: in the future, please never mix tabs and spaces in 
code.  Here are some simple developer guidelines for ipython:

http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines

Since I waited for so long on this one on you, I didn't want to ask you to 
resend the patches, but for the future, please use spaces only.  Mixing tabs 
and spaces in code is a recipe for disaster, and the rest of ipython already 
uses spaces.  I made the mistake of running untabify on the patch _before_ 
applying it, which mis-expanded the tabs, and I only noticed the problem after 
  lots of manual edits, so I essentially had to reindent the whole thing line 
by line, reading the original patch in parallel to make sure I didn't screw up.


Again, sorry for the long delay and many thanks for doing this work.  A very 
nice improvement, which I'll certainly use quite a bit.

Best,

f



From Fernando.Perez at colorado.edu  Tue Oct 18 16:53:10 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 18 Oct 2005 14:53:10 -0600
Subject: [IPython-dev] [Fwd: [issue42] win32 speaker beep option]
Message-ID: <435560B6.5060708@colorado.edu>

Anyone who can help me with this one?  Is there a way to disable beeping under 
win32?

Any advice will be very appreciated.

Cheers,

f

-------- Original Message --------
Subject: [issue42] win32 speaker beep option
Date: Tue, 18 Oct 2005 19:49:23 +0000
From: Gigi Kent <ipython_issue_tracker at scipy.org>
Reply-To: iPython Roundup issue tracker <ipython_issue_tracker at scipy.org>
To: fperez at colorado.edu


New submission from Gigi Kent <ipython.abcx at spamgourmet.com>:

I have Windows XP (normal, not CygWin) and the latest
version of IPython on Python 2.4.2. IPython beeps when some
actions are done (like pressing Tab with no possible
auto-completion). This is SUPER ANNOYING since it happens a
lot. Please add an option to disable it.

There are some (unofficial) options to disable the PC
speaker in Windows. I have enabled them but apparently they
don't work for all applications.


----------
assignedto: fperez
messages: 142
nosy: fperez, gigi
priority: feature
status: unread
title: win32 speaker beep option
_______________________________________________________________
iPython Roundup issue tracker <ipython_issue_tracker at scipy.org>
http://www.scipy.net/roundup/ipython/issue42
_______________________________________________________________



From Fernando.Perez at colorado.edu  Wed Oct 19 03:38:13 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 19 Oct 2005 01:38:13 -0600
Subject: [IPython-dev] [IPython-user] [Fwd: [issue42] win32 speaker beep
	option]
In-Reply-To: <4355F6E0.3000700@brainbot.com>
References: <435560B6.5060708@colorado.edu> <4355F6E0.3000700@brainbot.com>
Message-ID: <4355F7E5.4030701@colorado.edu>

Ralf Schmitt wrote:
> Fernando Perez wrote:
> 
>>Anyone who can help me with this one?  Is there a way to disable beeping under 
>>win32?
> 
> 
> well, he get's what he deserves for using windows :)

My opinions on win32 are relatively well known here, so I won't comment 
further :)  I still try to provide the best I can for users of the platform, 
many who use it against their will due to work constraints.

> from readline.Console import Console
> Console.bell = lambda *args: None

Many thanks for the info.  I'll pass it on to the issue tracker.

Cheers,

f



From jorgen.stenarson at bostream.nu  Wed Oct 26 16:46:22 2005
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 26 Oct 2005 22:46:22 +0200
Subject: [IPython-dev] Bug when launching dos commands
Message-ID: <435FEB1E.5020507@bostream.nu>

Hi,

I have found a problem with running dos commands (like dir) when my 
current directory is on a network share (UNC-path(I'm not sure what UNC 
means but cmd.exe complains about it)). The cmd.exe can not use UNC 
paths (paths beginning with \\). What happens is that the cmd.exe can 
not switch to the UNC address and instead ends up on some default 
directory on c:/, which means the command you issued will be performed 
in some other directory than you thought. Could be bad if your doing 
"del *.*"


So my workaround patches the shell command in genutils to temporarily 
switch the current directory to c: and then appending "pushd unc-path&&"
to the commandline string that is passed to os.system, and finally 
switch the work dir back to the unc-path. This is done if the os is 
windows and the workdir starts with \\

This works because "pushd UNC-path" mounts a network drive and then your 
path just becomes x:\.... and is thus not a UNC-path anymore.


This seems to work for me. But I'm not sure if this is the right place 
or the only place that need to change.

/J?rgen
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cmd_patch.txt
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20051026/ca65260b/attachment.txt>

From hans_meine at gmx.net  Thu Oct 27 09:16:52 2005
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 27 Oct 2005 15:16:52 +0200
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
Message-ID: <200510271516.53258.hans_meine@gmx.net>

Hi!

As I mentioned before, I am using IPython (on Linux) now instead of our 
home-brewn-Qt-based interactive Python shell.  Now my collegue (who 
originally wrote our "PyTerm") is unhappy with this situation (that he has to 
maintain a graphical shell just for his own personal use), but he says that 
IPython is "unusable under Windows because it does not really support 
copy&paste" since it's running in a DOS box.

I am not very familiar with Windows, Cygwin, DOS boxes or the like, but I 
guess if you are using IPython under Windows, you will probably have found a 
way to copy and paste, too?

I am looking forward to your responses,
  Greetings, Hans



From Fernando.Perez at colorado.edu  Thu Oct 27 13:56:32 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 27 Oct 2005 11:56:32 -0600
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
In-Reply-To: <200510271516.53258.hans_meine@gmx.net>
References: <200510271516.53258.hans_meine@gmx.net>
Message-ID: <436114D0.4070608@colorado.edu>

Hans Meine wrote:
> Hi!
> 
> As I mentioned before, I am using IPython (on Linux) now instead of our 
> home-brewn-Qt-based interactive Python shell.  Now my collegue (who 
> originally wrote our "PyTerm") is unhappy with this situation (that he has to 
> maintain a graphical shell just for his own personal use), but he says that 
> IPython is "unusable under Windows because it does not really support 
> copy&paste" since it's running in a DOS box.
> 
> I am not very familiar with Windows, Cygwin, DOS boxes or the like, but I 
> guess if you are using IPython under Windows, you will probably have found a 
> way to copy and paste, too?
> 
> I am looking forward to your responses,

Well, I just started using windows again a little bit this weekend, so I'm 
hardly what you could call an expert, and I intend to use it as little as I 
absolutely have to.  For the project I need windows, my plan is to develop 
under linux, and reboot under win32 only to validate that the code runs.  I 
simply can't work under windows efficiently, it's just beyond me.

But I saw that the 'terminal' that windows uses has a preferences panel with a 
'Quick Edit' checkbox.  Checking that provides some basic copy/paste 
abilities, though they seem to be restricted to the mouse.  I'm at the office 
now (no windows), but I can check again tonight at home (where the windows 
computer is) if you want further details or experiments.

If your friend wants the ability to highlight text with the cursor and 
copy/paste without the mouse, I'm not quite sure how that can be done.  In 
particular, the 'copy' shortcut is Ctrl-C, which triggers a KeyboardInterrupt 
exception under Windows.  How would one get around that?

Regards,

f



From Fernando.Perez at colorado.edu  Thu Oct 27 14:22:35 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 27 Oct 2005 12:22:35 -0600
Subject: [IPython-dev] Bug when launching dos commands
In-Reply-To: <435FEB1E.5020507@bostream.nu>
References: <435FEB1E.5020507@bostream.nu>
Message-ID: <43611AEB.2070102@colorado.edu>

J?rgen Stenarson wrote:
> Hi,
> 
> I have found a problem with running dos commands (like dir) when my 
> current directory is on a network share (UNC-path(I'm not sure what UNC 
> means but cmd.exe complains about it)). The cmd.exe can not use UNC 
> paths (paths beginning with \\). What happens is that the cmd.exe can 
> not switch to the UNC address and instead ends up on some default 
> directory on c:/, which means the command you issued will be performed 
> in some other directory than you thought. Could be bad if your doing 
> "del *.*"
> 
> 
> So my workaround patches the shell command in genutils to temporarily 
> switch the current directory to c: and then appending "pushd unc-path&&"
> to the commandline string that is passed to os.system, and finally 
> switch the work dir back to the unc-path. This is done if the os is 
> windows and the workdir starts with \\
> 
> This works because "pushd UNC-path" mounts a network drive and then your 
> path just becomes x:\.... and is thus not a UNC-path anymore.
> 
> 
> This seems to work for me. But I'm not sure if this is the right place 
> or the only place that need to change.

I could certainly use the voice of another win32 expert on helping me evaluate 
this.  Even though I have a windows box now, I have no network shares to even 
test this on, and I don't even know really what  the details are.  I trust 
that you tested it, but I'm a bit worried about applying a patch I don't 
understand at all.

At the very least, please keep on testing it for a few days before we apply 
it, and if any win32 user can comment on whether what Jorgen did is right or 
not, it would be much appreciated.

Cheers,

f

ps - no tabs in that patch, right ? ;)



From vivainio at gmail.com  Thu Oct 27 17:06:52 2005
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 27 Oct 2005 14:06:52 -0700
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
In-Reply-To: <436114D0.4070608@colorado.edu>
References: <200510271516.53258.hans_meine@gmx.net>
	<436114D0.4070608@colorado.edu>
Message-ID: <46cb515a0510271406q724e5553gbcb3002e6589ba58@mail.gmail.com>

> But I saw that the 'terminal' that windows uses has a preferences panel with a
> 'Quick Edit' checkbox.  Checking that provides some basic copy/paste
> abilities, though they seem to be restricted to the mouse.  I'm at the office

I think you don't even need the quick edit checked to copy/paste with
mouse. Just paint with mouse (caution - it freezes the window for the
duration of the operation), press enter to "copy" ang right-click to
paste.

Windows has craploads of problems, but copy-pasting isn't one of them.

--
Ville Vainio    http://tinyurl.com/2prnb



From Fernando.Perez at colorado.edu  Thu Oct 27 17:40:32 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 27 Oct 2005 15:40:32 -0600
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
In-Reply-To: <46cb515a0510271406q724e5553gbcb3002e6589ba58@mail.gmail.com>
References: <200510271516.53258.hans_meine@gmx.net>
	<436114D0.4070608@colorado.edu>
	<46cb515a0510271406q724e5553gbcb3002e6589ba58@mail.gmail.com>
Message-ID: <43614950.405@colorado.edu>

Ville Vainio wrote:
>>But I saw that the 'terminal' that windows uses has a preferences panel with a
>>'Quick Edit' checkbox.  Checking that provides some basic copy/paste
>>abilities, though they seem to be restricted to the mouse.  I'm at the office
> 
> 
> I think you don't even need the quick edit checked to copy/paste with
> mouse. Just paint with mouse (caution - it freezes the window for the
> duration of the operation), press enter to "copy" ang right-click to
> paste.

So what does the 'quick edit' thing do?  Just curious...

> Windows has craploads of problems, but copy-pasting isn't one of them.

Yes, that seemed to work for me, but it seems Hans' friend had further 
complains, so it would be good to know what they were.  I get the feeling that 
  in win32, the terminal copy/paste doesn't recognize the end of text lines, 
it's just a 'rectangle paint'.  Typically rich text widgets know how to 
highlight only text, and perhaps that's important to Hans' friend.

Anyway Hans, you'll need to let us know whether the solutions outlined so far 
are satisfactory to you or not.  Thanks to those who pitched in.

Cheers,

f



From hans_meine at gmx.net  Fri Oct 28 08:55:01 2005
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 28 Oct 2005 14:55:01 +0200
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
In-Reply-To: <43614950.405@colorado.edu>
References: <200510271516.53258.hans_meine@gmx.net>
	<46cb515a0510271406q724e5553gbcb3002e6589ba58@mail.gmail.com>
	<43614950.405@colorado.edu>
Message-ID: <200510281455.02379.hans_meine@gmx.net>

Hi,

and thanks for your comments.  I feel the same about Windows as Fernando, I am 
just feeling unhappy when having to do sth. with it.  I made Ullrich show me 
what he meant, and found this out:

- He tried to use Ctrl-C/V which obviously do nothing related in the terminal,
  so with "does not really work" he meant "does not work at all".

On Thursday 27 October 2005 23:40, Fernando Perez wrote:
> > I think you don't even need the quick edit checked to copy/paste with
> > mouse. Just paint with mouse (caution - it freezes the window for the
> > duration of the operation), press enter to "copy" ang right-click to
> > paste.
>
> So what does the 'quick edit' thing do?  Just curious...

- The "quick edit" checkbox enables you to mark, copy & paste without the
  menu.  Normally, you have to select "mark" and "paste" in the menu.

- Pressing Enter to copy the marked region is insane, but works.

> > Windows has craploads of problems, but copy-pasting isn't one of them.
>
> Yes, that seemed to work for me, but it seems Hans' friend had further
> complains, so it would be good to know what they were.  I get the feeling
> that in win32, the terminal copy/paste doesn't recognize the end of text
> lines, it's just a 'rectangle paint'.

- Exactly this is the serious remaining problem; it makes it impossible to
  copypaste multi-line commands, since it at best inserts spurious newlines, 
and usually also strips stuff from the left or right of the rectangle.

> Typically rich text widgets know how 
> to highlight only text, and perhaps that's important to Hans' friend.

Yes, normally you wouldn't copy single words with the mouse, since it's faster 
to retype them, but long commands are impossible to copy&paste in any sane 
way AFAWCS. :-(

Greetings,
  Hans (who happily returned to his Unix box ;-p )

PS: Of course, copy & paste is still interesting with Unix, but at least I do 
not suffer from *shudder* unwanted rectangular selections.



From Fernando.Perez at colorado.edu  Fri Oct 28 15:13:09 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 28 Oct 2005 13:13:09 -0600
Subject: [IPython-dev] Copy & Paste in IPython under Windows?
In-Reply-To: <200510281455.02379.hans_meine@gmx.net>
References: <200510271516.53258.hans_meine@gmx.net>
	<46cb515a0510271406q724e5553gbcb3002e6589ba58@mail.gmail.com>
	<43614950.405@colorado.edu> <200510281455.02379.hans_meine@gmx.net>
Message-ID: <43627845.6060601@colorado.edu>

Hans Meine wrote:
> Hi,
> 
> and thanks for your comments.  I feel the same about Windows as Fernando, I am 
> just feeling unhappy when having to do sth. with it.  I made Ullrich show me 
> what he meant, and found this out:
> 
> - He tried to use Ctrl-C/V which obviously do nothing related in the terminal,
>   so with "does not really work" he meant "does not work at all".

This is what I suspected.  I wonder, though, what his Qt terminal does with 
Ctrl-C.  How do you issue a SIGINT in his environment if you want to send a 
KeyboardInterrupt exception to a process?

At any rate, I think that the problem is simply that the underlying windows 
command terminal is fundamentally, irreparably broken.

One possibility would be to run under rxvt in cygwin.  That's a real terminal, 
so in it copy/paste probably would work sensibly (I'm guessing here, my 
windows box is at home).

Otherwise, he'd need to embed ipython as the shell inside a better Qt widget 
than the windows terminal.  This is doable, but not particularly easy today, 
as ipython makes too many assumptions about stdin/out.  I hope that in the 
near future this situation will improve, as the work to make the 
notebook/parallel (chainsaw) branches converge progresses, this is precisely 
one of our very first requirements.

Regards,

f