aboutsummaryrefslogtreecommitdiff
path: root/doc/ref/javascript/types.texi
diff options
context:
space:
mode:
authorHugo Hörnquist <hugo@lysator.liu.se>2023-09-05 11:41:46 +0200
committerHugo Hörnquist <hugo@lysator.liu.se>2023-09-05 11:41:46 +0200
commitf653a01328be3b8be6af35c0c96867623765ca5b (patch)
treeaee9a5d3abfc39270f55defd7bc1a7e47920ffc3 /doc/ref/javascript/types.texi
parentMinor whitespace cleanup. (diff)
downloadcalp-f653a01328be3b8be6af35c0c96867623765ca5b.tar.gz
calp-f653a01328be3b8be6af35c0c96867623765ca5b.tar.xz
Move JS documentation into the JS-code.
Texinfo was a bad match for how TypeScript is structured. This also allows generation of jsdoc pages, which can be nice. Another large win is that this opens up for the texinfo pages to replace the Guile heading with different subheadings, including - external library - internal library - C library - ...
Diffstat (limited to 'doc/ref/javascript/types.texi')
-rw-r--r--doc/ref/javascript/types.texi95
1 files changed, 0 insertions, 95 deletions
diff --git a/doc/ref/javascript/types.texi b/doc/ref/javascript/types.texi
deleted file mode 100644
index 6f518f53..00000000
--- a/doc/ref/javascript/types.texi
+++ /dev/null
@@ -1,95 +0,0 @@
-@node types
-@subsection types.js
-
-Collection of type information for calendar data.
-
-@defvar all_types
-Name of all valid icalendar types.
-
- text, uri, binary, float, integer, date-time, date, duration,
- period, utc-offset, cal-address, recur, boolean,
-@end defvar
-
-@deftp {Data Type} ical_type
-The union of all elements in @var{all_types}.
-@end deftp
-
-@defvar property_names
-All known names properties (top level keys) can have.
-Such as ``calscale'', ``dtstart'', ...
-@end defvar
-
-@deftypevar {Map<string, string[]>} valid_fields
-Which property fields each component can hold.
-
-@verbatim
-{ 'VCALENDAR': ['PRODID', 'VERSION', 'CALSCALE', 'METHOD'],
- ...
-}
-@end verbatim
-@end deftypevar
-
-@deftypevar {Map<string, Array<ical_type | ical_type[]>>} valid_input_types
-Which types are valid to store under each property.
-If multiple values are an option for that property, then
-the list of possibilities will contain a sub-list (see example).
-
-@verbatim
-{ 'DTSTART': ['date', 'date-time'],
- 'CATEGORIES': [['text']],
- ...
-}
-@end verbatim
-@end deftypevar
-
-@deftp {Data Type} tagname
-Alias of (@code{'vevent'} | @code{'string'}).
-@end deftp
-
-@deftp {Data Type} uid
-Alias of @code{'string'}.
-@end deftp
-
-@c TODO link to the RFC
-@c - RFC 7265 (jCal)
-
-@deftp {Data Type} JCalProperty
-Alias for a record consisting of
-@itemize @bullet
-@item the name of the type, as a string
-@item All parameters of the object, as a @code{Record<string, any>}
-@footnote{Which is simply a regular javascript object, mapping strings to anything}.
-@item An @code{ical_type} value, noting the type of the final field(s)
-@item And one or more values of the type specified by the third field.
-@end itemize
-@end deftp
-
-@deftp {Data Type} JCal
-A record consisting of a @code{tagname}, a list of
-@code{JCalProperties}, and a list of other @code{JCal} objects.
-@end deftp
-
-@defvar xcal
-The xml namespace name for xcalendar, which is
-``urn:ietf:params:xml:ns:icalendar-2.0''.
-@end defvar
-
-
-@deftp {Interface} ChangeLogEntry
-@anchor{ChangeLogEntry}
-
-@ref{VEventChangelog}
-
-@deftypecv {Interface Field} ChangeLogEntry {(@code{'calendar'} | @code{'property'})} type
-@end deftypecv
-
-@deftypecv {Interface Field} ChangeLogEntry {string} name
-@end deftypecv
-
-@deftypecv {Interface Field} ChangeLogEntry {string?} from
-@end deftypecv
-
-@deftypecv {Interface Field} ChangeLogEntry {string?} to
-@end deftypecv
-
-@end deftp