| 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
|
|
- 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.
|
|
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.
|
|
See issue #47.
|
|
|
|
|
|
Thanks again to Stefan for a useful discussion.
|
|
I haven't fully understood why, the two versions seem at first sight
equivalent, but they're not behaving equivalently.
|
|
|
|
It is available since Emacs 24.3 and we already depend on Emacs 24.4.
|
|
|
|
|
|
|
|
The whole first sentence should fit on the first line. If that makes
the line a bit long then that is unfortunate but better than wrapping
it onto a new line. When wrapping onto a new line anyway then the
second line should never be intended. When it can be avoided, then
long first lines should be made shorter.
|
|
|
|
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.
|
|
|
|
|
|
See discussion in issue !256.
|
|
Emacs trunk does not support arguments list like (lambda (&rest) nil)
anymore, which breaks geiser and errors with "Invalid function: "
|
|
At least by default.
|
|
That way we avoid circularities in the load graph, always a good thing.
|
|
This is gone now, since we're diligent enough to always end our impl
definitions with an explicit provide form. See PR #87 for a bit of
discussion.
|
|
Preparing the release of 0.7, which will feature support for Chicken
thanks to Dan and Freija!
|
|
|
|
By default, keywords are now not fontified in Scheme buffers unless
they have the correct (lower) case. This behaviour can be altered by
new, per-implementation customization variables.
Thanks to Diogo F. S. Ramos for pointing this out.
|
|
|
|
This reverts commit 801422d1558f488059ede4f9abab5163ca610900.
We cannot blindly substitute make-symbol for intern in the scheme
reader, because we rely on symbol equality elsewhere, often. The fix
will have to be much more careful.
|
|
We were calling `intern' instead of `make-symbol', polluting emacs'
obarray.
|
|
copy-list is from cl.
|
|
The trick consists on using a comint-input-ring-separator that is
*not* a newline, both for reading and writing the history file.
|
|
|
|
You don't really care unless you're a Geiser hacker (as opposed to a
hacker using Geiser), or wanna become one.
|
|
This interactive command will list all method needed to define a new
Scheme implementation in Geiser, together with their callers and doc
strings. Although i know very few additional schemes meta-dynamic
enough to be supported by Geiser (actually, just one: scheme48), one
never knows (there was a time when i thought that PLT Scheme wasn't in
the list).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* elisp/geiser-impl.el (with--geiser-implementation): macro was not
setting the implementation environment correctly.
|
|
|
|
|
|
|
|
|
|
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.
|
