| 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.
|
|
|
|
|
|
So that now all start with *Geiser (and a space for hidden ones) and
use consistent capitalization (see issue #38).
|
|
|
|
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.
|
|
|
|
This is a fix similar to the one made in commit
8e75455dfbd46355d777c26366e7ccfcb59ace20.
|
|
|
|
Since, you know, module names are now uninterned symbols.
|
|
We avoid using elisp's read for symbols, reading uninterned ones
instead. And then, we cannot use symbols as keys in responses from
scheme: we're using strings instead.
|
|
... which interns the symbol in the global obarray: rather unfriendly.
We still need to remove a few calls to that beast, and avoid intern in
the scheme reader.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
