| Age | Commit message (Collapse) | Author |
|---|
|
A note on why we won't use the mapatom trick to make geiser-custom--defcustom
obsolete while still preserving geiser-reload functionality (cf. !22).
|
|
In particular, removing a misleading FIXME comment that led to merge proposal
!22, and adding comments explaining why those changes would alter
geiser-reload's behaviour.
|
|
|
|
|
|
Also add a FIXME comment about how this macro isn't actually needed.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Implementations must invoke define-geiser-implementation with an
appropriate set of methods. Simple inheritance is supported. Each
geiser module defines and registers the method names it uses.
|
|
geiser-reload.
|
|
|
|
|
|
|
|
|
