| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
When no live REPL is found, of course. The flag's imaginatively
called geiser-mode-start-repl-p.
|
|
In case you don't care about killing live REPLs...
|
|
And, while we're at it, honour the new case-sentive flag, as suggested
by Diogo.
|
|
Just renamed geiser-repl--clear-buffer (we don't use -- when users can
call the command with M-x normally) and added documentation.
|
|
|
|
By means of a new entry in completion-at-point-functions that uses
the handy comint-filename-completion.
|
|
|
|
When no other completion is available, that is.
|
|
This variable controls whether REPL command history should contain
inputs during the debugger sessions (for schemes with such a thing,
that is, for Guile).
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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 not re-activating it on new input, cause we weren't detecting
the prompt unless preceeded by other output (and, hence, a newline).
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
|
|
As per Andy's request. Adding it to Racket (and to the user manual),
shouldn't be difficult).
|
|
i hope the anonymous reporter will check this...
|
|
Following a suggestion by M. Harig, and following the policy that it's
better for command names to not be doubly hyphenated.
|
|
TAB already does all the other stuff.
|
|
We were using a comint-get-old-input function that was including the
prompt in its returned value. This was no problem most of the time
because we don't use comint-send-input before the process mark, but
there's another circumstance under which comint-get-old-input is
called, namely, when reaching the end of the input history. When
history is exhausted, the "old input" is inserted (go figure), and we
were inserting a prompt, wreaking havoc with its read-only-ness.
|
|
... 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.
|
|
... and actually using it to implement geiser-smart-tab-mode. Always
nice to un-reinvent-the-wheel.
|
|
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.
|
|
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.
|
|
The trick consists on using a comint-input-ring-separator that is
*not* a newline, both for reading and writing the history file.
|
|
|
|
Let's not wait for active connections to clear their queue when we're
shutting down the REPL.
|
|
Nothing here, move on.
|
|
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.
|
