| Age | Commit message (Collapse) | Author |
|---|
|
- In the summary line, use three dashes to separate the file name
from the summary. That is the convention, which some tools depend
on, and for some libraries we already did it here too.
- Capitalize the first word in the summary. That is the convention,
and for some libraries we already did it here too.
- For libraries that have a commentary, make sure it is placed in a
"Commentary:" section.
- Make sure the "Code:" heading, which separates the header from the
code part of the library, exists in all files.
|
|
Should provide a better fix for extended issue #58.
|
|
* geiser-compile-file
* geiser-compile-current-buffer
* geiser-load-current-buffer
* geiser-add-to-load-path
|
|
|
|
Should address, sort of, issue #46
|
|
|
|
Fixes #45. Thanks to Brian Cully.
|
|
|
|
|
|
|
|
|
|
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
The convention doesn't say much about what parts of the code are
supposed to be part of that sections and what parts belong in a
subsequent section. Here we put the `require' forms in this section
and maybe some setup code, that's a popular approach.
In most cases there was " " where we now insert "Code:". They both
serve a similar purpose and we keep the former because some users
depend on that for navigation. We even add this " " in libraries
where it previously was missing.
In some cases the permission statement was followed by a commentary,
which obviously does not belong in the "Code:" section. In such cases
add the conventional "Commentary:" section.
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
|
|
Okay, i must confess it's sometimes handy to restart the REPL before
compiling a file (the proverbial clean slate and all). And we already
have geiser-restart-repl, so combining the two things when C-u happens
was not really difficult.
|
|
We were expanding the path of files to be loaded at the wrong place in
the wrong way. This should be better and address bug #196.
|
|
Let's see if i finally got this right...
|
|
|
|
|
|
As per Andy's request. Adding it to Racket (and to the user manual),
shouldn't be difficult).
|
|
We cannot consistently maintain a local cache, because of
re-evaluations of external symbols will go unnoticed. The new strategy
(remembering only the latest signatures) mostly works, although it
introduces a bit of extra flickering every now and then.
A global cache is perhaps worth considering.
|
|
|
|
This allows the implementation decide the concrete structure of the
code sent to the REPL. For instance, it doesn't need to be a single
s-expression, and argument order can be re-arranged.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
