| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
The convention doesn't say much about what parts of the code are
supposed to be part of that sections and what parts belong in a
subsequent section. Here we put the `require' forms in this section
and maybe some setup code, that's a popular approach.
In most cases there was " " where we now insert "Code:". They both
serve a similar purpose and we keep the former because some users
depend on that for navigation. We even add this " " in libraries
where it previously was missing.
In some cases the permission statement was followed by a commentary,
which obviously does not belong in the "Code:" section. In such cases
add the conventional "Commentary:" section.
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
|
|
|
|
|
|
|
|
Add a new customization variable for an init file to be read on startup of a
Chez REPL, where user code can be defined. The usage is copied from the
equivalent Racket init file, to avoid an error if the file has not been created.
|
|
|
|
|
|
|
|
when eval (make-violation)
it shall return: \#<condition &violation>
but previous impletement will treat it as an ERROR.
|
|
|
|
- Capture exceptions of ChezScheme
- handles multi-value return
|
|
`shell-command` assumes Bourne-shell-compatible quoting, which
doesn't work when the user isn't using a Bourne-compatible shell.
Instead of futzing about with quoting, we can just use `process-lines`
to execute a process and pass it arguments directly.
|
|
|
|
|
|
|
|
|
