From jcronin at egh.com  Thu Nov  1 19:42:48 2007
From: jcronin at egh.com (Jonathan Cronin)
Date: Thu, 1 Nov 2007 14:42:48 -0400
Subject: [Idle-dev] New to IDLE,  my wish list and, maybe, bugs.
Message-ID: <42D134F4-5B34-4657-9631-C700D2D8FA8D@egh.com>

IDLE wish list and maybe, bugs.

running on OS X version 10.4.10, IDLE version 1.2.1, MacBook

Wish list:
---------------------

Adjustable font/font size in dialog box entry fields.  Tracking the  
base editor font would be just as good.

Adjustable width of scrolling key list in key preferences.   
Autosizing would be better.

An settable option to automatically call "Debug:Go to File/Line" when  
the shell gets an error would be nice, if feasible.

A key on the "Debug:Go to File/Line" menu item to do the same would  
be nice too.

Underlying operations to support keys for Kill/Yank on a line basis  
(i.e. without previous selection)  (I know, these are just hard-wired  
in my fingers from Emacs.  I haven't used Emacs in years, but I've  
been using editors that support Emacs-like keys)

Underlying operations for using key selection, i.e. Set Mark,  
selection is between
Mark and Cursor.

(Some of the above support a low-mouse-use style of editing.)

Maybe not IDLE controllable, but it would be nice if the scroll-bars  
supported mouse roller-button scrolling on OS X

When keys are configurable, it's always nice if there's a way to type  
a key-combination and see the text you should enter to use that  
combination in the configuration.

(+1 to existing suggestion for tabbed windows. Tear off tabs would be  
very, very
nice, but that's asking a lot :) )

Bugs, maybe:
------------

On a syntax error, the shell window is left over the source window  
obscuring the error highlighting.  The source window should pop to  
the top. (Or I don't see the reason for the behavior)

The menu item (Format:Format Paragraph) and the key preferences show  
this attached to Option-q.  When I do this the paragraph is formatted  
but an ? (oe ligature) is appended.  (In a common OS X text window,  
option shift inserts the ligature.) Control-Option-Shift just does  
the paragraph format.

Replace highlighting of finds after the first one occasionally fails  
to highlight.

This is a useless report (I can't reproduce it,) but I had one  
incident of a run-away shell.  I accidently pasted a dictionary  
"{ <blah>:<blah>,... }" into the shell, typed something random in an  
attempt to clear it, went back to an edit window.  Response was slow  
and the fan came on louder than I've ever heard it. Both processors  
were at 100% and I couldn't close IDLE windows or quit IDLE.  I could  
edit in a window.  Force quit of IDLE worked.

Jonathan


From taleinat at gmail.com  Fri Nov  2 01:10:35 2007
From: taleinat at gmail.com (Tal Einat)
Date: Fri, 2 Nov 2007 02:10:35 +0200
Subject: [Idle-dev] New to IDLE, my wish list and, maybe, bugs.
In-Reply-To: <42D134F4-5B34-4657-9631-C700D2D8FA8D@egh.com>
References: <42D134F4-5B34-4657-9631-C700D2D8FA8D@egh.com>
Message-ID: <7afdee2f0711011710m6278c118r54d69d6e5c48f454@mail.gmail.com>

On Nov 1, 2007 8:42 PM, Jonathan Cronin <jcronin at egh.com> wrote:
> IDLE wish list and maybe, bugs.
>
> running on OS X version 10.4.10, IDLE version 1.2.1, MacBook
>
We haven't had too many posts from people using IDLE on OSX, so it's
good to get some feedback :)

> Wish list:
> ---------------------
>
> Adjustable font/font size in dialog box entry fields.  Tracking the
> base editor font would be just as good.

Using the editor font size sounds good, but I don't think we should
use its font face. Perhaps we should use its font size for all of the
text in the dialogs, not just the entry boxes. (IMO making them
configurable is out of the question.)

> Adjustable width of scrolling key list in key preferences.
> Autosizing would be better.

I agree that it is currently too narrow. I suggest reorganizing the
window, having two frames one on top of the other instead of
side-by-side. The top one would allow managing key sets, the bottom
one would contain the list of key bindings. This would the list of key
bindings to be wider.

> An settable option to automatically call "Debug:Go to File/Line" when
> the shell gets an error would be nice, if feasible.

Hmm, that could be useful, though sometimes annoying. I don't think
IDLE should do too much automatic jumping around, that tends to be
very confusing. With a keyboard shortcut, would you still want this to
be automatic (save one keystroke)?

> A key on the "Debug:Go to File/Line" menu item to do the same would
> be nice too.

I agree. Any suggestions?

> Underlying operations to support keys for Kill/Yank on a line basis
> (i.e. without previous selection)  (I know, these are just hard-wired
> in my fingers from Emacs.  I haven't used Emacs in years, but I've
> been using editors that support Emacs-like keys)

I would also like this very much. (Ctrl-k already kills a line, but it
is simply deleted, you can't retrieve it.)

> Underlying operations for using key selection, i.e. Set Mark,
> selection is between
> Mark and Cursor.

I never really understand this request - is holding the Shift key down
really so hard?

I'm wary of such a feature because new users may trigger it by
accident. Not knowing how to end it, they would have text selected and
replaced all of the time, forcing them to close and reopen the window.

> Maybe not IDLE controllable, but it would be nice if the scroll-bars
> supported mouse roller-button scrolling on OS X

They don't? Using a roller on WinXP works fine, as well as holding the
middle mouse button and moving the mouse up/down. Sounds like a
platform specific bug. Can another OSX user confirm this?

> When keys are configurable, it's always nice if there's a way to type
> a key-combination and see the text you should enter to use that
> combination in the configuration.

That would be very nice, especially for novice users. It shouldn't
really be difficult to do with Tk. Someone just needs to make such a
dialog. I'm doing a lot of stuff and this isn't very high priority
IMHO, so I don't know if or when I'll get around to it.

> (+1 to existing suggestion for tabbed windows. Tear off tabs would be
> very, very
> nice, but that's asking a lot :) )

I'm working on it, but it could take a while. (don't hold your breath
for tear-offs though...)

> Bugs, maybe:
> ------------
>
> On a syntax error, the shell window is left over the source window
> obscuring the error highlighting.  The source window should pop to
> the top. (Or I don't see the reason for the behavior)

Do you mean when you use "Goto file/line"? If so, on WinXP it raises
the source window, so perhaps this is another platform specific bug.

> The menu item (Format:Format Paragraph) and the key preferences show
> this attached to Option-q.  When I do this the paragraph is formatted
> but an ? (oe ligature) is appended.  (In a common OS X text window,
> option shift inserts the ligature.) Control-Option-Shift just does
> the paragraph format.

This is a bug - nice catch! Need to add "return 'break'" at the end of
FormatParagraph.format_paragraph_event. I'll post a patch tomorrow
morning.

> Replace highlighting of finds after the first one occasionally fails
> to highlight.
>
> This is a useless report (I can't reproduce it,) but I had one
> incident of a run-away shell.  I accidently pasted a dictionary
> "{ <blah>:<blah>,... }" into the shell, typed something random in an
> attempt to clear it, went back to an edit window.  Response was slow
> and the fan came on louder than I've ever heard it. Both processors
> were at 100% and I couldn't close IDLE windows or quit IDLE.  I could
> edit in a window.  Force quit of IDLE worked.

That is weird. The only thing I know of that may be related is that
pasting large amounts of text into a window can cause similar effects,
i.e. slowdown and high CPU usage. This is one of the things the
Squeezer extension (found on PyPI) helps avoid.

> Jonathan

Thank you very much for this! It really helps us make IDLE better.

- Tal

From jcronin at egh.com  Sat Nov  3 01:20:56 2007
From: jcronin at egh.com (Jonathan Cronin)
Date: Fri, 2 Nov 2007 20:20:56 -0400
Subject: [Idle-dev] New to IDLE, my wish list and, maybe, bugs.
In-Reply-To: <7afdee2f0711011710m6278c118r54d69d6e5c48f454@mail.gmail.com>
References: <42D134F4-5B34-4657-9631-C700D2D8FA8D@egh.com>
	<7afdee2f0711011710m6278c118r54d69d6e5c48f454@mail.gmail.com>
Message-ID: <89050B9B-C2C8-4EB9-B186-40BE7B546F97@egh.com>


On Nov 1, 2007, at 8:10 PM, Tal Einat wrote:
>
>> Wish list:
>> ---------------------
>>
>> Adjustable font/font size in dialog box entry fields.  Tracking the
>> base editor font would be just as good.
>
> Using the editor font size sounds good, but I don't think we should
> use its font face. Perhaps we should use its font size for all of the
> text in the dialogs, not just the entry boxes. (IMO making them
> configurable is out of the question.)

Size is probably good enough; in my experience, when you can't change  
size a font change alone may help, but size change trumps font change  
for better legibility.

>
>> Adjustable width of scrolling key list in key preferences.
>> Autosizing would be better.
>
> I agree that it is currently too narrow. I suggest reorganizing the
> window, having two frames one on top of the other instead of
> side-by-side. The top one would allow managing key sets, the bottom
> one would contain the list of key bindings. This would the list of key
> bindings to be wider.

Sounds good.

>
>> An settable option to automatically call "Debug:Go to File/Line" when
>> the shell gets an error would be nice, if feasible.
>
> Hmm, that could be useful, though sometimes annoying. I don't think
> IDLE should do too much automatic jumping around, that tends to be
> very confusing. With a keyboard shortcut, would you still want this to
> be automatic (save one keystroke)?

No, a keystroke is pretty much as good.  Better, now that I think of
it; I want to read the error message before I jump.

>
>> A key on the "Debug:Go to File/Line" menu item to do the same would
>> be nice too.
>
> I agree. Any suggestions?

Alt-e (for error?)
Alt-j (for jump to error line, a modified form of command-j)
Shift-Command-j (as above)
or
Command-j (i.e. in the shell window, jump to error line, in source  
window, get dialog to jump to line)

The last assumes no-one really uses Command-J in a shell window.  And  
that it's easy to do different things off the same key-sequence.  The  
key customize dialog doesn't distinguish shell and source windows, so  
that would also be a problem.

(I don't suggest function keys for two reasons. On Mac laptop  
keyboards, the function keys are overloaded with hardware functions  
(volume, screen brightness, embedded numeric pad shift and display  
swap) so require an extra shift key.  And I can't remember them, they  
have no mnemonic quality.)
>
>> Underlying operations for using key selection, i.e. Set Mark,
>> selection is between
>> Mark and Cursor.
>
> I never really understand this request - is holding the Shift key down
> really so hard?

Probably not, but I didn't know about it :) I'll try it now...
Yes, that's handy enough. It doesn't work for all the navigation key  
sequences: e.g. ^A, ^E, (which I take to be TCL defaults) but it's  
certainly 90% of the way. This isn't in the menu help.  Is it well- 
known from other editors?

(I also just discovered control-downarrow/uparrow, move by paragraph,
also useful, also not in the menu help.)

> I'm wary of such a feature because new users may trigger it by
> accident. Not knowing how to end it, they would have text selected and
> replaced all of the time, forcing them to close and reopen the window.

Having it as operation assignable to a key, but by default unassigned  
would take care of that.  (What you describe has happened to me in  
some vi-like editor on a customer host, so I certainly understand.)
>
>> When keys are configurable, it's always nice if there's a way to type
>> a key-combination and see the text you should enter to use that
>> combination in the configuration.
>
> That would be very nice, especially for novice users. It shouldn't
> really be difficult to do with Tk. Someone just needs to make such a
> dialog. I'm doing a lot of stuff and this isn't very high priority
> IMHO, so I don't know if or when I'll get around to it.

I'll attempt one, i.e. a separate app(let) that just pops a dialog  
box, (I'll learn some tkinter etc.) but I can't commit to how soon.  
Pointers to where it would hook in? I've poked around briefly in the  
IDLE sources (I really wanted Kill/Yank :)) but was scared off, given  
the time I could reasonably now commit.

>
>> Bugs, maybe:
>> ------------
>>
>> On a syntax error, the shell window is left over the source window
>> obscuring the error highlighting.  The source window should pop to
>> the top. (Or I don't see the reason for the behavior)
>
> Do you mean when you use "Goto file/line"? If so, on WinXP it raises
> the source window, so perhaps this is another platform specific bug.

I mean when I select the Check Module menu item.  (Goto file/line  
works fine.) I assume the shell is used for the checking, but since  
the error is reported in a dialog window and highlighted in the  
source window, the shell window is irrelevant.

>
> Thank you very much for this! It really helps us make IDLE better.


A pleasure.  I've just done my first serious work in Python/IDLE, a  
small dot pre-processor for software modeling diagrams and I am very  
enthused.

It should be called Pytho; it has the positive qualities of Play-Do  
and Lego: you get ideas squishing it through your fingers and it  
snaps together nicely to build things.

Jonathan



From jn.ml.idle.07 at wingsandbeaks.org.uk  Sat Nov 17 13:39:21 2007
From: jn.ml.idle.07 at wingsandbeaks.org.uk (Jeremy Nicoll - idle)
Date: Sat, 17 Nov 2007 12:39:21 +0000
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle 1.2.1
Message-ID: <gemini.jrnhtl0007huu02xo@wingsandbeaks.org.uk.invalid>

Here, under Windows XP Pro, I'm trying to get used to IDLE.  Yesterday I
used  Options -> Configure IDLE -> Highlighting  to define a custom colour
scheme where each colourable area is defined as some bright colour (fg) on
black (bg).

In the 'clickable area' that shows the colours in effect for each type of
colourable item, "cursor |" is shown in bright yellow on a black background.
 But in the file editing window the cursor never shows up in yellow. 
Experiments suggest that the cursor is ALWAYS displayed in black (fg) on
whatever background colour applies.

I've ended up changing all the other colourable items so they are on a
fairly dark grey background.  The cursor is just visible, if you look
closely.  It gets more visible if you lighten the background colour but I
don't want to.  (I loathe white backgrounds, finding black much more restful
on the eyes).

Is this a bug, or what?


-- 
Jeremy C B Nicoll - my opinions are my own.


From taleinat at gmail.com  Sat Nov 17 20:56:18 2007
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 17 Nov 2007 21:56:18 +0200
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <gemini.jrnhtl0007huu02xo@wingsandbeaks.org.uk.invalid>
References: <gemini.jrnhtl0007huu02xo@wingsandbeaks.org.uk.invalid>
Message-ID: <7afdee2f0711171156t33a9d1edoe6df8e0219e82132@mail.gmail.com>

Jeremy Nicoll wrote:
> Here, under Windows XP Pro, I'm trying to get used to IDLE.  Yesterday I
> used  Options -> Configure IDLE -> Highlighting  to define a custom colour
> scheme where each colourable area is defined as some bright colour (fg) on
> black (bg).
>
> In the 'clickable area' that shows the colours in effect for each type of
> colourable item, "cursor |" is shown in bright yellow on a black background.
>  But in the file editing window the cursor never shows up in yellow.
> Experiments suggest that the cursor is ALWAYS displayed in black (fg) on
> whatever background colour applies.

Try changing this setting, then close and restart IDLE.

> I've ended up changing all the other colourable items so they are on a
> fairly dark grey background.  The cursor is just visible, if you look
> closely.  It gets more visible if you lighten the background colour but I
> don't want to.  (I loathe white backgrounds, finding black much more restful
> on the eyes).
>
> Is this a bug, or what?

This is a known bug which has been fixed in SVN.

Still, thanks for taking the time to report this! Please do tell us
about any other issues you run in to.

- Tal

From jn.ml.idle.07 at wingsandbeaks.org.uk  Fri Nov 16 09:35:09 2007
From: jn.ml.idle.07 at wingsandbeaks.org.uk (Jeremy Nicoll - idle)
Date: Fri, 16 Nov 2007 08:35:09 +0000
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle 1.2.1
Message-ID: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>

Here, under Windows XP Pro, I'm trying to get used to IDLE.  Yesterday I
used  Options -> Configure IDLE -> Highlighting  to define a custom colour
scheme where each colourable area is defined as some bright colour (fg) on
black (bg).

In the 'clickable area' that shows the colours in effect for each type of
colourable item, "cursor |" is shown in bright yellow on a black background.
 But in the file editing window the cursor never shows up in yellow. 
Experiments suggest that the cursor is ALWAYS displayed in black (fg) on
whatever background colour applies.

I've ended up changing all the other colourable items so they are on a
fairly dark grey background.  The cursor is just visible, if you look
closely.  It gets more visible if you lighten the background colour but I
don't want to.  (I loathe white backgrounds, finding black much more restful
on the eyes).

Is this a bug, or what?


-- 
Jeremy C B Nicoll - my opinions are my own.


From taleinat at gmail.com  Sun Nov 18 15:21:18 2007
From: taleinat at gmail.com (Tal Einat)
Date: Sun, 18 Nov 2007 16:21:18 +0200
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>
Message-ID: <7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>

Jeremy Nicoll wrote:
> Here, under Windows XP Pro, I'm trying to get used to IDLE.  Yesterday I
> used  Options -> Configure IDLE -> Highlighting  to define a custom colour
> scheme where each colourable area is defined as some bright colour (fg) on
> black (bg).
>
> In the 'clickable area' that shows the colours in effect for each type of
> colourable item, "cursor |" is shown in bright yellow on a black background.
>  But in the file editing window the cursor never shows up in yellow.
> Experiments suggest that the cursor is ALWAYS displayed in black (fg) on
> whatever background colour applies.

Try changing this setting, then close and restart IDLE.

> I've ended up changing all the other colourable items so they are on a
> fairly dark grey background.  The cursor is just visible, if you look
> closely.  It gets more visible if you lighten the background colour but I
> don't want to.  (I loathe white backgrounds, finding black much more restful
> on the eyes).
>
> Is this a bug, or what?

This is a known bug which has been fixed in SVN.

Still, thanks for taking the time to report this! Please do tell us
about any other issues you run in to.

- Tal

From jn.ml.idle.07 at wingsandbeaks.org.uk  Mon Nov 19 03:12:05 2007
From: jn.ml.idle.07 at wingsandbeaks.org.uk (Jeremy Nicoll - idle)
Date: Mon, 19 Nov 2007 02:12:05 +0000
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>
Message-ID: <gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid>

"Tal Einat" <taleinat at gmail.com> wrote:

> Jeremy Nicoll wrote:

> >  But in the file editing window the cursor never shows up in yellow.
> > Experiments suggest that the cursor is ALWAYS displayed in black (fg) on
> > whatever background colour applies.
> 
> Try changing this setting, then close and restart IDLE.

A-ha! That worked.  

(Of course since all the others were instant changes I never thought of
trying this, also with each failed set of experimental custom setups I
always reverted to the standard one at the end of each set of experiments so
a close & restart didn't have any effect.)


> > Is this a bug, or what?
> 
> This is a known bug which has been fixed in SVN.

Does this mean I have to wait for the next formal release for that fix (not
that it matters with that simple workaround), or are there betas as well?  

If there are betas is there a list somewhere of what's different in them
compared to 1.2.1?  As I'm just getting started with Python & IDLE maybe I
might as well use a beta and take advantage of whatever extra facilities it
offers?

I did have a quick browse of Python25\Lib\idlelib ... 

Is all the code for IDLE here?  I see that most files exist in .py and .pyc
forms; presumably IDLE uses the (faster?) .pyc ones so if I made any
experimental changes in the .py ones I'd need then to compile them to .pyc
equivalents? Would they then be picked up immediately, or after close &
restart of IDLE, or not at all - maybe there's some other action required?

Where (under Windows XP) does IDLE store configurations?

> Still, thanks for taking the time to report this! Please do tell us
> about any other issues you run in to.
> 
> - Tal

I certainly shall!  Thank-you for your help.
  
-- 
Jeremy C B Nicoll - my opinions are my own.


From taleinat at gmail.com  Mon Nov 19 15:01:01 2007
From: taleinat at gmail.com (Tal Einat)
Date: Mon, 19 Nov 2007 16:01:01 +0200
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>
	<gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid>
Message-ID: <7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com>

Jeremy Nicoll wrote:
> > > Is this a bug, or what?
> >
> > This is a known bug which has been fixed in SVN.
>
> Does this mean I have to wait for the next formal release for that fix (not
> that it matters with that simple workaround), or are there betas as well?

Sorry, no nicely packaged beta versions. You can get the latest
version of IDLE by checking out just the contents of the idlelib
directory from the SVN (python\trunk\Lib\idlelib\) and placing it
inside your Python's Lib\idlelib directory. If you've ever worked with
CVS/SVN this should be simple enough. Otherwise, I can prepare a zip
file for you - again, installation is just replacing the contents of
the Lib\idlelib directory.

> If there are betas is there a list somewhere of what's different in them
> compared to 1.2.1?  As I'm just getting started with Python & IDLE maybe I
> might as well use a beta and take advantage of whatever extra facilities it
> offers?

Check out the NEWS.txt file in the idlelib directory. (You can read
the one in the SVN to see the changes since the version you are
using.)

> I did have a quick browse of Python25\Lib\idlelib ...
>
> Is all the code for IDLE here?

Yes.

> I see that most files exist in .py and .pyc
> forms; presumably IDLE uses the (faster?) .pyc ones so if I made any
> experimental changes in the .py ones I'd need then to compile them to .pyc
> equivalents? Would they then be picked up immediately, or after close &
> restart of IDLE, or not at all - maybe there's some other action required?

In general, when a .py file is run (or imported), Python first
compiles the file and saves the outcome ("byte-code") in a .pyc file.
But Python always makes sure that and .pyc file is up-to-date, i.e. if
any changes were made to the .py file, it will recompile it into a
.pyc file. So you don't have to worry about .pyc files at all really;
just work with the .py files, ignore the .pyc files, and you'll be
fine.

> Where (under Windows XP) does IDLE store configurations?

In a directory named .idlerc. On WinXP it is usually in your My
Documents directory (or one above it, e.g. c:\Documents and
Settings\Administrator\). In general in general, .idlerc will be under
whatever os.path.expanduser('~') returns.

> > Still, thanks for taking the time to report this! Please do tell us
> > about any other issues you run in to.
>
> I certainly shall!  Thank-you for your help.

HTH,
- Tal

From jn.ml.idle.07 at wingsandbeaks.org.uk  Mon Nov 19 15:25:00 2007
From: jn.ml.idle.07 at wingsandbeaks.org.uk (Jeremy Nicoll - idle)
Date: Mon, 19 Nov 2007 14:25:00 +0000
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com> 
	<gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com>
Message-ID: <gemini.jrrc1o005oyny02hg@wingsandbeaks.org.uk.invalid>

"Tal Einat" <taleinat at gmail.com> wrote:

... lots - thanks for this.

> Sorry, no nicely packaged beta versions. You can get the latest
> version of IDLE by checking out just the contents of the idlelib
> directory from the SVN (python\trunk\Lib\idlelib\) and placing it
> inside your Python's Lib\idlelib directory. If you've ever worked with
> CVS/SVN this should be simple enough.

I'm afraid I'm more a Panvalet and SMP/E man. I understand the theory of
what CVS, SVN etc do, buthave never set up or used either of them, so... 

> Otherwise, I can prepare a zip file for you - again, installation is just
> replacing the contents of the Lib\idlelib directory.

If you could, that'd be great.

> > I did have a quick browse of Python25\Lib\idlelib ...
> >
> > Is all the code for IDLE here?
> 
> Yes.

I realise that tracing it would slow IDLE down a lot, but maybe I'd learn a
lot that way too.  /Is/ there some way I can get a step-by-step trace of
some or all of the code there?


-- 
Jeremy C B Nicoll - my opinions are my own.


From taleinat at gmail.com  Mon Nov 19 16:42:41 2007
From: taleinat at gmail.com (Tal Einat)
Date: Mon, 19 Nov 2007 17:42:41 +0200
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <gemini.jrrc1o005oyny02hg@wingsandbeaks.org.uk.invalid>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>
	<gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com>
	<gemini.jrrc1o005oyny02hg@wingsandbeaks.org.uk.invalid>
Message-ID: <7afdee2f0711190742h39c53040wf0de3c7d355cdafb@mail.gmail.com>

Jeremy Nicoll wrote:
> I realise that tracing it would slow IDLE down a lot, but maybe I'd learn a
> lot that way too.  /Is/ there some way I can get a step-by-step trace of
> some or all of the code there?

You can use Python's built-in trace module - plenty of tutorials and
examples to be found online.

Or you can try CodeInvestigator, which has a nice web UI:
http://codeinvestigator.googlepages.com/main

Enjoy :)
- Tal

From jn.ml.idle.07 at wingsandbeaks.org.uk  Mon Nov 19 17:43:30 2007
From: jn.ml.idle.07 at wingsandbeaks.org.uk (Jeremy Nicoll - idle)
Date: Mon, 19 Nov 2007 16:43:30 +0000
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <7afdee2f0711190746w41a1f3d4l675a49949953f06d@mail.gmail.com>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com> 
	<gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com> 
	<gemini.jrrc1o005oyny02hg@wingsandbeaks.org.uk.invalid> 
	<7afdee2f0711190746w41a1f3d4l675a49949953f06d@mail.gmail.com>
Message-ID: <gemini.jrrigi0013tnz01uc@wingsandbeaks.org.uk.invalid>

"Tal Einat" <taleinat at gmail.com> wrote:

> Attached :)

Thanks very much!

I presume I should rename the existing Python25\Lib\idlelib
                                eg to: Python25\Lib\idlelib_original
and then put this one in instead?

Presumably the newer IDLE will read the old one's config files etc and then
when I next save settings and/or exit from IDLE, those will be saved in a
newer format (or with new values in, at any rate)?

Are there any non-backwards compatible changes, eg in config files, that
would make it impossible for me to revert to the original IDLE if I need to?
 I suppose I should back them up too...

-- 
Jeremy C B Nicoll - my opinions are my own.


From taleinat at gmail.com  Mon Nov 19 20:12:05 2007
From: taleinat at gmail.com (Tal Einat)
Date: Mon, 19 Nov 2007 21:12:05 +0200
Subject: [Idle-dev] Options -> Configure IDLE -> Highlighting in Idle
	1.2.1
In-Reply-To: <gemini.jrrigi0013tnz01uc@wingsandbeaks.org.uk.invalid>
References: <gemini.jrlbul000i85y033c@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711180621p7ee6a2aby34bbd03d7695bb03@mail.gmail.com>
	<gemini.jrqe4500hw5d900m0@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711190601w372d8dffw6e33420811c594b6@mail.gmail.com>
	<gemini.jrrc1o005oyny02hg@wingsandbeaks.org.uk.invalid>
	<7afdee2f0711190746w41a1f3d4l675a49949953f06d@mail.gmail.com>
	<gemini.jrrigi0013tnz01uc@wingsandbeaks.org.uk.invalid>
Message-ID: <7afdee2f0711191112ufca983cx4cd0538cd17d0aec@mail.gmail.com>

> I presume I should rename the existing Python25\Lib\idlelib
>                                 eg to: Python25\Lib\idlelib_original
> and then put this one in instead?

Yup.

> Presumably the newer IDLE will read the old one's config files etc and then
> when I next save settings and/or exit from IDLE, those will be saved in a
> newer format (or with new values in, at any rate)?

Same format, it hasn't changed in quite a while.

> Are there any non-backwards compatible changes, eg in config files, that
> would make it impossible for me to revert to the original IDLE if I need to?
>  I suppose I should back them up too...

Backing up wouldn't hurt, but IIRC there have been no such changes.


Enjoy :)
- Tal

From noreply at sourceforge.net  Thu Nov 29 20:26:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 29 Nov 2007 11:26:44 -0800
Subject: [Idle-dev] [ idlefork-Bugs-693418 ] Normal text background color
	not refreshed
Message-ID: <E1Ixp24-0006bx-8p@sc8-sf-web24.sourceforge.net>

Bugs item #693418, was opened at 2003-02-25 20:45
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 2
Private: No
Submitted By: David Harris (edcdave)
Assigned to: Kurt B. Kaiser (kbk)
Summary: Normal text background color not refreshed

Initial Comment:
IdleFork 0.9a2 / Python 2.2.2

Changing the background color for Normal Text in 
Custom Highlighting does not change the current 
window when 'Apply' is selected. The change does not 
become effective until a new Shell or Editor window is 
opened.

The other text choices (Comments, Keywords, etc.) do 
refresh their background colors when after 'Apply'.

Obviously, this discrepancy does not impact the 
usefulness of IdleFork, but the inconsistency is there.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-11-29 11:26

Message:
Logged In: NO 

I was just submitting info to a survey and got all of this garbage. 
Sorry!

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2004-03-08 10:31

Message:
Logged In: YES 
user_id=149084

Nigel Rowe was kind enough to submit a patch to the
Python tracker which implemented this request.  Applied
to Python IDLE only, as a new feature.  Not backported.

Python Patch 805830.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-05-26 11:58

Message:
Logged In: YES 
user_id=149084

You cannot change the normal text or highlight
foregrounds or backgrounds w/o (re)opening a
window.   It is great that Stephen actually was
able to update the definition, commment, keyword,
string and error text foregrounds and backgrounds
on the fly.  But only the latter are handled by the
colorizer; the former are set up when the window
is created.

This is not impossible to fix, just not worth the effort
IMHO.  You could offer a patch  :-) 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693418&group_id=9579