| Age | Commit message (Collapse) | Author | 
 | 
 | 
 | 
 | 
 | 
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
 | 
 | 
 | 
 | 
Fixes #95.  This is @kovrik's patch, with 80-columns max formatting.
 | 
 | 
 | 
 | 
Should fix #105
 | 
 | 
Seems this site is updated better than the canonical
download.savannah.gnu.org (which depends on mirror propagation).
 | 
 | 
 | 
 | 
Fixed by using font-lock-ensure instead
 | 
 | 
Mainly by reordering definitions so that functions are not used before
defined.  There are a couple of places where the compiler and I
disagree (it complains withing eval-after-load), and a valid complain
about functions defined via geiser-popup--define that should be
addressed).
 | 
 | 
 | 
 | 
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.
 | 
 | 
 | 
 | 
 | 
 | 
API for test suites is defined by SRFI-64.
 | 
 | 
Exceptions are defined by R6RS, SRFI-18 and SRFI-34.
 | 
 | 
I kind of dislike completion on symbols, because a quote reads to me as
'stop evaluating', and a symbol per se has infinite possible
conversions.  But, on the other hand, not completing has no practical
advantage, and, moreover, we're already completing symbols inside quoted
lists (e.g. try M-TAB next to `'(defi`)), so my prejudices are not even
consistent.  So here we go!
 | 
 | 
 | 
 | 
 | 
 | 
- Also adds page breaks to geiser-chicken.el
 | 
 | 
Move general indentation rules to "geiser-syntax".
 | 
 | 
 | 
 | 
 | 
 | 
Move general RNRS/SRFI keywords from "geiser-chicken" to "geiser-syntax".
 | 
 | 
Use this function instead of repeating the same code in each
implementation.
 | 
 | 
Many chickeners use prefixes when importing eggs, which breaks
completions. This commit adds the ability to define custom prefix
delimiters, with : and # pre-defined due to their common usage.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
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
 | 
 | 
 | 
 | 
 |