Thanks to Inge Gutheil for raising this problem.
* doc/ref/api-control.texi (Dynamic Wind): Remove doc for
scm_t_dynwind_flags, and change uses of scm_t_dynwind_flags to int.
Mention possible flags inside doc for scm_dynwind_begin instead.
Similarly for scm_t_wind_flags. In this case the doc on possible
flags is moved to after the four functions that can use them.
* libguile/dynwind.c (scm_dynwind_begin): Change scm_t_dynwind_flags
to int.
(scm_dynwind_unwind_handler): Change scm_t_wind_flags to int.
(scm_dynwind_rewind_handler): Ditto.
(scm_dynwind_unwind_handler_with_scm): Ditto.
(scm_dynwind_rewind_handler_with_scm): Ditto.
* libguile/dynwind.h (SCM_F_DYNWIND_REWINDABLE): Use #define instead
of typedef enum.
(SCM_F_WIND_EXPLICITLY): Ditto.
(function declarations): Change scm_t_dynwind_flags and
scm_t_wind_flags to int.
* test-suite/standalone/test-unwind.c (check_cont_body): Change
scm_t_dynwind_flags to int.
* doc/ref/api-memory.texi (Garbage Collection
Functions)[scm_gc_protect_object]: Explain that it's equivalent to
storing in a global variable.
* doc/ref/api-smobs.texi (Smobs)[scm_set_smob_free]: Expand on the
relationship with `scm_gc_malloc ()'.
[scm_set_smob_mark]: Explain that it's usually not needed.
* NEWS
* doc/ref/scheme-scripts.texi: doc updates for character encoding of
source code
* doc/ref/api-evaluation.texi: doc updates for character encoding of
source code
i.e. put the extensions where they need to be, and delete
ice-9-debugger-extensions.scm.
* doc/ref/api-debug.texi (Single Stepping through a Procedure's Code):
Change mentions of (ice-9 debugging ice-9-debugger-extensions)
module to whatever is appropriate now (or just remove them).
* module/Makefile.am (NOCOMP_SOURCES): Remove
ice-9-debugger-extensions.scm.
* module/ice-9/debugger.scm (debug-trap): Move here from
ice-9-debugger-extensions.scm.
* module/ice-9/debugger/command-loop.scm ("continue", "finish",
"step", "next"): Move here from ice-9-debugger-extensions.scm.
* module/ice-9/debugger/commands.scm (assert-continuable, continue,
finish, step, next): Move here from ice-9-debugger-extensions.scm.
* module/ice-9/debugging/breakpoints.scm: Don't use
ice-9-debugger-extensions module.
* module/ice-9/debugging/ice-9-debugger-extensions.scm: Removed.
* module/ice-9/debugging/trace.scm, module/ice-9/debugging/traps.scm:
Remove more old version code.
* module/ice-9/debugging/traps.scm (guile-trap-features): Hardcoded as
'(tweaking).
In particular avoid any suggestion that the API uses the
property list format, i.e. (key1 value1 key2 value2 ...),
as opposed to the alist format that it actually does use.
Reported by Daniel Kraft <d@domob.eu>.
* doc/ref/api-binding.texi (Binding Reflection): Update documentation of
`defined?'.
* libguile/evalext.c (scm_defined_p): Expect a module as the second
argument, not a lexical environment.
because it looks better in the DVI output. Exceptions are
- wide examples, which would cause overfull hboxes if they
used the bigger @lisp font
- very large examples, which may look too big at the @lisp size.
* doc/ref/goops.texi (Getting Started): Renamed `Quick Start', to fit
better with following Tutorial. Also add a bit more text to the
Methods subsection.
* doc/ref/goops-tutorial.texi (Class Definition): Minor text
improvements. Change the class being defined to <my-complex>, to
reduce the confusion with the built in <complex> class.
* doc/ref/goops-tutorial.texi (Introduction): Merge this subsection's
non-duplicate text into the introductory text of the whole section,
then remove this subsection.
(Tutorial): Textual updates to introductory text.
(Class definition and instantiation): Rename `Class definition',
since that's all it covers. Remove unnecessary footnote about
loading (oop goops) module.
(All @nodes): Remove explicit up, next and prev nodes. (They make
the document harder to change.)
* doc/ref/goops.texi (Tutorial): Move from the end of the GOOPS
chapter to the beginning of it.
(Running GOOPS): Removed; useful text merged into containing
section.
Since continuation barriers protect against non-local exits, it makes
better sense to document them in the same section as continuations and
exceptions.
I don't believe this has ever been useful, and I doubt that we've
consistently incremented it in the past. The reality is that the
manual evolves with the rest of Guile, so Guile's version number
should apply to the manual too. It is conceivable that we might
one day revise the manual for an existing Guile release, so we keep
a REVISION number to cover that.
