| Age | Commit message (Collapse) | Author |
|---|
|
- Avoid defining autoload definitions in a central location.
Instead add autoload cookies to the forms/definitions that should
be autoloaded, in the locations where the actual definitions are
located.
- Do this for `geiser-mode', `turn-on-geiser-mode',
`geiser-mode--maybe-activate' (including adding that to
`scheme-mode-hook'), `geiser', `geiser-connect',
`geiser-connect-local' and `geiser-repl-switch'.
- Also do this for `run-geiser', even though it is only an obsolete
function alias for `geiser', which might make it desirable to drop
the autoload altogether.
Some unusual autoload definitions remain in "geiser.el", see below.
- One issue with defining autoloads in a central location is that it
is easy to forget to remove such autoloads when the real definition
is removed.
No longer autoload `geiser-version' because since [1: 847d2ad]
there no longer exists a proper definition of that function.
- No longer autoload `geiser-unload', `geiser-reload' and
`turn-off-geiser-mode', because they are only useful if Geiser has
already been loaded, at which point any autoloaded definitions are
no longer relevant.
However,
- Keep autoloading `geiser-activate-implementation' and
`geiser-implementation-extension', even though I doubt that this
is actually useful.
- Keep using `custom-add-load' to specify dependencies of Custom
groups and keep autoloading that. I don't know if this is actually
necessary, and while it seems really weird, it might served a legit
purpose, that I am not aware of.
1: 2020-07-19 847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2
scheme and autotools removals
|
|
This makes it possible to `eval-buffer' the buffer defining this
constant. Not that doing so makes all that much sense, but I tried
doing it before reading its content, because generally speaking that
is a sensible thing to do, at least for someone working on the code.
|
|
|
|
Fixes issue #20
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to Stefan's patience and actual implementation, we now don't load all
of geiser-impl.el and its dependencies just because there's a call
geiser-activate-implementation in geiser-<impl>-autoloads.el.
|
|
|
|
|
|
|
|
the half backed attempt at standardising guile's model won't work well with
other schemes, and it's not really well thought-out anyway: let's guile do its
thing, and we'll see what we can do in chez.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Playing the trick of checking for eldoc-documentation-functions to
know wheter we're at a new enough version, and (hopefully) falling
back to the old implementation otherwise.
|
|
We remove by-now obsolete usage of eldoc, and depend on the elpa
package to ensure backwards compatibility.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The plan is to have geiser-core contain only, well, the elisp core
engine. The autotools scafolding is no really worth it, so it's gone
too (and in the process, i'll look younger).
|
|
|
|
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.
|
