"hchild" (a list of horizontally-arrayed children), "vchild" (a
list of vertically-arrayed children), and "buffer" (the buffer
contained in a leaf window). Exactly one of these will be
- non-nil. Remember that "horizontally-arrayed" means
+ non-`nil'. Remember that "horizontally-arrayed" means
"side-by-side" and "vertically-arrayed" means "one above the
other".
7. Leaf windows also have markers in their `start' (the first buffer
position displayed in the window) and `pointm' (the window's
stashed value of `point'--see above) fields, while combination
- windows have nil in these fields.
+ windows have `nil' in these fields.
8. The list of children for a window is threaded through the `next'
and `prev' fields of each child window.
Extents can be zero-length, and will end up that way if their
endpoints are explicitly set that way or if their detachable property
-is nil and all the text in the extent is deleted. (The exception is
+is `nil' and all the text in the extent is deleted. (The exception is
open-open zero-length extents, which are barred from existing because
there is no sensible way to define their properties. Deletion of the
text in an open-open extent causes it to be converted into a closed-open
the widget_instance tree recursively.
This has desirable properties such as lw_modify_all_widgets which is
-called from glyphs-x.c and updates all the properties of a widget
+called from `glyphs-x.c' and updates all the properties of a widget
without having to know what the widget is or what toolkit it is from.
Unfortunately this also has hairy properties such as making the lwlib
code quite complex. And of course lwlib has to know at some level what
projects / chise / xemacs-chise.git / blobdiff