| Age | Commit message (Collapse) | Author |
|---|
|
Since, you know, module names are now uninterned symbols.
|
|
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.
|
|
These ones seem safe: the resulting symbol is not compared for
equality anywhere.
|
|
We avoid calling symbol-at-point, and keep the cached signatures with
strings as keys.
|
|
... 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.
|
|
|
|
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.
|
|
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.
|
|
... and actually using it to implement geiser-smart-tab-mode. Always
nice to un-reinvent-the-wheel.
|
|
Besides removing code i didn't understand that well, we bring in
goodies such as partial completion. Jolly.
|
|
Was a real bug, after all, and quite reproducible. Sending an ,use
metacommand was not returning a prompt, and we were waiting for ever
to start (or almost). Now, connect-to-guile is not only right, but
spiffy again.
|
|
Today, W was seeing errors when connecting to Guile, which of course
immediately disappeared when we tried to reproduce them and get some
logs. I'm logging Guile's initialisation unconditionally, to make sure
the problem doesn't repeat. Much easier than fixing the bug.
|
|
|
|
|
|
|
|
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.
|
|
|
|
geiser-repl was missing a (require 'geiser-doc) that was making things
go pretty awry for compiled geiser on os x (emacs 23.2.20), but
nowhere else, for reasons that escape me.
Issue was, the popup buffer macros were not seen. Go figure.
|
|
|
|
Details, details.
|
|
|
|
|
|
|
|
|
|
Tell people that we're trying to complete, sometimes, on two different
prefixes.
|
|
It'd be interesting to check what percentage of commits are related to
autodoc...
|
|
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.
|
|
And, as a consequence, we were sending broken sexps to poor schemes.
|
|
We now display procedure signatures in module help, and keep a cache
in Guile, using procedure properties.
|
|
Simpler (we don't need no square brackets) and more correct (keywords
display as keywords and we only include default values when available
(Guile, i'm looking at you).
|
|
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).
|
|
|
|
Spinning up from correct fontification of [else in this brave Racket
world.
I'm keeping the list of extra keywords lean and mean, but making it
customizable in both Racket and Guile.
|
|
Let's not wait for active connections to clear their queue when we're
shutting down the REPL.
|
|
The latter is obsolete since 23.2.
|
|
Nothing here, move on.
|
|
It hadn't occurred to me that anyone wouldn't want non-automatic
geiser-mode often enough to require its own customization variable.
Rotty proved me wrong. Or maybe not, but he deserves a custom var!
|
|
Inferior schemes weren't really a good idea, were they? With remote
connections one can launch an external scheme to debug Geiser anyway.
And everything is (ahem, will be) simpler when we add new
implementations.
|
|
By prefixing their name with a space... an argument against inferior
schemes, btw, is that they raise the barrier to entry for new schemes:
they must provide a networked REPL server.
|
|
Separate connections for the REPL and Geiser commands was kind of
neat, but it had the problem of synchronising the current namespace
for both connections. A quick fix would have been to ask the scheme
for the current namespace for every Geiser command in the REPL, but
that, besides clunky, would add potentially prohibitive overhead for
(real) remote connections.
As it happens, using a single connection turned out to be not that
difficult and relatively clean code-wise. We could even turn back to
not use inferior schemes, and the net result of this refactoring would
be the replacement of comint-redirect (which wasn't able to match the
whole EOT token if it didn't arrive all at once) by transaction queues
(which also makes geiser-connection's implementation cleaner).
But using an inferior scheme has a dog-food value, and allows external
processes to connect to the scheme being used by Geiser without
further ado, which could be useful for debugging (although this is a
lame excuse: nothing prevents you from starting a REPL server from
emacs if you want). We'll see.
|
