| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
This one should address #79. I'm very surprised this ever worked!
|
|
That way we avoid circularities in the load graph, always a good thing.
|
|
This is gone now, since we're diligent enough to always end our impl
definitions with an explicit provide form. See PR #87 for a bit of
discussion.
|
|
|
|
|
|
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.
|
|
|
|
- Now give compile-file a reasonable destination for the output
- Check for aforementioned output and skip the compile if exists
- None of the above happens if the system-type is 'windows-nt,
which may not be a necessary restriction. And, the existing
geiser-chicken-compile-geiser-p var applies.
Resolves jaor/geiser#73 for non-windows system
|
|
|
|
|
|
|
|
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.
|
|
-:c is required to make csi behave nicely with Emacs on Windows.
This ought to resolve jaor/geiser#67
|
|
Chicken won't become available to Geiser until it's actually done
loading. A number of bugs are related to this, including jaor/geiser#68
but also some quizzically flaky completion behaviour.
The fix is to suppress output to STDOUT until Chicken is ready; output
to STDERR is not suppressed, so if bad things happen it will still
appear in the geiser messages buffer.
This may fix jaor/geiser#68
|
|
xscheme defines its own scheme-interaction-mode that, quite rudely if
you ask me, calls not only its hooks, but also scheme-mode's. Among
them, turn-on-geiser-mode, causing havoc to users of xscheme's
run-scheme function.
We, ahem, fix this problem by checking that we're actually in
scheme-mode when our hook is called.
Thanks to Federico Beffa for his reports.
|
|
Minor and Patch versions are now optional.
|
|
geiser--cut-version only supports single-digit minor versions.
- Improves the regex to support multiple-digit minor versions.
Contributed by @kovrik
|
|
Signed-off-by: Mario Domenech Goulart <mario.goulart@gmail.com>
|
|
- 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
|
|
|
|
|
|
For some X faces, a bold string in the modeline causes emacs to widen it
to two lines, which is kind of annoying. The default value of
font-lock-variable-name-face on color/X displays doesn't include any
boldness, and will probably improve the default experience of new users.
Thanks to Mario Domenech Goulart for noticing this and the previous one!
|
|
It should have been geiser-active-implementations since ages ago.
|
|
|
|
|
|
Preparing the release of 0.7, which will feature support for Chicken
thanks to Dan and Freija!
|
|
|
|
|
|
Image cache cleaning was being performed during comint output filtering
and, since that can happen in batches, if the total output had more
images than the maximum cache size, some of them would be gone (in fact
it was even worse: we were cleaning the cache after each image display).
Now we just perform cache maintenance before sending the input, and
avoid paying a price for non-rackets by making the cache dir setting
implementation-specific.
|
|
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.
|
|
|
|
|
|
Since we have so few, let's not wait to add just one more!
|
|
Which moreover complies with the unwritten naming conventions we use:
geiser-doc--render-docstring.
|
|
|
|
|
|
|
|
|
|
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...
|
