| 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.
|
|
Defining it as a macro, as it was done from the start, is just
weird.
|
|
|
|
same code that finds putative definitions, with all its caveats
|
|
we already had our own lighter mechanism, just needed to use it better. it
will also allow guessing local signatures, quite useful in chezzy (or more
generally r6rs-librarish) schemes.
|
|
... as well as a way of telling imenu to look for nested define forms, as the
ones one finds for instance inside (library ...) or (module ...) sexps, or
simply nested defines in function bodies. it's a crappy way of finding
definitions, but it's better than nothing when it's all we have (e.g., R6RS
libraries don't seem to provide an environment/namespace including their
privates, which is a killjoy).
|
|
|
|
NOTE: The patch is largely untested.
Modifications:
- Update readme.org
- Remove geiser-company
- Move Company extensions to geiser-completion
Omissions:
- geiser-company--inhibit-autodoc has been removed. Eldoc handling
should be implemented in the frontend, not in the backend.
See for example:
https://github.com/minad/corfu/blob/04fbfce3d7e9c125a7fd22a34455a508247a522b/corfu.el#L1212
- The quickhelp-string action and geiser-company--docstring have been
removed. company-quickhelp can use `:company-doc-buffer` instead with
minimal overhead.
See:
https://github.com/company-mode/company-quickhelp/blob/3ca2708b4e5190205aca01d65fe1b391963a53f9/company-quickhelp.el#L138
- The automatic Company setup has been removed. Personally I am not a
fan of such auto configuration. It is better if completion is
configured consistently in the user configuration. You may want to
restore the auto configuration for backward compatibility. It depends
on your backward compatibility story. I am fine with rare breaking
changes from time to time.
- There is a cyclic dependency between geiser-edit/geiser-doc and
geiser-completion, which should be untangled.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
