| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
|
