The former is a hash table in which keys are COMPONENTS-VECs and
values are the corresponding COMPOSITION-IDs. This hash table is
- weak, but as each key (COMPONENTS-VEC) is also kept as a value of
+ weak, but as each key (COMPONENTS-VEC) is also kept as a value of the
`composition' property, it won't be collected as garbage until all
- text that have the same COMPONENTS-VEC are deleted.
+ bits of text that have the same COMPONENTS-VEC are deleted.
The latter is a table of pointers to `struct composition' indexed
- by COMPOSITION-ID. This structure keep the other information (see
+ by COMPOSITION-ID. This structure keeps the other information (see
composite.h).
In general, a text property holds information about individual
characters. But, a `composition' property holds information about
- a sequence of characters (in this sense, it is like `intangible'
+ a sequence of characters (in this sense, it is like the `intangible'
property). That means that we should not share the property value
- in adjacent compositions we can't distinguish them if they have the
+ in adjacent compositions -- we can't distinguish them if they have the
same property. So, after any changes, we call
`update_compositions' and change a property of one of adjacent
compositions to a copy of it. This function also runs a proper
composition modification function to make a composition that gets
invalid by the change valid again.
- As a value of `composition' property holds information about a
+ As the value of the `composition' property holds information about a
specific range of text, the value gets invalid if we change the
- text in the range. We treat `composition' property always
+ text in the range. We treat the `composition' property as always
rear-nonsticky (currently by setting default-text-properties to
(rear-nonsticky (composition))) and we never make properties of
adjacent compositions identical. Thus, any such changes make the
- range just shorter. So, we can check the validity of `composition'
+ range just shorter. So, we can check the validity of the `composition'
property by comparing LENGTH information with the actual length of
the composition.
}
/* This composition is a new one. We must register it. */
-
+
/* Check if we have sufficient memory to store this information. */
if (composition_table_size == 0)
{
if (inhibit_modification_hooks)
return;
-
+
/* If FROM and TO are not in a valid range, do nothing. */
if (! (BEGV <= from && from <= to && to <= ZV))
return;
}
DEFUN ("find-composition-internal", Ffind_composition_internal,
- Sfind_composition_internal, 4, 4, 0,
+ Sfind_composition_internal, 4, 4, 0,
doc: /* Internal use only.
Return information about composition at or nearest to position POS.
}
else
end = -1;
-
+
if (!NILP (string))
{
CHECK_STRING (string);
{
Lisp_Object args[6];
extern Lisp_Object QCsize;
-
+
args[0] = QCtest;
args[1] = Qequal;
+ /* We used to make the hash table weak so that unreferenced
+ compostions can be garbage-collected. But, usually once
+ created compositions are repeatedly used in an Emacs session,
+ and thus it's not worth to save memory in such a way. So, we
+ make the table not weak. */
args[2] = QCweakness;
args[3] = Qnil;
args[4] = QCsize;
defsubr (&Scompose_string_internal);
defsubr (&Sfind_composition_internal);
}
+
+/* arch-tag: 79cefaf8-ca48-4eed-97e5-d5afb290d272
+ (do not change this comment) */