Hi,<br><br>Concerning the docs, I&#39;ve just recently made such a tool to easily create documentation from comments :<br><a href="http://planet.plt-scheme.org/display.ss?package=lazy-doc.plt&amp;owner=orseau">http://planet.plt-scheme.org/display.ss?package=lazy-doc.plt&amp;owner=orseau</a><br>

<br>You can check the docs online.<br>However, there is one remaining bug that prevents the package from being correctly installed but nobody seems to be able to help me... <br>(see the thread &quot;Error when installing package : ...&quot;)<br>

So I do not recommend to install the package right now, as it would screw your local documentation (removing the package would safely reverse the process though).<br><br>Apart from this, it should work fine and I think it would partly answer your first question.<br>

<br>There is also in-line scribble documenting:<br><a href="http://docs.plt-scheme.org/scribble/srcdoc.html">http://docs.plt-scheme.org/scribble/srcdoc.html</a><br><br>And I agree with you, something that gives information about a function more quickly than F1 and HTML in a browser would be great.<br>

Why not a function (help some-function) that renders docs in the interaction window ?<br><br>Best regards,<br>Laurent<br><br><br><br><div class="gmail_quote">On Tue, Oct 27, 2009 at 09:59, Scott McLoughlin <span dir="ltr">&lt;<a href="mailto:scott@adrenaline.com">scott@adrenaline.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I&#39;m fairly new to PLT, so I may be unaware of some features that i<br>
think are sorely lacking. As well, this is in part just a late night dump<br>
of an insomniac :-)<br>
1) First, while Scribble is a very cool virtual troff/TeX replacement,<br>
it&#39;s just *WAY* too complicated for documenting code quickly during the<br>
process of code writing. A more appropriate tool, IMHO, would simply<br>
embed docs in comments (or some other s-expr, docstring format, etc.).<br>
It would impose some minor structure via section tags, such as date,<br>
author, function parameters (checked by the documentation processor<br>
of course), type information where appropriate(including types from<br>
a fully integrated typed-scheme)  etc.<br>
The default doc processor should be a simple menu item that just<br>
generates HTML for a collection of source files, including hyper links<br>
where appropriate (who calls, struct use to struct definition, and<br>
so on). Ideally the docs would feature an index, search, etc. in<br>
the generated HTML docs.<br>
And sure, there may be some more involved doc generation options<br>
provided by DrScheme as well - options for printed docs, PDF output<br>
and what not. But aside from the basic &quot;Update Docs&quot; menu item.<br>
2) Regarding the &quot;collection of files&quot; refered to above, DrScheme<br>
would benefit greatly from a simple default Project structure concept.<br>
A simple directory hierarchy of files, included libraries, perhaps sub<br>
projects, maybe sharing - pretty much standard fare for many IDE&#39;s that<br>
have been out there for years now.  Regarding HTML doc generations, it&#39;s<br>
the project files (or a subdir or even sub project) that is the<br>
&quot;collection of files&quot; unit of HTML documentation.<br>
3) Spawning the browser to view the docs is fine, but really, just as<br>
easy these days  is providing an HTML tab for viewing the hyperlinked<br>
documentation. This avoids repeatedly switching between apps to compare<br>
source and documentation, especially if DrScheme would provide both<br>
horizontal and vertical window splitting as Emacs does.  Ideally, the<br>
source editor would be modified to hyperlink source forms directly to their<br>
associated documentation, presumably by an unobtrusive right mouse button<br>
context menu item.  Request for such a source item doc could easily<br>
verify the up-to-date status of the HTML docs and bring them back up<br>
to date as necessary (CPUs and Disks are blessedly fast these days).<br>
4) Dr Scheme needs clean, simple revision control integration. I&#39;ve been<br>
on quite an illness driven coding hiatus, but not too many years ago, emacs<br>
and cvs went together like rum and coke, and setting up a CVS server was only<br>
a little harder than falling off a log.  Subversion seems the new CVS if I&#39;m<br>
reading the lay of the tech land correctly, but ideally, DrScheme should support<br>
a family of the most popular version control systems. The source file tabs can<br>
then show the checkin and even remote modification status, display inline diffs,<br>
generate regular diffs and of course allow resolution of conflicts right within<br>
the editor and so forth.  Basically, on any kind of multi-user project, or even<br>
a  large single user project, including this type of revision control by default<br>
would be a MAJOR productivity enhancement.<br>
5) Anyway, just some immediate off the cuff observations.<br>
I *REALLY DO* have the greatest admiration for the folks banging on DrScheme and<br>
the whole PLT technology suite, and I (reluctantly) understand that there are<br>
design priorities outside of building a commercial software development tool.<br>
I also want to say that the resulting technology to date is nothing short of<br>
amazing and is, so far, my development technology of choice for so many different<br>
and good reasons.<br>
So I hope my critiques are taken in the right spirit.<br>
Night all,<br>
 For list-related administrative tasks:<br>
 <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br>