bbs/deb-goldedplus
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation updated

Browse Source
This commit is contained in:
Alexander S. Aganichev 2001-11-22 12:58:35 +00:00
parent f7a39d9cdf
commit d19caefb11
2 changed files with 382 additions and 279 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/notework.txt
View File

@ -12,6 +12,8 @@ ______________________________________________________________________
Notes for GoldED+ 1.1.5, /snapshot/ Notes for GoldED+ 1.1.5, /snapshot/
______________________________________________________________________ ______________________________________________________________________
! REPLYLINK defaults changed to DIRECT.
! AREAAUTOID defaults changed to LONG. ! AREAAUTOID defaults changed to LONG.
! GoldED+ will now show hidden lines and RFC header in the message ! GoldED+ will now show hidden lines and RFC header in the message

659
manuals/gold_ref.tei
View File

@ -1,4 +1,4 @@
<!doctype tei.2 public '-7//TEI//DTD TEI Tools 0.1//EN'> <!doctype tei.2 public '-//TEI//DTD TEI Tools 0.1//EN'>
<!-- $Id$ --> <!-- $Id$ -->
<TEI.2 lang='en'> <TEI.2 lang='en'>
<!-- --------------------------------------------------------------------- --> <!-- --------------------------------------------------------------------- -->
@ -202,238 +202,319 @@
<head> <head>
The Message Database Formats The Message Database Formats
</head> </head>
<p> <div2>
<list type=gloss> <head>
<label> Opus, FTS-0001
<name/Opus/, <name/FTS-0001/ </head>
</label> <p>
<item> These are two variants of the same type of msgbase. It works by using
These are two variants of the same type of msgbase. It works by using one physical file per message (<code/1.msg/, <code/2.msg/ etc.),
one physical file per message (<code/1.msg/, <code/2.msg/ etc.), collecting them in a directory for each area. Depending on the
collecting them in a directory for each area. Depending on the clustersize on the harddisk, this can be a very wasteful and slow
clustersize on the harddisk, this can be a very wasteful and slow way to store messages. With a clustersize of about 512 bytes, the
way to store messages. With a clustersize of about 512 bytes, the waste may be acceptable, but the access speed can be dramatically
waste may be acceptable, but the access speed can be dramatically slow if there are many <code/*.msg/ files, due to the file system.
slow if there are many <code/*.msg/ files, due to the file system. Cache adjustments can improve it, but there are limits.
Cache adjustments can improve it, but there are limits.<bl> </p>
In echomail areas, this format has a special quirk: The first message <p>
(<code/1.msg/) is normally used to store the so-called In echomail areas, this format has a special quirk: The first message
<q/highwatermark/. The highwatermark tells the echomail processor (<code/1.msg/) is normally used to store the so-called
where it should start scanning for new messages entered by users. <q/highwatermark/. The highwatermark tells the echomail processor
By deleting (zapping) the highwatermark, you can make the echomail where it should start scanning for new messages entered by users.
processor re-scan the whole area again. This may cause messages to By deleting (zapping) the highwatermark, you can make the echomail
be sent out as <q/dupes/, so this should be used sparingly and processor re-scan the whole area again. This may cause messages to
carefully, if at all! The highwatermark can also be <q/heated/ - be sent out as <q/dupes/, so this should be used sparingly and
which means that it is set to the last msg in the area. This carefully, if at all! The highwatermark can also be <q/heated/ -
prevents the echomail processor from finding newly entered which means that it is set to the last msg in the area. This
unscanned msgs. Use with care.<bl> prevents the echomail processor from finding newly entered
The variants: The <name/Opus/ format originated in the <name/Opus/ unscanned msgs. Use with care.
<abbr/BBS/ system. It put some <name/Fido/ undocumented (?) fields to </p>
use as date/time stamps. The <name/FTS-0001/ (defined in FTS-0001, <p>
revision 12 and later) format uses the undocumented fields to set the The variants: The <name/Opus/ format originated in the <name/Opus/
zone/point information for the message. To the authors knowledge, the <abbr/BBS/ system. It put some <name/Fido/ undocumented (?) fields to
<name/Opus/ variant is the dominant, and the <name/FTS-0001/ variant use as date/time stamps. The <name/FTS-0001/ (defined in FTS-0001,
is doomed to oblivion. If in doubt, use the <name/Opus/ format. revision 12 and later) format uses the undocumented fields to set the
</item> zone/point information for the message. To the authors knowledge, the
<label> <name/Opus/ variant is the dominant, and the <name/FTS-0001/ variant
<name/QuickBBS/, <name/RemoteAccess/, and <name/Hudson/ is doomed to oblivion. If in doubt, use the <name/Opus/ format.
</label> </p>
<item> </div2>
This msgbase format was invented by <name/Adam Hudson/, and was first <div2>
used in his <name/QuickBBS/ package. Later several other <head>
<abbr/BBS/'es were cloned from <name/QuickBBS/ (like QuickBBS, RemoteAccess, and Hudson
<name/RemoteAccess/ and <name/SuperBBS/).<bl> </head>
The format limits the total size of <code/msgtxt.bbs/ to a maximum of <p>
16MB, which translates to about 16000 msgs of <q/average/ length. This msgbase format was invented by <name/Adam Hudson/, and was first
<name/GoldED+/ automatically warns you if the limit is close to being used in his <name/QuickBBS/ package. Later several other
reached, and advises you to pack the msgbase.<lb> <abbr/BBS/'es were cloned from <name/QuickBBS/ (like
The first incarnations of <name/QuickBBS/ did not support <q/sharing/ <name/RemoteAccess/ and <name/SuperBBS/).
of the msgbase. This became more and more important in later years as </p>
multitaskers and networks got cheaper. <name/RemoteAccess/ <abbr/BBS/ <p>
was the first to implement a useful method, and later a better method The format limits the total size of <code/msgtxt.bbs/ to a maximum of
was evolved (known as <name/RA/ 1.01 or <name/RA/ 1.1x), which is now 16MB, which translates to about 16000 msgs of <q/average/ length.
the standard for all modern software that supports msgbase sharing. <name/GoldED+/ automatically warns you if the limit is close to being
<name/GoldED+/ fully supports the new standard of course.<lb> reached, and advises you to pack the messagebase.
The main virtue of this format is that it is very fast to access the </p>
msgbase.<lb> <p>
The main disadvantage is that it can be very sensitive to disk The first incarnations of <name/QuickBBS/ did not support <q/sharing/
problems, and it is a common horror story that people loose their of the msgbase. This became more and more important in later years as
entire msgbase because the disk developed bad clusters or some multitaskers and networks got cheaper. <name/RemoteAccess/ <abbr/BBS/
program went berserk and messed up the msgbase files. was the first to implement a useful method, and later a better method
</item> was evolved (known as <name/RA/ 1.01 or <name/RA/ 1.1x), which is now
<label> the standard for all modern software that supports msgbase sharing.
<name/Goldbase/ <name/GoldED+/ fully supports the new standard of course.
</label> </p>
<item> <p>
This is an enhanced version of the <name/Hudson/ format, introduced The main virtue of this format is that it is very fast to access the
in <name/QuickBBS/ 2.80 by the <name/QuickBBS/ group.<lb> msgbase.
The <name/Goldbase/ format removes the 16MB size limit and allows up </p>
to 500 message areas instead of the 200 in <name/Hudson/. <p>
</item> The main disadvantage is that it can be very sensitive to disk
<label> problems, and it is a common horror story that people loose their
<name/Squish/ entire msgbase because the disk developed bad clusters or some
</label> program went berserk and messed up the msgbase files.
<item> </p>
The <name/Squish/ format was invented by <name/Maximus/ <abbr/BBS/ </div2>
author <name/Scott Dudley/ in 1991, and was first used in <div2>
<name/Maximus CBCS/ v2.00.<bl> <head>
The use of a database for each area - instead of one file per msg, Goldbase
or all msgs in one big database - makes this format fast, very </head>
safe and resistant to disk problems. Even if something messed up a <p>
<name/Squish/ area, it can almost always be fixed and recovered, This is an enhanced version of the <name/Hudson/ format, introduced
using the <name/SQFIX/ or <name/SQREIDX/ utilities that come with the in <name/QuickBBS/ 2.80 by the <name/QuickBBS/ group.
<name/Squish/ echomail processor.<lb> </p>
A special feature of <name/Squish/ areas is that they can be <p>
self-maintaining. You can setup a <name/Squish/ area so that it may The <name/Goldbase/ format removes the 16MB size limit and allows up
only contain a maximum of so-and-so many msgs, and then it will to 500 message areas instead of the 200 in <name/Hudson/.
automatically re-use the space used by old msgs when the limit is </p>
reached, and so it will practically stop growing. It will still need </div2>
packing, but not nearly as often as a <name/Hudson/ msgbase has to. <div2>
</item> <head>
<label> Squish
<name/Ezycom/ </head>
</label> <p>
<item> The <name/Squish/ format was invented by <name/Maximus/ <abbr/BBS/
<name/Ezycom/ format. author <name/Scott Dudley/ in 1991, and was first used in
</item> <name/Maximus CBCS/ v2.00.
<label> </p>
<name/JAM/ <p>
</label> The use of a database for each area - instead of one file per msg,
<item> or all msgs in one big database - makes this format fast, very
<name/JAM/ format as defined in the <name/JAM(mbp)/ revision 001. safe and resistant to disk problems. Even if something messed up a
Also supports <name/CrashMail/, <name/CrashEcho/, and <name/HPT/ <name/Squish/ area, it can almost always be fixed and recovered,
highwater marks.<bl> using the <name/SQFIX/ or <name/SQREIDX/ utilities that come with the
<name/GoldED+/ currently ignores revision number of header structure <name/Squish/ echomail processor.
and assumes that future revisions will remain backward compatible. </p>
When creating new msgs, GoldED uses the revision 1 header <p>
structure.<bl> A special feature of <name/Squish/ areas is that they can be
<name/GoldED+/ currently doesn't support passwords to access the self-maintaining. You can setup a <name/Squish/ area so that it may
message base and/or indiviual messages. When creating a new only contain a maximum of so-and-so many msgs, and then it will
<name/JAM/ msgbase and/or new <name/JAM/ msgs, <name/GoldED+/ sets automatically re-use the space used by old msgs when the limit is
the password to FFFFFFFFh. If you change an existing message which reached, and so it will practically stop growing. It will still need
has a password, the password is <hi/NOT/ preserved, but reset to packing, but not nearly as often as a <name/Hudson/ msgbase has to.
FFFFFFFFh.<bl> </p>
The <name/JAM/ lastread file is designed such that is has to be </div2>
searched for a userid/usercrc, because one cannot assume that the <div2>
records are in a specific order. The <name/JAM/ <abbr/API/ searches <head>
the userid field. However <name/GoldED+/ searches for the usercrc, Ezycom
not the userid. In any case, it seems that <name/RemoteAccess/ 2.x </head>
sets both the userid and usercrc to the same value.<bl> <p>
<name/GoldED+/ currently doesn't support the escaping described in <name/Ezycom/ format is supported by <name/GoldED+/. Status is not
the <name/JAM/ specs. The specs state that the current revision of known.
<name/JAM/ does not support it either, so it seems to be not great </p>
loss.<bl> </div2>
<name/GoldED+/ does not supports the following <name/JAM/ subfields: <div2>
<q/Force pickup/, and <q>Msg may not be displayed to user</q> (always <head>
displayed).<bl> JAM
<name/GoldED+ optionally may use tricky method invented by </head>
<name/Odinn/ and aprooved by the <name/JAM/ developers when deleting <p>
messages. The configuration keyword <name/JAM/ format as defined in the <name/JAM(mbp)/ revision 001.
<ref target=JAMHARDDELETE><kw/JAMHARDDELETE/</ref> specifies which Also supports <name/CrashMail/, <name/CrashEcho/, and <name/HPT/
method to use. highwater marks.
</item> </p>
<label> <p>
<name/PCBoard/ <name/GoldED+/ currently ignores revision number of header structure
</label> and assumes that future revisions will remain backward compatible.
<item> When creating new msgs, <name/GoldED+/ uses the revision 1 header
<name/PCBoard/ v15.x format.<lb> structure.
<name/GoldED+/ is aware of <name/PCBoard/ v15.x extended headers in </p>
the message text. The <gi/TO/, <gi/TO2/, <gi/FROM/, <gi/FROM2/ and <p>
<gi/SUBJECT/ extended headers are directly supported and <name/GoldED+/ currently doesn't support passwords to access the
<q/swallowed/ when reading a message. Other extended headers are message base and/or indiviual messages. When creating a new
currently treated like normal message text and is therefore not <name/JAM/ msgbase and/or new <name/JAM/ msgs, <name/GoldED+/ sets
hidden to the reader.<lb> the password to FFFFFFFFh. If you change an existing message which
Passwords are not supported.<lb> has a password, the password is <hi/NOT/ preserved, but reset to
The Private, Received, Crash and Direct attributed are supported.<lb> FFFFFFFFh.
<name/GoldED+/ reads the <code/pcboard.dat/ file to determine whether </p>
to use E3h or 0Dh (<gi/CR/) as the line/paragraph termination <p>
character when reading and writing message text.<lb> The <name/JAM/ lastread file is designed such that is has to be
The mail waiting flags are updated when you write to people that are searched for a userid/usercrc, because one cannot assume that the
named in the userbase.<lb> records are in a specific order. The <name/JAM/ <abbr/API/ searches
When changing a message, the new edition is saved as if it were a new the userid field. However <name/GoldED+/ searches for the usercrc,
message, with a new message number, and then the old edition is not the userid. In any case, it seems that <name/RemoteAccess/ 2.x
deleted. This behaviour is consistent with the way <name/PCBoard/ sets both the userid and usercrc to the same value.
itself works when changing a message. The old edition will still </p>
exist with the <gi/DEL/ attribute. <p>
</item> <name/GoldED+/ currently doesn't support the escaping described in
<label> the <name/JAM/ specs. The specs state that the current revision of
<name/AdeptXBBS/ <name/JAM/ does not support it either, so it seems to be not great
</label> loss.
<item> </p>
The implementation is based on the documentation in version 1.05, <p>
experimentation and questions to the authors. Thanks go to <name/GoldED+/ does not supports the following <name/JAM/ subfields:
<name/Frank Jacobberger for the initial testing and prodding of the <q/Force pickup/, and <q>Msg may not be displayed to user</q> (always
authors to answer <name/Odinns/ questions :-)<bl> displayed).
The <name/AdeptXBBS/ format does not have a quick method of finding </p>
deleted messages via the index file. This means that deleted messages <p>
left in the messagebase marked with the <gi/DEL/ attribute.<bl> <name/GoldED+/ optionally may use tricky method invented by
Mixing of netmail and echomail or other types of mail in the same <name/Odinn/ and aprooved by the <name/JAM/ developers when deleting
area is not directly supported. If an area is setup as both netmail messages. The configuration keyword
and echomail, <name/GoldED+/ will treat it as netmail. If an area is <ref target=JAMHARDDELETE><kw/JAMHARDDELETE/</ref> specifies which
neither netmail nor echomail, <name/GoldED+/ wil treat it as a local method to use.
area.<bl> </p>
<name/GoldED+/ detects <name/Usenet/ (newsgroup) and <name/Internet/ </div2>
e-mail areas in the <name/AdeptXBBS/ setup and uses them as such, but <div2>
it has not yet been tested if <name/GoldED+/ and <name/AdeptXBBS/ are <head>
compatible in the way they store and process <name/Internet/ header PCBoard
information.<bl> </head>
The <name/AdeptXBBS/ personal mail feature (the index in the <p>
<code/Personal_Mail/ directory) is supported for mails you write to The supported <name/PCBoard/ messagebase corresponds to the v15.x of
other users on the <abbr/BBS/. However, personal mail for you via <name/PCBoard/ <abbr/BBS/.
this feature or by other means is not yet supported.<bl> </p>
The replylinking method used by <name/AdeptXBBS/ (whatever the method <p>
is??!) is not yet supported. This means that links to other messages <name/GoldED+/ is aware of <name/PCBoard/ v15.x extended headers in
are missing. the message text. The <gi/TO/, <gi/TO2/, <gi/FROM/, <gi/FROM2/ and
</item> <gi/SUBJECT/ extended headers are directly supported and
<label> <q/swallowed/ when reading a message. Other extended headers are
<name/WildCat!/ currently treated like normal message text and is therefore not
</label> hidden to the reader.
<item> </p>
The <name/WildCat!/ 4.x format does not have a quick method of <p>
finding deleted messages via the index file. This means that deleted Passwords are not supported.
messages left in the messagebase marked with the <gi/DEL/ </p>
attribute.<bl> <p>
WildCat features which are not supported yet: The <gi/Private/, <gi/Received/, <gi/Crash/, and <gi/Direct/ attributes
<list type=simple> are supported.
<item/The userbase./ </p>
<item/The message unread chain./ <p>
<item/The message from/to title./ <name/GoldED+/ reads the <code/pcboard.dat/ file to determine whether
<item/The message network name./ to use E3h or 0Dh (<gi/CR/) as the line/paragraph termination
<item/The message internal and external attach./ character when reading and writing message text.
</list> </p>
There is a keyword <p>
<ref target=WILDCATUSERNO><kw/WILDCATUSERNO/</ref>, which works just The mail waiting flags are updated when you write to people that are
like the other <kw/>&lt;msgbase&gt;USERNO</kw> keywords. By default named in the userbase.
<name/GoldED+/ will use the first record in the lastread file </p>
(<code/*.lrd/), so if you are not the first person in the userbase, <p>
or you are sharing the messagebase with others, you may have to When changing a message, the new edition is saved as if it were a new
change this user number. The userbase is currently not supported message, with a new message number, and then the old edition is
(i.e.: you can't set the number to -1 to let <name/GoldED+/ find the deleted. This behaviour is consistent with the way <name/PCBoard/
correct user and lastread automatically).<bl> itself works when changing a message. The old edition will still
<hi/Note/: The <name/WildCat!/ support is currently not very exist with the <gi/DEL/ attribute.
well-tested, so use it with caution. Limited testing shown that </p>
<name/GoldED+/ not damages the messagebases, but you should probably </div2>
test it on less important areas and/or make backups until it is <div2>
determined that it is safe. <head>
</item> AdeptXBBS
<label> </head>
<name/Synchronet/ <p>
</label> The implementation is based on the documentation in version 1.05,
<item> experimentation and questions to the authors. Thanks go to
<name/Synchronet/ message base as described in <name>Synchronet <name/Frank Jacobberger/ for the initial testing and prodding of the
Message Base Specification</name> version 1.21. <name/GoldED+/ authors to answer <name/Odinns/ questions :-)
currently linked with <name/SMBLib/ taken from the <name/Synchronet/ </p>
<abbr/BBS/ sources slightly adopted to the <name/GoldED+/ internal <p>
definitions.<bl> The <name/AdeptXBBS/ format does not have a quick method of finding
Just like <name/WildCat!/ format, <name/Synchronet/ format does not deleted messages via the index file. This means that deleted messages
have a quick method of finding deleted messages via the index file. left in the messagebase marked with the <gi/DEL/ attribute.
This means that deleted messages left in the messagebase marked with </p>
the <gi/DEL/ attribute.<bl> <p>
<hi/Note/: The <name/Synchronet/ support is currently not tested at Mixing of netmail and echomail or other types of mail in the same
all. area is not directly supported. If an area is setup as both netmail
</item> and echomail, <name/GoldED+/ will treat it as netmail. If an area is
</list> neither netmail nor echomail, <name/GoldED+/ wil treat it as a local
</p> area.
</p>
<p>
<name/GoldED+/ detects <name/Usenet/ (newsgroup) and <name/Internet/
e-mail areas in the <name/AdeptXBBS/ setup and uses them as such, but
it has not yet been tested if <name/GoldED+/ and <name/AdeptXBBS/ are
compatible in the way they store and process <name/Internet/ header
information.
</p>
<p>
The <name/AdeptXBBS/ personal mail feature (the index in the
<code/Personal_Mail/ directory) is supported for mails you write to
other users on the <abbr/BBS/. However, personal mail for you via
this feature or by other means is not yet supported.
</p>
<p>
The replylinking method used by <name/AdeptXBBS/ (whatever the method
is??!) is not yet supported. This means that links to other messages
are missing.
</p>
</div2>
<div2>
<head>
WildCat!
</head>
<p>
The <name/WildCat!/ 4.x format does not have a quick method of
finding deleted messages via the index file. This means that deleted
messages left in the messagebase marked with the <gi/DEL/
attribute.
</p>
<p>
WildCat features which are not supported yet:
<list type=simple>
<item/The userbase./
<item/The message unread chain./
<item>The message from/to title.</item>
<item/The message network name./
<item/The message internal and external attach./
</list>
</p>
<p>
There is a keyword
<ref target=WILDCATUSERNO><kw/WILDCATUSERNO/</ref>, which works just
like the other <kw/>&lt;msgbase&gt;USERNO</kw> keywords. By default
<name/GoldED+/ will use the first record in the lastread file
(<code/*.lrd/), so if you are not the first person in the userbase,
or you are sharing the messagebase with others, you may have to
change this user number. The userbase is currently not supported
(i.e.: you can't set the number to -1 to let <name/GoldED+/ find the
correct user and lastread automatically).
</p>
<p>
<hi/Note/: The <name/WildCat!/ support is currently not very
well-tested, so use it with caution. Limited testing shown that
<name/GoldED+/ not damages the messagebases, but you should probably
test it on less important areas and/or make backups until it is
determined that it is safe.
</p>
</div2>
<div2>
<head>
Synchronet
</head>
<p>
<name/Synchronet/ message base as described in <name>Synchronet
Message Base Specification</name> version 1.21. <name/GoldED+/
currently linked with <name/SMBLib/ taken from the <name/Synchronet/
<abbr/BBS/ sources slightly adopted to the <name/GoldED+/ internal
definitions.
</p>
<p>
Just like <name/WildCat!/ format, <name/Synchronet/ format does not
have a quick method of finding deleted messages via the index file.
This means that deleted messages left in the messagebase marked with
the <gi/DEL/ attribute.
</p>
<p>
<hi/Note/: The <name/Synchronet/ support is currently not tested at
all.
</p>
</div2>
</div1> </div1>
<!-- --------------------------------------------------------------------- --> <!-- --------------------------------------------------------------------- -->
<div1> <div1>
@ -1024,7 +1105,7 @@ RDDT path.rpt -n2:5020/604.19 -l2:5020/604 2:5020/604.19 -p</eg>
</list> </list>
</p> </p>
<p> <p>
When the using <ref targe=AREAFILE><kw/AREAFILE/</ref> feature to read When the using <ref target=AREAFILE><kw/AREAFILE/</ref> feature to read
external area configuration from other programs, the individual external area configuration from other programs, the individual
<ref target=AREAFILE><kw/AREAFILE/</ref>'s may use specific environment <ref target=AREAFILE><kw/AREAFILE/</ref>'s may use specific environment
variables to find the files. Please read the variables to find the files. Please read the
@ -1331,7 +1412,7 @@ ENDIF</eg>
the <term/4D/ format <ident>zone:net/node.point</ident>. Most modern the <term/4D/ format <ident>zone:net/node.point</ident>. Most modern
mailers and mail processors now supports the <term/4D/ format, mailers and mail processors now supports the <term/4D/ format,
but if you are a point, you should always consult your boss about but if you are a point, you should always consult your boss about
which format to use.<bl> which format to use.<lb>
The optional <ident/@domain/ part can be used to specify a The optional <ident/@domain/ part can be used to specify a
<term/fifth/ dimension to the <term/4D/ address. It is normally not <term/fifth/ dimension to the <term/4D/ address. It is normally not
necessary to specify a domain. Domains are never shown in the header. necessary to specify a domain. Domains are never shown in the header.
@ -1409,28 +1490,28 @@ ADDRESS 2:236/77@fidonet ; Node address with domain</eg>
following criterias: following criterias:
<list type=simple> <list type=simple>
<item> <item>
it's a <kw/ROBOTNAME/ It's a <ref target=ROBOTNAME><kw/ROBOTNAME/</ref>
</item> </item>
<item> <item>
it's a <kw/USERNAME/ It's a <ref target=USERNAME><kw/USERNAME/</ref>
</item> </item>
<item> <item>
it's the <kw/WHOTO/ It's the <ref target=WHOTO><kw/WHOTO/</ref>
</item> </item>
<item> <item>
it's the mailinglist's sender address It's the mailinglist's sender address
</item> </item>
<item> <item>
it's an UUCP It's an UUCP
</item> </item>
<item> <item>
it's already an email address It's already an email address
</item> </item>
<item> <item>
address/aka is unknown Address/aka is unknown
</item> </item>
<item> <item>
it's an <kw/ADDRESSMACRO/ It's an <ref target=ADDRESSMACRO><kw/ADDRESSMACRO/</ref>
</item> </item>
</list> </list>
</item> </item>
@ -1544,14 +1625,9 @@ ADDRESS 2:236/77@fidonet ; Node address with domain</eg>
<ref target=NAMESFILE><kw/NAMESFILE/</ref> for details. However, you <ref target=NAMESFILE><kw/NAMESFILE/</ref> for details. However, you
should not use the syntax with the attributes in the <code/names.fd/ should not use the syntax with the attributes in the <code/names.fd/
file, because <name/FrontDoor/ and <name/Maximus/ do not know this file, because <name/FrontDoor/ and <name/Maximus/ do not know this
syntax. syntax.<lb>
</item> When used in the <name/Internet/ area, <q/@/ as the first character
<label> in the <ident/name/ field may be omitted.
Bugs:
</label>
<item>
When used in the <name/Internet/ area, name should <hi/not/ contain
<q/@/ as the first character in the <ident/name/ field.
</item> </item>
<label> <label>
Processed by: Processed by:
@ -1578,7 +1654,7 @@ ADDRESSMACRO dn,@INTERNET/david@csource.oz.au,2:241/999]]></eg>
</item> </item>
</list> </list>
</div2> </div2>
<div2> <div2 id=ADEPTXBBSPATH>
<head> <head>
ADEPTXBBSPATH ADEPTXBBSPATH
</head> </head>
@ -1690,7 +1766,7 @@ ADDRESSMACRO dn,@INTERNET/david@csource.oz.au,2:241/999]]></eg>
<item> <item>
Your network address, <name/FidoNet/-style. More than one address can Your network address, <name/FidoNet/-style. More than one address can
be specified if you are member of more than one network. The keywords be specified if you are member of more than one network. The keywords
<kw/ADDRESS/ and <ref target=AKA><kw/AKA/</ref> can be used <ref target=ADDRESS><kw/ADDRESS/</ref> and <kw/AKA/ can be used
interchangeably. interchangeably.
</item> </item>
<label> <label>
@ -1705,7 +1781,7 @@ ADDRESSMACRO dn,@INTERNET/david@csource.oz.au,2:241/999]]></eg>
the <term/4D/ format <ident>zone:net/node.point</ident>. Most modern the <term/4D/ format <ident>zone:net/node.point</ident>. Most modern
mailers and mail processors now supports the <term/4D/ format, mailers and mail processors now supports the <term/4D/ format,
but if you are a point, you should always consult your boss about but if you are a point, you should always consult your boss about
which format to use.<bl> which format to use.<lb>
The optional <ident/@domain/ part can be used to specify a The optional <ident/@domain/ part can be used to specify a
<term/fifth/ dimension to the <term/4D/ address. It is normally not <term/fifth/ dimension to the <term/4D/ address. It is normally not
necessary to specify a domain. Domains are never shown in the header. necessary to specify a domain. Domains are never shown in the header.
@ -1730,12 +1806,6 @@ ADDRESSMACRO dn,@INTERNET/david@csource.oz.au,2:241/999]]></eg>
<ref target=ADDRESS><kw/ADDRESS/</ref>, <ref target=ADDRESS><kw/ADDRESS/</ref>,
<ref target=NETNAME><kw/NETNAME/</ref> <ref target=NETNAME><kw/NETNAME/</ref>
</item> </item>
<label>
Example:
</label>
<item><eg>
AKA 2:236/77.1</eg>
</item>
</list> </list>
</div2> </div2>
<div2 id=AKAMATCH> <div2 id=AKAMATCH>
@ -1858,7 +1928,7 @@ AKAMATCH 23: 22:33/44</eg>
</item> </item>
</list> </list>
</div2> </div2>
<div2> <div2 id=AKAMATCHING>
<head> <head>
AKAMATCHING AKAMATCHING
</head> </head>
@ -1917,7 +1987,7 @@ AKAMATCH 23: 22:33/44</eg>
</item> </item>
</list> </list>
</div2> </div2>
<div2> <div2 id=AKAMATCHLOCAL>
<head> <head>
AKAMATCHLOCAL AKAMATCHLOCAL
</head> </head>
@ -1973,7 +2043,7 @@ AKAMATCH 23: 22:33/44</eg>
</item> </item>
</list> </list>
</div2> </div2>
<div2> <div2 id=AKAMATCHNET>
<head> <head>
AKAMATCHNET AKAMATCHNET
</head> </head>
@ -2057,7 +2127,7 @@ AKAMATCH 23: 22:33/44</eg>
The <ident/programname/ parameter defines name of the software which The <ident/programname/ parameter defines name of the software which
wants to read its configuration from <name/GoldED+/ configuration wants to read its configuration from <name/GoldED+/ configuration
file. <name/GoldED+/ itself will ignore <kw/APP/ lines just like file. <name/GoldED+/ itself will ignore <kw/APP/ lines just like
<ref target=REM><kw/remark/</ref> lines. <ref target=REM/remark/ lines.
</item> </item>
<label> <label>
Processed by: Processed by:
@ -2069,7 +2139,7 @@ AKAMATCH 23: 22:33/44</eg>
See also: See also:
</label> </label>
<item> <item>
<ref target=REM><kw/Remark/</ref> chapter <ref target=REM/Remark/ chapter
</item> </item>
<label> <label>
Example: Example:
@ -2089,7 +2159,7 @@ APP OtherProg IRQ 5</eg>
Synopsis: Synopsis:
</label> </label>
<item> <item>
<kw/AREA/ <ident>&lt;echoid&gt; &lt;<q>desc</q>&gt; <kw/AREA/ <ident>&lt;echoid&gt; &lt;<![ CDATA ["desc"]]>&gt;
&lt;msgbase&gt;&lsqb;type&rsqb; &lt;location&gt; &lsqb;akano&rsqb; &lt;msgbase&gt;&lsqb;type&rsqb; &lt;location&gt; &lsqb;akano&rsqb;
&lsqb;attrs&rsqb;</ident> &lsqb;attrs&rsqb;</ident>
</item> </item>
@ -2268,21 +2338,51 @@ APP OtherProg IRQ 5</eg>
</item> </item>
</list> </list>
</div2> </div2>
<div2>
<head>
AREAAUTONEXT
</head>
<list type=gloss>
<label>
Synopsis:
</label>
<item>
<kw/AREAAUTONEXT/ <ident>&lt;YES/NO&gt;</ident>
</item>
<label>
Description:
</label>
<item>
This keyword controls where to put cursor in arealist on startup
and after exiting from an area you have been reading.
</item>
<label>
Parameters:
</label>
<item>
If enabled, <name/GoldED+/ will automatically jump to the first
marked area in the arealist on startup, and the next marked area
after exiting from an area you have been reading.
</item>
<label>
Default:
</label>
<item>
<ident/YES/
</item>
<label>
Processed by:
</label>
<item>
Mail reader.
</item>
</list>
</div2>
<!-- finished here --> <!-- finished here -->
<div2>
<head>
AREAAUTONEXT &lt;(yes)/no&gt;
</head>
<p>
If enabled, <name>GoldED+</name> will automatically jump to the first
marked area in the arealist on startup, and the next marked area after
exiting from an area you have been reading.
</p>
</div2>
<div2> <div2>
<head> <head>
AREACATCHUPREAD &lt;(yes)/no&gt; AREACATCHUPREAD &lt;(yes)/no&gt;
@ -5968,7 +6068,7 @@ AREASEP &excl;C "Group C" C Local]]></eg>
editing a mail in the internal message editor. editing a mail in the internal message editor.
</p> </p>
</div2> </div2>
<div2> <div2 id=JAMHARDDELETE>
<head> <head>
JAMHARDDELETE &lt;yes/no&gt; JAMHARDDELETE &lt;yes/no&gt;
</head> </head>
@ -6611,6 +6711,7 @@ AREASEP &excl;C "Group C" C Local]]></eg>
merit and should not be used. It is provided for cosmetical merit and should not be used. It is provided for cosmetical
purposes and backward compatibility only. purposes and backward compatibility only.
--> -->
<p>dummy text</p>
</div2> </div2>
<div2> <div2>
<head> <head>
@ -7884,7 +7985,7 @@ AREASEP &excl;C "Group C" C Local]]></eg>
Since version 2.50, a completely rewritten implementation is used. Since version 2.50, a completely rewritten implementation is used.
</p> </p>
</div2> </div2>
<div2> <div2 id=SQUISHUSERNO>
<head> <head>
SQUISHUSERNO &lt;index&gt; SQUISHUSERNO &lt;index&gt;
</head> </head>
@ -8645,7 +8746,7 @@ AREASEP &excl;C "Group C" C Local]]></eg>
This keyword can be used globally and in a Random System group. This keyword can be used globally and in a Random System group.
</p> </p>
</div2> </div2>
<div2> <div2 id=WILDCATUSERNO>
<head> <head>
WILDCATUSERNO &lt;userno&gt; WILDCATUSERNO &lt;userno&gt;
</head> </head>