| Age | Commit message (Collapse) | Author |
|---|
|
Use this function instead of repeating the same code in each
implementation.
|
|
Soooo, the long delay experienced when evaluating long string lists in
Guile had nothing to do with the time took by emacs to read the response
from the scheme process; that process is always a breeze, no matter or
its format or number of newlines. The delay was provoked by an innocent
looking function that scans the received string (which includes a prompt
at the end as an EOT marker) to check whether Guile (or any other
scheme) has just entered the debugger (that's done inside
`geiser-con--connection-update-debugging`). For some reason,
`string-match` on that kind of string using Guile's regexp for a debug
prompt takes forever. Instead of trying to optimize the regular
expression, i've just applied it to the *second* line of the received
string, which is the one that contains the response's prompt.
|
|
Should fix issue #85
|
|
We use the same trick as chicken for guile, and pretty-print the
evaluation results before writing them. The trick wasn't working at all
until i specified a value for the undocumented keyword parameter
`#:max-expr-width`, which makes me think i might be missing something.
|
|
Apparently, the nesting level returned by emacs's syntax parser can be
negative (presumably when it gets confused), and we were not avoiding
calling backward-up-list when that happened.
Could or could not address issue #41...
|
|
|
|
Follow the convention for `with-' procedures.
|
|
Guile's `define-once' allows defining a variable only once, but its
syntax is different from `define', so its highlight is different.
|
|
And, if you happen to be launching it all the time, a way of skipping
them via a customizable variable.
Should address issue #15.
|
|
|
|
We add the paths in geiser-guile-load-path also to %load-compiled-path,
and new directories added to the load path via geiser-add-to-load-path
are added to both %load-path and %load-compiled-path.
Here's hope Ludovic will like all these additions!
|
|
We add the paths in geiser-guile-load-path also to %load-compiled-path,
and new directories added to the load path via geiser-add-to-load-path
are added to both %load-path and %load-compiled-path.
Here's hope Ludovic will like all these additions!
|
|
|
|
|
|
|
|
|
|
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.
|
|
Splitting better the specially indented forms between our two
implementations, so that users of a single one don't get weird
indentations for froms without a special meaning in their scheme.
Ideally, we should make these indentation rules buffer-local, so that
when a user is in a, say, Guile buffer, module+ has no special
indentation (as is the case now if that user also has activated
support for Racket).
|
|
I must admit this is yet another excuse to check geiserbot over at
freenode.
|
|
In my debian machine, the info nodes for guile live in the "guile-2.0"
node, rather than plain "guile". A new customizable variable,
geiser-guile-manual-lookup-nodes, lets now specify additional names,
and we only add indexes to the info-lookup mode definition when the
node actually exists.
|
|
We were just ignoring it so far!
|
|
Actually, i'm not even sure the calls to format i was using were
correct at all!
|
|
If we didn't find a define-module form after the cursor, or an
enclosing R6RS library form, we search forward for a module
definition. That way, things like C-c C-a work also from the top of
the file.
|
|
Thanks Jon!
|
|
The new custom variable, geiser-guile-load-init-file-p, will be gone
once Guile adquires the ability to specify the path to its init file.
|
|
This is a 2.0 fluid that governs how warning messages are displayed.
In Geiser, we need the prefix set to an empty string so that file
paths are clickable (and the display in a separate emacs buffer is nicer).
|
|
|
|
|
|
|
|
As per Andy's request. Adding it to Racket (and to the user manual),
shouldn't be difficult).
|
|
|
|
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.
|
|
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.
|
|
We put the value of the identifier where it belongs, and add a missing
period. Works, but geiser/doc.scm is in sore need of a refactoring.
|
|
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.
|
|
|
|
We now display procedure signatures in module help, and keep a cache
in Guile, using procedure properties.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
Or the importance of EOL. Switching to a transaction queue for
communication with the Scheme process means that i had to care about
sending eols in the queries... Guile was waiting for ever reading a
metacommand taking a variable number of arguments. Argh: this has
taken me a few hours -- i'm getting old.
|
