so in emacs, I have c-h k, c-h f; for perl i have perl doc; for c, I have man pages
in gambit scheme, when I want to lookup a quick descrition of what a function does, or look up it's source code, what's the most convenient way? currently I'm doing a mix of:
grep "func_name" gambit-c.txt
and
cd ~/gambit-build-dir
grep "func_name" . -R | grep "scm:"
but i feel there should be a more elegant solution
Afficher les réponses par date
On 10-Feb-09, at 8:31 AM, lowly coder wrote:
so in emacs, I have c-h k, c-h f; for perl i have perl doc; for c, I have man pages
in gambit scheme, when I want to lookup a quick descrition of what a function does, or look up it's source code, what's the most convenient way? currently I'm doing a mix of:
grep "func_name" gambit-c.txt
and
cd ~/gambit-build-dir
grep "func_name" . -R | grep "scm:"
but i feel there should be a more elegant solution
Funny you should ask that now! I am in the process of adding a "comma command" so that ,(h X) will open a browser with the definition of X in gambit-c.html . By clicking on the function name in the browser you will navigate to the page which documents X on the wiki. Once you are on the wiki you can add comments, examples, corrections to X's definition.
That should be available in the next release.
Marc
Marc Feeley wrote:
Funny you should ask that now! I am in the process of adding a "comma command" so that ,(h X) will open a browser with the definition of X in gambit-c.html . By clicking on the function name in the browser you will navigate to the page which documents X on the wiki. Once you are on the wiki you can add comments, examples, corrections to X's definition.
I think that such things should be in specific library-extension over repl, but not in the repl itself. Repl should be as small as possible for the minimal diagnostic messages and basic debugging.
May be factorize extra repl functionality over some set of libraries? - library for help functions - and so on.
Vasil
On 10-Feb-09, at 9:10 AM, vasil wrote:
I think that such things should be in specific library-extension over repl, but not in the repl itself. Repl should be as small as possible for the minimal diagnostic messages and basic debugging.
May be factorize extra repl functionality over some set of libraries?
- library for help functions
- and so on.
Are you worried about code bloat? This functionality actually requires little code. My plan is to call an external script (in ~~bin) which will do the brunt of the work. This script has to be generated by the configure script so that it calls up the correct browser for the system.
Putting this functionality in a library will not reduce code by much and it will be tedious for the user to load this library before they can get help. In this case the very minor code size increase is far outweighed by convenience for the user.
Marc
Marc Feeley wrote:
Are you worried about code bloat? This functionality actually requires little code. My plan is to call an external script (in ~~bin) which will do the brunt of the work. This script has to be generated by the configure script so that it calls up the correct browser for the system.
Putting this functionality in a library will not reduce code by much and it will be tedious for the user to load this library before they can get help. In this case the very minor code size increase is far outweighed by convenience for the user.
Marc
Partially agree, but how many users will use this functionality directly from the repl? I think only some of very-beginners. I suppose that most of users use some kind of IDEs such as emacs and so on. So, I see several most useful ways to bring help documentation to user: 1. generation of default .gambcini during installation with default set of libraries to load various extensions. This way is for beginners and their convenience. And extension libraries may be as big and as featured as needed, without worrying about size of repl and other parts of gambit at all. 2. extensions to emacs with ability to use on-line help, like use CLHS (Common Lisp HyperSpec) with SLIME. This way is for other users.
Vasil
On 10-Feb-09, at 9:55 AM, vasil wrote:
Partially agree, but how many users will use this functionality directly from the repl? I think only some of very-beginners. I suppose that most of users use some kind of IDEs such as emacs and so on. So, I see several most useful ways to bring help documentation to user:
- generation of default .gambcini during installation with default
set of libraries to load various extensions. This way is for beginners and their convenience. And extension libraries may be as big and as featured as needed, without worrying about size of repl and other parts of gambit at all. 2. extensions to emacs with ability to use on-line help, like use CLHS (Common Lisp HyperSpec) with SLIME. This way is for other users.
OK, now I see that what you want is extensionality. Don't worry there will be a hook that can be redefined to redirect the documentation request to what the user wishes.
Marc
On Tue, Feb 10, 2009 at 10:44:20AM -0500, Marc Feeley wrote:
On 10-Feb-09, at 9:55 AM, vasil wrote:
Partially agree, but how many users will use this functionality directly from the repl? I think only some of very-beginners. I suppose that most of users use some kind of IDEs such as emacs and so on. So, I see several most useful ways to bring help documentation to user:
- generation of default .gambcini during installation with default
set of libraries to load various extensions. This way is for beginners and their convenience. And extension libraries may be as big and as featured as needed, without worrying about size of repl and other parts of gambit at all. 2. extensions to emacs with ability to use on-line help, like use CLHS (Common Lisp HyperSpec) with SLIME. This way is for other users.
OK, now I see that what you want is extensionality. Don't worry there will be a hook that can be redefined to redirect the documentation request to what the user wishes.
Marc
Hello there. It's not about extendability but about system design in terms of orthogonality, simplicity and may be sanity. Displaying documentation in browser is NOT scheme implementation work at all. It's IDE's work. Autocompletion, history, syntax highlighting is NOT repl work. It's responsibility of IDE. There should be strong differentiation of core and library features in order to keep system clean.
Thus I suggest to move those «convenient development» features to IDE.
Concerning beginner friendliness: I think a special configured package should be made. Something that includes gambit, libraries, editor with embedded documentation. I with colleagues can try to make such package.
On 10-Feb-09, at 11:43 AM, Ben Goetter wrote:
Ramil Farkhshatov wrote:
Displaying documentation in browser is NOT scheme implementation work at all. It's IDE's work. Autocompletion, history, syntax highlighting is NOT repl work. It's responsibility of IDE.
Au contraire. The REPL is a development environment.
You beat me to it! Yes the REPL is an IDE. That's one of Lisp's and Scheme's fundamental principles. Of course it is not a full-feature IDE like Jedi, but still you can get a whole lot of work done at the REPL. So even though a full-feature IDE will have a documentation browser, with obviously many fancy features for browsing documentation, there is also a need for the REPL to access the documentation. What is important is that hooks in the REPL implementation are available to integrate with the full-feature IDE if/ when there is one.
Marc
Au contraire. The REPL is a development environment.
You beat me to it! Yes the REPL is an IDE. That's one of Lisp's and Scheme's fundamental principles. Of course it is not a full-feature IDE like Jedi, but still you can get a whole lot of work done at the REPL.
Don't mix up different levels. REPL is «read eval print loop» that's it. IDE is an environment that can include fancy stuff such as documentation, xref and things I've mentioned before. Yes, repl can be (and should be) underlying level of IDE which even can be just a command line interface over repl. But IDE should be a separate entity either a library or an application.
So even though a full-feature IDE will have a documentation browser, with obviously many fancy features for browsing documentation, there is also a need for the REPL to access the documentation.
Where is a reason to include that functionality right into REPL? If one need such thing he can always use external library for it.
What is important is that hooks in the REPL implementation are available to integrate with the full-feature IDE if/ when there is one.
Also, I don't see any reason for such hooks. IDE must work with object->documentation relations.
Bloat is not only huge amounts of code, but also an assignment of additional functionality to facilities without strong reason, a violation of Occam's razor principle.
My plan is to call an external script (in ~~bin) which will do the brunt of the work. This script has to be generated by the configure script so that it calls up the correct browser for the system.
Nah, this script has to use a Scheme variable (or an environment variable) to select the browser or the command to run. Setting it to firefox may just be the right default value, and others will call w3m or whatever as they want it. Deciding what to run at compile time of gambit is useless work.
Also, looking at slime may be nice, the hyperspec integrates quite well (should it be or not installed locally). Can the wiki be fetched dumped on a parsable format on a local machine (say, HTML)?
P!
A part from explicitly clicking on a link, I find it disturbing when a command causes some other program to open, and steal focus from emacs. At that point my brain switches in a different gear and causes me to get distracted from the problem at hand.
What you guys are describing sounds really good and w3m is one way out of the small annoyance described above. But it would be nice if this thing fetches the contents of the wiki page, parses them, then displays the results in a temp buffer - kind of like what describe-function does. That might be the more emacs user friendly way to do it.
Pavel
On Wed, Feb 11, 2009 at 12:22 AM, Adrien Piérard pierarda@iro.umontreal.ca wrote:
My plan is to call an external script (in ~~bin) which will do the brunt of the work. This script has to be generated by the configure script so that it calls up the correct browser for the system.
Nah, this script has to use a Scheme variable (or an environment variable) to select the browser or the command to run. Setting it to firefox may just be the right default value, and others will call w3m or whatever as they want it. Deciding what to run at compile time of gambit is useless work.
Also, looking at slime may be nice, the hyperspec integrates quite well (should it be or not installed locally). Can the wiki be fetched dumped on a parsable format on a local machine (say, HTML)?
P!
-- Français, English, 日本語, 한국어
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On 11-Feb-09, at 4:11 AM, Pavel Dudrenov wrote:
A part from explicitly clicking on a link, I find it disturbing when a command causes some other program to open, and steal focus from emacs. At that point my brain switches in a different gear and causes me to get distracted from the problem at hand.
I agree and that is why by default the "lynx" text-only browser is used if it is available. That way the documentation appears in the terminal in which the REPL is running. I've been using this for a few days and its really very slick and fast!
What you guys are describing sounds really good and w3m is one way out of the small annoyance described above. But it would be nice if this thing fetches the contents of the wiki page, parses them, then displays the results in a temp buffer - kind of like what describe-function does. That might be the more emacs user friendly way to do it.
It shouldn't be too hard to add this feature to gambit.el .
Marc
On 11-Feb-09, at 3:22 AM, Adrien Piérard wrote:
Nah, this script has to use a Scheme variable (or an environment variable) to select the browser or the command to run. Setting it to firefox may just be the right default value, and others will call w3m or whatever as they want it. Deciding what to run at compile time of gambit is useless work.
Yes there will be a parameter, but what I was talking about is a configure option, i.e. --enable-doc-browser=firefox, so that a default documentation browser can be selected when Gambit is built.
Also, looking at slime may be nice, the hyperspec integrates quite well (should it be or not installed locally). Can the wiki be fetched dumped on a parsable format on a local machine (say, HTML)?
What do you mean? A simple GET (with curl or Gambit) will get you the HTML of a page.
Marc
Also, looking at slime may be nice, the hyperspec integrates quite well
(should it be or not installed locally). Can the wiki be fetched dumped on a parsable format on a local machine (say, HTML)?
What do you mean? A simple GET (with curl or Gambit) will get you the HTML of a page.
That is the problem: whereas the hyperspec is website where they kept it simple, GETting from the wiki means loads of useless informations (that is, what makes it a wiki: all those links on the left, and the links "edit this page" "discussions" on top, etc).
Therefor, I wonder if it's possible to dump a static image of the content of the wiki, that would generate some proper HTML with no hint that it comes from a wiki.
Say, <html> <header> <title>foo</title> </header> <body> <h1>foo</h1> This is the <b>foo</b> procedure. It is a kind of <b><a href="bar.html">bar</a></b> </body> </html>
Which is a lot friendlier that what you'd get by GETting the wikipage (I once tried to get some pages of wikipedia, it's close to impossible to parse properly) And that could be packaged with along gambit in distributions/OSs, à la Hyperspec (though ours would be meant to evolve along with gambit, unlike hyperspec since CL is defined)
P!
On 11-Feb-09, at 10:25 AM, Adrien Piérard wrote:
That is the problem: whereas the hyperspec is website where they kept it simple, GETting from the wiki means loads of useless informations (that is, what makes it a wiki: all those links on the left, and the links "edit this page" "discussions" on top, etc).
Therefor, I wonder if it's possible to dump a static image of the content of the wiki, that would generate some proper HTML with no hint that it comes from a wiki.
Say,
<html> <header> <title>foo</title> </header> <body> <h1>foo</h1> This is the <b>foo</b> procedure. It is a kind of <b><a href="bar.html">bar</a></b> </body> </html>
Which is a lot friendlier that what you'd get by GETting the wikipage (I once tried to get some pages of wikipedia, it's close to impossible to parse properly) And that could be packaged with along gambit in distributions/OSs, à la Hyperspec (though ours would be meant to evolve along with gambit, unlike hyperspec since CL is defined)
I already have a Gambit script to do that. Perhaps this can be added to the distribution if I clean it up a bit.
Marc
That is the problem: whereas the hyperspec is website where they kept it simple, GETting from the wiki means loads of useless informations (that is, what makes it a wiki: all those links on the left, and the links "edit this page" "discussions" on top, etc).
There's always the "source" of the wiki. It's not as easy to parse as html but only the relevant information is there.
A nice solution might be to have a new set of URLs for echoing just the text/plain content.
These could be from a script, like "foo.com/plain-doc?procedure=map". or they could be simple cached "pages", like "foo.com/plain-doc/map.txt"
I'm not sure how hard the scripting would be, but the point here is that you can serve text/plain from a web page instead, which is probably preferable.
-
Adrien Piérard -
Ali -
Ben Goetter -
Jeremie Lasalle Ratelle -
lowly coder -
Marc Feeley -
Pavel Dudrenov -
Ramil Farkhshatov -
vasil