change Scribble to complain about colliding tags
svn: r8025 original commit: fd1de94a484332ae57d648b83b32038011bace1b
This commit is contained in:
parent
87d0b9b732
commit
b030295bb3
|
@ -82,11 +82,11 @@ Now, the standard cut and paste operations work, and the user can even
|
|||
on the outside of the box is rearranged as the box changes
|
||||
sizes. Note that the box itself can be copied and pasted.
|
||||
|
||||
The content of an editor is made up of @deftech{snips}. An embedded
|
||||
editor is a single snip from the embedding editor's point-of-view. To
|
||||
encode immediate text, a snip can be a single character, but more
|
||||
often a snip is a sequence of adjacent characters on the same
|
||||
line. The @method[text% find-snip] method extracts a snip
|
||||
The content of an editor is made up of @defterm{@tech{snips}}. An
|
||||
embedded editor is a single snip from the embedding editor's
|
||||
point-of-view. To encode immediate text, a snip can be a single
|
||||
character, but more often a snip is a sequence of adjacent characters
|
||||
on the same line. The @method[text% find-snip] method extracts a snip
|
||||
from a text editor:
|
||||
|
||||
@schemeblock[
|
||||
|
@ -396,15 +396,15 @@ Graceful and extensible encoding of snips requires that
|
|||
@item{Some editors may require additional information to be stored
|
||||
about a snip; this information is orthogonal to the type-specific
|
||||
information stored by the snip itself. For example, a pasteboard
|
||||
needs to remember a snip's @techlink{location}, while a text editor does not
|
||||
need this information. If data is being cut and pasted from one
|
||||
pasteboard to another, then information about relative @techlink{location}s
|
||||
needs to be maintained, but this information should not inhibit
|
||||
pasting into an editor. Extra data is associated with a snip through
|
||||
@deftech{editor data} objects, instances of the
|
||||
@scheme[editor-data%] class; decoding requires that each editor data
|
||||
object has an @deftech{editor data class}, an instance of the
|
||||
@scheme[editor-data-class%] class.}
|
||||
needs to remember a snip's @techlink{location}, while a text editor
|
||||
does not need this information. If data is being cut and pasted from
|
||||
one pasteboard to another, then information about relative
|
||||
@techlink{location}s needs to be maintained, but this information
|
||||
should not inhibit pasting into an editor. Extra data is associated
|
||||
with a snip through @deftech{editor data} objects, which are
|
||||
instances of the @scheme[editor-data%] class; decoding requires that
|
||||
each editor data object has an @deftech{editor data class}, which is
|
||||
an instance of the @scheme[editor-data-class%] class.}
|
||||
|
||||
}
|
||||
|
||||
|
@ -415,7 +415,7 @@ Snip classes, snip data, and snip data classes solve problems related
|
|||
|
||||
@subsubsection[#:tag "editorsnipclasses"]{Snip Classes}
|
||||
|
||||
Each snip can be associated to a @deftech{snip class}. This ``class''
|
||||
Each snip can be associated to a @tech{snip class}. This ``class''
|
||||
is not a class description in the programmer's language; it is an
|
||||
object which provides a way to create new snips of the appropriate
|
||||
type from an encoded snip specification.
|
||||
|
@ -455,12 +455,12 @@ A snip class's name can also be just @scheme["(lib ...)"], which is
|
|||
While a snip belongs to an editor, the editor may store extra
|
||||
information about a snip in some specialized way. When the snip is to
|
||||
be encoded, this extra information needs to be put into an
|
||||
@deftech{editor data} object so that the extra information can be
|
||||
@tech{editor data} object so that the extra information can be
|
||||
encoded as well. In a text editor, extra information can be
|
||||
associated with ranges of @techlink{item}s, as well as snips.
|
||||
|
||||
Just as a snip must be associated with a snip class to be decoded (see
|
||||
@|snipclassdiscuss|), an editor data object needs an @deftech{editor
|
||||
@|snipclassdiscuss|), an editor data object needs an @tech{editor
|
||||
data class} for decoding. Every editor data class object can be added
|
||||
to the eventspace-specific @deftech{editor data class list}, returned
|
||||
by @scheme[get-the-editor-data-class-list]. Alternatively, like snip
|
||||
|
|
|
@ -8,17 +8,17 @@ For documentation purposes, the MrEd toolbox is organized into three
|
|||
|
||||
@itemize{
|
||||
|
||||
@item{The @deftech{windowing} toolbox, for implementing form-filling
|
||||
@item{The @deftech{windowing toolbox}, for implementing form-filling
|
||||
GUI programs (such as a database query window) using buttons, menus,
|
||||
text fields, and events. The windowing toolbox is described in
|
||||
@secref["windowing-overview"].}
|
||||
|
||||
@item{The @deftech{drawing} toolbox, for drawing pictures or
|
||||
@item{The @deftech{drawing toolbox}, for drawing pictures or
|
||||
implementing dynamic GUI programs (such as a video game) using
|
||||
drawing canvases, pens, and brushes. The drawing toolbox is
|
||||
described in @secref["drawing-overview"].}
|
||||
|
||||
@item{The @deftech{editor} toolbox, for developing traditional text
|
||||
@item{The @deftech{editor toolbox}, for developing traditional text
|
||||
editors, editors that mix text and graphics, or free-form layout
|
||||
editors (such as a word processor, HTML editor, or icon-based file
|
||||
browser). The editor toolbox is described in
|
||||
|
|
|
@ -109,7 +109,7 @@ In addition to dispatching events, the GUI classes also handle the
|
|||
graphical layout of windows. Our example frame demonstrates a simple
|
||||
layout; the frame's elements are lined up top-to-bottom. In general,
|
||||
a programmer specifies the layout of a window by assigning each GUI
|
||||
element to a parent @deftech{container}. A vertical container, such
|
||||
element to a parent @tech{container}. A vertical container, such
|
||||
as a frame, arranges its children in a column, and a horizontal
|
||||
container arranges its children in a row. A container can be a child
|
||||
of another container; for example, to place two buttons side-by-side
|
||||
|
@ -296,9 +296,9 @@ Menu bars, menus, and menu items are graphical elements, but not areas
|
|||
@item{@scheme[separator-menu-item%] --- a @deftech{separator} is
|
||||
an unselectable line in a menu or popup menu.}
|
||||
|
||||
@item{@scheme[menu-item%] --- a @deftech{menu item} is a selectable
|
||||
text item in a menu. When the item is selected, its callback procedure
|
||||
is invoked.}
|
||||
@item{@scheme[menu-item%] --- a @deftech{plain menu item} is a
|
||||
selectable text item in a menu. When the item is selected, its
|
||||
callback procedure is invoked.}
|
||||
|
||||
@item{@scheme[checkable-menu-item%] --- a @deftech{checkable menu
|
||||
item} is a text item in a menu; the user selects a checkable menu
|
||||
|
@ -405,7 +405,7 @@ Each @tech{containee}, or child, has the following properties:
|
|||
|
||||
@item{horizontal and vertical @deftech{stretchability} (on or off); and}
|
||||
|
||||
@item{horizontal and vertical @deftech{margins}.}
|
||||
@item{horizontal and vertical @tech{margins}.}
|
||||
|
||||
}
|
||||
|
||||
|
@ -822,7 +822,7 @@ Although a programmer has no direct control over the order in which
|
|||
|
||||
@subsection[#:tag "espacethreads"]{Eventspaces and Threads}
|
||||
|
||||
When a new eventspace is created, a corresponding @deftech{handler
|
||||
When a new eventspace is created, a corresponding @tech{handler
|
||||
thread} is created for the eventspace. When the system dispatches an
|
||||
event for an eventspace, it always does so in the eventspace's
|
||||
handler thread. A handler procedure can create new threads that run
|
||||
|
|
|
@ -435,7 +435,7 @@ special comment contains the comment text.}
|
|||
A text-mode reader for XML boxes.}]
|
||||
|
||||
|
||||
@defclass[comment-editor% editor% (readable<%>)]{
|
||||
@defclass[xml-editor% editor% (readable<%>)]{
|
||||
|
||||
Instantiated for DrScheme XML boxes in a @tech{WXME} stream for text
|
||||
mode.
|
||||
|
@ -469,7 +469,7 @@ Scheme boxes.}
|
|||
A text-mode reader for Scheme boxes.}]
|
||||
|
||||
|
||||
@defclass[comment-editor% editor% (readable<%>)]{
|
||||
@defclass[scheme-editor% editor% (readable<%>)]{
|
||||
|
||||
Instantiated for DrScheme Scheme boxes in a @tech{WXME} stream for text
|
||||
mode.
|
||||
|
@ -493,15 +493,15 @@ Generates an S-expression for the code in the box.}
|
|||
|
||||
@section{DrScheme Text Boxes}
|
||||
|
||||
@defmodule[wxme/scheme]
|
||||
@defmodule[wxme/text]
|
||||
|
||||
@in[wxme/scheme
|
||||
@in[wxme/text
|
||||
@defthing[reader (is-a?/c snip-reader<%>)]{
|
||||
|
||||
A text-mode reader for text boxes.}]
|
||||
|
||||
|
||||
@defclass[comment-editor% editor% (readable<%>)]{
|
||||
@defclass[text-editor% editor% (readable<%>)]{
|
||||
|
||||
Instantiated for DrScheme text boxes in a @tech{WXME} stream for text
|
||||
mode.
|
||||
|
|
Loading…
Reference in New Issue
Block a user