Commit 4ba4259a authored by Per Cederqvist's avatar Per Cederqvist
Browse files

(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).
parent 97f572a3
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment