geiser-guile/elisp, branch 0.4 geiser and guile talk to each other https://jao.io/cgit/geiser-guile/atom?h=0.4 2013-04-21T00:45:28Z Fix for Racket compilation error jumping in REPL 2013-04-21T00:45:28Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-21T00:45:28Z urn:sha1:bfa5d426c48a075d1386f4feb8d6833ba6ba1670 The backtraces now display some leading whitespace, which the default compilation-mode regexps was making part of the file name. Racket: fixing error backtrace cleansing 2013-04-21T00:17:58Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-21T00:17:58Z urn:sha1:8c9313c3976cd8962edc2b5ee95b1168a3e21814 i.e., removing again references to geiser's innards Racket: fix for jump to manual for symbols not in the namespace 2013-04-17T16:14:31Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-17T16:14:31Z urn:sha1:8b16e095fd38bc3ca0c51b8b97b449f6a8d80e1b We had broken using the hint that `help` offers during our recent adventures... Racket: correct detection of manual lookup failures 2013-04-15T09:14:13Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-15T09:14:13Z urn:sha1:8c6eb94980cac77f22d8a972b08a0a2ed4d44b77 Still a tad messy, because we are always forcing a retort-syntax error and checking its ouput, but good enough for now. Racket: better help commands 2013-04-15T02:08:08Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-15T02:08:08Z urn:sha1:c00f24907cf87589f4b28885507443d419385502 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. Disabling company calls while the REPL is working 2013-04-14T01:15:52Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-14T01:15:52Z urn:sha1:8966cbbdc5615051bf0def94d7b6f18e4b295de3 A better solution to the funky filename problem 2013-04-13T03:22:20Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-13T03:22:20Z urn:sha1:3b5397c8dad34f9dfe83c2c44eeece0de9097df3 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. Another take at the fix (files with >, bleh) 2013-04-12T22:43:45Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-12T22:43:45Z urn:sha1:d494b97c34386470fa9b7ee7ddcc63c41b8c51ff Racket: accepting spaces within comint's prompt 2013-04-12T22:03:54Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-12T22:03:54Z urn:sha1:d59b4b1ffe2892d918ad9354c7a0b28f5f30de5f Since spaces are allowed inside filenames after all. A bit of documentation for the previous patches 2013-04-11T23:10:17Z Jose Antonio Ortega Ruiz jao@gnu.org 2013-04-11T23:05:34Z urn:sha1:65bc295b35beac42e410ae78a3077ce28f1e49a9