dotemacs

parens.texi (30510B)

---

 @node Between the parens, Cheat sheet, The REPL, Top
 @chapter Between the parens
 
 A good REPL is a must, but just about half the story of a good Scheme
 hacking environment.  Well, perhaps a bit more than a half; but, at any
 rate, one surely needs also a pleasant way of editing source code.  Don't
 pay attention to naysayers: Emacs comes with an excellent editor
 included for about any language on Earth, and just the best one when
 that language is sexpy (especially if you use
 @ifhtml
 @ref{paredit,,Paredit}).
 @end ifhtml
 @ifnothtml
 Paredit).
 @end ifnothtml
 Geiser's support for writing Scheme code adds to Emacs'
 @code{scheme-mode}, rather than supplanting it; and it does so by means
 of a minor mode (unimaginatively dubbed @code{geiser-mode}) that defines
 a bunch of new commands to try and, with the help of the same Scheme
 process giving you the REPL, make those Scheme buffers come to life.
 
 @menu
 * Activating Geiser::
 * The source and the REPL::
 * Documentation helpers::
 * To eval or not to eval::
 * To err perchance to debug::
 * Jumping around::
 * Geiser writes for you::
 @end menu
 
 @node Activating Geiser, The source and the REPL, Between the parens, Between the parens
 @section Activating Geiser
 
 @cindex geiser-mode
 @img{geiser-mode, right}
 With Geiser installed following any of the
 procedures described in @ref{The quick and easy way} or @ref{From the
 source's mouth}, Emacs will automatically activate @i{geiser-mode} when
 opening a Scheme buffer.  Geiser also instructs Emacs to consider files
 with the extension @file{rkt} part of the family, so that, in principle,
 there's nothing you need to do to ensure that Geiser's extensions will
 be available, out of the box, when you start editing Scheme code.
 
 Indications that everything is working according to plan include the
 'Geiser' minor mode indicator in your mode-line and the appearance of a
 new entry for Geiser in the menu bar.  If, moreover, the mode-line
 indicator is the name of a Scheme implementation, you're indeed in a
 perfect world; otherwise, don't despair and keep on reading: i'll tell
 you how to fix that in a moment.
 
 @cindex geiser-mode commands
 The menu provides a good synopsis of everything Geiser brings to the
 party, including those keyboard shortcuts we Emacsers love.  If you're
 seeing the name of your favourite Scheme implementation in the
 mode-line, have a running REPL and are comfortable with Emacs, you can
 stop reading now and, instead, discover Geiser's joys by yourself.  I've
 tried to make Geiser as self-documenting as any self-respecting Emacs
 package should be.  If you follow this route, make sure to take a look at
 Geiser's customization buffers (@kbd{M-x customize-group @key{RET}
 geiser}): there's lot of fine-tuning available there.  You might also
 want to take a glance at
 @ifhtml
 our @ref{Cheat sheet,,cheat sheet}.
 @end ifhtml
 @ifnothtml
 the tables in @pxref{Cheat sheet, our cheat sheet}.
 @end ifnothtml
 
 Since @i{geiser-mode} is a minor mode, you can toggle it with
 @kbd{M-x geiser-mode}, and control its activation in hooks with the
 functions @code{turn-on-geiser-mode} and @code{turn-off-geiser-mode}.
 If, for some reason i cannot fathom, you prefer @i{geiser-mode} not
 to be active by default, customizing @code{geiser-mode-auto-p} to
 @code{nil} will do the trick.
 
 @cindex scheme file extensions
 And if you happen to use a funky extension for your Scheme files that is
 not recognised as such by Emacs, just tell her about it with:
 
 @example
 (add-to-list 'auto-mode-alist '("\\.funky-extension\\'" . scheme-mode))
 @end example
 
 @cindex useless wretch
 Now, @i{geiser-mode} is just a useless wretch unless there's a running
 Scheme process backing it up.  Meaning that virtually all the commands it
 provides require a REPL up and running, preferably corresponding to
 the correct Scheme implementation.  In the following section, we'll see
 how to make sure that that's actually the case.
 
 @node The source and the REPL, Documentation helpers, Activating Geiser, Between the parens
 @section The source and the REPL
 
 As i've already mentioned a couple of times, @i{geiser-mode} needs a
 running REPL to be operative.  Thus, a common usage pattern will be
 for you to first call @code{geiser}
 @ifhtml
 (or @ref{choosing-impl,,one of its variants}),
 @end ifhtml
 @ifnothtml
 (or one of its variants, e.g. @code{run-guile}),
 @end ifnothtml
 and then open some Scheme files;
 but there's nothing wrong in first opening a couple Scheme buffers and
 then starting the REPL (you can even find it more convenient, since
 pressing @kbd{C-c C-z} in a Scheme buffer will start the REPL for
 you).  Since Geiser supports more than one Scheme implementation, though,
 there's the problem of knowing which of them is to be associated with
 each Scheme source file.  Serviceable as it is, @i{geiser-mode} will try
 to guess the correct implementation for you, according to the algorithm
 described below.
 @ifhtml
 If you find that Geiser is already guessing right the Scheme
 implementation, feel free to skip to the @ref{switching-repl-buff,,next
 subsection}.
 @end ifhtml
 
 @subsubheading How Geiser associates a REPL to your Scheme buffer
 @cindex scheme implementation, choosing
 @anchor{repl-association} To determine what Scheme implementation
 corresponds to a given source file, Geiser uses the following algorithm:
 
 @enumerate
 @item
 If the file-local variable @code{geiser-scheme-implementation} is
 defined, its value is used.  A common way of setting buffer-local
 variables is to put them in a comment near the beginning of the file,
 surrounded by @code{-*-} marks, as in:
 
 @example
 ;; -*- geiser-scheme-implementation: guile -*-
 @end example
 
 @item
 If you've customized @code{geiser-active-implementations} so that it's a
 single-element
 @ifhtml
 list (as explained in @ref{choosing-impl,,here}),
 @end ifhtml
 @ifnothtml
 list,
 @end ifnothtml
 that element is used as the chosen implementation.
 @item
 The contents of the file is scanned for hints on its associated
 implementation.  For instance, files that contain a @code{#lang}
 directive will be considered Racket source code, while those with a
 @code{define-module} form in them will be assigned to a Guile REPL.
 @item
 The current buffer's file name is checked against the rules given in
 @code{geiser-implementations-alist}, and the first match is applied.  You
 can provide your own rules by customizing this variable, as explained
 below.
 @item
 If we haven't been lucky this far and you have customized
 @code{geiser-default-implementation} to the name of a supported
 implementation, we'll follow your lead.
 @item
 See?  That's the problem of being a smart aleck: one's always outsmarted
 by people around.  At this point, @i{geiser-mode} will humbly give up and
 ask you to explicitly choose the Scheme implementation.
 @end enumerate
 
 As you can see in the list above, there are several ways to influence
 Geiser's guessing by means of customizable variables.  The most direct (and
 most impoverishing) is probably limiting the active implementations to a
 single one, while customizing @code{geiser-implementations-alist} is the
 most flexible (and, unsurprisingly, also the most complex).  Here's the
 default value for the latter variable:
 
 @example
 (((regexp "\\.scm$") guile)
  ((regexp "\\.ss$") racket)
  ((regexp "\\.rkt$") racket))
 @end example
 
 @noindent
 which describes the simple heuristic that files with @file{.scm} as
 extension are by default associated to a Guile REPL while those ending
 in @file{.ss} or @file{.rkt} correspond to Racket's implementation (with
 the caveat that these rules are applied only if the previous heuristics
 have failed to detect the correct implementation, and that they'll match
 only if the corresponding implementation is active).  You can add rules
 to @code{geiser-implementations-alist} (or replace all of them) by
 customizing it.  Besides regular expressions, you can also use a
 directory name; for instance, the following snippet:
 
 @example
 (eval-after-load "geiser-impl"
   '(add-to-list 'geiser-implementations-alist
                 '((dir "/home/jao/prj/frob") guile)))
 @end example
 
 @noindent
 will add a new rule that says that any file inside my
 @file{/home/jao/prj/frob} directory (or, recursively, any of its
 children) is to be assigned to Guile.  Since rules are first matched,
 first served, this new rule will take precedence over the default ones.
 
 @cindex autostart REPL
 @cindex start REPL, automatically
 A final tip: if you want Geiser to start automatically a REPL for you if
 it notices that there's no one active when it enters @i{geiser-mode},
 you can customize @code{geiser-mode-start-repl-p} to @code{t}.
 
 @subsubheading Managing multiple scheme projects
 @cindex dir-locals
 @cindex project.el
 @cindex projectile
 @cindex projects
 @anchor{repl-per-project} By default, Geiser will re-use a single REPL
 for all buffers sharing the same scheme implementation.  This works well
 enough in many cases, but may become problematic (or at least annoying)
 when working on multiple projects with separate dependencies and include
 paths.
 
 @cindex geiser-repl-per-project-p
 Geiser provides optional support for using separate REPLs for each
 project, which can be enabled by customizing
 @code{geiser-repl-current-project-function} and selecting your Emacs
 project-management library of choice (eg. @code{project.el} or
 @code{projectile}).  With this configured, if you want new REPLs to
 automatically associate themselves with the current project, so that all
 Geiser commands will ignore REPLs that are not associated with the
 project, customize the toggle @code{geiser-repl-per-project-p} to
 @code{t} and you're all set up.
 
 @cindex geiser-repl-add-project-path-p
 This can be very convenient when used with a @file{.dir-locals.el} in
 the project root to set include paths, ensuring that Geiser REPLs will
 always know where to find your project's modules or dependencies.
 Geiser automatically handles the common case of the project root
 belonging to the load path: unless you tell it otherwise (using the
 customisable flag @code{geiser-repl-add-project-path-p}, which defaults
 to @code{t}), it will add the result of calling
 @code{geiser-repl-current-project-function} to the REPLs load path on
 startup.
 
 @subsubheading Switching between source files and the REPL
 @cindex switching to REPL
 @cindex switching to source
 @anchor{switching-repl-buff} Once you have a working @i{geiser-mode},
 you can switch from Scheme source buffers to the REPL or @kbd{C-c
 C-z}.  Those shortcuts map to the interactive command
 @code{geiser-repl-switch}.
 
 @cindex switching to module
 If you use a numeric prefix, as in @kbd{C-u C-c C-z}, besides being
 teleported to the REPL, the latter will switch to the namespace of the
 Scheme source file, as if you had used @kbd{C-c C-m} in the REPL, with
 the source file's module as argument;
 cf. discussion in
 @altr{Switching context,,Switching context,. This}
 command is also bound to @kbd{C-c C-a}.
 
 Once you're in the REPL, the same @kbd{C-c C-z} shortcut will bring
 you back to the buffer you jumped from, provided you don't kill the
 Scheme process in between.  This is why the command is called
 @i{geiser-repl-switch} instead of @i{switch-to-repl}, and what makes it
 really handy, if you ask me.
 
 @cindex switching schemes
 If for some reason you're not happy with the Scheme implementation that
 Geiser has assigned to your file, you can change it with @kbd{C-c C-s},
 and you probably should take a look at
 @ifhtml
 @ref{repl-association,,the previous subsection}
 @end ifhtml
 @ifnothtml
 the previous subsection
 @end ifnothtml
 to make sure that Geiser
 doesn't get confused again.
 
 @subsubheading A note about context
 As explained before (@pxref{Modus operandi}), all Geiser activities take
 place in the context of the @i{current namespace}, which, for Scheme
 buffers, corresponds to the module that the Scheme implementation
 associates to the source file at hand (for instance, in Racket, there's
 a one-to-one correspondence between paths and modules, while Guile
 relies on explicit @code{define-module} forms in the source file).
 
 Now that we have @code{geiser-mode} happily alive in our Scheme buffers
 and communicating with the right REPL instance, let us see what it
 can do for us, besides jumping to and fro.
 
 @node Documentation helpers, To eval or not to eval, The source and the REPL, Between the parens
 @section Documentation helpers
 
 @subsubheading Autodoc redux
 
 @cindex autodoc, in scheme buffers
 The first thing you will notice by moving around Scheme source is that,
 every now and then, the echo area lights up with the same autodoc
 messages we know and love from our REPL forays.  This happens every
 time the Scheme process is able to recognise an identifier in the
 buffer, and provide information either on its value (for variables) or
 on its arity and the name of its formal arguments (for procedures and
 macros).  That information will only be available if the module the
 identifier belongs to has been loaded in the running Scheme image.  So it
 can be the case that, at first, no autodoc is shown for identifiers
 defined in the file you're editing.  But as soon as you evaluate them
 (either individually or collectively using any of the devices described
 in @ref{To eval or not to eval}) their signatures will start appearing
 in the echo area.
 
 @cindex disabling autodoc
 @cindex manual autodoc
 Autodoc activation is controlled by a minor mode, @code{geiser-autodoc},
 which you can toggle with @kbd{M-x geiser-autodoc-mode}, or its associated
 keyboard shortcut, @kbd{C-c C-d a}.  That @t{/A} indicator in the
 mode-line is telling you that autodoc is active.  If you prefer that it
 be inactive by default (e.g., because you're connecting to a really
 remote scheme and want to minimize network exchanges), just set
 @code{geiser-mode-autodoc-p} to @code{nil} in your customization files.
 Even when autodoc mode is off, you can use @code{geiser-autodoc-show},
 bound by default to @kbd{C-c C-d s}, to show the autodoc string for the
 symbol at point.
 
 @cindex autodoc explained
 @img{autodoc-scm, right}
 The way autodoc displays information deserves
 some explanation.  It will first show the name of the module where the
 identifier at hand is defined, followed by a colon and the identifier
 itself.  If the latter corresponds to a procedure or macro, it will be
 followed by a list of argument names, starting with the ones that are
 required.  Then there comes a list of optional arguments, if any,
 enclosed in parentheses.  When an optional argument has a default value
 (or a form defining its default value), autodoc will display it after
 the argument name.  When the optional arguments are keywords, their names
 are prefixed with ``#:'' (i.e., their names @i{are} keywords).  An
 ellipsis (@dots{}) serves as a marker of an indeterminate number of
 parameters, as is the case with @i{rest} arguments or when autodoc
 cannot fathom the exact number of arguments (this is often the case with
 macros defined using @code{syntax-case}).  Another way in which autodoc
 displays its ignorance is by using an underscore to display parameters
 whose name is beyond its powers.
 
 @img{autodoc-multi, right}
 It can also be the case that a function or
 macro has more than one signature (e.g., functions defined using
 @code{case-lambda}, or some @code{syntax-rules} macros, for which Geiser
 has often the black magic necessary to retrieve their actual arities).
 In those cases, autodoc shows all known signatures (using the above
 rules for each one) separated by a vertical bar (|).
 
 As you have already noticed, the whole autodoc message is enclosed in
 parentheses.  After all, we're talking about Scheme here.
 
 @cindex autodoc for variables
 @img{autodoc-var, right}
 Finally, life is much easier when your cursor
 is on a symbol corresponding to a plain variable: you'll see in the echo
 area its name, preceded by the module where it's defined, and followed
 by its value, with an intervening arrow for greater effect.  This time,
 there are no enclosing parentheses (i hope you see the logic in my
 madness).
 
 @cindex autodoc customized
 You can change the way Geiser displays the module/identifier combo by
 customizing @code{geiser-autodoc-identifier-format}.  For example, if you
 wanted a tilde surrounded by spaces instead of a colon as a separator,
 you would write something like:
 
 @example
 (setq geiser-autodoc-identifier-format "%s ~ %s")
 @end example
 
 @noindent
 in your Emacs initialisation files.  There's also a face
 (@code{geiser-font-lock-autodoc-identifier}) that you can customize (for
 instance, with @kbd{M-x customize-face}) to change the appearance of the
 text.  And another one (@code{geiser-font-lock-autodoc-current-arg}) that
 controls how the current argument position is highlighted.
 
 @subsubheading Other documentation commands
 
 @anchor{doc-browser}Sometimes, autodoc won't provide enough information
 for you to understand what a function does.  In those cases, you can ask
 Geiser to ask the running Scheme for further information on a given
 identifier or module.
 
 @cindex documentation for symbol
 @cindex docstrings, maybe
 For symbols, the incantation is @kbd{M-x geiser-doc-symbol-at-point}, or
 @kbd{C-c C-d C-d} for short.  If the associated Scheme supports
 docstrings (as, for instance, Guile does), you'll be teleported to a new
 Emacs buffer displaying Geiser's documentation browser, filled with
 information about the identifier, including its docstring (if any;
 unfortunately, that an implementation supports docstrings doesn't mean
 that they're used everywhere).
 
 @imgc{docstring}
 
 Pressing @kbd{q} in the documentation buffer will bring you back,
 enlightened, to where you were.  There's also a handful of other
 navigation commands available in that buffer, which you can discover by
 means of its menu or via the good old @kbd{C-h m} command.  And feel free
 to use the navigation buttons and hyperlinks that justify my calling
 this buffer a documentation browser.
 
 For Racket, which does not support docstrings out of the box, this
 command will provide less information, but the documentation browser
 will display the corresponding contract when it's available, as well as
 some other tidbits for re-exported identifiers.
 
 @imgc{docstring-racket}
 
 You can also ask Geiser to display information about a module, in the
 form of a list of its exported identifiers, using @kbd{C-c C-d C-m},
 exactly as you would do in
 @altr{repl-mod,the REPL,The REPL,.}
 
 In both cases, the documentation browser will show a couple of buttons
 giving you access to further documentation.  First, you'll see a button
 named @i{source}: pressing it you'll jump to the symbol's definition.
 The second button, dubbed @i{manual}, will open the Scheme
 implementation's manual page for the symbol at hand.  For Racket, that
 will open your web browser displaying the corresponding reference's page
 (using the HTML browser in Racket's configuration, which you can edit in
 DrRacket's preferences dialog, or by setting
 @code{plt:framework-pref:external-browser} directly in
 @file{~/.racket/racket-prefs.rktd}), while in Guile a lookup will be
 performed in the texinfo manual.
 
 @cindex Guile info nodes
 For Guile, the manual lookup uses the info indexes in the standard
 Guile info nodes, which are usually named ``guile'' or ``guile-2.0''.
 If yours are named differently, just add your name to the customizable
 variable @code{geiser-guile-manual-lookup-nodes}.
 
 A list of all navigation commands in the documentation browser is
 available in
 @altr{Documentation browser,our cheat-sheet,Documentation browser,.}
 
 @cindex opening manual pages
 You can also skip the documentation browser and jump directly to the
 manual page for the symbol at point with the command
 @code{geiser-doc-look-up-manual}, bound to @kbd{C-c C-d i}.
 
 @node To eval or not to eval, To err perchance to debug, Documentation helpers, Between the parens
 @section To eval or not to eval
 
 @cindex philosophy
 @cindex incremental development
 One of Geiser's main goals is to facilitate incremental development.
 You might have noticed that i've made a big fuss of Geiser's ability to
 recognize context, by dint of being aware of the namespace where its
 operations happen.
 
 That awareness is especially important when evaluating code in your
 scheme buffers, using the commands described below.  They allow you to
 send code to the running Scheme with a granularity ranging from whole
 files to single s-expressions.  That code will be evaluated in the module
 associated with the file you're editing, allowing you to redefine values
 and procedures to your heart's (and other modules') content.
 
 @cindex incremental development, evil
 Macros are, of course, another kettle of fish: one needs to re-evaluate
 uses of a macro after redefining it.  That's not a limitation imposed by
 Geiser, but a consequence of how macros work in Scheme (and other
 Lisps).  There's also the risk that you lose track of what's actually
 defined and what's not during a given session.  But,
 @uref{https://jaortega.wordpress.com/2009/03/29/from-my-cold-prying-hands,
 in my opinion}, those are limitations we lispers are aware of, and they
 don't force us to throw the baby with the bathwater and ditch
 incremental evaluation.  Some people disagree; if you happen to find
 @uref{https://blog.racket-lang.org/2009/03/the-drscheme-repl-isnt-the-one-in-emacs.html,
 their arguments} convincing, you don't have to throw away Geiser
 together with the baby: @kbd{M-x geiser-restart-repl} will let you
 restart the REPL as many times as you see fit.  Moreover, you can invoke
 @kbd{geiser-compile-current-buffer} and @kbd{geiser-load-current-buffer}
 with a prefix argument (that'd be something like @kbd{C-u C-c C-k} for
 compilation, for instance), to tell Geiser to restart the REPL
 associated with a buffer before compiling or loading its current
 contents.
 
 @cindex evaluation
 @cindex incremental development, not evil
 For all of you auld bearded lispers still with me, here are some of the
 commands performing incremental evaluation in Geiser.
 
 @code{geiser-eval-last-sexp}, bound to @kbd{C-x C-e}, will eval the
 s-expression just before point.  If you use a prefix, as in @kbd{C-u C-x
 C-e}, besides evaluating it the expression is inserted in the the
 buffer.
 
 @code{geiser-eval-definition}, bound to @kbd{C-M-x}, finds the topmost
 definition containing point and sends it for evaluation.  The variant
 @code{geiser-eval-definition-and-go} (@kbd{C-c M-e}) works in the same
 way, but it also teleports you to REPL after the evaluation.
 
 @code{geiser-eval-region}, bound to @kbd{C-c C-r}, evals the current
 region.  Again, there's an @i{and-go} version available,
 @code{geiser-eval-region-and-go}, bound to @kbd{C-c M-r}.  And, if you
 want to extend the evaluated region to the whole buffer, there is
 @code{geiser-eval-buffer}, bound to @kbd{C-c C-b} and its companion
 @code{geiser-eval-buffer-and-go}, bound to @kbd{C-c M-b}.
 
 @cindex evaluating images
 @cindex image display
 For all the commands above, the result of the evaluation is displayed in
 the minibuffer, unless it causes a (Scheme-side) error (@pxref{To err
 perchance to debug}), or, for schemes supporting them (such as Racket),
 the evaluation yields an image, in which case you'll see it in popping
 up in the Geiser debug buffer (if your Emacs runs under the auspices of
 a graphical toolkit), or via an external viewer if you set
 @code{geiser-image-viewer} to the path of an appropriate visualization
 program (see also @ref{Seeing is believing} for more on image support).
 
 At the risk of repeating myself, i'll remind you that all these
 evaluations will take place in the namespace of the module corresponding
 to the Scheme file from which you're sending your code, which, in
 general, will be different from the REPL's current module.  And, if all
 goes according to plan, (re)defined variables and procedures should be
 immediately visible inside and, if exported, outside their module.
 
 Besides evaluating expressions, definitions and regions, you can also
 macro-expand them.  The corresponding key bindings start with the prefix
 @kbd{C-c C-m} and end, respectively, with @kbd{C-e}, @kbd{C-x} and
 @kbd{C-r}.  The result of the macro expansion always appears in a pop up
 buffer.
 
 @cindex interrupt evaluation
 All the evaluations and expansions performed by the commands above are
 asynchronous@footnote{For local REPLs, where we can easily send an
 interrupt signal to the scheme process; remote REPLs are another kettle
 of fish in this regard, and generally interruptions are supported:
 you'll just have to kill the connection if caught in a loop.}, so that
 you can move around while the answer is being computed.  The command
 @code{geiser-eval-interrupt}, bound to @kbd{C-c C-i} will interrupt any
 on-going evaluation and, when the scheme implementation supports a
 debugger, bring you to a buffer where you can perform buffer actions in
 the interrupted evaluation's context.
 
 Oh, didn't i mention we have support for debuggers?  Let's talk about
 that next.
 
 @node To err perchance to debug, Jumping around, To eval or not to eval, Between the parens
 @section To err: perchance to debug
 
 @cindex to err is schemey
 @cindex backtraces
 When an error occurs during evaluation, it will be reported according to
 the capabilities of the underlying Scheme REPL.
 
 @cindex error buffer
 In most schemes, you'll be presented with a backtrace, in a new buffer
 where file paths locating the origin of the error are click-able (you
 can navigate them using the @key{TAB} key, and use @key{RET} or the
 mouse to jump to the offending spot; or invoke Emacs' stock commands
 @code{next-error} and @code{previous-error}, bound to @kbd{M-g n} and
 @kbd{M-g p} by default).
 
 @imgc{eval-error}
 
 By default, Geiser will tele-transport your pointer to the debug buffer:
 if you prefer to stay in the source buffer, set
 @code{geiser-debug-jump-to-debug} to nil.
 
 For schemes with good debug support (Guile is one), the debug buffers
 offer a @i{debugging menu}, accesible via the @code{,} (that's a comma)
 key.  If you press it, a transient menu will appear, offering you a
 variety of actions, including showing local variable values or a more
 detailed backtrace or frame display.  This is the same interface you'll
 encounter the in case of interrupted evaluations, either by your
 explicit @kbd{C-c C-i} command or because a breakpoint has been
 previosuly set.
 
 In addition, Geiser will sometimes report warnings for otherwise
 successful evaluations.  In those cases, it won't enter the debugger,
 just report the warnings in a debug buffer.
 
 @node Jumping around, Geiser writes for you, To err perchance to debug, Between the parens
 @section Jumping around
 
 @cindex jumping in scheme buffers
 This one feature is as sweet as it is easy to explain: @kbd{M-.}
 (@code{geiser-edit-symbol-at-point}) will open the file where the
 identifier around point is defined and land your point on its
 definition.  To return to where you were, press @kbd{M-,}
 (@code{geiser-pop-symbol-stack}).  This command works also for module
 names: Geiser first tries to locate a definition for the identifier at
 point and, if that fails, a module with that name; if the latter
 succeeds, the file where the module is defined will pop up.
 
 Sometimes, the underlying Scheme will tell Geiser only the file where
 the symbol is defined, but Geiser will use some heuristics (read,
 regular expressions) to locate the exact line and bring you there.  Thus,
 if you find Geiser systematically missing your definitions, send a
 message to the @email{geiser-users@@nongnu.org, mailing list}, and we'll
 try to make the algorithm smarter.
 
 @cindex jumping customized
 You can control how the destination buffer pops up by setting
 @code{geiser-edit-symbol-method} to either @code{nil} (to open the file
 in the current window), @code{'window} (other window in the same frame)
 or @code{'frame} (in a new frame).
 
 @node Geiser writes for you,  , Jumping around, Between the parens
 @section Geiser writes for you
 
 @cindex completion in scheme buffers
 No self-respecting programming mode would be complete without
 completion.  In geiser-mode, identifier completion is bound to
 @kbd{M-@key{TAB}}, and will offer all visible identifiers starting with
 the prefix before point.  Visible here means all symbols imported or
 defined in the current namespace plus locally bound ones.  E.g., if
 you're at the end of the following partial expression:
 
 @example
 (let ((default 42))
   (frob def
 @end example
 
 @noindent
 and press @kbd{M-@key{TAB}}, one of the possible completions will be
 @code{default}.
 
 @cindex partial completion
 After obtaining the list of completions from the running Scheme, Geiser
 uses the standard Emacs completion machinery to display them.  That
 means, among other things, that partial completion is available: just
 try to complete @code{d-s} or @code{w-o-t-s} to see why this is a good
 thing.  Partial completion won't work if you have disabled it globally in
 your Emacs configuration: if you don't know what i'm talking about,
 never mind: Geiser's partial completion will work for you out of the
 box.
 
 @cindex smart tabs
 If you find the @kbd{M} modifier annoying, you always have the option to
 activate @code{geiser-smart-tab-mode}, which will make the @key{TAB} key
 double duty as the regular Emacs indentation command (when the cursor is
 not near a symbol) and Geiser's completion function.  If you want this
 smarty pants mode always on in Scheme buffers, customize
 @code{geiser-mode-smart-tab-p} to @code{t}.
 
 @cindex completion for module names
 Geiser also knows how to complete module names: if no completion for the
 prefix at point is found among the currently visible bindings, it will
 try to find a module name that matches it.  You can also request
 explicitly completion only over module names using @kbd{M-`} (that's a
 backtick).
 
 Besides completion, there's also this little command,
 @code{geiser-squarify}, which will toggle the delimiters of the
 innermost list around point between round and square brackets.  It is
 bound to @kbd{C-c C-e [}.  With a numeric prefix (as in, say, @kbd{M-2
 C-c C-e [}), it will perform that many toggles, forward for positive
 values and backward for negative ones.
 
 @subheading Caveat about completion
 
 It is possible for Geiser to hang your Emacs process when trying to
 complete symbols. This can happen in the REPL itself or even in a
 Scheme buffer that is attached to the REPL process. For more details
 on how to fix this problem, @ref{completion-caveat,,Caveat about
 completion & the REPL}
 
 @c Local Variables:
 @c mode: texinfo
 @c TeX-master: "geiser"
 @c End: