| Age | Commit message (Collapse) | Author |
|---|
|
Fixes issue #68.
|
|
That results in less code and less confusing indirection.
|
|
`geiser-doc--xbutton' will be tackled in the next commit.
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
|
|
So that now all start with *Geiser (and a space for hidden ones) and
use consistent capitalization (see issue #38).
|
|
|
|
In some cases, Guile cannot figure out a signature and it comes back
as #f (:t in emacs-land), rather than a list.
|
|
|
|
It is available since Emacs 24.3 and we already depend on Emacs 24.4.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
As patiently pointed out by Alex Kost in the discussion of issue #121,
using the macro defined by the geiser-popup--define macro before its
actual definition causes problems when geiser is loaded after
compilation. Thanks again, Alex and Federico.
|
|
Which moreover complies with the unwritten naming conventions we use:
geiser-doc--render-docstring.
|
|
|
|
|
|
Session seems to be recovering the value of geiser-doc--history
badly (see issue #7 for @achitu's discoveries), and since it is, in
fact, not a good idea to save it anyway, we've added an eval-on-load
deregistering the variable from session's list.
|
|
|
|
Seems like the add-on package filladapt.el is broken in that its
version of fill-adapt uses a non-optional first argument. Aquamacs
users were filling the pain. Fixed by passing nil in our call to
fill-paragraph. Hat tip Jonathan Oddie.
|
|
|
|
We avoid using elisp's read for symbols, reading uninterned ones
instead. And then, we cannot use symbols as keys in responses from
scheme: we're using strings instead.
|
|
... which interns the symbol in the global obarray: rather unfriendly.
We still need to remove a few calls to that beast, and avoid intern in
the scheme reader.
|
|
We were adding extra spaces to function signatures.
|
|
When the symbol is imported and re-exported by a second module, we
display its definition name and original module, besides the name of
the module re-exporting it.
|
|
|
|
But i should really refactor this: module and value are (or can be)
already available in the response coming from Scheme.
|
|
Just justifying and indenting them.
|
|
|
|
|
|
|
|
We have a new "manual lookup" command, and Racket now displays a doc
browser buffer for help with a button activating it. In the process,
we've cleaned-up a little mess in geiser-eval.el and geiser-doc.el,
and refactored the affected Racket modules.
Next in line is providing manual lookup for Guile.
|
|
Details, details.
|
|
|
|
We're being a bit silly here, first converting the autodoc retort
string to an elisp value and then reconverting the arguments again to
a string with scheme syntax. We should probably do this at
geiser-syntax's parser level, with a special mode producing stringy
representations of tokens. Don't tell anyone.
|
|
We now display procedure signatures in module help, and keep a cache
in Guile, using procedure properties.
|
|
|
|
This allows the implementation decide the concrete structure of the
code sent to the REPL. For instance, it doesn't need to be a single
s-expression, and argument order can be re-arranged.
|
|
|
|
|
|
|
