| Age | Commit message (Collapse) | Author |
|---|
|
Using cond-expand to provide support for the new world of guile 2.2
|
|
Exposes geiser-load-paths, makes add-to-load-path and find-file
'unsafe'. Those needn't be memoized and would be strange if they are.
This should finish fixing jaor/geiser#114
|
|
|
|
That was annoying.
|
|
|
|
If one were to re-evaluate a buffer with a module in it there would be
problems because it would appear as a nested request.
Solution:
- Check if a module definition is a fore-most request, and if so,
evaluate at top level
|
|
If literals were present chicken wouldn't provide any autodocumentation
due to an error. Module evaluation was failing due to poor
input. Chicken's Error output was failing to parse
- Filter out all non-symbols from the autodoc set
- Properly escape module names
- Add "Error" to the set of accepted error prefixes
|
|
It doesn't make sense to memoize the following:
geiser-start-server
geiser-macroexpand
|
|
Removed the unnecessary csi reference
Added a flag to force build an so
|
|
|
|
Clears memo when anything other than a safe geiser call is made.
Removes the last calls to regex within the thing
|
|
This seems to improve speed; in a large environment I witnessed a
regular 100ms increase in speed for autodoc.
|
|
Improves speed by an order of magnitude.
|
|
|
|
|
|
Crunch is a subset of R5RS that the crunch egg can heavily optimize via
c++ compilation. This change allows geiser to report to chicken
programmers whether the function is found within that subset, easing
development.
Details on the crunch egg can be found at:
http://wiki.call-cc.org/eggref/4/crunch
|
|
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.
|
|
|
|
This change should fix it for most any input.
|
|
In some instances apropos-information-list returns a string and not a
list of symbols; this is the case for Chicken's builtins, like C_plus.
IE, the following would fail:
(geiser-autodoc #f '(+))
This fixes jaor/geiser#72
|
|
Emacs chokes on buffers with very long lines. Use of pretty-print
instead of write causes most incidents of long lines to be avoided by
use of better formatting.
This fixes jaor/geiser#64 for Chicken, and appears to greatly speed up
completions in the general case for Chicken.
|
|
- Can now optionally compile Geiser components for enormous speed
improvements; enabled by default
- Apropos was returning many duplicates, which was causing slowdowns;
duplicates are now filtered
- Now check for #<unspecified> results and return something
- Fixed a typo in a comment
- Fixed a typo in calling string-length
|
|
Preparing the release of 0.7, which will feature support for Chicken
thanks to Dan and Freija!
|
|
|
|
By hooking the pretty-printer, as discovered by Greg in issue #49. To
attain nirvana, we would still need (display (list graph)) to work...
|
|
Up to now, we were only displaying images when printed as values by the
REPL, but not when image values were explicitly print-ed, write-d or
display-ed. This patch solves that problem by installing (semi)
appropriate port-{print,write,display}-handler. This is still and
incomplete solution in that those handlers (as well as the already
installed current-print-handler) don't recurse over a value's structure
and won't produce images embedded in other data structures, as discussed
in issue #49.
|
|
|
|
When using our current-load/used-compiled function, we were compiling
the syntax of a module using compile, which seems to not honour
With luck, this should address bug #14 for real.
|
|
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.
|
|
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!
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
... by the obvious device of waiting for the thread building the index
to finish.
|
|
The evaluation of the help form must happen in a good enough
namespace.
|
|
|
|
For some reason that i don't fully understand, evaluating a function
in the racket/base namespace first thing after loading errortrace
breaks the help macro (!). This patches provides a workaround by
actually invoking help first thing when Geiser starts, with alibi that
it serves to preload the help index (in a separate thread).
While i was at it, i improved the message printed in the minibuffer
when no help is found.
|
|
So, the problem was that our regexp for a Racket prompt didn't take
into account that filenames could contain white spaces: "@[^ ]*> ". A
simple solution was accepting them: "@[^>]+> " won't work because '>'
is also a valid character in filenames, so we went for "@.*> ".
The drawback is that finding the beginning of the prompt (e.g. in C-a)
fails when you're writing things like:
racket@foo bar.rkt> (> 2 3)
because here comint believes that the prompt is "racket@foo bar.rkt> (> "
And that could have side-effects elsewhere. So what i've done is
simply changing the way white-space is (not) printed in the prompt,
substituting it by underscores. That way, whe can go back to the
initial regexp, comint doesn't get confused, and users can easily
infer that "@foo_bar.rkt>" is actually referring to their
"foo bar.rkt" file.
|
|
Thanks to Haiwei Zhou for catching this one!
|
