emacs and scheme talk to each other https://jao.io/cgit/geiser/atom?h=0.5 2013-09-26T17:08:19Z 2013-09-26T17:08:19Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-09-26T17:08:19Z urn:sha1:368a6ab958c1f8c85cbf94d8982b851959b19798 ... so that we don't end up with a blank, useless buffer around. 2013-09-25T03:10:00Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-09-25T03:10:00Z urn:sha1:5c08caccbec41d9c14781ece9a336f91da2c7ab8 And, if you happen to be launching it all the time, a way of skipping them via a customizable variable. Should address issue #15. 2013-09-19T07:29:16Z Steve Purcell steve@sanityinc.com 2013-09-19T07:29:16Z urn:sha1:5f7e332259eb4b0bd46c165384e85d5a4d9d8908 This will allow `package-buffer-info` to parse the description out of the file. 2013-09-19T01:24:55Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-09-19T01:24:55Z urn:sha1:f92da84f3e3ffbd971c6cf71fb33cf0afd086229 Everything in geiser.el needs one, so that the generated geiser-autoloads.el initializes variables and the like properly automatically. 2013-09-19T00:37:06Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-09-19T00:37:06Z urn:sha1:888aa00c83742a5934b53b707f1f4330e93fb008 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. 2013-08-25T23:36:58Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-08-25T23:36:58Z urn:sha1:5334b5c3ec6792c8be57211119f2a312a958cab9 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. 2013-08-25T05:12:07Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-08-25T05:12:07Z urn:sha1:2a903ff81c1696a05d99bc78ebc9558f64b41c81 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. 2013-08-25T04:22:05Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-08-25T04:22:05Z urn:sha1:f417431b8b72fbc6e98c1310b99cba50882b13d2 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. 2013-08-11T22:31:12Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-08-11T22:31:12Z urn:sha1:600ef3a419f61c738f0e054bad4c02925cb964f0 ... 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. 2013-07-29T00:34:22Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-07-29T00:34:22Z urn:sha1:418efac4c62fc4133b2d87aabd318b3567ecf3c1 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.