| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
A bunch of shellish ops, but seems to be working fine.
|
|
|
|
Useless there right now, but Emacs package engine is going to use
them.
|
|
|
|
Images rendered via put-image won't be deleted by
erase-buffer (they're overlays), while those inserted by
insert-image (text properties) will.
|
|
|
|
|
|
When geiser-repl-inline-images-p is false (or we're in a terminal),
the inserted text replacement is a button that calls the external
viewer on click. There's also a parameter controlling whether the
viewer should be invoked automatically upon insertion.
|
|
|
|
When no cache dir is set in the emacs customization, we ask Racket for
the one that it's using by default.
|
|
Brought to you by a comma-command in the REPL and the REPL startup
function.
|
|
Emacs now remembers the directory that Racket put the last image in.
It leaves up to 10 previously viewed images in this directory,
providing an 'image history'.
This also reduces memory requirements; emacs no longer reads image
content into memory.
|
|
|
|
|
|
they are displayed in the REPL.
|
|
On the racket side, we use a custom print handler to print
images (convertible? values; see file/convertible) in a special format:
#<Image: filename>
On the geiser side, we add a comint post-output hook to search for
that filename and replace it with inline images.
|
|
Just adjusting a regexp.
|
|
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 had only for two of them, and one was wrong!
|
|
That is, `else' gets keyword fontlocking. Undecided as to whether
extend this highlighting to all schemes...
|
|
We were not re-activating it on new input, cause we weren't detecting
the prompt unless preceeded by other output (and, hence, a newline).
|
|
|
|
Hat tip Marijn.
|
|
This bugs was exposed by using rackunit, where all the output of, say,
check-eq? was lost for good (it was being sent to the stderr black
hole).
Hat tip Grant Retkke.
|
|
We were not checking that the region sent to the scheme process was
balanced, resulting in said process waiting for ever on `read' (or its
moral equivalent in our current implementation). We now just refuse
to evaluate an improper region in the first place.
|
|
At some point, we should make indentation rules buffer-local.
|
|
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.
|
|
The nice go-back-to-previous-scheme-buffer behaviour of C-c C-z wasn't
working when the jump from a scheme file to the REPL was initiated via
run-geiser. Thanks, Marijn.
|
|
|
|
Namely, geiser-font-lock-repl-prompt and geiser-font-lock-repl-input.
|
|
In this little notebook i'm using, racket takes its time to start. In
fact, it can take more the previously slotted 10 seconds. Hence the
new geiser-repl-startup-time variable.
|
|
Thanks, Leo.
|
|
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.
|
|
Using called-interactively-p instead of interactive-p, if you have to
know. The latter is deprecated as of Emacs 23.2, which the lowest
version supported by Geiser.
|
|
Autodoc was firing while the REPL was waiting for input of a (read)
call, causing all kinds of misbehaviour. We now inhibit autodoc on
sending a form for evaluation and re-inhibit it once a prompt is read
back again.
|
|
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.
|
|
We were not checking the implementation associated to a REPL buffer
when reusing it, with much confusion ensued.
|
|
|
|
Nothing interesting, really.
|
|
|
|
|
|
|
|
|
|
|
|
We weren't tracking the "enter debugger" event correctly, and all
evaluations in debug mode were failing. There's still (at least)
another bug, because error navigation in backtraces seems broken.
|
|
|
|
|
