| Age | Commit message (Collapse) | Author |
|---|
|
When evaluating (re)definitions in a typed module, it's necessary that
the form evaluated is wrapped with #%top-interaction, so that typed
racket's redefinition of that macro enters into play and the system
records the type information of the new value.
Many thanks to Sam Tobin-Hochstadt for the tip, and for his encouraging
words.
|
|
We used to check for a good racket version during its start-up, but
these days we already have an independent version check before that.
|
|
|
|
|
|
|
|
... so that we don't end up with a blank, useless buffer around.
|
|
|
|
And, if you happen to be launching it all the time, a way of skipping
them via a customizable variable.
Should address issue #15.
|
|
|
|
This will allow `package-buffer-info` to parse the description out of the file.
|
|
Everything in geiser.el needs one, so that the generated
geiser-autoloads.el initializes variables and the like properly
automatically.
|
|
Following the discussion in GitHub, i'm adding an alternative scheme
path to geiser.el as well as ##autoload cookies. As a first benefit,
this simplifies a bit the elpa target, after playing a similar path
trick in bin/geiser-racket.sh.
Things should be almost ready for creating a MELPA recipe.
|
|
|
|
|
|
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!
|
|
Too much clojure latetly!!
|
|
This variable makes comint wait for the underlying process to echo its
input, something our schemes won't do. If anyone sets the variable
globally for what can only be perverse reasons, we just would just hung.
Not anymore.
|
|
So the new functions are named geiser-racket-*-submodules, and by
default all submodule forms are hidden.
Now that we have the helpers in geiser-edit, we could have a generic
command in geiser-mode to change the visibility of form at point.
|
|
The new commands, being racket-specific, are called
geiser-racket-{show,hide,toggle}-tests, and have no default binding in
geiser-mode (since they don't have any meaning in Guile).
The implementation is based on more generic functions in geiser-edit
that allow hiding of any top-level form, given its name, so we will
probably find new forms to hide in the future.
Hiding is limited to top-level forms, which i think is fine for the only
use case we have in mind right now.
|
|
... so we have to check if it's defined and, in its defect, use the
new shiny comint-last-prompt. A bit of refactoring resulted.
|
|
|
|
So the generated tarball from `make dist' will have `dir' inside.
|
|
If a user doesn't want to install geiser, it's possible to run it in
place by loading `elisp/geiser.el' directly.
It's also possible to read the info manual directly but it's
inconvenient to not have it listed when hitting C-h i inside Emacs.
To list such manual, it's necessary to tell info where to look for it.
One way of doing it is adding the directory to the variable
`Info-additional-directory-list'. But, for this to work, there's need
to be a `dir' file listing the info manual.
|
|
The parser in geiser-syntax is (tail, but elisp doesn't care)
recursive, and we are setting max-lisp-eval-depth to some, ahem,
heuristic value before starting a read. For long strings, such as
that returned by the list of identifiers exported by the racket
module, the heuristic was bad enough to produce a value making Emacs
to blow away.
This is just a palliative. The real solution is turn the recursion in
geiser-syntax--read into an explicit iteration.
|
|
We were using a history entry separator including \0 that wasn't
writeable as an utf-8 file. Changing the separator to \n}{\n allows
using UTF-8 characters in the REPL which are correctly read back.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
The new submodules and errortrace interact badly, for what i've seen.
In particular, even with the submodule[+*] loading correctly, its
namespace doesn't have all identifiers bound, and new ones seem to
appear in the bindings lists (things like a.1 or b.2, when a and b are
the actual identifiers defined inside the module).
Since moreover someone mentioned in the devel ML that errortrace is in
general terms buggy, i guess we can leave without it for the time
being.
|
|
|
|
|
|
|
|
just because we can
|
|
Submodule (re)loading is not without pecularities. In particular,
module[*+] submodules are not visited the first time one enters its
parent, but once you load them once, they're revisited every time we
load the parent afterwards--racket's native enter! exhibits the same
behaviour, so i'm guessing we'll have to live with that.
There is however a glitch in that submodules can only be reloaded then
by loading the parent, so we need to confirm that this is expected
behaviour and, if it is, automating the parent's load when the
submodule's is requested.
On the other hand, entering a module[*+] is not working in Geiser yet,
and it does in plain racket, so this one is our fault. Working on it.
|
|
... and used also internally for C-c C-k, although it doesn't yet work
as well as i wanted when it comes to load modules. The reason is
probably in geiser/enter, where we don't record modification times per
submodule but per path, which is not correct in the presence of submodules.
|
|
|
|
|
|
Recognizing those forms in the elisp module getter.
|
|
That is, complying to the submodule loading protocol (cf. racket's own
enter!).
|
|
|
|
And we display it (the current path, settable via ,cd) as a string.
This was, i'm sure, a secret command nobody is using!
|
|
It is now possible to ,enter racket submodules. This is only the
first part of the story, because evalations should take place in the
submodule, not in its top level module, as it happens now.
|
|
Racket is happy with that, so who are we to disagree?
|
|
We weren't considering the obvious: (define/match (foo bar) ...)
|
|
We could probably generalize to more function definition forms, but
this is a start.
|
|
|
