From 4ba4259a1b6e9adf11d1d0a3749f60c3642761ff Mon Sep 17 00:00:00 2001
From: Per Cederqvist <ceder@lysator.liu.se>
Date: Sun, 11 Aug 2002 11:52:41 +0000
Subject: [PATCH] (The User Area): The description of the common block grammar
contained many errors. State that everything is encoded as HOLLERITHs,
and that they in turn contain datatypes. Removed "list" and "elems"; added
"string-list". Added the "language" setting. (Bug 124).
---
doc/Protocol-A.texi | 92 +++++++++++++++++++++++++--------------------
1 file changed, 51 insertions(+), 41 deletions(-)
diff --git a/doc/Protocol-A.texi b/doc/Protocol-A.texi
index fe578eaa5..5b3e822b9 100644
--- a/doc/Protocol-A.texi
+++ b/doc/Protocol-A.texi
@@ -9002,25 +9002,16 @@ what you name your client's block.
@section The Common Block
-This defines the theoretical structure of the common block. The real
-world probably does not agree entirely with this, and it is likely to
-change just as soon as I have time to define something better. In the
-mean while you're probably better off ignoring the common block and
-storing all your settings in a client block. The Emacs lisp client uses
-the common block, but I have a feeling that it might store data that
-other clients can't read.
-
-The common block contains a list of variable settings. Each variable
-setting consists of a name, some whitespace, and a value. Settings are
-separated by a line feed character. As of protocol version 10, values
-can be integers, strings, booleans or lists. The encoding is such that a
-value is encoded as a single protocol A token. That means that strings
-and lists are both encoded as HOLLERITHs. The reason for this is to
-simplify for clients that need to ignore the value, and so it is
-possible to add new value types without confusing old clients (new types
-will be encoded as HOLLERITHs.)
-
-The grammar below sort of defines the syntax of the common block.
+This defines the structure of the common block. The common block
+contains a list of variable settings. Each variable setting consists
+of a name, some whitespace, and a value. Settings are separated by a
+line feed character. The values can be of several different types
+(such as integers, strings, booleans, lists of stuff) but they are all
+encoded as HOLLERITHs. The reason for this is to simplify for clients
+that need to ignore the value, and so it is possible to add new value
+types without confusing old clients.
+
+The grammar below defines the syntax of the common block.
@c ispell-ignore
@example
@@ -9029,57 +9020,76 @@ settings : settings setting
| /* empty */
setting : variable ' ' value '\n'
variable : [A-Za-z-_0-9]+
-value : boolean
- | HOLLERITH
- | list
- | integer
+value : HOLLERITH
+@end example
+@c ispell-end-ignore
+
+The values contain structure within the HOLLERITH. The following
+grammar defines the datatypes that are currently used. Clients must
+be prepared to ignore values that have other datatypes.
+
+@c ispell-ignore
+@example
boolean : 1 | 0
integer : -?[0-9]+
-list : integer elems // Encoded in a HOLLERITH
-elems : elems value
- | empty
+string-list : string-list ' ' HOLLERITH
+ | HOLLERITH
@end example
@c ispell-end-ignore
Currently the following variables are used, but more may be added, and
-as of protocol version 10, clients should be able to cope with variables
-they know nothing of in the common block, as long as they are of one of
-the types above. Pre-protocol version 10 clients can't deal with
-HOLLERITHs in the common block.
-
-As of protocol 10 the following variables are stored in the common
-block:
+clients must cope with variables they know nothing of in the common
+block. (Doing so is easy, as all values are encoded as HOLLERITHs.)
@table @code
@item created-texts-are-read
True if the user wants texts s/he creates to be marked as read
-automatically. Boolean.
+automatically. @code{boolean}.
@item dashed-lines
True if the user wants dashed lines around the text body when it's
-displayed. Boolean.
+displayed. @code{boolean}.
@item presence-messages
True if the user wants messages about people logging in and logging out
-of LysKOM. Boolean.
+of LysKOM. @code{boolean}.
@item print-number-of-unread-on-entrance
True if the user wants to see the number of unread texts when entering a
-conference. Boolean.
+conference. @code{boolean}.
@item read-depth-first
-True if the user wants to read text in depth-first order. Boolean.
+True if the user wants to read text in depth-first order. @code{boolean}.
@item reading-puts-comments-in-pointers-last
True if the user wants the client to display comment links after the
-text body. Boolean.
+text body. @code{boolean}.
@item confirm-multiple-recipients
True if the user wants the client to ask for confirmation before sending
-a text to many conferences.
+a text to many conferences. @code{boolean}.
@item default-mark
-The default mark to set on marked texts.
+The default mark to set on marked texts. @code{integer}.
+
+@item language
+Preferred languages, in priority order. @code{string-list}.
+
+This contains a list of ISO 639 language codes. ISO 639-2 should be
+used for languages that have a 2-character language code. For other
+languages, ISO 639-1 should be used.
+@uref{http://lcweb.loc.gov/standards/iso639-2/langcodes.html} contains
+a list of the current language codes.
+
+The client should configure its user interface to use the first
+language in the list that it supports. Example: a client that
+supports English and Swedish would use:
+@itemize @bullet
+@item Swedish if the list is @samp{2Hfr 2Hsv 2Hen}
+@item English if the list is @samp{2Hen 2Hsv 2Hfr}
+@item either if the list is @samp{2Hes 2Hfr}
+@end itemize
+
@end table
--
GitLab