[Idle-dev] IDLEfork / Docs / Startup etc.

[Stephen M. Gava]

David Scherer wrote:
> [Stephen M. Gava writes]
>
> > As for
> > help documentation: if pressing the "F1" (or configured help)
> > key is to
> > retain it's sensible common meaning of "help on using this
> > application" then
> > I believe it should by default pop up help on using idle
> > itself (and the
> > python documentation could be on shift-F1 for instance)
>
> I disagree.
>
> The purpose of help is not to provide information on an application; the
[..]
> They should therefore have access to help for all these things.  There's
> no particular reason that (1) should be separated from the others.

We're just going around in circles on this now. I have at no stage suggested 
that python language help shouldn't be easily available from within idle, nor 
would I. It should of course always be available easily and by default or 
idle wouldn't be much of a python ide would it? As for what particular key is 
by default bound to this or that, well it's (obviously  :^)  endlessly 
debateable.  This isn't cast in stone yet and anyway it will be configurable. 
End of that story, surely. The aim is that with the planned changes, 
including configurable help entries on the idle help menu, ultimately help 
will be in much better shape in idle than it was.  

> [Fred L. Drake writes]
>
> >   Perhaps the right thing would be to go ahead with a
> > registration for help components, and re-generate the front
> > page when new components are added.
>
> I like this idea, although it might be a lot of work.  A dynamically
> expandable Python help system would be useful beyond IDLE, as well.  It
> does feel a little like feeping creaturism, though.  (Why not update the
> documentation automatically from the web when a network connection is
> available?  Why not integrate it with a directory of Python packages, so
> that you can look at the help for a module you don't have installed, and
> click to download and install it?)

It does seem like a nify idea Fred, but it seems like it might also be a 
lot of work to implement and maintain?  You'd have a better idea than I on 
that though.

-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy "