home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Pier Shareware 6
/
The_Pier_Shareware_Number_6_(The_Pier_Exchange)_(1995).iso
/
035
/
geob1006.zip
/
GOLDBETA.DOC
< prev
next >
Wrap
Text File
|
1994-10-06
|
207KB
|
5,628 lines
______________________________________________________________________
GoldED 2.50.Beta Manual
Updated 6. october 1994
______________________________________________________________________
______________________________________________________________________
Notes About This Manual
______________________________________________________________________
This is the first "complete" manual since version 2.40 and it is long
overdue, sorry. Well here it is at last - better late than never :-)
It is currently written using a plain text editor (QEdit) with a 70
char margin and does not have page breaks, page numbers, table of
contents, index etc. That will come in a later edition. Does anyone
know of a simple-to-use Shareware/PD "manual compiler" which can make
page header/footers with page numbers, toc's and allows editing with a
text editor?
This edition is partly based on the old 2.40 manual plus later
addendums. It has been brought up-to-date in the configuration keyword
reference and edited here and there in other parts. Some chapters have
been removed entirely and will either be rewritten or incorporated
into other chapters. It is quite possible that there are still places
where the manual is not 100% up-to-date or correct, and there are
certainly many features that should be documented. Many features are
still only documented (one might almost say "buried" :-) in the
NOTE*.DOC file.
If you find spelling, grammatical or factual errors, please let me
know as soon as possible.
If you think the wording is bad or confusing in some parts, please
send me your improved version.
If you would like to write entirely new chapters (especially "users
guide" type chapters), please do and send them to me. Screen shots may
be included, but should be edited to fit a 70 char wide page.
I have limited time and would be very grateful for any help which can
improve the quality and usefulness of the manual.
Thanks for reading. Enjoy!
Odinn Sorensen, The GoldED Author.
______________________________________________________________________
Legal Notes
______________________________________________________________________
GoldED is provided as is, with no warranty of any kind, either
expressed or implied. GoldED is only guaranteed to occupy disk space.
You are free to copy and distribute the GoldED archive freely,
provided no changes or additions are made to the package.
Odinn Sorensen (The Author) shall in no event be held liable to you or
anyone else for any damages of ANY kind, incidental or consequential,
arising from the use or inability to use this program.
All products by Odinn Sorensen are trademarks and are Copyright by
Odinn Sorensen. Other products and brand names may be trademarks and
Copyright by the respective holders.
______________________________________________________________________
Commandline Reference
______________________________________________________________________
Commandline syntax: GOLDED/GED386/GED2 [options] [keystacking]
Available options:
-C<configname>
Specifies another configuration file than the default GOLDED.CFG.
-D
Disable old configuration keywords. For backward compatibility,
GoldED still supports a number of old names for some configuration
keywords. I recommend that you use -D sometimes and rename the
keywords that are reported as unknown.
-E<echoid>
If specified, GoldED starts directly in the specified echo,
bypassing the arealist screen. See the AREASTART configuration
keyword for more info.
-F
Force recompile of most configuration files, but not all. Does not
recompile the .CHS files.
-FF
Force complete recompile of all configuration files, regardless of
whether they are up-to-date or not. This is equivalent to deleting
all the *.GE? files.
-M
Mute. Disables all sounds in GoldED.
-N
No share. If used, this prevents GoldED from using SHARE
compatible file-open calls, which are used by default. Works only
until the SHAREMODE keyword is used in GOLDED.CFG. This keyword is
normally not useful, but may be used to debug your setup or
something.
-O<ovlsize>
Specifies the overlay size for GoldED (the default is
approximately 64K). Higher values (up to about 300K) causes GoldED
to run faster and use more memory. Lower values (down to about
32K) makes it run slower, but use less memory. Check the "memory
meter" on the right side of the statusline to see how much memory
is free at any given time. The memory meter value should be
*minimum* 50-100k or more for best performance and insurance
against "out of memory" errors. The lower memory meter value, the
higher risk of out of memory errors...
This option is ignored by the 386 and OS/2 versions.
-Q
Quiet. Turns off verbose config compile. On by default. This could
be used on the commandline to disable a -V(erbose) option in the
GEDCMD environment variable.
-S<sortspec>
Sort all areas according to <sortspec>. See the AREALISTSORT
config keyword for details.
-T<seconds>
Set the timeout value. A value of zero (0) means never timeout.
See the TIMEOUT config keyword for details.
NOTE: This options is currently not functional.
-V
Turns on verbose config compile. When used, GoldED will display
the full filename of each main config file it compiles. It also
displays the name of the detected multitasker, if any. This can be
useful for debugging your setup, and see if GoldED accesses the
files (especially the AREAFILE's) it is supposed to.
-VV
Same as -V, but also displays all the active lines while
compiling. This could be used to find the exact spot if it crashes
or stops while compiling.
-W
If used, GoldED will create (and overwrite if existing) the file
GOLDAREA.INC, which will then contain all areas in the AREADEF
form, sorted by your AREALISTSORT specification. This is very
useful for converting your AREAFILE's to a form you can edit with
your favorite text editor and use in GoldED. It is also useful if
you have used the new AREADESC keyword or the AREAFILE EchoList
reader. The GOLDAREA.INC file (created in the GOLDPATH) can be
used by adding "INCLUDE GOLDAREA.INC" to your GOLDED.CFG or
GOLDAREA.CFG. When creating the file, GoldED will use '.' if an
aka is the same as the main aka, and leave out the optional origin
if it's the same as the first ORIGIN in your GOLDED.CFG. This
makes it easier to share the same GOLDAREA.INC between different
setups.
Commandline keystacking
Any non-option characters on the commandline are stuffed into the
keyboard buffer. See the chapter on keyboard definition and the
KEYBSTACK keyword for more info.
Example: GOLDED @S A
Makes GoldED go to the area scanning menu <Alt-S>, and select
scanning of <A> all areas.
See the Macros and Keystacking chapter for more info.
______________________________________________________________________
Environment Variables
______________________________________________________________________
These are the GoldED specific environment variables:
GOLDED
Path to the GOLDED.CFG file. It is recommended to set this
variable, but don't forget to change it if you move your GoldED
setup to a different directory!
GEDCMD
Specifies additional commandline options. Use this if you want to
specify options, but need to run GoldED without them (for example
when renaming GOLDED.EXE to DBEDIT.EXE in older versions of
D'Bridge). You can override the environment options with
commandline options.
GOLDNODE
The path where GoldNODE can find a GOLDED.CFG to use.
When the using AREAFILE feature to read external area configuration
from other programs, the individual AREAFILE's may use specific
environment variables to find the files. Please read the Area
Configuration chapter for specific details of each supported AREAFILE.
______________________________________________________________________
Batchfile Errorlevels
______________________________________________________________________
For operation in batch files, GoldED has a set of errorlevel values:
032 or higher Error exit (check the logfile for details).
004 Echomail entered.
002 Netmail entered.
001 Local mail entered.
000 No errors. No mail entered.
Add values together to find the combined error levels. For example,
error level 6 is returned if netmail and echomail (2+4) was entered.
Example RUNGOLD.BAT or RUNGOLD.CMD file:
=== Cut ===
@echo off
golded.exe
rem ged386.exe
rem ged2.exe
if errorlevel 008 goto error
if errorlevel 007 goto e_n_l
if errorlevel 006 goto e_n__
if errorlevel 005 goto e___l
if errorlevel 004 goto e____
if errorlevel 003 goto __n_l
if errorlevel 002 goto __n__
if errorlevel 001 goto ____l
goto nomail
:error
echo golded error exit!
goto end
:e_n_l
echo **** New echo, net and local mail entered.
goto end
:e_n__
echo **** New echo and netmail entered.
goto end
:e___l
echo **** New echo and local mail entered.
goto end
:e____
echo **** New echomail entered.
goto end
:__n_l
echo **** New net and local mail entered.
goto end
:__n__
echo **** New netmail entered.
goto end
:____l
echo **** New local mail entered.
goto end
:nomail
echo **** No new mail entered.
:end
echo.
echo Thank you for using GoldED! :-)
=== Cut ===
______________________________________________________________________
Nodelist and Userlist Support
______________________________________________________________________
In order to enable nodelist/userlist lookup and browsing, GoldED needs
to use a set of special nodelist index files, created by the GoldNODE
nodelist compiler.
None of the existing types of nodelist indexes were sufficiently
useful or documented, so I had to create my own format, and a compiler
for it. My index is "moderately" sized, a bit smaller than the
nodelist itself and smaller than most other indexes. We can only hope
that some day there will be a binary nodelist format or index which
can be used by most or all of the FidoNet developers, but that day has
yet to come.
GoldED normally uses and displays information from the nodelist when
browsing, but it doesn't really need the nodelist for anything. The
index files contains sufficient information for lookup and browsing of
names or addresses. This means that you can delete or pack away the
nodelists and/or userlists after compiling with GoldNODE, if you want
to save space and you don't need them for anything else.
Command line syntax: GOLDNODE/GN386/GN2 [-options] [configfile]
Available options:
-C Conditional compile.
-D Remove duplicate nodes from index.
-F Forced compile.
-M<nodes> Compile max <nodes> nodes (maximum is 32767).
-NE Disable the use of EMS memory.
-NX Disable the use of XMS memory.
-S<size> Set the max size of names. Normally not used.
-U<file> Create sorted FIDOUSER.LST userlist file.
The [configfile] is the path AND filename of the GOLDED.CFG
configuration file to read. If no filename is given, the path
specified with the GOLDNODE or GOLDED environment variables are used.
The nodelist index files are named GOLDNODE.GX? are are placed in the
path pointed to by the NODEPATH keyword.
______________________________________________________________________
Configuration Keyword Reference
______________________________________________________________________
This is an alphabetical list of all the configuration keywords that
can be used in the main GoldED configuration file (GOLDED.CFG and any
file included from it). It also lists and documents the keywords that
are specific to the Random System groups.
The following special symbols are used in the keyword parameter lists:
() Default value.
[] Optional parameter.
<> Required parameter, not optional.
"" Parameter must be inclosed in quotes ("").
/ Separates mutually exclusive values.
, Separates possible values for the keyword.
Here is the complete keyword list:
ADDRESS <zone:net/node[.point][@domain][, pointnet]>
Your network address, FidoNet-style. More than one address can be
specified if you are member of more than one network. The keywords
ADDRESS and AKA can be used interchangeably.
If a pointnet is specified with a point address, GoldED will use
the so-called "3D" addressing method in netmail msgs, otherwise
the "4D" method is used. The 3D method works by putting the
address ZONE:POINTNET/POINT.0 in the msg header, instead of the 4D
format ZONE:NET/NODE.POINT. Most modern mailers and mail
processors now supports the 4D format, but if you are a point, you
should always consult your Boss about which format to use.
The optional @domain part can be used to specify a "fifth"
dimension to the 4D address. It is normally not necessary to
specify a domain. Domains are never shown in the header and are
not put in the origin line. The only place the domain is
used/added by GoldED is in the MSGID kludge.
Examples:
Address 2:236/77 ; Node address
Address 2:236/77.1 ; Point address (4D)
Address 2:236/77.1, 16077 ; Point address (3D)
Address 2:236/77@fidonet ; Node address with domain
ADDRESSMACRO <macro>,<name>,<address>[,"subject"][,attribs]
Defines a short name for often used addresses. Typical uses are
for AreaFix/AreaMgr, your uplink, boss, points or others you write
to often. To use a defined address macro, you just type it in the
To: name field.
If (and ONLY if) the subject is enclosed in quotes ("" or ''),
GoldED will look for message attributes after the subject. See the
Message Attributes Reference for a valid attribute. You cannot
have quotes within quotes (not the same type anyway).
The attribues are *added* to the ones already there, they do *not*
replace them.
Examples:
afup,AreaFix,2:236/512,"password -q -l",K/S
ffup,FileFix,2:236/512,password
odin,Odinn Sorensen,2:236/77,GoldED - What else? :-)
A special format is supported for UUCP or INTERNET gateways. The
special format is indicated with a (@) as the first character in
the <name>.
jfu,@fallesen@diku.dk,2:310/33
dn,@INTERNET/david@csource.oz.au,2:241/999
In the first example, GoldED will put "UUCP" (the default gateway
name) in the TO: msg header field and "To: fallesen@diku.dk" on
the first line of the message text.
In the second example, GoldED will put "INTERNET" in the TO:
field, and "To: david@csource.oz.au" in the message. The forward
slash (/) separates the gateway name from the receiver address.
Any gateway name may be used.
The address macros can also be specified in an external file, like
the NAMES.FD file supported by the FrontDoor mailer/editor and
Maximus BBS. See the keyword NAMESFILE for details. However, you
should not use the syntax with the attributes in the NAMES.FD
file, because FrontDoor and Maximus do not know this syntax.
AKA <zone:net/node[.point][@domain][, pointnet]>
AKA (Also Known As) is an alias for the ADDRESS keyword.
AKAMATCHECHO <yes/no> (no)
If enabled, GoldED will attempt to match one of your akas to the
address of the person you are replying to in echomail areas.
Normally it is not desirable to enable aka matching in echomail,
because some echoes may be restricted to members of one particular
network, and an accidental wrong aka matching may attract unwanted
attention from the moderator or the compulsive flamers :-)
AKAMATCHLOCAL <yes/no> (no)
If enabled, GoldED will attempt to match one of your akas to the
address of the person you are replying to in local areas.
It doesn't really make sense to do aka matching in local areas.
The keyword is just there for completeness.
AKAMATCHNET <yes/no> (yes)
If enabled, GoldED will attempt to match one of your akas to the
address of the person you are replying to in netmail areas. This
is especially useful if you are a member in more than one network,
and therefore have more than one address.
AREA <echoid> <"desc"> <msgbase>[type] <loc> [akano] [attrs]
This keyword defines a mail area in GoldED. You need to define at
least one mail area to run GoldED, or use the AREAFILE keyword to
read the area setup of your mailer, mail processor or BBS.
<echoid> Mail area identifier.
<"desc"> Area description in ("") quotes.
<msgbase> O(Opus *.MSG), F(Fido *.MSG), S(FTS-0001 *.MSG),
Q(QuickBBS), R(RemoteAccess), H(Hudson), M(Squish),
J(JAM), G(Goldbase), P(PCBoard).
[type] N(Netmail), E(Echomail), L(Local).
<location> Directory path/file or Hudson board number.
[aka] AKA number (starting from 0)
[attrs] R/O(Read-Only), and/or other attributes.
"O(Opus)" and "F(Fido)" are synonyms (*.MSG files).
"S(FTS-0001)" are *.MSG files, but with zone/point header fields.
"Q(QuickBBS)", "R(RemoteAccess)" and "H(Hudson) are synonyms.
"M(Squish)" is the Squish format.
"J(JAM) is the JAM format.
"G(Goldbase)" is the Goldbase format.
"P(PCBoard) is the PCBoard format.
It is recommended to use the newer AREADEF keyword, which allows
more detailed mail area setup.
AREAAUTOFREQ <echoid>
Obsolete keyword name. Replaced by AREAFREQTO.
AREAAUTONEXT <yes/no> (yes)
If enabled, 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.
AREACOPYTO <echoid>
Sets the default area for the Copy/Move functions. Typically you
could set it to a "safe/permanent storage" type of area, for
example a JOKES2KEEP or THE_SAFE area. Note that the Forward
function uses the AREAREPLYTO area instead.
This keyword can be used globally and in a Random System group.
Related keywords: AREAFREQTO, AREAREPLYTO.
AREADEF <setup>
This is newer version of the "AREA" keyword, with more detailed
parameters.
The full syntax is: (must be all on one line)
AREADEF <echoid> <"desc"> <group> <type> <msgbase> <path/board>
<aka> <(attrs)> ["origin"]
<echoid> The echoid.
<"desc"> Area description in quotes.
<group> Groupid letter (A-Z), or 0 if not in a group.
<type> Net, Echo or Local.
<msgbase> Opus, FTSC, Hudson, Squish, Ezycom, JAM, Goldbase or
PCBoard.
<path/board> Area path, boardnumber or base filename.
<aka> Aka address for the area, or '.' for main aka.
<(attrs)> Default attributes in brackets ().
["origin"] Optional default origin in quotes.
This looks a lot like the AREA keyword. Additional parameters are
the <group>, the verbose <type> and <msgbase>, the fully specified
<aka> address, the brackets for the attributes and the optional
origin.
Note the possibility of using '.' to specify the main aka. This,
and the optional default origin, makes it simpler to create a
common INCLUDE'able area configuration for several setups with
different addresses, for example two people sharing the same
msgbase.
AREADESC <echoid> <"desc"> [group] [aka] [(attrs)] ["origin"]
Adds a description and optionally a group letter, aka, attributes
and origin to an _existing_ (previously defined) area. This is
useful if you use an AREAFILE that does not contain descriptions,
groups, akas, attributes or origins.
<echoid> The echoid.
<"desc"> Area description in quotes.
[group] Optional groupid letter (A-Z) or 0 if not in a group
or '-' to keep the existing group letter.
[aka] Optional aka address for the area, or '.' for main
aka, or '-' to keep the existing aka.
[(attrs)] Optional default attributes in brackets (), '-' to
keep the existing attributes. Note that if they are
specified, they are _added_ to the default
net/echo/local attributes.
["origin"] Optional default origin in quotes.
NOTE: You cannot skip any of the optional parts in the middle,
even if you only want to set, say, an origin. Use '-' to keep the
existing value for the parts you skip.
AREAEXCL <echoid mask>
With this keyword, you can define the echoids of areas which
should be ignored by GoldED (thereby leaving them out of the
arealist). This is normally used in connection with AREAFILE, to
exclude areas you are not interested in reading. DOS/4DOS-style
wildcards (* and ?) can be used in the echoid mask.
Examples:
AREAEXCL * Excludes all areas.
AREAEXCL *INTER* Excludes all areas containing "INTER" anywhere
in the echoid.
AREAEXCL INT*.* Excludes all areas beginning with "INT" and
containing a '.' anywhere in the echoid.
You can use the AREAINCL keyword to re-include areas which have
been excluded with AREAEXCL.
AREAFILE <type> [path/file] [switches]
GoldED can read the area setup of many popular mailers, mail
processors and BBS'es, thereby making it much easier and simpler
to configure GoldED for the mail areas you receive, by eliminating
the need to write AREA lines for all or most of your areas.
<type> Name of the program.
[path/file] Filename or path to the area setup files.
[switches] Msgbase specific switches.
For most programs, GoldED can automatically find the path or
filename using environment variables. By default, GoldED will look
for the area setup files in the AREAPATH.
There are switches for sorting the areas, and for turning off an
update-check when GoldED starts up.
This keyword is explained in greater detail in the Area
Configuration chapter.
AREAFILEGROUPS <yes/no> (no)
In some AREAFILE setups, you can groups the areas using single
letters (A-Z). If this keyword is enabled, GoldED will use the
area groupid letter instead of the area echoid when gathering area
specific information from the Random System.
If this keyword is enabled, you should setup matching GROUP's in
GOLDRAND.CFG. See the Random System chapter for details.
AREAFREQTO <echoid>
Sets the default area for the filerequest function. You should set
this to the netmail area where you normally put the filerequest
messages.
This keyword can be used globally and in a Random System group.
Related keywords: AREACOPYTO, AREAREPLYTO.
AREAINCL <echoid mask>
With this keyword, you can define the echoids of areas which
should be re-included by GoldED, if they have been excluded with
the AREAEXCL keyword. DOS/4DOS-style wildcards (* and ?) can be
used in the echoid mask.
Examples:
AREAINCL * Includes all areas.
AREAINCL *INTER* Includes all areas containing "INTER" anywhere
in the echoid.
AREAINCL INT*.* Includes all areas beginning with "INT" and
containing a '.' anywhere in the echoid.
You can use the AREAINCL keyword to re-include areas which have
been excluded with AREAEXCL.
AREAKEEPLAST <yes/no> (yes)
If enabled, GoldED will write the file GOLDLAST.LST in the
GOLDPATH at exit and read it back when run next time. The contents
of the file is a list of lastread information for each area as it
was at last scan.
This new feature is helpful when you know that there have not been
tossed new mail and don't want to wait for a full msgbase scan.
Now you can just hit ESC at the startup screen to abort the area
scan and GoldED will put up the lastread info from the previous
session.
It also makes the "new mail since last scan" feature even better,
because the new mail marker now shows which areas that have new
mail since last session even when scanning areas at startup.
AREALISTECHOMAX <size> (0)
Allows you to specify a fixed or dynamically sized width of the
EchoID column in the arealist.
If a negative value is specified, the width will be the that of
the widest echoid in the arealist plus the negative value. This
might be useful if some long-name echoes have uninteresting ends,
such as "VERYLONGECHOID_R23.PUB" (could benefit from a <size> of
-7). There is currently no provision for long echoids with common
beginning.
The arealist can dynamically resize the EchoID and Description
columns, so that long echoids are not cut off. The sizing of the
EchoID column is done against the Description column, which
thereby looses or gains width. In version 2.41 and earlier, the
EchoID column width was fixed at 13 chars on 80 column displays.
AREALISTNOS <yes/no> (no)
If enabled, GoldED will display the board numbers of Hudson areas
in the arealist instead of the default sequential numbers.
AREALISTSORT <sortspec>
This keyword defines how the area list should be sorted. You can
override the default setting from the commandline with the -S
switch.
The <sortspec> can be composed of the following types:
A Sort by aka.
B Sort by board number.
D Sort by description.
E Sort by echoid.
F Sorts all "fuzzy search" matches first.
G Sort by group (if any).
M Sorts all marked areas first.
O Sort by original order.
T Sort by type (in the order net, echo, local).
U Sort by unread messages (try it!).
Y Sorts all areas with "new" mail first.
- Descending sort (largest first).
+ Ascending sort (smallest first) (default).
In practice 'M' and 'Y' will usually give the same result, because
GoldED automatically marks scanned areas if they contain new mail.
Example:
AREALISTSORT T-U+E
This sorts ascending by Type, descending by Unread (that is, areas
with the most unread messages comes first) and ascending by Echoid
(in case two areas have the same number of unread msgs).
By default no sorting is done, and all areas are listed in the
order they were found (unless sorting was specified with an
AREAFILE keyword). However, the configuration examples all make
use of the Unread sorting type. This is a very useful way of
sorting areas, because it keeps all the areas with mail together.
Personally I now sort my areas like this: "AREALISTSORT FYTUE".
This puts all areas with new mail first, then sorts these into
type (net/echo/local), then into number of new msgs and finally
into echoid. The 'F' at the start enables fuzzy match sorting,
which is very handy when looking for an echoid containing a
particular word. Let's say I want a list of all GOLDED echoes. I
can now simply type "GOLDED" and then the arealist automagically
sorts itself so that all echoes with an echoid containing "GOLDED"
comes first :-)
AREALISTTYPE <new/last> (new)
Defines the contents of the 4th column (the one after the "Total"
column).
New Displays the amount of new (unread) msgs.
Last Displays the number of the last msg read.
AREAPATH <path>
If you use the AREAFILE keyword, GoldED might need to know where
the area setup files are located. This keyword specifies where
they are found, if not current directory.
NOTE: Most AREAFILE types can find the path using the environment
variable(s) specific for the program(s). Such environment
variables (or a path specified with the AREAFILE definition)
always overrides the AREAPATH.
AREAREADONLY <soft/hard> (soft)
If this keyword is set to "hard", it is no longer possible to
enter/reply/change messages in areas marked read-only with the R/O
area attribute. The "soft" setting uses a menu to ask permission
as in the previous versions. This option is designed for those who
setup a system for new computer users who might be confused enough
to enter a message in a read-only area despite the warning menu.
AREARENAME <from echoid> <to echoid>
Renames one echoid to another. The feature is meant to be used in
connection with AREAFILE, where some types do not store echoids
with the areas (and GoldED then automatically gives them unique
echoids).
Examples:
AREARENAME NET001 NETMAIL
AREARENAME ECHO001 BAD_MSGS
AREARENAME LOCAL001 BBS.USERS
AREAREPLYTO <echoid> (first netmail area)
Sets the default area for the READmovequotemsg, READmovecommentmsg
and Forward functions. The default area is the first netmail area
found in your setup. You should check if GoldED found the correct
one if you have more than one. If you find yourself often
forwarding or quoting from one area to another, it might be a good
idea to setup a Random System group and put in this keyword.
Example:
Group GOLDED
AreaReplyto GOLDED.BETA
EndGroup
This keyword can be used globally and in a Random System group.
Related keywords: AREACOPYTO, AREAFREQTO.
AREASCAN <echoid mask>
This keyword defines areas which will be automatically scanned
when starting GoldED. DOS/4DOS-style wildcards (* and ?) can be
used in the echoid mask.
Examples:
AREASCAN * Scan all areas.
AREASCAN *INTER* Scan all areas containing "INTER" anywhere in
the echoid.
AREASCAN INT*.* Scan all areas beginning with "INT" and
containing a '.' anywhere in the echoid.
It is recommended to have an "AREASCAN *" to scan all areas at
startup. If you don't want to wait for the scan to complete, you
can abort the scan by pressing ESC during startup.
AREASCANEXCL <echoid or wildcards>
With this keyword you can prevent areas from being scanned with
AREASCAN on startup. This is good if you use "AREASCAN *", but
have some big areas which slows it down.
AREASCANINCL <echoid or wildcards>
Here you can specify areas to be scanned with AREASCAN even if
they were excluded with AREASCANEXCL. Useful for partial reversal
of wildcard specs in the excludes.
AREASTART <echoid>
Normally GoldED starts by displaying the arealist, to let you
select which area you want to read. If this keyword is defined,
the arealist is bypassed and GoldED starts directly in the
configured area. You can override AREASTART with the -E
commandline switch.
ASKDELORIG <yes/no> (yes)
If enabled, you will be asked if the message you just replied to
should be deleted. Otherwise it is left untouched.
This keyword is only functional in netmail and local areas.
ASSIGNTO <echoid> [echoid] [..]
Obsolete alias of the MEMBER keyword. ASSIGNTO is used in Random
System GROUP's.
ATTRIBSATTACH <attributes>
Defines the attributes that are *added* to the existing attributes
of a message when the file attach attribute is toggled on.
ATTRIBSCC <attributes>
Defines the default attributes of Carbon Copy messages. CC
attributes are *added* to the existing attributes of the original
message. Usually used to add the Kill/Sent attribute.
ATTRIBSCFM <attributes>
Defines the default attributes of the Confirmation Receipt
message.
ATTRIBSECHO <attributes>
Defines the default attributes of messages entered in echomail
areas.
ATTRIBSFRQ <attributes>
Defines the attributes to use for messages generated with the file
request function. Suggested attributes are: PVT K/S CRA. The FRQ
and LOC attributes are added automatically.
ATTRIBSLOCAL <attributes>
Defines the default attributes of messages entered in local areas.
ATTRIBSNET <attributes>
Defines the default attributes of messages entered in netmail
areas.
ATTRIBUTES <attributes>
Defines the default attributes for area members of the current
Random System group.
BEEPCOMMENT <yes/no> (yes)
If enabled, GoldED will make a noise when the cursor in the
internal editor is moved across a word defined with the
EDITCOMMENT keyword.
BEEPFACTOR <value> (5)
The value changes the noise made by the BEEPCOMMENT, BEEPLOCALMSG
and BEEPYOURMAIL keywords.
The noise is dependent on speed of the computer, to a low value is
best for XT's and AT's, while larger values may be better for
386's and 486's. Experiment with different values until you find a
good one.
BEEPLOCALMSG <yes/no> (yes)
If enabled, GoldED will make a noise if it finds a msg with the
"Local" (LOC) attributes set. This can be useful for the sysop who
wants to monitor the msgs entered by users on his/her BBS.
A related keyword is DISPLOCALHIGH.
BEEPNOISES <yes/no> (yes)
If enabled, GoldED makes noises when it wants attention.
NOTE: This is the "master switch" for all noises in GoldED.
BEEPYOURMAIL <yes/no/always> (yes)
If set to "yes", GoldED will make a noise if it finds a
non-received message to one of your USERNAME's. If set to
"always", GoldED will make the noise even if it has already been
marked as received.
CARBONCOPYLIST <listspec> (Names)
This specifies the format of the Carbon Copy list, as it will look
after processing. You can also change the format in the CC menu
before processing.
The <listspec> can be one of the following:
Keep Keep the list as entered.
Names Convert list to "CC: Name, Name, Name.." format.
Visible Convert list to "CC: Name Address" format.
Hidden Convert list to "^aCC: Name Address" format.
Remove Remove the list completely.
More details can be found in the Carbon Copy and Crossposting chapter.
COLOR <colorspec>
Using this keyword you can define or redefine all the colors used
in GoldED. See the Color Configuration chapter for details.
A complete color setup consists of a quite a lot of COLOR
keywords, and it is normal practice to put them in a separate .CFG
file and use the INCLUDE keyword to let GoldED read it. The COLORS
archive contains a number of example color/mono setups. Try them
out if you think the default colors stink :-)
COLORSET <Normal/Intense/Mono> (Normal or Mono)
Three color setups are built-in, and can be selected with this
keyword.
The Normal set is the default when a color display adapter is
detected. The Normal set has all black background, with bright
neon-like colors for the window frames. Some hate it, some love
it. :-)
The Intense set switches off the "blink" attribute, thereby
enabling the use of intense (bright) colors for the background
("paper") colors as well as the foreground ("ink") colors. This is
used in the Intense set to make a bright white background, sort of
like the standard Windows 3.0 setup.
The Mono set is the default when a monochrome adapter is detected.
CONFIRMFILE <filename> (GOLDED.CFM)
GoldED supports the Confirmation Receipt attribute, as used in
FrontDoor 2.xx with the FLAGS CFM kludge. If GoldED finds an
unreceived message to one of your USERNAME's with the CFM (or the
RRQ Return Receipt Request) attribute set, it generates an
automatic response message from the content of the CONFIRMFILE. In
the file you can use many of the template tokens to personalize
the automatic message. You can specify the default attributes for
the message with the ATTRIBSCFM keyword.
Template tokens are explained in the Message Template chapter.
COOKIEFILE <[path]<file>>
Defines any number of "cookie" files, which will be automatically
indexed if needed. The cookie (or "random") files are those which
can be used in the templates, using the "@random" token.
The [path] defaults to the GOLDPATH.
NOTE: This feature only works for REGISTERED users, and replaces
the old external utility "GoldRAND" which was distributed in the
GRAND101 archive.
COOKIEPATH <path> (defaults to the GOLDPATH)
Defines the default path for the COOKIEFILE keyword and the
@random template token.
CROSSPOSTLIST <listspec> (Verbose)
This specifies the format of the Crosspost list, as it will look
after processing.
The <listspec> can be one of the following:
None Crosspost without a list in the msgs.
Verbose Change the list to lines of "* Crossposted in ..."
Raw Keep the crosspost list as you entered it.
More details can be found in the Carbon Copy and Crossposting
chapter.
CTRLINFOECHO <Tearline,Origin,yes/no> (Tearline Origin)
Specifies if you want tearline and origin in your echomail
messages. They will be added by your echomail processor if you
disable them here.
Examples:
CTRLINFOECHO Tearline Origin ; Add both tearline and origin.
CTRLINFOECHO Tearline ; Add only a tearline.
CTRLINFOECHO Origin ; Add only an origin.
NOTE: If you use the last example, your mail processor may get
confused. However, most modern mail processors *can* handle msgs
without a tearline.
CTRLINFOLOCAL <Tearline,Origin,yes/no> (Tearline Origin)
Specifies if you want tearline and origin in your messages in
local areas. In local areas, the tearline and origin is normally
never required but can be used for cosmetic purposes.
Examples:
CTRLINFOLOCAL Tearline Origin ; Add both tearline and origin.
CTRLINFOLOCAL Tearline ; Add only a tearline.
CTRLINFOLOCAL Origin ; Add only an origin.
CTRLINFONET <Tearline,Origin,yes/no> (Tearline)
Specifies if you want tearline and origin in your netmail
messages. In netmail areas, the tearline and origin is normally
never required but can be used for cosmetic purposes.
Examples:
CTRLINFONET Tearline Origin ; Add both tearline and origin.
CTRLINFONET Tearline ; Add only a tearline.
CTRLINFONET Origin ; Add only an origin.
DISPAREANO <yes/no/always> (yes)
This keyword specifies if GoldED should display the area number on
the top line in the reader.
Yes Display it only if non-zero.
No Never display it.
Always Always display the area number.
The area number is the same as that displayed in the leftmost
column in the arealist. This also means that the number displayed
can be either the "real" area number (Hudson/Goldbase/Ezycom
board) or the standard sequential number (toggleable with Alt-B in
the arealist).
The number is displayed in square brackets to the left of the area
description. I am not sure that is the best place for it - things
are getting kinda crowded up there... Suggestions are welcome.
DISPATTACHSIZE <bytes/kbytes/no> (kbytes)
Controls how the size of attached files is displayed in the
header. Either the exact byte size, the rounded kbyte size, or not
displayed at all. If the kbytes setting is chosen, the value is
rounded according to the following formula: kbytes = (bytes + 512)
/ 1024. So a 600 bytes file is rounded up to "1k", but a 500 bytes
file is rounded down to "0k".
DISPAUTONEXT <yes/no> (yes)
If enabled, GoldED will automatically jump to the next message
when entering an area.
DISPHDRDATESET <pos> <len> (-20 20)
Specifies the position and length of the date field in the header
display. If a negative value is specified, that value is added to
the current display width.
DISPHDRNAMESET <pos> <len> (8 36)
Specifies the position and length of the from/to name field in the
header display. If a negative value is specified, that value is
added to the current display width.
DISPHDRNODESET <pos> <len> (44 16)
Specfies the position and length of the from/to node address field
in the header display. If a negative value is specified, that
value is added to the current display width.
NOTE: The attributes display moves along with the DISPHDRNODESET
values.
DISPLISTWRAP <yes/no> (yes)
Enables/disables wrap-round when the selection bar in the main
list/browser windows reaches the top or bottom.
DISPLOCALHIGH <yes/no> (yes)
If enabled, GoldED will display the FROM name with the highlight
color, if a message has the Local (LOC) attribute set.
A related keyword is BEEPLOCALMSG.
DISPMARGIN <width> (0)
This is the right margin (display width) used for message display.
If the value is 0 (zero), GoldED will default to the current
screen width. If a negative value is specified, that value will be
added to the current screen width (thereby decreasing the display
width relative to the screen width).
If the DISPPAGEBAR keyword is enabled, the right margin is
automatically decreased by one char.
DISPMSGLIST <yes/no> (no)
If enabled, GoldED automatically starts the message lister when
entering an area.
This keyword can be used globally and in Random System groups.
DISPMSGSIZE <bytes/kbytes/no> (bytes)
When enabled, this keyword displays the msgbody size in the lower
left side of the header. The size displayed is for the message
body text only, the header and nul-terminator (and anything that
may lurk beyond it) is excluded from the calculation.
NOTE: This feature currently only works when _reading_ msgs. While
editing a msg in the internal editor, this feature is disabled -
however, the size will be displayed when you are in the Save msg
menu (if EDITSAVEMENU is enabled).
DISPPAGEBAR <yes/no> (yes)
If enabled, a "pagebar" (similar to the scrollbar in GUI's) will
appear on the right margin, telling you about the relative size
and position in the message you are reading. It is only displayed
if a message is longer than a screenful.
The pagebar automatically decreases the DISPMARGIN by one char.
DISPREALMSGNO <yes/no> (no)
GoldED can display the message numbers in two ways:
1. As the actual (real) msg numbers.
2. As "relative" numbers, which are always sequential from msg
number 1.
Normally the relative numbers are best, because they reflect the
actual number of msgs in the system.
DISPSOFTCR <yes/no> (no)
If enabled, GoldED will treat the so-called Soft-CR character
(ASCII 141, HEX 8D) just like any other displayable character,
instead of ignoring it like linefeed chars (LF). Note that by
enabling this feature, you _disable_ the character translation
feature that uses the Soft-CR as an escape character. This feature
was added to help users in countries which use the Soft-CR
character for other purposes like 2-byte characters in Japan.
NOTE: The Ezycom msgbase format requires the Soft-CR to terminate
each line. Therefore this feature is unlikely to be useful to
Ezycom sysops.
DISPSTATUSLINE <yes/no> (yes)
If set to NO, the statusline with memory meter, clock etc. will be
disabled. This option has been implemented as a temporary help for
visually impaired users. More extensive help may be implemented in
future versions.
DISPTABSIZE <chars> (8)
The tab size (number of spaces) used when displaying the tab
(ASCII 9) character, and when pressing <Tab> in the internal
editor.
If you use an external editor, you should switch it to create
spaces instead of tabs, because tabs are technically not allowed
in FidoNet technology messages.
DOSPROMPT (yes/no) (yes)
If enabled, GoldED will add a message about itself to the DOS
prompt when shelling out.
DOSSWAP <yes/no,xms,ems,disk,hide,checknet,noprealloc> (no)
With this keyword you can specify what storage devices the DOS
shell swapper should try or use, and what order to try them in.
It is only relevant for the standard 16-bit DOS version. The 386
and OS/2 versions will ignore this keyword.
The YES parameter tells the swapper to try XMS, EMS, DISK in that
order, and NO tells it not to swap at all (this will leave the
main part of GoldED in memory, and give you little room in the DOS
shell).
You can specify your own order, such as "DOSSWAP EMS, XMS, DISK",
which makes it try it in that order, or "DOSSWAP EMS, DISK", which
makes it ignore XMS.
If disk swapping is used, the swap file will be placed in the
SWAPPATH.
These parameters modify the disk swapping behaviour:
HIDE Hides the swapfile, if diskswapping is used.
CHECKNET For some reason, disk swapping is slower if running
on a (Novell) network without this.
NOPREALLOC Use this if you are always running on a network
(instead of enabling CHECKNET).
IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
Some programs use extended memory in ways that may conflict with
the XMS extended memory driver, causing inexplicable crashes. If
you have problems, you should first try turning off the OVERLAY
keyword, and if it still fails, turn off DOSSWAP (or stop using
those other programs :-)
EDITAUTOATTACH <yes/no> (yes)
If enabled, and you use drivespec (C:, D:, etc.) in the subject in
a netmail message, GoldED will automatically turn on the file
attach attribute. Autoattaching only works if the subject has been
edited, so that subject files will not automatically be
re-attached in replies.
EDITAUTOSAVE <seconds> (30)
If a non-zero value is given, the internal editor will
automatically execute the EDITsavefile function with intervals of
<seconds>. Good for keeping automatic backup of the message you
are writing. The saved file can be restored with the EDITloadfile
command. The name of the saved file is defined with the EDITORFILE
keyword.
If disaster strikes (power blackout, etc.) while you are writing a
message in the internal editor, this feature lets you continue
from the last autosaved message, which will popup automatically
when you enter the internal editor again.
NOTE: This feature is currently not functional, but will soon be
re-implemented.
EDITCHANGEDATE <yes/no> (yes)
If enabled, GoldED will always "touch" the message date in the
header, if you change a message after saving it.
EDITCHARPARA [']<char>['] (' ')
This keyword defines the character GoldED displays at the end of
paragraphs in the internal editor. This is where the CR character
will be placed once the msg is saved.
EDITCHARSPACE [']<char>['] (' ')
This keyword defines the character GoldED displays when it should
display a space character in the internal editor. See also the
description of the EDITCHARPARA keyword.
The keywords EDITCHARPARA and EDITCHARSPACE were added to aid me
while rewriting and debugging the new internal editor. By
redefining them to visible characters instead of spaces, I could
see if strange things were happening while inserting or deleting
characters. This was a great help. Personally I now always use
redefinitions to ASCII 20 (a paragraph sign) and CP437 250 (a
small dot).
EDITCOMMENT <"word"> <"comment">
This feature is mostly for fun :-)
It allows you to define words which causes GoldED to display a
comment in the statusline, when you place the cursor on the word
in the internal editor.
Example:
EDITCOMMENT ":-(" "Don't worry, be happy!"
EDITCOMMENT ":-)" "Are we having fun yet?"
EDITCOMMENT ";-)" "Wink wink, nudge nugde..."
EDITCOMMENT "!!!" "Flame Warning!"
EDITCOMMENT "GoldED" "Great program, isn't it?"
EDITCOMMENT "Odin" "One more 'n' please."
EDITCOMMENT "Odinn" "That's right :-)"
Have fun with it!
EDITCRLFTERM <yes/no> (no)
If enabled, all text paragraphs in your messages will be
terminated with a CR/LF combination. If disabled, only a single CR
is used. This option was created to fix a problem with an older
version of the Dutchie mail processor, that apparently needed the
CR/LF termination of kludge lines.
EDITFIELDCLEAR <yes/no> (yes)
If enabled, the input-fields will be automatically cleared for new
entry, if a non-edit key is the first key pressed.
EDITHARDLINE <string> ("<<")
The string is needed if you use an external editor that terminates
all lines with a CR or CR/LF. The hardline string acts as a text
paragraph terminator, and the normal CR's are ignored.
The concept of "hardlines" is explained in the Hardline Feature
chapter.
EDITHARDLINES <yes/no> (yes)
This keyword enables the "hardline" feature. If disabled, the
EDITHARDLINE string is never written to the editor message file,
and the editor message file is read back exactly as entered,
including terminating CR's on all lines.
EDITHDRNAMESET <pos> <len> (8 36)
Specfies the position and length of the from/to name field in the
header edit display. If a negative value is specified, that value
is added to the current display width.
EDITHDRNODESET <pos> <len> (44 36)
Specfies the position and length of the from/to node address field
in the header edit display. If a negative value is specified, that
value is added to the current display width.
EDITINTERNAL <yes/no> (yes)
Specifies if the internal editor should be the default, even if an
external editor is defined. You can always change the setting in
the editor menu (if EDITMENU is enabled) before you start writing
your message.
EDITMENU <yes/no> (yes)
This keyword enables or disables the "Edit menu" that pops up
right after you have edited the message header. If you disable the
menu, you will go to the internal or external editor immediately
and save a keystroke, but you will of course lose the features
available from the menu, such as selection of template etc.
EDITMIXCASE <yes/no> (no)
If this keyword is enabled, GoldED will automatically format the
name with uppercase the first letter in words and lowercase the
rest, when entering names in the header.
Examples:
"odinn sorensen" or "ODINN SORENSEN"
These would be re-cased to "Odinn Sorensen".
EDITMSGSIZE <bytes> (65000)
This lets you limit the size of loaded msgs. GoldED currently
cannot handle msgs larger than 64k in the DOS version (the 386 and
OS/2 versions do not have this limit). This keyword ensures that
the system will not get confused and possibly crash or exit, if a
message was encountered that was larger than 64k.
EDITOR <commandline> [@file] [@line]
With GoldED it is possible to use your favorite text editor or
even word processor to write messages. With this keyword you
specify the commandline for the editor.
If you use a word processor, be sure to make it export clean ASCII
text files without control codes. You may also need to enable the
DOSSWAP keyword, if the editor or word processor requires a lot of
free memory to run.
<commandline> Program commandline.
@file Token which is replaced by the editor message
filename.
@line Token which is replaced by the @Position
template line number.
EDITORFILE <file> (GOLDED.MSG)
Defines the name of the temporary editor message file. This file
is written by GoldED when swapping to the external editor, or when
using the EDITsavefile command in the internal editor.
The file is written in the TEMPPATH if there is no explicit path.
EDITORVERSION <version> (2)
Obsolete and no longer used. There were once two different
versions of the internal editor included in GoldED, but now the
new editor is stable enough (IMHO) to allow me to throw out the
old editor.
EDITQUOTEMARGIN <margin> (80)
Sets the right margin for quoted lines in the internal editor. You
could set this to the same value as QUOTEMARGIN (default 65), but
then you won't be able to edit quotes as freely as might be
desirable.
EDITREPLYRE <yes/no> (no)
If enabled, GoldED inserts the "RE:" string in front of the
subject when you reply to a message. If not enabled, GoldED will
strip any leading "RE:" when you reply to a msg.
The "RE:" string in subjects is an obsolete practice, and today it
only slows down modern replylinking software. Do yourself and
others a favor and let GoldED strip the RE: in your replies.
EDITSAVEMENU <yes/no> (yes)
This keyword enables or disables the "Save menu" that pops up
after you have edited your message in the internal or external
editor. If you disable the menu, your message will be saved (or
discarded if not edited) immediately and save you a keystroke, but
you will also lose the features available from the menu.
EDITSAVEUTIL <utilno> <"L menu text">
Defines the external utilities that will be added to the
EDITSAVEMENU (if enabled). The menu text is inserted in the menu.
The first two characters of the menu text are the "hotkey" letter
that will be highlighted in the menu text, plus a space. Example:
EDITSAVEUTIL 1 "S PGP Sign the msg"
EDITSAVEUTIL 2 "E PGP Encode the msg"
EDITSAVEUTIL 3 "D PGP Decode the msg"
If you have changed the default language in this menu (in
GOLDLANG.CFG), then make sure the highlight letters don't clash.
With EDITSAVEUTIL definitions and EDITSAVEMENU enabled, you can
directly call an external utility to do things like encoding or
encrypting msgs before saving them.
EDITSOFTCRXLAT <char>
If a translation char is defined, GoldED will translate the
soft-cr character (ASCII 141, HEX 8D) while importing a file in
the internal editor. Example:
EDITSOFTCRXLAT H
This example for Russians translates the soft-cr to an 'H'.
EDITSPELLCHECK <commandline> [@file]
While in the internal editor, you can use the EDITspellcheck
command to save your message to a file and shell to external
spellchecking software. When the check is completed, the corrected
file is read back and you can continue editing your message. The
EDITspellcheck command internally uses the EDITsavefile and
EDITloadfile commands.
<commandline> Spellchecker program commandline.
[@file] Token which is replaced by the message filename
(defined by the EDITORFILE keyword).
EDITUNDELETE <lines> (50)
This keyword defines the number of lines to keep in the undelete
buffer between messages.
EMPTYTEARLINE <yes,no> (no)
With this keyword enabled, GoldED will always strip the tearline
down to just the three dashes, "---", and instead inserts the PID
(Product IDentification) kludge line, which contains the same
information, but in a safer form in a safer place. The PID kludge
is proposed in FidoNet document FSC-0046.
ENDGROUP
Ends a Random System GROUP definition.
EVENT <eventtype> <eventcommand [parameters]>
This keyword allows you to specify which soundfile to play when a
specfic event occurs. The following <eventtype>'s are defined for
this release:
EVENTTYPE TRIGGER:
Arealist When the arealist shows.
AskYesNo Any Yes/No type prompt.
Attention Warnings or information popup messages.
DosShell When entering a DOS or OS/2 shell.
EditComment When an editcomment is found.
EndOfMsgs When there are no more msgs in the area.
ErrorFatal Fatal error exit.
Exit Exit from GoldED.
JobDone Successful completion of a job.
JobFailed Unsuccessful completion of a job.
MsgDeleting When deleting a msg.
MsgFromYou When a msg from you is found.
MsgIsLocal When a msg marked Local is found.
MsgIsTwit When a msg from a Twit is found.
MsgToYou When a msg to you is found.
SearchFailed Search operation failed.
SearchSuccess Search operation was successful.
Startup When the GoldED startup screen shows.
There is only one <eventcommand> defined in this release: PLAY.
The standard config files in this release contains a set of
default assignments. You will need the GOLD_VOC archive with the
"authorized" set of VOC's if you want to try these default
assignments.
Example usages:
EVENT MsgToYou PLAY HIMAN.VOC (Bart Simpson :-)
EVENT MsgIsTwit PLAY SHOTGUN.VOC
As I found out(!), you have to select the sounds carefully and
probably with a lot of experimentation, unless you want to turn
your mailreader into a honking, wailing and farting monster and
drive your poor family nuts with a cacophony of noises...
The "authorized" set is under no delusion of being well balanced,
but it's fun to use - for a while anyway.
NOTE: The sound card support feature is currently disabled.
EXCLUDENODES <addressmask>
You can define up to 50 different addressmasks to be excluded from
the compiled nodelists. Use this if you are short of space, or the
nodelist compile takes very long on your system. This keyword is
used by GoldNODE, and must be present in the main GOLDED.CFG file
(not in INCLUDE'ed .CFG's).
Excluded nodes can be re-included with the INCLUDENODES keyword.
EXTERNOPTIONS <-options>
Defines the default options for the EXTERNUTIL's. Valid options:
-Cls * Clear screen.
-Swap * Swap GoldED out of memory before shelling.
-Cursor * Cursor in shell.
-Reload * Reload the message file (@file).
-Pause Pause for keypress before returning to GoldED.
-PauseOnError * Pause only if utility errorlevel is nonzero.
Plus the reverse options with a "No" prefix, for example -NoCls.
The default options are marked with an asterisk (*).
EXTERNUTIL <utilno> [-options] <commandline>
This new feature can be used to "filter" msgs, for example calling
PGP or other encryption utilities.
The <utilno> must be in the range 1 to 24 for utilities that will
be called with key definitions (see below). Higher numbers can be
used for utilities that are called from the EDITSAVEMENU (if
enabled). See the EDITSAVEUTIL keyword for details.
The default options are those specified with the EXTERNOPTIONS
keyword. With [-options], you can change the those options locally
for specific utils. See the EXTERNOPTIONS keyword for a list of
valid options.
The <commandline> specfies the DOS or OS/2 commandline you want to
execute. This works in the same way as for the external editor and
spellchecker. See the manual for details about this, especially if
you want to execute batchfiles. In the <commandline> you can use
@tokens to transfer information from the msg to the commandline.
The @tokens are the same as for templates, and in addition you can
use two other @tokens:
@path The GOLDPATH, including a trailing backslash.
@file The full filename of the message file (GOLDED.MSG) that
will be written to disk before the utility is called.
Examples:
EXTERNUTIL 1 c:\4dos\4dos.com /c c:\crypt\encrypt.bat @file
EXTERNUTIL 2 c:\4dos\4dos.com /c c:\crypt\decrypt.bat @file
To call a defined external utility, you must assign a key to it.
There are 24 new keyboard commands you can use in GOLDKEYS.CFG for
this purpose:
ExternUtilNN
Where NN is in the range 01 to 24 _with_ leading zero. Examples:
F11 ExternUtil01
F12 ExternUtil02
Then if you press F11, you would call external utility number 1
and so on. The ExternUtilNN keywords ONLY work in reader mode, not
in the internal editor or any other place.
HOW IT WORKS:
1. Just before the external utility is called, GoldED writes the
current message text to the GOLDED.MSG file in the GOLDPATH.
The file is written as a textfile with each line CR-LF
terminated. The content is exactly as you see it on the
screen, which means that kludges are only included if you have
enabled kludge viewing.
2. GoldED clears the screen and then calls the utility after
swapping itself out of memory (if swapping is enabled or
relevant for the version).
3. The utility can now load and process the @file, or do anything
else you want. It doesn't have to have anything to do with the
current msg. You could call a spreadsheet, a game, whatever.
But I think this feature will mainly be used for utilities
that process the @file. If the utility processes the @file, it
could write the changes back to the @file.
4. After returning from the utility, GoldED reloads the @file and
displays it just as if it was the current message. For
example, if your utility was a decrypter and the msg was
encrypted, you would now see the decrypted msg. Neat eh? :-)
5. If you want to make the reloaded text permanent (save it in
the msg), you can use the Change Msg function and immediately
choose "Save Message" from the Editing menu (if enabled with
EDITMENU Yes). This is in fact the method you could use if you
wanted to EN-crypt a msg (however, it is easier to use the
method which involves the EDITSAVEUTIL keyword).
The QUOTESPACING feature can interfere with encoded msgs that
include the '>' character at the beginning of lines (often seen in
uuencoded msgs), by automatically inserting blank lines before and
after the lines with '>'. I have therefore changed the
quotespacing default from YES to NO. Be sure to check if you have
a different setting if you are using an older edition of the
advanced configuration files.
See the "Using PGP as an External Utility" chapter for batchfile
examples and instructions on how to use this new feature with PGP.
!!! IMPORTANT !!! From FidoNet Policy 4.07 (chapter 2.1.4):
"[..] Therefore, encrypted and/or commercial traffic that is
routed without the express permission of all the links in the
delivery system constitutes annoying behavior."
So be careful with this feature!
TIP: You can use the EXTERNUTIL feature to setup keys to view or
print an attached fax. Use something like this in GOLDED.CFG:
EXTERNUTIL 11 c:\zfax\zfax.com pf @subject ; print fax
EXTERNUTIL 12 c:\zfax\zfax.com vf @subject ; view fax
And this in GOLDKEYS.CFG:
@F11 ExternUtil11 ; Press Alt-F11 to print the fax
@F12 ExternUtil12 ; Press Alt-F12 to view the fax
Or choose your own key assignments and fax view/print utils.
Note that this assumes that the fax file is listed in the subject
line like an attached file.
EZYCOMMSGBASE <path>
Defines the base path for the Ezycom msgbase. If not set, AREAFILE
Ezycom will set it.
EZYCOMUSERBASE <path>
Defines the base path for the Ezycom userbase. If not set,
AREAFILE Ezycom will set it.
FIDOHWMARKS <yes/no> (no)
If enabled, GoldED will use the echomail "highwater mark" (1.MSG)
to determine if a message is "sent" or "unsent" in *.MSG areas.
NOTE: Some older echomail processors do not update the highwater
mark in a way that GoldED can recognize. If all messages appear to
marked "Uns", even after the mail has been scanned out, try
turning off this keyword.
FIDOLASTREAD <file> (LASTREAD.)
Defines the filename of the *.MSG lastread files. DO NOT specify a
path.
FIDOLASTREADNO <userno> (0)
This is an index into the FIDOLASTREAD file. Each user occupies 2
bytes in the lastread file.
FIDOMSGTYPE <Opus/FTSC> (Opus)
keyword defines the default format of Fido *.MSG files. It is only
used by some AREAFILE's when reading external area configuration
files, where the preferred format is unknown.
The FTSC (FTS-0001.012 and later) format uses zone/point fields,
where the Opus format uses date/time stamps. When set to Opus
format, GoldED interprets the date/time stamps as DOS-style
bitmapped date/time.
FIDONULLFIX <yes/no> (no)
If set to YES, GoldED will replace NUL chars with LF chars in the
msg body when reading a Fido *.MSG file. This is slower of course,
but not noticably on fast machines.
This option was created to enable GoldED users to read msgs that
were created/handled by brain-dead programs (I don't have names,
sorry) which are not obeying our primary technical standard:
FTS-0001. FTS-1 states that a NUL terminates the msg body. But
sometimes msgs are encountered which have a NUL as the first char
in the msg body or perhaps in other places, thereby causing GoldED
to show a blank or cut-off msg. In some Pascal-based readers, such
as FM, these msgs can be read anyway, because in Pascal a NUL does
not terminate a string like in C/C++.
NOTE: Even if the new FIDONULLFIX keyword is disabled, GoldED will
still fix a NUL if it is the _first_ character in the msg body.
This probably fixes most of these buggy msgs without the overhead
of checking the entire msg.
FILEALIAS <alias> <filename>
Used to define short alias names for filenames. If you regularly
write msgs to different files in different paths, this feature is
very useful, and reduces the risk of typing wrong.
Example:
FILEALIAS DKB R:\DKBBS\DKBBS
With this file alias, you can simply write "DKB" at the filename
prompt, and the long filename will be used.
FORCETEMPLATE <yes/no> (no)
If enabled, GoldED will popup a template selection menu when you
start writing a new msg or reply. If you have both TEMPLATE(s) and
FORCETEMPLATE in a Random System group, you can tell GoldED to use
the random template(s) by hitting ESC instead of selecting from
the menu.
This keyword can be used globally and in Random System groups.
FREETEAR <echoid> (MAGNA)
This keyword only works for UN-registered users. It defines one
area in which you are allowed to have a userdefined (with the
TEARLINE keyword) or a random tearline (using the Random System).
FRQEXT <.ext>
With this keyword you can add extra known filename extensions for
the filerequest function. The following extensions are already
known by default, and need not be defined (duplicate definitions
are ignored):
.ARC .ARJ .COM .DOC .EXE .GIF .LHA .LZH .PAK .RAR .RUN .SDA .SDN
.TXT .ZIP .ZOO
Each extension _must_ have the leading dot.
Example: FRQEXT .XYZ
GOLDBASEPATH <path>
Specifies the directory where GoldED can find the Goldbase msgbase
files.
GOLDPATH <path>
This is the path where GoldED finds all it's control files. It is
not necessary to define this, unless you have special needs. The
GOLDPATH defaults to directory where the GOLDED.CFG file was
found.
GROUP <groupname>
Starts a Random System group. See the Random System chapter for
details.
HUDSONPATH <path>
Specifies the directory where GoldED can find the Hudson msgbase
files.
IGNORE
This tells the configuration file reader to ignore all subsequent
lines until another IGNORE keyword is encountered. Useful for
testing and quickly switching portions of configuration.
However it is probably more useful to use the IF/ELSE/ENDIF
control keywords.
INBOUNDPATH <path> (defaults to GOLDPATH)
The inbound path is currently only used with the file request
feature (the READfilerequest command, <Ctrl-F>). If you use this
feature, GoldED will put the file descriptions into a FILES.BBS in
the inbound path, ready for when the requested files are moved to
the correct file areas.
INCLUDE <file>
This tells the configuration file reader to stop reading the
current .CFG file, and start reading the <file> as an extra
configuration file, then resume reading the previous .CFG. The
INCLUDE filenames are stored and their timestamps are checked when
GoldED is started. INCLUDE files can be nested without limit.
INCLUDENODES <addressmask>
You can define up to 50 different addressmasks to be included from
the compiled nodelists. This is only used in conjunction with the
EXCLUDENODES keyword to include otherwise EXcluded nodes. This
keyword is only used by GoldNODE, and must be present in the main
.CFG file (not in INCLUDE'ed .CFG's).
INPUTFILE <filename> (*.*)
Defines the default name in the internal editor file import
function.
This keyword can be used globally and in Random System groups.
INTENSECOLORS <yes/no> (no)
GoldED is capable of switching off the "blink" color, and thereby
enabling the use of bright background (paper) colors. Enable this
keyword, and try out one of the intense color setup examples.
INVALIDATE <type> <"findstring"> <"replacestring">
This is used to invalidate (change) certain control strings in
quoted text. Use this in conjunction with D'Bridge or other
software that chokes on control strings in quoted text. As an
added bonus feature, if the tearline or origin is invalidated to a
null string (""), they will not be quoted at all.
The <type> can be one of the following:
Tearline Invalidate tearline ("---").
Origin Invalidate origin (" * Origin: ").
Seenby Invalidate SEEN-BY's.
By default, the following invalidations are used:
"---" "-+-"
" * Origin: " " + Origin: "
"SEEN-BY" "SEEN+BY"
INTERNETGATE [gatename<,>]<address>
Defines the local internet gate you use when sending netmail to
internet users. This option is activated when you write an
internet address in the TO: field in the header display. GoldED
detects the internet address by looking for the '@' character. If
detected, GoldED puts the gate address from INTERNETGATE in the
TO: address field. If you have defined the optional gate name
(typically UUCP), GoldED also replaces the typed internet address
with the gate name and puts the internet address in a TO: line in
the message body. Some gate software accepts the internet address
directly in the header, while other software may need the special
(UUCP) name and a separate TO: line. Examples:
INTERNETGATE UUCP, 1:105/42 ; Standard, with gate name
INTERNETGATE 2:230/9316 ; My uplink runs GIGO software
This keyword can be used globally in GOLDED.CFG, if you only ever
use one gate, or in GROUP's for specific areas in GOLDRAND.CFG if
you have multiple netmail areas and regularly use more than one
gate.
INTERNETLOOKUP <yes/no> (no)
If set to Yes, GoldED will check the systemname in the nodelist
when doing a lookup and if the systemname looks like an Internet
address (contains an '@' char), the msg will be addressed to that
Internet address using the INTERNETGATE name/address if defined.
For example, let's say there was something like this in the
nodelist:
,999,somebody@somewhere,Whereever,Some_Body,...
And this in my GOLDED.CFG:
INTERNETLOOKUP Yes
INTERNETGATE 2:230/9316
Then if I did a lookup of "Some Body" and selected the entry with
the Internet address, GoldED would make a msg looking like this:
--------------------------------------
From : odinn@winboss.dk 2:236/77
To : somebody@somewhere 2:230/9316
Subj : whatever
--------------------------------------
Or if my gate was defined as "INTERNETGATE UUCP 2:230/9316":
--------------------------------------
From : odinn@winboss.dk 2:236/77
To : UUCP 2:230/9316
Subj : whatever
--------------------------------------
To: somebody@somewhere
So what's the use of all this? It allows you to make a
nodelist-style list of users with Internet addresses and use it
with GoldED so that you can do a lookup of normal names instead of
trying to remember strange Internet addresses. Of course something
similar could be done using the ADDRESSMACRO's, but with the
nodelist approach, you could build a "network" of users which have
offline Internet access via FTN-gate software and distribute the
nodelist for automatic processing.
INTERNETREPLY <yes/no> (yes)
When INTERNETREPLY is enabled, GoldED always uses the FSC-35
REPLYADDR/REPLYTO kludges to gate replies to msgs from internet
correctly. If disabled, GoldED only uses the FSC-35 method if the
internet address is too large to fit in the max-35-character TO:
header field. Some gate software requires that the FSC-35 method
is used, while other software accepts internet addresses directly
in the header.
JAMHARDDELETE <yes/no> (no)
The default setting makes GoldED conform to the JAMAPI specs when
deleting msgs in JAM msgbases. This means that deleted msgs are
only marked as such in the message header, not in the index. As a
result, GoldED will find and display the deleted msgs until you
run a message pack utility to physically remove the deleted msgs.
If JAMHARDDELETE is set to Yes, GoldED will zap the reference to
the message in the index when deleting msgs. This way the deleted
msgs will not show up again later. The drawback of this approach
is that it is hard to undelete msgs, and may break other software
which assume 100% to-the-letter conformance to the specs. Note
however, that the hard-delete method is transparent to normal use
of JAM msgbases. Probably the only software that might break are
undelete utilities.
For the techies and programmers, the hard-delete method is simply
setting both UserCRC and HdrOffset in the index to 0xFFFFFFFF
instead of only the UserCRC. According to the JAMAPI specs, a
value of 0xFFFFFFFF in HdrOffset means that "there is no
corresponding message header". Sounds remarkably like a deleted
msg, right? :-)
JAMPATH <path> (defaults to the HUDSONPATH)
Defines the path where GoldED can access the NETMAIL/ECHOMAIL.JAM
files, which are used by mail processors to find and scan out mail
written by users.
KEYBCLEAR <yes/no> (no)
Tells GoldED whether or not to clear the keyboard buffer on
startup. This also clears KEYBSTACK or commandline key stuffing.
In older versions of GoldED, it was necessary to enable this
keyword if you had renamed GOLDED.EXE to DBEDIT.EXE. This version
detects the .EXE renaming and automatically enables KEYBCLEAR,
regardless of the configuration setting.
KEYBEXT <yes/no> (no)
If enabled, GoldED will use extended bios calls to read the
keyboard. With the extended keyboard, you can use keys like
<Alt-Left>, <Alt-Home> and other extended keys. If you don't have
an extended keyboard, don't despair - using a few neat tricks, I
have made it possible to use some of the extended keys even with a
non-extended keyboard.
KEYBSTACK <keystring>
With this keyword, you can "stack" keys in the keyboard buffer.
The KEYBSTACK can be overridden by commandline keystacking, which
uses the same syntax.
The <keystring> can be a mixture of the following:
^Char Ctrl-key (^Letter).
~Char Ctrl-key (~Letter). (Use this with 4DOS!).
@Key Alt-key (@Number or @Letter).
Char Literal character.
"String" String, enclosed in double quotes.
'String' String, enclosed in single quotes.
Number Keyboard scan code (decimal).
! Clear keyboard buffer.
Whitespace (space and tab) is ignored, except in quoted strings.
See the Macros and Keystacking chapter for more info.
KLUDGE <kludge-definition>
The definition may optionally be enclosed in quotes. A definition
must be enclosed in quotes if it contains leading or trailing
spaces. The KLUDGE tells GoldED which kludges it should consider
as "known" in addition to the built-in known kludges.
Here are a bunch of examples, most of which are kludges generated
by the GIGO internet gateway software:
KLUDGE " " ; For wrapped kludges
KLUDGE "Content-Type:"
KLUDGE "Date:"
KLUDGE "From:"
KLUDGE "In-Reply-To:"
KLUDGE "Message-Id:"
KLUDGE "Mime-Version:"
KLUDGE "Organization:"
KLUDGE "Newsgroups:"
KLUDGE "Received:"
KLUDGE "Reply-To:"
KLUDGE "Sender:"
KLUDGE "Subject:"
KLUDGE "To:"
KLUDGE "Errors-To:"
KLUDGE "X-FTN-From:"
KLUDGE "ORIGREF:" ; Gatebau?
KLUDGE "ORIGID:" ; Gatebau?
KLUDGE "RFC-" ; Seen in NET_DEV
The kludges defined with KLUDGE are not case-sensitive, but when
GoldED looks for the kludges, it matches to the exact length. This
means that for example "RFC-" will match all kludges beginning
with that string.
The ASCII 1 kludge char should not be included in the definition
string, but GoldED can handle it if you do.
KLUDGECHRS <yes/no> (yes)
If set to YES, GoldED uses the "^aCHRS" kludge instead of the
"^aCHARSET" kludge when appropriate.
LOADLANGUAGE <file>
If defined, this keyword will load a language definition file.
This feature can be used to load a small set of national language
definitions in national areas, an english set in international
areas, etc. Typically this would be used to load the definitions
of the date/time strings for use in the template and the
Msg/From/To/Subj strings in the header display.
In the ADVANCED archive, a set of GEDLNG*.CFG files are provided,
which are designed for use with LOADLANGUAGE. Please note that
there is also a @loadlanguage template token. This way you can
choose to load a language file from the template, or by using the
Random System. The template token takes precedence over the
LOADLANGUAGE in the Random System, but if both are defined, both
will be loaded.
This keyword can be used globally and in Random System groups, but
it is probably not very useful when used globally.
LOGFILE <file> (GOLDED.LOG or GED386.LOG or GED2.LOG)
Defines the name of the GoldED logfile. You should not change the
default.
LOGFORMAT <fd,max,bink,qbbs,db> (fd)
Defines the log format GoldED should use when writing to the
logfile.
LOOKUPECHO <yes/no> (no)
If enabled, GoldED will use nodelist lookup when entering the TO:
name in msgs in echomail areas.
LOOKUPLOCAL <yes/no> (no)
If enabled, GoldED will use nodelist lookup when entering the TO:
name in msgs in local areas.
LOOKUPNET <yes/no> (yes)
If enabled, GoldED will use nodelist lookup when entering the TO:
name in msgs in netmail areas.
MAPDRIVE <server driveletter> <local driveletter>
If your system is running on a network, you might have your
mailer, mail processor and other software running on the server,
while GoldED is running locally on another machine on the network.
In such a case, the drive specification (C: etc) on the server
will probably not match those of the local machine (i.e. C: on the
server might be H: on the workstation). If you are file attaching
or reading area config from the mailer or mail processor on the
server with AREAFILE, the drives would be all wrong. This problem
is solved by using MAPDRIVE to remap the drive letters in GoldED.
NOTE: This keyword ONLY works in AREAFILE's to convert remote
driveletters.
MEMBER <echoid>
Defines Random System group members. See the Random System chapter
for details.
MENUDROPMSG <yes/no> (no)
Defines the default selection in the "Drop This Msg?" menu.
MOUSE <yes/no> (no)
The mouse support in GoldED is currently not functional.
NAMESFILE <file> (NAMES.FD)
GoldED supports the "address macro" file supported by FrontDoor
and Maximus. If no path is specified, the file is first searched
for in the path from the "FD" environment variable and then the
GOLDPATH, if the FD variable failed.
The address macros are added *after* those defined with the
ADDRESSMACRO keyword (if any) (see this for details on the
format).
NETNAME <"string">
This is the "netname" that is placed in the originline, in front
of the address.
Example:
NETNAME "FidoNet"
Produces:
* Origin: Whatever (FidoNet 2:236/77)
This keyword can be used globally and in a Random System group.
NOTE: The netname is a non-standard practice with no technical
merit and should not be used. It is provided for cosmetical
purposes and backward compatibility only.
NODELIST <file> [zone/addr]
Here you define the nodelists that are used by GoldED and the
companion nodelist compiler GoldNODE. The nodelists must generally
be in the standard "St.Louis" nodelist format, but they can also
contain FrontDoor/Version7 style Boss/Point extensions. The
default zone is defined by the first ADDRESS or AKA, but can be
overridden by adding the zone number or a full address after the
filename. GoldED currently needs it's own special index files to
use the nodelists. These index files are created by GoldNODE.
<file> Nodelist file. If the extension is numeric or a
wildcard (".*"), the newest file with a numeric
extension is used.
[zone/addr] Default zone or address for the nodelist (if no
zone info is present in the list itself).
See also the USERLIST keyword, and the Nodelist Browsing chapter.
NOTE: If you have nodelists with duplicate some of each others
nodes, the nodelist with the newest or most correct entries should
be placed LAST, and you should use the -D (remove duplicates)
option with GoldNODE.
NODELISTWARN <yes/no> (yes)
If set to YES, GoldED will warn you during startup if one or more
nodelists are missing. Use NO to disable the warning if it bothers
you or you delete/pack your nodelists when the nodelists are
compiled.
NOTE: GoldED can work fine with lookups etc. without nodelists as
long as it can access its own indexes (GOLDNODE.GX?). Only the
extra details will be missing.
NODEPATH <path>
This is where GoldED and GoldNODE finds the nodelist files and
indexes.
ORIGIN <"string">
You can define many different origins for use in GoldED. You can
select one of the defined origins from the Origin selection menu
(the READchangeorigin keyword), which is also available from the
EDITMENU and the EDITSAVEMENU.
Leading and/or trailing spaces can be added by enclosing the
origin string in quotes.
This keyword can be used globally and in a Random System group.
NOTE: Origins defined in the Random System will always override
the global origins defined with this keyword, except when they are
selected from the EDITSAVEMENU.
OUTPUTFILE <file>
This is the default name of the file written using the
READwritemsg command.
This keyword can be used globally and in a Random System group.
OVERLAY <ems/ext/disk> (disk)
This keyword controls where GoldED places the overlay swap blocks.
GoldED (the standard DOS version) uses the Borland VROOMM dynamic
overlays to decrease the resident executable code.
See the DOSSWAP keyword for a warning note!
Ignored by the 386 and OS/2 versions.
PCBOARDPATH <path>
Defines the default path where GoldED should look for the PCBoard
setup files if it can't find the PCBOARD environment variable.
PLAY <soundfile>
If used in GOLDED.CFG, it defines the default sound to play when
entering an area. If used in GOLDRAND.CFG, it defines the sound to
play when entering an area or group of areas. If more than one
PLAY is used in a group in GOLDRAND.CFG, one will be chosen at
random.
The only soundfile supported in this release is the Creative
Technology Voice format - the *.VOC files. When a VOC is played
with GoldED, it is first loaded complete into memory (so don't use
big ones...) and then the CT-VOICE driver plays it. It is possible
(in most situations) to do other things while the VOC is playing,
but beware that you may run out of memory. Keep an eye on the
memory meter in the statusline. The VOC will be automatically
unloaded when it stops playing.
It is important to supply the .VOC file extension. This is the
only way GoldED knows what kind of soundfile it is. Later versions
might add support for .WAV and other types.
This keyword can be used globally and in a Random System group.
NOTE: The sound card support is currently disabled.
PRINTDEVICE <devicename> (PRN)
Defines the name of the device used for printing. PRN is the
default, but LPTx can also be used. Printers on COMx ports may
also work, but this has not been tested.
Devices are opened in Write-Only text mode. The function has been
successfully tested to work with two popular peer-to-peer network
packages.
You should NOT use a filename as devicename. Use the filename
option in the Write menu instead.
PRINTFORMFEED <yes/no> (yes)
Used when printing messages. If enabled, it prints a Form Feed
(12d) character after each message.
PRINTINIT <printstring>
This keyword defines the command string sent to your printer to
initialize it before the actual printing.
The <printstring> can contain items like these:
$Hex A hexadecimal string.
#Decimal A decimal (integer) number.
"String" Text string, enclosed in double quotes.
'String' Text string, enclosed in single quotes.
Other chars Ignored.
PRINTLENGTH <lines> (65)
Defines the number of lines per page for printing. A formfeed is
printed when every time PRINTLENGTH lines have been printed.
PRINTMARGIN <characters> (80)
The right margin to use in printed messages.
PRINTRESET <printstring>
This keyword defines the command string sent to your printer to
reset it after printing.
<printstring> See the PRINTINIT keyword.
QUOTEBLANK <yes/no> (no)
If enabled, GoldED will put the QUOTESTRING on blank lines in the
quote. Otherwise blank lines are left blank in quotes.
QUOTEBUFFILE <filename>
If used, it sets the default filename for the quotebuffer. If no
path is specified, the GOLDPATH is used.
This keyword can be used globally and in Random System groups.
NOTE: If this keyword is used in globally (in GOLDED.CFG), it
effectively disables the automatically named quotebuffers, as
described in the chapter about the QUOTEBUFMODE keyword.
QUOTEBUFMODE <ask/append/overwrite> (ask)
Specifies what GoldED should do, if the quotebuffer file exists
already.
Ask A menu asks you to select append/overwrite/skip.
Append Always append, no asking.
Overwrite Always overwrite, no asking.
The "always overwrite" mode is not very useful I guess, but it's
there if you need it.
The quotebuffer feature automatically creates special filenames
for the buffer file, using these guidelines:
FORMAT FILENAME LOCATION
Fido GOLDED.QBF In the directory with the *.MSG's.
Hudson GOLDHxxx.QBF In the HUDSONPATH.
Squish filename.QBF Where the Squish area is.
Ezycom GLDxxxxx.QBF In the EZYCOMMSGPATH.
JAM filename.QBF Where the JAM area is.
Goldbase GOLDGxxx.QBF In the GOLDBASEPATH.
PCBoard filename.QBF Where the PCBoard area is.
Note that they all have extension .QBF so that you can easily find
them.
QUOTECHARS ["]<chars>["]
Defines up to 10 chars to recognize in addition to '>' as quote
string chars. This is most useful in gated internet newsgroups,
where chars such as '|', ':' and ';' are sometimes used instead of
the '>'.
This keyword can be used globally and in Random System groups.
Example:
Group Internet:
Member alt.*, comp.*, net.email
Attributes Dir
Quotechars "|:;"
Username odinn@winboss.dk
EndGroup
The example is similar to the one I use myself (net.email is a
local netmail area where I import my gated e-mail from
winboss.dk). The username is my actual internet address.
Note that using additional quotechars such as '|' and ':' may
cause odd results when quoting in the cases when they are actually
NOT used in a message as quotechars. Consider for example quoting
a smiley :-)
QUOTEMARGIN <chars> (65)
The margin to which quotes are wrapped. A negative value means
that the negative value is added to the DISPMARGIN (not
recommended).
QUOTESPACING <yes/no> (no)
If enabled, GoldED will automatically add blank lines before and
after a block of quoted text, if none are present already. This
improves the readability of some messages.
QUOTESTRING <quotespec> (" FML> ")
With this keyword you define how you want the quotestring to look
in your quoted replies.
The <quotespec> can contain these characters:
F Replaced with the first letter of the first name.
M Replaced with the letters of the middle names.
L Replaced with the first letter of the last name.
> Required quote-char.
Spaces Cosmetics.
Other characters are allowed but *not* recommended.
RA2USERSBBS <yes/no> (no)
Use this keyword to *force* GoldED to use a RemoteAccess 2.xx
(RA2) compatible USERS.BBS file, even if RA2 is not detected. If
used, this keyword should be placed in the configuration file
_after_ any AREAFILE keyword.
REGISTERKEY <keycode>
REGISTERNAME <keyname>
These keywords are only used in registered setups.
REPLYLINK <chain/direct> (direct for JAM, chain for everything else)
If set to "direct", GoldED will link your reply directly to the
original message. If set to "chain", it will link to the last
message in the reply chain. The default ("chain") is how GoldED
has done it in all previous versions.
The advantage of the "direct" linking method is that you can
easily find the the original message the reply was for. Unless of
course you have later re-linked using a chain-linking replylinker
utility. I can recommend the utility SQLINK by David L. Nugent.
SQLINK links Squish areas using the MSGID/REPLY kludges and makes
direct links instead of chain-linking on the subject line like
most other replylinkers do. There are probably also similar
replylinkers for other msgbase formats, I just don't know them.
NOTE: Direct linking is not always useful or practical. It can be
very hard to follow a discussion with more than one participants,
because the links become branched trees instead of simple chains.
Currently GoldED is not designed to follow the branched direct
links.
ROBOTNAME <name>
A "robot" is a program on the Boss or Uplink system which responds
automatically to netmail messages. Usually the robot links or
unlinks echomail areas or distributed files.
The following ROBOTNAME's are defined by default:
AreaFix, AreaMgr, FileFix, AreaLink, AllFix, Raid, GEcho.
If you write a netmail message where the TO: name is one of the
robot names, GoldED will ignore any template definition, and give
you a blank msg (possibly with a tearline) to edit.
SCREENBLANKER <seconds> (180)
If non-zero, GoldED will blank the screen after the defined number
of seconds, and put a small moving window up instead. Hitting any
key (including shiftkeys) will return the screen to normal. If
zero, no blanking is done.
NOTE: This feature is currently not functional.
SCREENELIMSNOW <yes/no> (no)
By default GoldED writes directly to the screen memory, but
unfortunately on older CGA display adapters, direct screen writes
can produce harmless, but annoying "snow". If you can't live with
that, enable this keyword. Note however, that this also slows down
the screen updating drastically.
This option is ignored in the 386 and OS/2 versions.
SCREENMAXCOL <columns> (0)
On some systems, GoldED cannot detect the correct display size.
With this keyword you can force a specific size. If zero,
autodetect is used.
SCREENMAXROW <rows> (0)
On some systems, GoldED cannot detect the correct display size.
With this keyword you can force a specific size. If zero,
autodetect is used.
SCREENPALETTE <reg> <value> OR <reg> (red green blue)
You can change the color palette used in GoldED. The palette has
16 color registers, corresponding to the 16 colors from black (0)
to intense white (15). By changing the values in the palette
registers, it is possible to make any of the 16 colors a
completely different color. You can even make the background
colors intense, without using the intense color feature. There are
64 different colors to chose from.
To configure the palette colors in GoldED, the SCREENPALETTE
keyword is used. There are two different syntaxes:
SCREENPALETTE <reg> <value>
SCREENPALETTE <reg> (red green blue)
So you can either compose the color value using separate red,
green, blue components, or directly use a precalculated value. The
red/green/blue values can only be in the range 0-3.
These are the original palette values:
SCREENPALETTE 0 (0 0 0)
SCREENPALETTE 1 (0 0 2)
SCREENPALETTE 2 (0 2 0)
SCREENPALETTE 3 (0 2 2)
SCREENPALETTE 4 (2 0 0)
SCREENPALETTE 5 (2 0 2)
SCREENPALETTE 6 (2 2 0)
SCREENPALETTE 7 (2 2 2)
SCREENPALETTE 8 (0 1 0)
SCREENPALETTE 9 (1 1 3)
SCREENPALETTE 10 (1 3 1)
SCREENPALETTE 11 (1 3 3)
SCREENPALETTE 12 (3 1 1)
SCREENPALETTE 13 (3 1 3)
SCREENPALETTE 14 (3 3 2)
SCREENPALETTE 15 (3 3 3)
Copy these lines into your GOLDED.CFG and start experimenting! :-)
If you have written a program to edit the palette and write a
GoldED palette setup file, please don't keep it a secret! :-)
SCREENSHADOWS <yes/no> (yes)
If enabled, all relevant windows and menus in GoldED will have
shadows.
SCREENSIZE <mode> (Auto)
Use this to force GoldED to use either 25 lines, 43/50 lines on
EGA/VGA, or even special videomodes supported by your SuperVGA
adapter (modes like 132x44, 100x40 or 80x60).
The <mode> can be one of the following:
Auto Use detected size.
25 Switch to 25 lines.
4350 Switch to 43/50 lines.
Mode <NN> Switch to videomode NN (a hexadecimal value).
Please check your video adapter manual carefully before trying out
the Mode option. SELECTING A WRONG MODE CAN DAMAGE YOUR MONITOR!!!
The Mode option is ignored in the OS/2 version.
SCREENUSEBIOS <yes/no> (no)
If enabled, GoldED will use standard BIOS calls for screen
updates. This is VERY slow, and should only be used if really
needed. Normally GoldED uses direct screen writes.
This feature is ignored in the OS/2 version.
SEARCHFOR <string;string;..>
Defines a set of search strings, separated by semicolons. The
search set defined here is the default when using the Alt-F/Z
search functions or the marking system.
The semicolon works like an OR operator. That is, the search is
successful if one or more of the strings are matched.
This keyword can be used globally and in Random System groups.
SEMAPHORE <type> <file>
This keyword defines "semaphore" files, for use with other mailer
and/or mail processing software.
The <type> can be one of the following:
NETSCAN Empty netmail scan file (for D'Bridge/FD).
ECHOSCAN Empty echomail scan file (for D'Bridge).
EXPORTLIST Echoid-list of your new messages.
IMPORTLIST Echoid-list of new imported messages.
The semaphore files are placed in the AREAPATH, if no path is
specified.
See the example .CFG files for typical semaphore filenames.
SHAREMODE <yes/no/mode#> (yes)
If enabled, GoldED opens all files in a SHARE.EXE compatible mode.
The default share-mode is "Share Deny None", but another may be
specified directly if you give the mode number as the keyword
parameter (decimal).
It is normally not necessary to change the default.
SOUNDDEVICE <device> [parameters]
Default is no device, and only the standard set of beeping
effects. Valid <device>'es are:
SB or SBPRO Enable Sound Blaster support.
If SB or SBPRO was chosen and the card is setup with the factory
defaults, you don't have to supply parameters. If no parameters
are specified, GoldED uses the SOUND and BLASTER environment
variables to get the parameters or just uses the factory defaults.
The valid parameters for SB/SBPRO are:
-A<ioport> (optional)
-I<intnum> (optional)
<full path and name of the CT-VOICE.DRV file> (optional)
Example: SOUNDDEVICE SBPRO -A220 -I7 C:\SBPRO\DRV\CT-VOICE.DRV
The SB support is done by loading the CT-VOICE.DRV driver into
memory and handing it the VOC's to play with.
Although it is not tested by me, GoldED should be able to work
with any Sound Blaster compatible sound card that comes with a
CT-VOICE.DRV compatible driver.
If you don't get any sound, try (re-)installing the CT-VOICE.DRV
file with the correct parameters using the INST-DRV utility (Run
"INST-DRV DRV" in your SB/SBPRO directory).
NOTE: The sound card support is currently not functional.
SOUNDPATH <path> (defaults to the GOLDPATH)
Tells GoldED where to find the sound files for the PLAY and EVENT
keywords.
NOTE: The sound card support is currently not functional.
SQUISHSCAN <api/quick> (quick)
Specfies whether to use a quick scanning method which only looks
in the .SQI files. This will normally work fine, but may fail
slightly in obscure cases, especially when used with Squish 1.0x
or programs using the old version of the MSGAPI. If you suspect
problems, try to set this keyword to "api", which tells GoldED to
look in the .SQD file for an exact count of active msgs in the
.SQI file.
NOTE: GoldED does NOT use the original MSGAPI by Scott Dudley.
Since version 2.50, a completely rewritten implementation is used.
SQUISHUSERNO <index>
This sets the lastread index number for the Squish *.SQL lastread
files. Lowest number is 0 (zero), highest is (in theory) 65534.
If used, this disables the use of USER.BBS to find the index
number, and will in effect also stop GoldED from creating USER.BBS
or any new entries in it (useful in a single-user point system).
If a Squish msgbase is shared between several users, and you don't
want to have a USER.BBS (recommended in such a case), each user
must have a unique SQUISHUSERNO in their GOLDED/GOLDAREA.CFG.
SQUISHUSERPATH <path>
This keyword defines the path where GoldED can find and use/create
your USER.BBS file, which is used in connection with the Squish
area lastreads.
If this path is not defined, GoldED will instead take the one
specified with AREAFILE Squish or AREAFILE Maximus (whichever
comes first), or failing that, use the MAXIMUS or SQUISH
environment variables. If even that fails, the AREAPATH or
GOLDPATH is used.
STATUSLINECLOCK <yes/no> (no)
In this release, the clock is only updated when the statusline is
updated (usually when keys are pressed), and stands still when
not. In a later release, I'll add some optional timer trickery so
that it will be updated continuously (at the expense of
performance under multitaskers). No promises when that will
happen.
STATUSLINEHELP <yes/no> (no)
If enabled, GoldED will replace the "logo" in the left side of the
statusline with a text saying "F1 Help". This is for use in "point
package" setups where the user may be a complete novice, maybe
even to computers, and who needs to be guided to the help screens.
The "F1 Help" text is configurable with the ST_STATUSLINEHELP
language keyword (put it in GOLDLANG.CFG).
SWAPPATH <path> (defaults to TEMPPATH)
Defines where the swap file will be placed in case of disk
swapping in DOS shells. It is recommended that this points to a
RAM disk, if available. GoldED needs 3-500k free disk space for
the swapfile, depending on the overlay buffer size specified with
the -O commandline switch.
This keyword is ignored in the 386 and OS/2 versions.
TEARLINE <string> (@longpid @version)
Here you can define your default tearline. The tearline can be up
to 76 chars long (excluding the leading "--- "), but beware that
policies (such as FidoNet ECHOPOL1) may set a significantly lower
limit (around 30).
This keyword can be used globally and in a Random System group.
Tearlines defined in the Random System *always* overrides the
default tearline defined with this keyword.
If your tearline does not contain at least the string "GoldED" or
"GED", GoldED will automatically insert it's PID kludge.
NOTE: The tearline redefinition feature is only fully functional
for registered users. Unregistered users are only be able to
define their own tearline in one area, defined with the FREETEAR
keyword.
TEMPLATE <file> ["desc"] (GOLDED.TPL)
You can define many different template files. The templates can be
switched using the READchangetemplate popup menu or the EDITMENU.
The optional "desc" can be used to give the templates more
meaningful names like "International template" instead of just
plain "C:\GOLDED\GOLDED.TPL".
This keyword can be used globally and in a Random System group.
The Random System always overrides the default templates, except
when selected from the EDITMENU.
TEMPLATEPATH <path> (defaults to the GOLDPATH)
Defines the default path for msg templates. Use this if you want
to place templates in a path separate from the GOLDPATH.
TEMPPATH <path>
Defines the directory where temporary files are placed by GoldED
and GoldNODE.
This path should *NOT* point to a RAM disk or other volatile
media! The editor autosave file is placed here, and will almost
certainly be lost if a RAM disk is used...
GoldNODE uses this path to store a temporary file which can become
as large as the largest index file (GOLDNODE.GXN), so again, don't
point it to a small RAM disk. If GoldNODE cannot find a TEMPPATH,
it will use the NODEPATH instead.
TIMEOUT <seconds> (360)
Similar to the screen blanking (SCREENBLANKER) feature, GoldED can
auto-exit after a specified period of time. Useful if you are in a
hurry (or didn't get enough sleep last night ;-), and run GoldED
from your mailer shell. The timeout value can be overridden with
the -T commandline option.
NOTE: This feature is currently not functional.
TIMEOUTSAVEMSG <yes/no> (yes)
If set to YES, GoldED behaves as usual: It saves the (perhaps
partially written) msg text in the internal editor to the msgbase
and exits. If set to NO, GoldED will save the msg text in
GOLDED.MSG just as if EDITAUTOSAVE function was in use and the
power went out. Next time you started GoldED and entered a msg, it
would detect the "lost" msg and ask you if it should be continued.
NOTE: This feature is currently not functional.
TIMESLICE <type> (none)
This keyword is no longer functional and is obsolete. Since
version 2.50, GoldED uses a non-polling keyboard handler, so it
does not have to worry about timeslicing.
TWITMODE <mode> (Show)
In GoldED you can define several "Twit" names, addresses or
subjects. With this keyword you can specify the action taken when
a Twit message is encountered.
The <mode> can be one of the following:
Show Show twit messages.
Blank Blank twit messages.
Skip Skip twit messages, unless to your USERNAME's.
Ignore Skip twit messages, always.
This keyword can be used globally and in a Random System group.
TWITNAME <name/address>
With this keyword, you can specify "Twit" names and/or addresses.
When a Twit name/address is detected, the TWITMODE setting will
determine the action taken.
TWITSUBJ <"string">
With this keyword, you can specify "Twit" subjects. When a Twit
subject is detected, the TWITMODE setting will determine the
action taken. The subject string is searched in the entire subject
text, so you can specify a partial twit subject. Twit subjects are
limited to maximum 35 characters.
USEFLAGS <yes/no> (yes)
If enabled, GoldED inserts the FLAGS kludge for certain extended
attributes, as defined in FSC-0053 by Joaquim H. Homrighausen, and
supported by FrontDoor, D'Bridge, IMail and other modern software.
GoldED uses FLAGS to emulate the Hold and Freq attributes which
are not defined in the Hudson message format.
USEINTL <type> (yes)
The INTL kludge is normally only inserted in netmail messages, if
the origination zone is different from the destination zone (the
"Auto" setting), but on systems with many AKA's in the mailer, it
might be useful/necessary to add it ALWAYS (the "Yes" setting).
The "No" option should never be used.
The <type> can be one of the following:
Auto Only insert in inter-zone netmail.
Yes Always insert. Recommended and default.
No Never insert.
USEMSGID <yes/no> (yes)
If enabled, the MSGID kludge is inserted in netmail and echomail,
and the REPLY kludge is inserted when replying to a msg with a
MSGID.
The MSGID kludge is defined in FidoNet document FTS-9.
USERLIST <file> [zone/addr]
In addition to normal nodelist support, GoldED also supports the
"FIDOUSER.LST" style userlist format. The default zone is defined
by the first ADDRESS or AKA, but can be overridden by adding the
zone number or a full address after the filename.
<file> Userlist file in FIDOUSER.LST format.
[zone/addr] Default address for the userlist (if no zone info
is present).
USERLISTFILE <file> (GOLDED.LST)
GoldED can generate a list of all users in the current area. This
keyword defines the default name of the FIDOUSER.LST style
userlist output file generated with the READmakeuserlist command.
USERNAME <name>[,address]
You can define many different names/aliases. When GoldED finds an
un-received message to one of your USERNAME's, it is marked as
received. Useful if you use alias names in some conferences. It is
possible to change the current name using the READchangeusername
popup menu.
For msgbase formats with an associated user database, GoldED uses
the *first* defined USERNAME to look in the user database for
which lastread record to use. If your name is not found, it is
added and a new lastread record created.
This keyword can be used globally and in a Random System group.
VIEWHIDDEN <yes/no> (yes)
Hidden lines are "unknown" kludge lines. If enabled, hidden lines
will be displayed (in a different color) when reading msgs.
A hidden line is defined as a line which has the FidoNet kludge
char (^a, ASCII 1) as the first char and is not on the list of
internally or user defined known kludges.
This keyword can be used globally and in a Random System group.
IMPORTANT NOTE:
In some conferences the hidden lines are used to give witty
comment "between the lines" in the plain text, but generally it is
considered a bad practice and should be avoided because it may
cause severe technical problems if a witty comment in a hidden
line happens to match a (perhaps experimentally) defined kludge
somewhere. It should also be noted that hidden lines are not kept
in their original places when used in the JAM msgbase. This is due
to the way the JAM specification stores FidoNet kludges.
VIEWKLUDGE <yes/no> (no)
If enabled, known kludge lines will be displayed (in a different
color) when reading msgs.
Known kludges are those defined internally in GoldED plus those
defined with the KLUDGE keyword.
This keyword can be used globally and in a Random System group.
WHOTO <name>
This name is inserted in the TO: name field, when entering new
messages (not replies) in echomail or local areas.
This keyword can be used globally and in a Random System group.
XLATCHARSET <importid> <exportid> <file>
This keyword defines character set translation table files.
<importid> Charset import identifier.
<exportid> Charset export identifier.
<file> Charset translation table file.
See the Character Translation chapter for details.
XLATESCSET <import> <export> <escfile>
This keyword defines escape sequence translation table files.
<importid> Escset import identifier.
<exportid> Escset export identifier.
<file> Escape sequence translation table file.
See the Character Translation chapter for details.
XLATEXPORT <charsetid>
Defines the export charset for your messages. See the Character
Translation chapter for details.
This keyword can be used globally and in a Random System group.
XLATIMPORT <charsetid> (IBMPC)
Defines the local charset for your machine. See the Character
Translation chapter for details.
This keyword can be used globally and in a Random System group.
XLATPATH <path>
This is the path where GoldED tries to find the XLATCHARSET and
XLATESCSET files.
ZONEGATING <yes/no/ask> (ask)
When writing a netmail message to a destination in another zone,
you can either send the message directly (No) or via the local
ZoneGate (Yes). You can also be consulted each time (Ask).
______________________________________________________________________
Message Attributes Reference
______________________________________________________________________
This is a list and description of all message attributes that are
supported by GoldED in the keywords that accept attribute settings or
can be displayed in the header.
A/S Archive/sent.
ARQ Audit request.
ATT File attached.
CFM Confirmation receipt requested.
COV Fax cover letter.
CRA Crash - high priority mail.
DEL Deleted.
DIR Direct. Don't route this message.
FAX Fax image attached.
FRQ File request.
GRP Group message.
HIR Fax hi-resolution image.
HLD Hold for pickup.
HUB Host- or Hub-route message.
IMM Immediate - Send message NOW!
K/S Kill/sent. Delete message automatically after it is sent.
KFS Kill/file/sent. Delete attached files after they are sent.
LET Fax letterhead.
LOC Local. Message was written on your system.
LOK Lock. Prevents send/delete/purge/editing.
ORP Orphan. Could not be sent because destination node is unknown.
PVT Private. Message may only be read by the addressee and author.
R/O Read only. Used in area definitions to prevent writing.
RCV Received. Read by the addressee.
RRC Return receipt.
RRQ Return receipt requested.
RSV FTS-1 reserved (unused) attribute.
SIG Fax signature.
SNT Sent. Message has been sent or exported from the msgbase.
TFS Truncate/file/sent. Truncate files to zero length when sent.
TRS Transit. Message passing through, not for you.
UNS Unsent message.
URQ Update file request.
XMA Xmail. Attach does not conform to the ARCmail 0.60 standard.
ZON Zonegate. Route through zonegate if possible.
______________________________________________________________________
Area Configuration
______________________________________________________________________
GoldED offers a wide variety of methods for defining message areas.
You can define each area manually in the GOLDED.CFG file (or an
INCLUDE'ed GOLDAREA.CFG file), or you can tell GoldED to read the area
setup files of many popular BBS/mailer/mail processor packages.
For manual definition of areas, use the AREA or AREADEF (recommened)
keywords.
For external area configuration, the general syntax for the AREAFILE
keyword is:
AREAFILE <programname> [path or filename(s)] [-options]
Available options:
-NoChk
Normally GoldED will check the areafile timestamps when starting
up, and recompile the configuration if a file was changed. If this
option is given for any AREAFILE, those areafiles will not be
checked. This can be useful in cases like TosScan, GEcho, IMail
and several others which "touch" their files every time they run.
-S<sortspec>
If you are *not* using the global AREALISTSORT keyword for sorting
all the areas, you can sort the areas of each AREAFILE separately.
See the AREALISTSORT keyword for the definition of <sortspec>.
If no path is specified, the appropriate environment variable or the
AREAPATH is used to find the files.
The <programname> can be one of the following:
AreasBBS
GoldED is can handle a wide variety of AREAS.BBS type files. It
can read and distinguish between the old CONFMAIL style with paths
for *.MSG areas, the Hudson/Goldbase style with board numbers, the
Squish style with "$basename" and the JAM style with "!basename".
The disadvantage of using an AREAS.BBS is that there are no area
descriptions. The echoid is used as description instead. However,
GoldED will use any text behind a semicolon on definition lines as
description. This may or may not be compatible with mail
processors, so be careful. A better solution may be to use the
AREAFILE Echolist to add descriptions from a separate file.
One or more AREAS.BBS files may be specified on the same line.
D'Bridge
Reads the DBRIDGE.AA1/.AA2 files (for version 1.30) or the
DBRIDGE.ADF of the later versions.
Looks for the "DBRIDGE" and "DB" environment variables.
Dutchie
Reads the DUTCHIE.ARE file.
Looks for the "DUTCHIE" environment variable.
Echolist
Reads a simple ascii-text file containing an echolist in this
format:
<echoid> <description>
This feature adds descriptions to already existing areas in
GoldED. Example:
AREAFILE AreasBBS AREAS.BBS
AREAFILE EchoList ECHOLIST.TXT
Descriptions for unknown echoids are ignored. Blank lines and
lines beginning with characters which are illegal in echoids (such
as ';') are also ignored.
Ezycom
Reads CONFIG.EZY and MESSAGES.EZY. Supports Ezycom 1.02 and 1.10g,
but not 1.01.
Looks for the "EZY" and "TASK" environment variables.
FastEcho
Reads the FASTECHO.CFG file. Supports all versions up to 1.41.
Looks for the "FASTECHO" environment variable.
FidoPCB
Reads FIDOPCB.CFG Supports version 1.x.
Looks for the "FIDOPCB" environment variable.
FMail
Reads FMAIL.CFG and FMAIL.AR. Supports versions 0.92 and 0.98.
Looks for the "FMAIL" environment variable.
FrontDoor
Reads the SETUP.FD/FD.SYS and FOLDER.FD/FOLDER.SYS files. If you
want the real echoid's attached to the areas, you will also need
to supply the filename of the relevant AREAS.BBS file(s). Supports
versions 1.99c and 2.xx.
Looks for the "FD" environment variable.
GEcho
Reads SETUP.GE and AREAFILE.GE. Supports versions 1.00, 1.02 and
1.10.
Looks for the "GE" environment variable.
IMAIL
Reads the IMAIL.CF and IMAIL.AR files. Supports all versions up to
1.50.
Looks for the "IMAIL" environment variable.
InterMail
Reads the FD.SYS and FOLDER.CFG/IMFOLDER.CFG files. Supports
version 2.26 and newer.
Looks for the "IM" environment variable.
LoraBBS
Reads the CONFIG.DAT and SYSMSG.DAT files. Supports version 2.33
and newer.
Looks for the "LORA" and "LORABBS" environment variables.
Maximus
Reads the AREA.DAT file. Compatible with both the old (1.xx) and
new (2.xx) formats. If your AREA.DAT is named differently, you
must supply the correct filename.
Looks for the "MAXIMUS" environment variable.
ME2
Reads the old ME2 editor AREADESC.ME2 file and AREAS.BBS file(s).
You must supply the names of both files.
Opus
Reads the Opus 1.1x SYSTEM??.DAT files or the Opus 1.7x SYSMSG.DAT
file.
Looks for the "OPUS" environment variable.
PCBoard
Reads the PCBOARD.DAT, CNAMES.@@@ and CNAMES.ADD files. Supports
version 14.x and 15.x. Note that echoid's are not read from this
format. The description is used as echoid.
Looks for the "PCBOARD" environment variable.
Portal
Reads the PORTAL*.CFG and PORTAL.ARE files.
Looks for the "POPCMDLINE" environment variable.
QuickBBS
Reads the CONFIG.BBS or QUICKCFG.DAT+MSGCFG.DAT files. To get the
real echoid's, you must also supply the filename of the relevant
AREAS.BBS.
Looks for the "QUICKBBS" and "QBBS" environment variables.
RaEcho
Reads AREAS.RAE. Supports version 1.00 and 1.01.
Looks for the "RAECHO" environment variable.
RemoteAccess
Reads the MESSAGES.RA file. To get the real echoid's, you must
also supply the filename of the relevant AREAS.BBS. Supports
versions 0.xx, 1.xx and 2.xx.
Looks for the "RA" environment variable.
Squish
Reads SQUISH.CFG and AREAS.BBS (if used). Supports version 1.0x
and 1.10. The "Include <filename>" feature of Squish 1.10 is also
supported.
Looks for the "MAXIMUS" environment variable. Note that Squish
itself does not use any environment variables (or if it does, it
is not documented).
SuperBBS
Reads CONFIG.BBS, SCONFIG.BBS and BOARDS.BBS. Supports version
1.16 and 1.17.
Looks for the "SUPERBBS" and "SBBS" environment variables.
TosScan
Reads the FD.SYS/SETUP.FD and AREAFILE.FD files. Supports version
1.00 and FrontDoor 1.99c and 2.xx.
Looks for the "FD" environment variable.
WMail
Reads the WMAIL.PRM and AREAS.PRM files. Supports version 2.2.
Looks for the "WMAIL" environment variable.
XMail
Reads the AREAS.XM file. Supports version 1.00.
Looks for the "XM" environment variable.
______________________________________________________________________
Color Configuration
______________________________________________________________________
Color configuration in GoldED is a bit complicated, and you probably
have to experiment quite a bit, if you want make your own setup. For
your convenience, I have added a number of example color setups,
provided by some of my many good users. I suggest you try them all and
use the one that suits you best, perhaps tuning it a bit to your
taste.
The COLOR keyword uses the following syntax:
COLOR <window> <part> <colors>.
<window> AREA, ASK, BACKGROUND, BRAG, HEADER, HELP, INFO, MENU,
READER, SHADOW, STATUS.
<part> BLOCK, BORDER, BTYPE, EDIT, HIDDEN, HIGHLIGHT, INPUT,
KLUDGE, NOSELECT, ORIGIN, QUOTE, SELECTOR, TEARLINE,
TITLE, WINDOW.
The <colors> are composed of [blinking] <ink> [on <paper>].
<ink> Black, Blue, Green, Cyan, Red, Magenta, Brown, LGrey,
DGrey, LBlue, LGreen, LCyan, LRed, LMagenta, Yellow,
White.
<paper> Black, Blue, Green, Cyan, Red, Magenta, Brown, LGrey.
For monochrome setups we instead have:
<ink> Normal, Highlight, Reverse, Underline.
The SHADOW color does not need a <part>, because it is global.
The paper color always defaults to Black if not specified.
If <part> is "BTYPE", the <color> is a value in the range 0-3, which
defines the type of lines used when drawing menus and windows:
BTYPE 0 is single horizontal and single vertical lines.
BTYPE 1 is double horizontal and double vertical lines.
BTYPE 2 is single horizontal and double vertical lines.
BTYPE 3 is double horizontal and single vertical lines.
The default border type is always BTYPE 0.
The following is a description of the different window parts:
Various general color items
SHADOW Shadow below windows and menus.
STATUS WINDOW Status line at the bottom.
BACKGROUND WINDOW Background for the startup window.
Startup screen / logo window
BRAG WINDOW The Copyright window.
BRAG BORDER Lines around the Copyright window.
BRAG TITLE The logo text.
BRAG HIGHLIGHT The inner logo lines.
BRAG BLOCK The outer logo lines.
BRAG BTYPE Copyright window border type.
Area Selection Menu
AREA WINDOW Descriptions, the top line (inc. search).
AREA BORDER Lines.
AREA TITLE Titles on the border.
AREA SELECTOR Selection bar.
AREA HIGHLIGHT The color for the area marks.
AREA BTYPE Window border type.
Message Header
HEADER WINDOW Header text.
HEADER BORDER Lines.
HEADER TITLE Titles on the border.
HEADER INPUT Message number input field.
HEADER EDIT Header input fields.
HEADER HIGHLIGHT Marks.
HEADER BTYPE Window border type.
Message Text
READER WINDOW Normal message text.
READER BORDER The Pagebar.
READER QUOTE Quoted lines.
READER CURSOR Character at cursor pos. (int. editor).
READER KLUDHIDD Kludges and hidden lines.
READER TEARORIG Tearline and Origin.
READER BLOCK Block color (internal editor).
READER BTYPE Window border type.
READER HIGHLIGHT Search highlight in the message text.
Miscellaneous Smaller Menus
ASK WINDOW Menu items.
ASK BORDER Lines.
ASK TITLE Menu title.
ASK SELECTOR Selection bar.
ASK NOSELECT Non-selectable menu items.
ASK HIGHLIGHT Hotkeys.
ASK BTYPE Window border type.
Miscellaneous Larger Menus (Browser Windows)
MENU WINDOW Menu items.
MENU BORDER Lines.
MENU TITLE Menu title.
MENU SELECTOR Selection bar.
MENU NOSELECT Non-selectable menu items.
MENU HIGHLIGHT Hotkeys/marks.
Help Screens
HELP WINDOW Help text.
HELP BORDER Lines.
HELP SELECTOR Current keyword.
HELP HIGHLIGHT Other keywords.
HELP BTYPE Window border type.
Pop Up Information Windows
INFO WINDOW Window text.
INFO BORDER Lines.
INFO TITLE Info title.
INFO BTYPE Window border type.
See the GEDCOL*.CFG and GEDMON*.CFG files for examples of color
configuration.
______________________________________________________________________
The Random System
______________________________________________________________________
With the Random System, you can define area-specific sets of origins,
netnames, tearlines, templates, usernames and many other items. If
more than one item of each type is specified, a random one is picked -
a Random System. This is a very useful feature when (for example)
participating in conferences with different languages.
The Random System is built on the idea of "groups". A group is a
collection of "items", belonging to the group. You can assign one or
more echomail areas, designated by their echoid's to a group. Groups
can also be specified for just a single echo, and DOS/4DOS-style
wildcards can be used to simplify the assignment of echoes with common
strings in their name, such as *.DK, SIG.* and so on. In this way, you
could for example setup one group for all national echoes, another for
special local echoes, a third for international echoes etc.
Defining Groups
The general syntax of a group definition is:
GROUP <id>[:]
; items go here
[Member <id list>]
The Group <id> can be one of three things:
1. A group letter, matching the group letters used in the AREAFILE's
of D'Bridge, GEcho, IMail, TosScan and probably others. To use
this feature, you need to enable the AREAFILEGROUPS keyword, and
the letter groups must be defined before any other group types.
2. An echoid or echoid mask (wildcards can be used). The items are
simply defined below the Group line.
3. A group label, terminated by a colon (:). The group items are
defined below the Group line. Echoes are assigned to the group by
adding one or more Member statements.
You can't assign a group to another group. It will not harm, but it
also won't work :-)
Groups must defined with the most explicit groups first. GoldED simply
scans from beginning to end, and stops at the first group with a
matching <id> or Member list.
Defining Random Items
The random items are defined much like in the main GoldED
configuration file.
If more than one of each item is defined within a group, those items
will be picked randomly (hence the name "Random System"), while GoldED
collects items when entering an area.
Random System Example
Below is an example of how a Random System could be setup. Note how
the letter group 'D' goes first, followed by the explicit group
definitions for the NERDS and FOO echoes. Then comes the more general
groups (those with Label:'s), where the echoes are assigned with one
or more Member statements. At last there is the catch-all "Group *",
which works as the default group.
=== Cut, GOLDRAND.CFG ===
Group D ; Letter D for Danish echoes.
Template DANSK.TPL
Group NERDS ; For the NERDS echo.
Origin "I am a Nerd. Take me to your Loser!"
Group FOO ; This group is *only* for the FOO echo.
Tearline FooED @rev
Origin "Foo-ing my day away"
Group FooEchoes:
Member *FOO* ; Use wildcards to catch any other foo echo.
Tearline FooED @rev
Origin "This is a Foo-lish origin"
Group FidoNet:
Member NET_DEV, WORLDPOL, INTERCOOK
Member GREEN.029, C_ECHO, C_PLUSPLUS
Origin "Fight-O-Net? Good name..."
Template FIDONET.TPL
Whoto Everyone
Group SigNet:
Member SIG.* ; The wildcard is VERY handy here ;-)
Origin "To SIG or not to SIG..."
Template SIGNET.TPL
Group * ; This is default group
Origin "Yet forgotten echo"
=== Uncut ===
See the example GOLDRAND.CFG in the ADVANCED archive for a real-life
setup similar to the one I use myself.
______________________________________________________________________
The Message Template
______________________________________________________________________
The message template gives you a ready-made skeleton for writing your
messages in the editor. The template is one of GoldED's many strong
features. With this, you can eliminate the tedious typing of greetings
etc etc. GoldED also provides a number of replacement strings,
"tokens", to dynamically add message specific information to the
template.
As in the configuration file, a semicolon (;) first on the line makes
the line a comment. Any other line is put into the editor file, after
token expansion. Tokens are not case sensitive.
The following is a list of the tokens available:
Conditional tokens (these are replaced with a null string)
@changed Line is only inserted in Changed msgs (from others).
@comment Line is only inserted in Reply-Comments.
@echo Line is only inserted in Echomail.
@forward Line is only inserted in Forwarded messages.
@local Line is only inserted in Local messages.
@moved Line is only inserted in Reply-Moved messages.
@net Line is only inserted in Netmail.
@new Line is only inserted in New messages (not replies).
@position Specifies the starting line for the editor cursor.
@quotebuf Line is only inserted in Quotebuffered msgs.
@quoted Line is only inserted in Quoted replies.
@reply Line is only inserted in Non-Quoted Replies.
Insert tokens (anything else on the line is ignored)
@attrib <attributes> - Adds specific message attributes.
@loadlanguage Loads a partial language config file.
@message Inserts the original message (in Forward & Change).
@quote Inserts a quote of the original message.
@random [random.txt [random.idx]] - Inserts random text.
@setfrom <"from"> - Sets the message FROM: field.
@setsubj <"subject"> - Sets the message SUBJ: field.
@setto <"to"> - Sets the message TO: field.
Replacement tokens (replaced with message specific data):
@caddr Current user address.
@cdate Current date.
@cdesc Current area description.
@cecho Current echoid.
@cfname Current user first name.
@clname Current user last name.
@cname Current user name.
@ctime Current time.
@daddr Destination address.
@dfname Destination first name.
@dlname Destination last name.
@dname Destination name.
@longpid Long program id. "GoldED", "GoldED/2" or "GoldED/386".
@oaddr Original address.
@odate Original date.
@odesc Original area description if moved, else current.
@oecho Original echoid if moved, otherwise current.
@ofname Original first name.
@olname Original last name.
@oname Original name.
@os2slash "/2" if running GoldED/2. Empty otherwise.
@otime Original time.
@pid Short program id. "GED", "GED/2" or "GED386".
@rev The revision number (in the form mmdd).
@serialno For registered users: The registration serialno.
@subject The message subject line.
@taddr Destination to address.
@tfname Destination to first name.
@tlname Destination to last name.
@tname Destination to name.
@ver The simple version number (in the form x.yy)
@version The complete release version number of GoldED.
@_caddr Current user address (fixed width: 19 chars).
@_cname Current user name (fixed width: 34 chars).
@_daddr Destination address (fixed width: 19 chars).
@_dname Destination name (fixed width: 34 chars).
@_oaddr Original address (fixed width: 19 chars).
@_oname Original name (fixed width: 34 chars).
@_taddr Destination to address (fixed width: 19 chars).
@_tname Destination to name (fixed width: 34 chars).
The template text begins at the first non-comment line.
See the included GOLDED.TPL for example usage.
______________________________________________________________________
The Online Help System
______________________________________________________________________
GoldED has a built-in context sensitive help system, tied to the <F1>
key (one of the very few keys that cannot be reconfigured). It
contains a complete keyboard reference and help for most situations.
It is current not as complete or sophisticated as I'd like it myself,
but this may be improved in future versions.
You can completely redefine the help screens if you wish - the
GOLDHELP.CFG file is a plain ASCII text file which contains all help
definitions. The help file is split into several help categories. Here
is an example of a couple of defined help categories:
*B 1,Help Category 1
help text help text help text
help text help text help text
*P
help text help text help text
help text help text help text
*E
*B 2,Help Category 2
help text help text help text
help text help text help text
*P
help text help text help text
help text help text help text
See also: ^Help Category 1^
*E
The "*B" indicator specifies the beginning of a help category. The
format is "*B helpcatnumber[,helpcatname]". In GoldED the help
categories are numbered 1000-9999, split into more or less logical
groups. See the help file for assignments. There should be only one
space between the "*B" and the help category number. The help category
name is only required for cross-references. If there are no
cross-references to that help category, then you can leave the
helpcatname parameter out.
The "*P" indicator specifies a page break and is optional. You may
have as many page breaks as you'd like. The "*E" indicator specifies
the end of the help category. The "*B", "*P", and "*E" indicators must
all begin in the first column. These indicators and the help category
name are case insensitive (can be in lowercase, uppercase, or mixed).
In the definition of Help Category 2, you will notice the
crossreference to Help Category 1. All cross-referencing is done by
embedding the cross- reference category name (not number) inside
carats (^). If you need to display a carat inside the help file, use a
double carat (^^).
Any text contained outside of the "*B" and "*E" is treated as
comments. If an "*E" is not found, then the end-of-file will be
treated as an "*E".
Not all of the help categories in this help file are actually used in
the current version of GoldED. The ones not used are empty, except for
a two-line "header".
The usable dimensions of the help window are 60 columns by 16 lines.
In the help file there is a model of the actual window.
______________________________________________________________________
Character Translation
______________________________________________________________________
GoldED implements several different proposals for character
translation in imported and exported messages:
FSC-0050 "Charset Identifier" Thomas Sundblom (2:201/114).
FSC-0051 "I51" Thomas Gradin (2:200/108).
FSC-0054 "CHARSET proposal" Duncan McNutt (2:243/100).
No FSC "Composed Characters" Andre van de Wijdeven (2:500/131).
FSC-0050 is currently known to be implemented in the OPMED 3.xx
message editor, and in Opus 1.7x. It uses the same identifier as
FSC-0054 (a ^aCHARSET kludge), but is a lot simpler (but not
necessarily better).
The "I51" and "CHARSET" proposals are in the process of being merged
to one proposal, which should combine the advantages of both. They are
both based on using the LATIN-1 (also known as ISO 8859-1) character
set for extended ASCII. The LATIN-1 set is the same set used by
Windows 3.xx, Amiga and many other non-PC computers. In addition to
LATIN-1, I51 defines a set of so-called escape sequences for
characters not found in the LATIN-1 set.
"Composed Characters" became quite popular in Holland, but the author
decided to drop his proposal because it relied on escape sequences
using the so called "soft-cr" (141d, 8Dh) character. GoldED will
continue to support Composed as long as it seems necessary.
If you want to know more about the details, I suggest you read the
proposals or contact the authors.
GoldED currently supports two types of translation tables, the *.ESC
files and the *.CHS files.
The *.ESC files are used for import translation of the escape
sequences defined in I51 and Composed Characters.
In the ESC files, the semicolon is used for comments. The *first*
non-comment line defines the charset the escape code are mapped TO.
This is normally IBMPC, and should not be changed. Any other
non-comment line is treated as an escape sequence definition with this
syntax:
<esc1><esc2><space><map chars>[; comment/description]
Leading spaces are *not* allowed in ESC files. <esc1> and <esc2> are
the two characters that define the escape sequence. <space> is ignored
and can be used to make the table look better. <map chars> defines the
local representation of the escape sequence, up to three characters.
Normally you would only map to one extended ascii character. The map
chars can be either the characters themselves, or decimal or
hexadecimal numbers of the form "\d<dec>" or "\x<hex>" (like in the C
programming language).
The *.CHS files are used for import and export translation of the
CHARSET type character sets, and export of I51 and Composed escape
sequences.
The CHS files uses the format of the raw text files provided in the
CHARSET3.ZIP example implementation of FSC-0054. Study some of the
files provided if you want to know how to define them.
The two keywords XLATESCSET and XLATCHARSET are used to define which
files belong to what import and export set. You can define more than
one import and export set for each file.
The keyword XLATIMPORT defines which charset you have on your own
machine - this would normally be "IBMPC". It can be useful to change
this (using the Random System) in areas where another character set
than IBMPC is the dominant (like Amiga or MacIntosh, whatever).
The keyword XLATEXPORT defines the charset your messages should be
exported to, if any.
Confused? Yeah, I know - this is a confusing subject, and my
implementation and documentation is far from perfect. Normally you
will not have to worry about it. Turn it off completely if you don't
understand it.
______________________________________________________________________
Keyboard Command Reference
______________________________________________________________________
Most of the GoldED keyboard commands can be reached with just one
keystroke. To ease operation for experienced users of other message
editors, GoldED comes with several sets of keys for each of the
keyboard commands - direct non-shifted keys, Alt/Ctrl-keys and
function keys. Many of these key assignments will be familiar for
users of Msged, Msged/Q, ME2 and FM.
The following is a list of all keyboard commands, sorted by type and
alphabetically, using the format
<command> <short description>
This list is also available in the context-sensitive help system on
the <F1> key.
It is possible to almost completely redefine the keyboard - this in
done in the GOLDKEYS.CFG file, which also handles macro definition
(see later).
Arealist commands:
AREAabort Abort the arealist.
AREAaskexit Exit GoldED, prompt for final decision.
AREAboardnos Toggle sequential areas vs. board numbers.
AREAdosshell Shell to DOS.
AREAheat Heat highwatermarks.
AREAgotofirst Move selection bar to first area.
AREAgotolast Move selection bar to last area.
AREAgotonext Move selection bar to next area.
AREAgotoprev Move selection bar to previous area.
AREAjump Move selection bar to next marked area.
AREAjumpnextmatch Move selection bar to next matching area.
AREAquitnow Exit immediately, no questions asked.
AREAscan Scan areas - all or marked.
AREAselect Enter the reader for the selected area.
AREAtoggle Toggle mark on the selected area.
AREAzap Zap highwatermarks.
Internal editor commands:
EDITabort Abort editing this message - ask first.
EDITanchor Set a block "anchor" on the current line.
EDITaskexit Exit from GoldED - ask first.
EDITcleardeletebuf Clears the undelete buffer.
EDITclearpastebuf Clears the cut'n'paste buffer.
EDITcut Cut the block to the cut'n'paste buffer.
EDITdelchar Delete the char at the cursor position.
EDITdeleteeol Delete from cursor position to end of line.
EDITdelleft Delete the char to the left of the cursor.
EDITdelline Delete the current line. (Copied to the
EDITdelltword Delete the word to the left of the cursor.
EDITdelrtword Delete the word to the right of the cursor.
EDITdosshell Shell to DOS.
EDITdupline Duplicates the current line.
EDITexitmsg Drop this message - NO ASKING! DANGEROUS!
EDITexporttext Exports the current block to a file.
EDITgobegline Move cursor to beginning of line.
EDITgobotline Move cursor to the bottom line in the display.
EDITgobotmsg Move cursor to the last line in the message.
EDITgodown Move cursor down to next line.
EDITgoeol Move cursor to the end of the line.
EDITgoleft Move cursor one position left.
EDITgopgdn Move cursor one page of lines down.
EDITgopgup Move cursor one page of lines up.
EDITgoright Move cursor one position right.
EDITgotopline Move cursor to the top line in the display.
EDITgotopmsg Move cursor to the first line in the message.
EDITgoup Move cursor up to the previous line.
EDITgowordleft Move cursor to the previous word.
EDITgowordright Move cursor to the next word.
EDITheader Edit the message header, attributes etc.
EDITimportquotebuf Imports the current quote buffer.
EDITimporttext Import text file into this message.
EDITloadfile Load the message file saved with EDITsavefile.
EDITlookupcursor Lookup name/node at cursor position.
EDITlookupdest Lookup TO: node.
EDITlookuporig Lookup FROM: node.
EDITnewline Terminate paragraph and/or add a new line.
EDITpaste Paste a previously cut block at the cursor.
EDITquitnow Quit GoldED immediately - no asking.
EDITsavefile Saves the current message as a file.
EDITsavemsg Save this message.
EDITspellcheck Calls an external spell checker for the msg.
EDITtab Add spaces to the next tab-stop.
EDITtogglecase Toggle the case of the cursor character.
EDITtoggleinsert Toggle insert mode.
EDITtolower Change the cursor character to lowercase.
EDITtoupper Change the cursor character to uppercase.
EDITundelete Undelete previously deleted lines.
File selection commands:
FILEabort Abort file selection.
FILEaskexit Exit GoldED - ask first.
FILEdosshell Shell to DOS.
FILEgotofirst Go to first file.
FILEgotolast Go to last file.
FILEgotonext Go to next file.
FILEgotoprev Go to previous file.
FILEmark Mark file.
FILEmarkall Mark all files.
FILEquitnow Quit GoldED immediately.
FILEselect Select the marked file(s).
FILEtogglemark Toggle file mark.
FILEunmark Unmark file.
FILEunmarkall Unmark all files.
Message lister commands:
LISTabort Abort message lister.
LISTaskexit Exit GoldED - ask first.
LISTdosshell Shell to DOS.
LISTgotobookmark Go to BookMark message.
LISTgotofirst Go to first message.
LISTgotolast Go to last message.
LISTgotonext Go to next message.
LISTgotoprev Go to previous message.
LISTmarkingoptions Marking menu.
LISTquitnow Quit GoldED immediately.
LISTselect Go to reader at the selected message.
LISTtogglebookmark Toggle BookMark on the selected message.
LISTtogglemark Toggle Mark on the selected message.
Nodelist browser commands:
NODEabort Abort nodelist browsing.
NODEaskexit Exit GoldED - ask first.
NODEdosshell Shell to DOS.
NODEgotofirst Go to first node.
NODEgotolast Go to last node.
NODEgotonext Go to next node.
NODEgotoprev Go to previous node.
NODEquitnow Quit GoldED immediately.
NODEselect Select node.
Message reader commands:
READaskexit Exit GoldED, prompt for final decision.
READchangeaka Change default AKA address for current area.
READchangeattrs Change the attributes of the current message.
READchangemsg Change current message.
READchangeorigin Change default origin for the current area.
READchangetemplate Change default template.
READchangeusername Change default username.
READcommentmsg Comment-Reply to message. (Reply to TO name).
READcopymoveforward Enter the Copy/Move/Forward function menu.
READdecreasemargin Decrease message margin. For test purposes.
READdeletemsg Delete current/marked message(s). Ask first.
READdosshell Shell to DOS.
READfidorenumber Renumber Fido/Opus *.MSG files.
READfilerequest Generate a filerequest from the current msg.
READfindall Find string(s) in message header and text.
READfindheader Find string(s) in message header.
READgotobookmark Go to the "BookMark" message.
READgotodownlink Go to the previous message in the replylink.
READgotofirstmsg Go to the first message in the area.
READgotolastmsg Go to the last message in the area.
READgotomsgno Go to a specific message number.
READgotonextarea Go directly to the next area.
READgotonextmsg Go to the next message.
READgotoprevarea Go directly to the previous area.
READgotoprevmsg Go to the previous message.
READgotouplink Go to the next message in the replylink.
READincreasemargin Increase message margin. For test purposes.
READlookupdest Lookup TO: node.
READlookuporig Lookup FROM: node.
READmakeuserlist Generate FIDOUSER.LST of users in the area.
READmarkingoptions Enter the marking menu.
READmessagelist Enter the message lister.
READmovecommentmsg Comment-Reply in another area.
READmovequotemsg Quote-Reply in another area.
READmsgcontinue Page down or go to next message.
READmsgend Display last part of current message.
READmsghome Display first part of current message.
READmsglinedown Scroll message display.
READmsglineup Scroll message display.
READmsgpgdn Page message display.
READmsgpgup Page message display.
READnewarea Enter the area selection screen.
READnewmsg Start a new message.
READquitnow Exit GoldED immediately, no questions asked.
READquotebuf Append quote of the msg to the quotebuffer.
READquotemsg Quote-Reply to message. (Reply to FROM name).
READreplymsg Reply to the current message, without quoting.
READtogglebookmark Toggle a "BookMark" on the current message.
READtogglehexdump Toggle hexdump mode. For debugging purposes.
READtogglehiddklud Toggle display of Hidden and Kludge lines.
READtogglehidden Toggle display of Hidden lines.
READtogglekludge Toggle display of Kludge lines.
READtogglemark Toggle a message mark on the current message.
READtogglemarkread Toggle "Read Marked" mode.
READtogglepagebar Toggle the "PageBar" feature.
READtogglerot13 Toggle ROT13 encryption for the current msg.
READtogglerealmsgno Toggle between seq. or real message numbers.
READtoggletwits Toggle Twit display - Show/Blank/Skip/Ignore.
READtouchnetscan Touches the SEMAPHORE NETSCAN file.
READwritemsg Write message(s) to file or printer.
See the Key Reference below for a list of the key symbols you can use
in keyboard redefinition.
______________________________________________________________________
Macros and Keystacking
______________________________________________________________________
GoldED has a simple keyboard macro facility, which you can use to
automate certain common operations. In addition, a "keystacking"
facility allows you to create simple automatic macros on the fly.
The macro definition syntax is modelled after the syntax used in the
QEdit text editor:
<assignment-key> Macro <commands or keys>
Macros are defined in the GOLDKEYS.CFG file, where you can also find
several examples.
By using the word "Auto" as <assignment-key>, you can even define a
special macro which will be automatically executed when you start
GoldED.
Keystacking is a special form of auto-macros. You simply specify a
bunch of keys to be "stacked" in the (special internal) keyboard
buffer for sequential execution.
You can either specify a default set of keystacking in the .CFG
configuration file, or override any default keystacking by typing the
keystack definitions at the GoldED commandline or the GEDCMD
environment variable.
See the Key Reference chapter for a list of the key symbols you can
use in macros and keystacking.
______________________________________________________________________
Key Reference
______________________________________________________________________
Below is the list of key symbols recognized by GoldED for
keyboard/macro definition and keystacking.
Unshifted function keys
F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12
Shift-function keys
#F1 #F2 #F3 #F4 #F5 #F6 #F7 #F8 #F9 #F10 #F11 #F12
Alt-function keys
@F1 @F2 @F3 @F4 @F5 @F6 @F7 @F8 @F9 @F10 @F11 @F12
Ctrl-function keys
^F1 ^F2 ^F3 ^F4 ^F5 ^F6 ^F7 ^F8 ^F9 ^F10 ^F11 ^F12
Alt-Numbers
@0 @1 @2 @3 @4 @5 @6 @7 @8 @9
Alt-Letters
@A @B @C @D @E @F @G @H @I @J @K @L @M
@N @O @P @Q @R @S @T @U @V @W @X @Y @Z
Ctrl-Letters
^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M
^N ^O ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z
Insert/Delete
Ins ^Ins @Ins
Del ^Del @Del
Home/End
Home ^Home @Home
End ^End @End
Page up/down
PgUp ^PgUp @PgUp
PgDn ^PgDn @PgDn
Cursor left/right
Left ^Left @Left
Right ^Right @Right
Cursor up/down
Up ^Up @Up
Down ^Down @Down
Misc other keys
Esc ^Grey* Key5 Space Tab #Tab @Tab BackSpace ^BackSpace
@BackSpace Enter ^Enter @Enter
Note that some of the Alt-keys, especially the cursor-related keys and
the F11/F12 keys, are "extended" keys normally only available on
systems with an extended keyboard bios. However, GoldED uses a few
tricks to make some the extended keys available on non-extended
systems.
______________________________________________________________________
Language Definition
______________________________________________________________________
GoldED allows you to almost completely redefine the language dependent
text in the program.
The language dependent text in GoldED is defined in the plain ASCII
text GOLDLANG.CFG file.
See the example language file for the actual method and format of
language redefinition.
If you are planning to translate the text in GoldED, you should also
look into the definition of the help screens.
If you think you have made a good set of translated files, you should
contact the nearest registration or support site for official
distribution of your files with future versions and/or with disk
registrations.
You do not need permission from the author before announcing or
distributing your own modified language files.
*** NOTE ***
In the continuing development of GoldED, it is impossible to
completely maintain backward compatibility of the language format or
the text defined there. New features may add and/or obsolete some
definitions, or may change the format of others.
The existing language file may contain definitions which are already
obsolete, but which I haven't had time to search for and remove, as
well as there may be some texts in GoldED which are not yet definable.
All this will of course be corrected in future versions. If you find
inconsistencies, please report them, because I may have overlooked
them.
______________________________________________________________________
The Message Database Formats
______________________________________________________________________
GoldED supports many different message database formats. The following
is a list of them all, with notes about their characteristics and what
special quirks to look out for with each of them.
Opus/FTSC (*.MSG)
These are two variants of the same type of msgbase. It works by
using one physical file per message (1.MSG, 2.MSG etc.),
collecting them in a directory for each area. Depending on the
clustersize on the harddisk, this can be a very wasteful and slow
way to store messages. With a clustersize of about 512 bytes, the
waste may be acceptable, but the access speed can be dramatically
slow if there are many *.MSG files, due to the DOS file system.
Caches and BUFFERS adjustments can improve it, but there are
limits.
In echomail areas, this format has a special quirk: The first
message (1.MSG) is normally used to store the so-called
"highwatermark". The highwatermark tells the echomail processor
where it should start scanning for new messages entered by users.
By deleting (Zapping) the highwatermark, you can make the echomail
processor re-scan the whole area again. This may cause messages to
be sent out as "dupes", so this should be used sparingly and
carefully, if at all! The highwatermark can also be "Heated" -
which means that it is set to the last msg in the area. This
prevents the echomail processor from finding newly entered
unscanned msgs. Use with care.
The variants: The "Opus" format originated in the Opus BBS system.
It put some Fido undocumented(?) fields to use as date/time
stamps. The "FTSC" (defined in FTS-0001, revision 12 and later)
format uses the undocumented fields to set the zone/point
information for the msg. To the authors knowledge, the Opus
variant is the dominant, and the FTSC variant is doomed to
oblivion. If in doubt, use the Opus format.
Hudson
This msgbase format was invented by Adam Hudson, and was first
used in his QuickBBS package. Later several other BBS'es were
cloned from QuickBBS (like RemoteAccess and SuperBBS).
The basic format is built around 7 main files:
MSGTXT.BBS This contains the message text of all msgs in all
areas.
MSGHDR.BBS The headers for all the msgs in MSGTXT.BBS.
MSGIDX.BBS Index to MSGHDR.BBS.
MSGINFO.BBS Tells how many msgs there are in each area.
MSGTOIDX.BBS Index that contains all the TO names.
LASTREAD.BBS Lastreads for all areas for each user in USERS.BBS.
USERS.BBS Contains a record for each user. Also the index to
LASTREAD.BBS.
The format limits the total size of MSGTXT.BBS to a maximum of
16MB, which translates to about 16000 msgs of "average" length.
GoldED automatically warns you if the limit is close to being
reached, and advises you to pack the msgbase.
The first incarnations of QuickBBS did not support "sharing" of
the msgbase. This became more and more important in later years as
multitaskers and networks got cheaper. RemoteAccess BBS was the
first to implement a useful method, and later a better method was
evolved (known as "RA 1.01 or RA 1.1x"), which is now the standard
for all modern software that supports msgbase sharing. GoldED
fully supports the new standard of course.
The main virtue of this format is that it is very fast to access
the msgbase.
The main disadvantage is that it can be very sensitive to disk
problems, and it is a common horror story that people loose their
entire msgbase because the disk developed bad clusters or some
program went berserk and messed up the msgbase files.
Goldbase
This is an enhanced version of the Hudson format, introduced in
QuickBBS 2.80 by the QuickBBS group.
The Goldbase format removes the 16MB size limit and allows up to
500 message areas instead of the 200 in Hudson. The filenames are
the same, except that the extension is .DAT instead of .BBS.
Squish
The Squish format is relatively new. It was invented by Maximus
BBS author Scott Dudley in 1991, and was first used in Maximus
CBCS v2.00. Soon after, GoldED was among the first message editors
to support this new format.
Squish uses three files per area: A header/message text file
(*.SQD), an index file (*.SQI) and a lastread file (*.SQL). The
SquishMail echomail processor uses a fourth file (*.SQB) to hold a
dup-database.
The use of a database for each area - instead of one file per msg,
or all msgs in one big database - makes this format fast, very
safe and resistant to disk problems. Even if something messed up a
Squish area, it can almost always be fixed and recovered, using
the SQFIX or SQREIDX utilities that come with the Squish echomail
processor.
A special feature of Squish areas is that they can be
self-maintaining. You can setup a Squish area so that it may only
contain a maximum of so-and-so many msgs, and then it will
automatically re-use the space used by old msgs when the limit is
reached, and so it will practically stop growing. It will still
need packing, but not nearly as often as a Hudson msgbase has to.
Ezycom
<to be described>
JAM
<to be described>
PCBoard
<to be described>
______________________________________________________________________
Entering Messages
______________________________________________________________________
The process of entering a message deserves some description, because
there a number of steps that may be a bit hard to figure out directly.
You start a message by using one the following commands:
READnewmsg Start a blank new message.
READquotemsg Quote-reply the current msg (FROM person).
READcommentmsg Quote-reply the current msg (TO person).
READmovequotemsg Quote-reply in another area.
READreplymsg Reply to current msg, but don't quote.
The first thing that happens is that the header display comes to life,
and allows you to change the names and addresses of destination and
origination. In netmail areas, the userlist lookup feature is in
effect for the destination name field. You move around in the header
with the arrowkeys. Pressing <Tab> or <Enter> moves to the next field.
Pressing <Enter> in the subject field or <Ctrl-Enter> anywhere, ends
the header editing. Pressing <Esc> drops the message. While editing
the header, you can use the Alt-keys to toggle message attributes.
After the header editing is done, a menu appears, allowing you to
change the message attributes, origin, template, start the internal or
external editor or quit it.
When you select to start the editor, the template is processed and
prepared for use.
Safely back from the editor, you are presented with a menu where you
can select to save the message, drop the message, continue editing,
view the message, change origin or ROT13 crypt it (the latter only if
you are a registered user).
______________________________________________________________________
The "Hardline" Feature
______________________________________________________________________
This chapter relates only to the use of an *external* editor.
Like all message editors that allows the use of external text editors
for writing messages, GoldED must deal with the problem of
free-flowing text paragraphs versus hard-cr-terminated lines.
Most text editors terminate *all* lines with a carriage return (CR,
13d, 0Dh). Unless you use a fairly short right margin in the text
editor, those lines can be very annoying to quote if the quotemargin
is shorter. This usually results in "ragged" quotes, with a long
quoteline alternating with a short leftover. This looks bad, and
requires a lot of work to edit to a respectable shape.
To solve this problem, GoldED treats the file from the text just as if
text blocks doesn't have any hard-cr's in them - it "reflows" the
text. Of course, this immediately creates another problem: If you
include a cut from a log file, source code, table or other stuff that
*requires* the text block to be aligned with itself. Those blocks
would become scrambled and unreadable.
GoldED recognizes a special control string, that tells the reflowing
code to put hard-cr's on single lines or groups of lines. You define
the string with the keyword "Hardline" in the configuration file. Here
is an example of the use of the hardline string (in the example "<<"):
<<
==== Log Cut ====
+ 22.24.31 Event 0-@
- 22.24.42 Preparing outbound mail
= 22.58.47 RING
= 22.58.55 CONNECT 2400
+ 22.59.02 Incoming call at 2400 baud
==== Log Cut ====
<<
In this example, the hardline string on the lines before and after the
cutting tells the reflower that all those lines must the hard-cr
terminated. The hardline string must be the only characters on the
line, and it must be placed on the *first* position. The reflow code
looks for <string><cr>. The hardline string works as a "toggle".
The hardline string also has another use: If you put the string as the
last characters on a line, that line will also be hard-cr terminated.
Example:
Greetings...<<
Odinn Sorensen<<
The last << in this example was not really necessary, because a blank
line always ends the preceding line or paragraph with a hard-cr. In
any case, the hardline string is stripped off before the message is
saved.
Some lines are by definition always hard-cr terminated, and does not
need hardline strings. Those lines are quoted lines and control lines
such as kludges, tearlines and originlines. In addition, three
identical characters at the beginning of a line also terminates the
preceding paragraph.
______________________________________________________________________
Quote Reflow
______________________________________________________________________
When you quote a message that already contains quoted lines, those
lines may be too long for your quotemargin. Most message editors would
then just cut a bit off the end and put it on a line below. GoldED
does it differently - it determines the quotestring of the line, and
then "reflows" all the following lines with the same quotestring and
puts the quotestring back on the reflowed lines. This usually works
great and looks good. It can also fail miserably in some
circumstances.
The reflowing is in effect in both the message displaying and in
quoting. If you want to observe the effects, try executing the
READdecreasemargin or READincreasemargin commands (they don't have any
default key assignments though).
______________________________________________________________________
Carbon Copy and Crossposting
______________________________________________________________________
Carbon copy (CC) is a way to send the same message to a number of
people without the trouble of manually entering and copying a message
for each of them. The CC works only in netmail or local areas. You can
send any message, including fileattaches (in netmail) with the CC
function.
Carbon copies are created by putting the string "CC:" followed by one
or more names or addresses, separated by commas, on one or more lines
at the beginning of the message. The names and addresses must follow
the same rules as when using the lookup function in the netmail
header.
Example:
CC: 16, Joergensen, #236/512
If you put a "#" in front of a name or address, that node will be left
out of the list, but will still receive a carbon copy.
You can also use address macros (see the NAMESFILE keyword) instead of
names or addresses.
If you often send carbon copies to the same people, it can get a bit
tedious to type (and remember) every time. Therefore you can also
specify a file with the names and addresses:
CC: @TESTERS.LST
Files names and addresses can be mixed on the same line. The lines in
the file must be the same format as above. No nesting is allowed: You
can't specify files within files.
When you save the CC message, GoldED will scan the message text to
find and process the CC: lines. When this is done, a menu will pop up
and allow you change the format of the CC: lines, the attributes of
the CC messages or drop the copies.
When processing the CC list, GoldED will check each node in the
nodelist and pop up the nodelist browser in case of more than one
match or if the node was not found.
Crosspost is similar to Carbon Copy, except that instead of sending
copies to a list of persons, it posts copies of a message in several
different conferences. Typical usage is announcement of files, vital
BBS information and other general interest info.
To crosspost a message is simple - just add lines in this format:
XC: <echoid> [echoid] [..]
The "XC:" must be the first three characters on the line. The <echoid>
must be valid echoid's defined in GoldED. Example:
XC: GOLDED, NEWFILES_R23.PRO, ENET.SOFT
This would produce the following output in the message:
* Crossposted in GOLDED
* Crossposted in NEWFILES_R23.PRO
* Crossposted in ENET.SOFT
And post it in the conferences.
Please moderate your use of this feature - it adds duplicate
information to the mail flow, and excessive use may be frowned upon by
cost-sensitive individuals.
______________________________________________________________________
Encrypting Messages
______________________________________________________________________
GoldED allows you to en/decrypt messages encoded with the ROT13
encryption method. ROT13 is very simple: It just swaps the letters
"A-M", "a-m" with "N-Z", "n-z" and vice-versa.
ROT13 is mostly used in UUCP (or whatever they are called :-)
networks, where it is used as a "spoiler warning", so that game
solutions, joke punchlines and other stuff is not read by accident. In
those networks, all message readers have ROT13 de/crypting
capabilities.
In FidoNet, not all message readers have ROT13 capability, and the
current policy (Policy 4) states:
2.1.4 Encryption and Review of Mail
FidoNet is an amateur system. Our technology is such that the
privacy of messages cannot be guaranteed. As a sysop, you have the
right to review traffic flowing through your system, if for no
other reason than to ensure that the system is not being used for
illegal or commercial purposes. Encryption obviously makes this
review impossible. Therefore, encrypted and/or commercial traffic
that is routed without the express permission of all the links in
the delivery system constitutes annoying behavior.
If you have registered GoldED, you will be able to encrypt your
messages with ROT13, but you should not use the crypting facility of
GoldED, unless your network allows it, and *never* in international
echoes.
______________________________________________________________________
Nodelist Browse and Lookups
______________________________________________________________________
When you write a netmail message, you must know the name and net
address of the recipient. Unless you have a remarkable memory, this
information can be a bit hard to remember. Therefore GoldED uses a
special nodelist/userlist index to enable you to quickly lookup any
node.
The index is created by the GoldNODE nodelist/userlist compiler.
GoldNODE supports the standard "St.Louis" nodelists, the FrontDoor
Boss/Point pvt/nodelist extensions (also known as Version7 extensions)
and the simpler FIDOUSER.LST userlist.
When you enter a name or address in the header (the TO: field) and
press <Enter>, GoldED looks in the nodelist index to find the missing
data. You can enter the address in the name field. Names to be
searched for must be entered last name first (because of the way the
index is structured). If you enter a partial name or address, GoldED
will find the closest match. Addresses can be entered in short form,
based on the current AKA, like .3 for the address of your third Point,
or 33 for node 33 in your net.
Before the nodelist is searched, the list of address macros are first
scanned, and if a match is found there, the information there is used
instead.
When GoldED has found a match, it looks a bit further to see if there
are more matches. If not, the matching data is inserted in the header,
and you can continue editing. If more than one match was found, it
starts the nodelist browser. Here you can browse around and find the
correct destination node. When found, you select it with <Enter>. The
full name and address of the node you selected is then placed in the
appropriate fields in the header. Pressing <Esc> in the browser quits
it without inserting any node information.
The list of nodes in the browser is sorted differently, according to
what you entered. If you entered a name, the list is sorted
alphabetically by last name. If you entered an address, the list is
sorted ascending by address.
The nodelist browser can also be accessed in other ways. The keys F10
and Shift-F10 brings up the browser at the FROM and TO names (nodes)
respectively, to let you inspect their nodelist data. It's quite
handy, you will wonder how you could do without it - I did :-)
The nodelist lookup feature can also be used when in the internal
editor, but an even more useful key is available there. By pressing
Alt-L, the browser will pop up for the name or address at the editor
cursor position!
______________________________________________________________________
User Database Lookup
______________________________________________________________________
GoldEd has a special user database lookup feature for BBS sysops.
In Hudson, Ezycom, Squish (and *.MSG, if you are using Maximus) type
areas, GoldED can perform an additional type of name lookup, using
wildcards.
This form of lookup is triggered by using DOS/4DOS-style wildcard
characters in the name you want to lookup. Examples:
To: Joe* Finds any name beginning with "Joe".
To: *Blow Finds any name ending with "Blow".
To: Od?n* Finds "Odinn", "Oden" etc.
Depending on the size of your user database and the speed of your
computer, the lookup may take a little while.
As currently implemented, this user database lookup is only good for
simple one-shot lookups - you can't bring up a browser to pick the
user, or see his/hers other user data.
______________________________________________________________________
Marking Messages
______________________________________________________________________
GoldED has a message marking system, which allows flexible
manipulation with selected messages.
You can either mark messages manually one by one using the
READtogglemark command <Space>, or use the READmarkingoptions menu
<Alt-S>. With the marking menu, you can for example mark all messages
in a particular thread (replychain), or all messages that match a
certain string or a number of other criteria.
When you have marked the messages, you can then Copy, Move, Delete or
Write them. Or you can switch to reading only the marked messages.
The marks stay in position until removed (unmarked) or you exit
GoldED. Marks are kept even if you leave the current area and do
business in another for a while.
Another, more volatile, form of mark is the "bookmark". Bookmarks can
be used for returning to a certain position after a stroll out a long
reply chain and stuff like that. There is only one bookmark, and it is
reset when you leave the area. Using the Find function leaves a
bookmark at the current message.
______________________________________________________________________
The File Request Feature
______________________________________________________________________
Often when you see a msg where new files are announced, you wish you
could simply press a key and select files to request. Well, with
GoldED you can!
The file request function (default key Ctrl-F) will scan the current
message and present you with a list of the requestable files it found.
If the message was generated with one of the "standard" file
announcement programs (like RFD, Ticket etc), GoldED will even show
the file descriptions.
You select the files by toggling marks with the Space key. A '+' will
show in front of the selected files. The selections can be discarded
by pressing Esc. When done with the selections, press Enter to
continue.
Now the destination area must be selected from the list. You have to
pick a netmail area of the *.MSG type, since the Hudson and Squish
netmail areas are currently not supported by most mailers today.
After selecting the area, check that the header data (TO name etc) is
correct. You can now go on to perhaps write a thank you note in the
accompanying msg, or you can save (empty) your msg immediately (if you
have the EDITMENU keyword set to Yes).
At the moment you start editing the header, the filenames and
descriptions are written to a FILES.BBS in the INBOUNDPATH. This can
be very helpful if you are getting files for your own BBS and are
tired of inventing or finding descriptions for all those files.. The
fact that the FILES.BBS is written to disk before you even save you
msg, can be used to get "free" descriptions later from the response
msgs some mailers send back when you do a file request.
There are currently a couple of limitations in the file request
function:
* You can only request as many files as can fit in the subject line
of one msg.
* GoldED recognizes several different types of file announcement
formats, but some may not be fully supported. This means that
legitimate descriptions may not be found by GoldED, or that some
files are not recognized as such.
* If a msg does not conform to a known announcement format, it is
instead (actually it is _also_) scanned for a number of standard
archive extensions. These extensions are currently not
configurable. The supported extensions are: .ARC .ARJ .COM .EXE
.LHA .LZH .PAK .RUN .RAR .SDA .SDN .ZIP .ZOO. Only one such file
per line can be found by GoldED, and only if it is "straight" - no
spaces between name and extension, and no "funny" characters in
the filename. The description is simply the rest of the line.
______________________________________________________________________
33. KLUDGE LINES
______________________________________________________________________
Kludge lines are special control lines, that begin with a ^a (ASCII 1)
as the first character of the line, followed by a unique identifying
name and the relevant control information.
GoldED is aware of a lot of these kludges, and supports a number of
them, if you want to have them inserted in your messages.
Some kludges are useless junk and more or less commercials for this
and that software, but a few are useful for miscellaneous purposes. In
the following, I will list the known and supported kludges, and a
short description of what they are used for.
ACUPDATE:
This kludge is a feature of Squish 1.10: Message Broadcast
Modify/Delete. Read the docs for Squish 1.10 for details.
AREA:<echoname>
This is not really a kludge, and it doesn't begin with a ^a, but I
included it on the kludge list because it sometimes turned up in
echomail areas where it should have been stripped off by the mail
tosser.
CC: <name> <address>
When GoldED produces carbon copies, it adds to each message a full
list of the persons who get a copy. One version of this list is
hidden behind the CC: kludge.
CHARSET:<charset identifier>
Proposed in FSC-0050 and FSC-0054, this kludge is an attempt to
find a solution to the problem of the high-bit characters (like
the IBM PC vs Amiga vs Mac etc. national chars) in messages.
GoldED can recognize, use and generate this kludge.
CHRC:<font change id>
Proposed in FSC-0054, this is a kludge for changing fonts,
underlining and other stuff.
CHRS:<charset identifier>
Alternative FSC-0054 version of the CHARSET kludge.
DESTADDR:<destaddress>
This one is not proposed anywhere, but it looks like it gives the
address of the intended recipient. GoldED takes the address for
the dest field.
DOMAIN <destdomain> <destaddress> <origdomain> <origaddress>
Proposed in FSC-0038, this tries to solve the problem of mail
crossing domain boundaries. GoldED takes both addresses.
EID:<crc16> <stamp> [replycrc16] <replystamp>
Proposed in FSC-0031, this is used for dupe checking and reply
linking. The EID is today generally considered as garbage, but a
lot of older mail processors such as QMail still generate it.
EOT:
End Of Text. See SOT.
FLAGS <special attributes>
Proposed in FSC-0053, this is a special netmail kludge used by the
FrontDoor and D'Bridge mailers and the IMail mail processor. It
provides extra attributes not found among the standard attributes
in the normal message/packet headers. GoldED uses and generates
this kludge, if you set the attributes.
FMPT <from point>
Defined in FTS-0001, this tells the Point number of the
originator. Netmail only. GoldED can generate this line.
GATECHK:<???>
Some sort of gating kludge? Don't know what it's for.
GROUP:<echoname>
I think this one comes from stray Groupmail messages. Similar to
the AREA: kludge.
I51 (no parameters)
Proposed in FSC-0051, this indicates that the message text
conforms to the ISO 8859-1 (LATIN-1) character set, and may
contain certain escape codes. The ISO 8859-1 set is used in Amiga
and Windows 3.xx. GoldED can recognize, use and generate this
kludge.
INTL <destaddress> <origaddress>
Defined in FTS-0001, this one solves the problem of crossing Zone
boundaries. Netmail only. GoldED can generate this line.
MSGID: <origaddress> <serialno>
Defined in FTS-0009, this is a method for unique identification of
a message. It can be used for dupe checking and replylinking.
GoldED can generate this line.
MSGTO: <destaddress>
This one is not proposed anywhere, but it looks like it gives the
address of the intended recipient. GoldED takes the address for
the dest field.
Original: <Carbon copy, original name>
Generated by the FrontDoor FM editor when it produces carbon
copies.
PATH: <list of nodes>
Defined in FTS-0004, this is a valuable tool for finding dupe
links and other structural faults in the net structures.
Unfortunately the list of nodes is 2D (net/node), and this creates
problems when exporting echomail across zones.
PTH: <list of nodes>
Not yet a FSC (or is it?), this is a 5D-version of the PATH
kludge, which sticks to the top of the msg.
PID: <identifier> <version> [serialno]
Proposed in FSC-0046, this takes a stab at the tearline abuse, and
puts "safe" information about the first mail processing software
in the line. This could be message editors, mail scanners and
other stuff.
RFD: <id>
Received For Distribution. A kludge inserted by one of the file
announcement programs.
REPLY: <replyaddress> <replyserialno>
Defined in FTS-0009, this is the MSGID: counterpart. When replying
to a message with a MSGID:, the MSGID: of the original is renamed
to REPLY:.
RID:<stuff>
Unknown kludge which looks suspiciously like the EID.
SEEN-BY: <list of nodes>
Defined in FTS-0004, this is a tool for finding dupe links and
other structural faults in the net structures. Depending on the
mail tosser, the seen-by's may or may not have a preceding ^a
character. Unfortunately the list of nodes is 2D (net/node), and
this can create problems when exporting echomail across zones.
SN:<serialno>
Serial number inserted by the Dutchie message editor.
SOT:
Start Of Text. See EOT.
SPLIT:
Defined in FSC-47. A method for splitting large msgs so that some
mail processors don't choke on them.
TCL1:, TCL2: <long hex string>
Old obsolete swedish dupecheck/replylink kludge.
TID:
Tosser ID. Similar to the PID, but specifically for mail
processors.
TOPT <to point>
Defined in FTS-0001, this tells the Point number of the
destination. Netmail only. GoldED can generate this line.
TZ <offset from UTC>
Specifies the time to *add* to the header time to get the UTC
(Universal Time Coordinated) time. Generated by newer versions of
the TrackMail netmail processor.
TZUTC
See TZ.
VIA: <netmail tossing info>
Routed netmail messages usually gets a Via line for each node it
passes through. This can be used for tracing faults in the netmail
routing structure.
XID:<stuff>
Unknown kludge which looks suspiciously like the EID.
______________________________________________________________________
Using the Internet Features
______________________________________________________________________
This chapter discusses how to use the Internet compatibility features
in GoldED, implementation details, limitations etc.
These are the configuration keywords that are relevant for use with
Internet:
ADDRESSMACRO Short aliases for e-mail adresses.
INTERNETGATE Internet gate definition.
INTERNETLOOKUP Parsing of e-mail addresses in the nodelist.
INTERNETREPLY Reply method for long e-mail adresses.
QUOTECHARS Definition of extra quotechars in addition to '>'.
See the Configuration Keyword Reference chapter for details about
these keywords.
<not completed yet>
______________________________________________________________________
Using PGP as an External Utility
______________________________________________________________________
This chapter describes how to can install PGP as an external utility
in the GoldED setup. The examples assume that PGP 2.3 or higher is
installed in the directory C:\PGP.
Add the following to your GOLDED.CFG:
--- Cut ---
IF DOS
EXTERNUTIL 1 c:\pgp\pgp.exe +force -sa @file "@dname" "@oname" -u
"@oname" -o @file
EXTERNUTIL 2 c:\pgp\pgp.exe +force -ea @file "@dname" "@oname" -o
@file
EXTERNUTIL 3 c:\pgp\pgp.exe +force @file -o @file
EXTERNUTIL 4 c:\pgp\pgp.exe +force -ka @file
ELSEIF OS/2
EXTERNUTIL 1 c:\pgp\pgp2.exe +force -sa @file "@dname" "@oname" -u
"@oname" -o @file
EXTERNUTIL 2 c:\pgp\pgp2.exe +force -ea @file "@dname" "@oname" -o
@file
EXTERNUTIL 3 c:\pgp\pgp2.exe +force @file -o @file
EXTERNUTIL 4 c:\pgp\pgp.exe +force -ka @file
ENDIF
EDITSAVEMENU Yes
EDITSAVEUTIL 1 "S PGP Sign the msg"
EDITSAVEUTIL 2 "E PGP Encrypt the msg"
EDITSAVEUTIL 3 "D PGP Decrypt the msg"
EXTERNOPTIONS -Pause
--- Cut ---
NOTE: The configuration lines for utilities 1 and 2 were split in two
due to the document margin. They must of course be on one line in the
actual GOLDED.CFG.
Add the following to your GOLDKEYS.CFG:
--- Cut ---
F11 ExternUtil01 ; Sign
F12 ExternUtil02 ; Encrypt
^F11 ExternUtil03 ; Decrypt
^F12 ExternUtil04 ; Add a publickey to keyring
--- Cut ---
You need to have KEYBEXT Yes in GOLDED.CFG if you want to use the
F11/F12 keys. You can of course assign other keys, just make sure they
don't clash with already defined keys.
Both the signature and encryption PGP commandlines are set up for
multiple recipients, the TO: name and your own FROM: name. Otherwise
you would not be able to decrypt your own msgs, and that could get a
bit unpractical ;-)
HOW TO USE IT:
To sign or encrypt a msg, simply select the appropriate menu item in
the save menu. Another method is described below.
To decrypt an encrypted msg, Hit Ctrl-F11 while viewing the msg in the
reader. After decryption, you can write the msg to disk/printer, reply
to it, copy it, etc. The decrypted text will revert as soon as you
move away from the msg, or after you perform any operation on it. To
make a decrypted msg permanent (saved to disk in decrypted form), use
the Change Msg command after decryption and then save the msg
immediately, or use the copy function if you want to keep the original
untouched..
One thing to be aware of, is that the encrypted msg text does NOT
contain kludges if it was encrypted from the EDITSAVEMENU. If you make
such a text permanent, you would loose the kludges. Currently the only
way to keep kludges in the encrypted text is to encrypt it "manually"
after saving it, using F11, Change Msg, save immediately. If you do it
this way, you should be careful in a multitask/network environment,
where a mail scanner could scan out the unencrypted msg before you get
a chance to encrypt it... I plan to fix this problem in a future
release.
______________________________________________________________________
JAM Implementation Notes
______________________________________________________________________
This chapter describes details about the implementation of the JAM
messagebase format in GoldED. Should be read in conjunction with the
JAM specs for better understanding. A lot of technical terms will be
used, so if you are not the technical type, just skip over it.
General notes
The first release of the JAM messagebase specifications (JAM-001,
rev.1, dated 93-07-01) included an example implementation in the C
language of a "JAM API".
For the purpose of use in GoldED, the JAM API C implementation was
both too complete and not complete enough. Therefore I developed my
own specialized JAM msgbase handling code. My own code was of course
designed be compatible with the original JAM API as well as the
specifications, but some things are done slightly differently for
various reasons.
File I/O checks
Reads and writes to the msgbase files are generally NOT checked for
errors in GoldED. In contrast, the original JAM API checks everything
and stores error values in the API, for the user to use or ignore.
Full checking degrades performance a bit, adds more code to the EXE
file, and most importantly, GoldED just doesn't have a safe way to
recover from the detection of such errors anyway at this time.
Assuming that your system is working well, there are no harddisk
errors etc., this will normally not be a problem.
Message header revisions
The JAM message headers contain a field to indicate the revision
number of the header structure.
GoldED currently ignores this field and assumes that future revisions
will remain backward compatible. When creating new msgs, GoldED uses
the revision 1 header structure.
When new revisions of the JAM specs are released, GoldED will be
updated to handle these as quickly as possible.
Passwords
The JAM specs contain fields for passwords to access the msgbase
and/or indiviual messages.
GoldED currently doesn't support these passwords. When creating a new
JAM msgbase and/or new JAM msgs, GoldED sets the password to
FFFFFFFFh. If you change an existing msg which has a password, the
password is NOT preserved, but reset to FFFFFFFFh.
Lastreads
The JAM lastread file is designed such that is has to be searched for
a userid/usercrc, because one cannot assume that the records are in a
specific order.
The JAM API searches the userid field. However it seems more
reasonable to search for the usercrc, because that is a value the
program can calculate from the username without looking in other
files. I'm not sure why the JAM API chooses to look in the userid
field instead. GoldED searches for the usercrc, not the userid. In any
case, it seems that RemoteAccess 2.x sets both the userid and usercrc
to the same value.
The specs state that the user's lastread record must be searched for
both when retrieving it and storing an updated record. However, the
JAM API seems to implemented slightly differently, because when it
stores an updated record, it stores it at the same position as it was
read *without* first searching for it.
GoldED has been implemented to work in a similar manner. It searches
for the user's lastread record when the msgbase is opened, and it
assumes that it will remain in the same position as it was found,
until the msgbase is closed.
This is normally a quite reasonable assumption. The only circumstance
where the lastread records might be re-ordered is when a msgbase
maintentance utility cleans up or sorts, and such a utility is
normally designed to open the msgbase files in exclusive mode, which
it can't do when the files are already open. If it tries to re-order
without exclusive access, the utility is badly designed and
potentially dangerous in multitask/networking environments.
Size limits
The JAM specs allow msgbases and msgs of really huge sizes. The 16-bit
DOS version of GoldED cannot handle the full extremes of this. The
32-bit OS/2 and 32-bit protected mode DOS versions of GoldED can
handle any size, only restricted by memory, disk space or unknown
compiler or operating system limits.
The internal limits for the 16-bit versions of GoldED means that they
can only handle msgbases containing a maximum of 8191 msgs (including
deleted msgs), and msgs a maximum of about 64k long. In theory at
least. In practice the limits may be smaller due to lack of memory.
ASCII 7-bit escaping
GoldED currently doesn't support the escaping described in the JAM
specs. The specs state that the current revision of JAM does not
support it either, so I guess it's no great loss.
Date fields
GoldED currently doesn't display the DateReceived field, but it is
updated on disk when a message is received (read) by the recipient.
The DateProcessed field is set to the current date when a msg is
writtten or changed with GoldED.
All new dates are set to the system time and are not adjusted for
timezone.
Subfields
The concept of the JAM subfields is difficult to support easily in a
program like GoldED, which was designed to support the traditional
fixed header formats and kludges in the msg body. Therefore the
implementation in GoldED of the JAM subfields is not currently as
complete as one might wish.
However, it should be adequate for most purposes. I will of course do
what I can to improve the JAM subfield support in future releases. The
following is a list of the current limitations of the JAM subfield
support in GoldED:
* Subfields are converted internally to the equivalent kludges for
easy viewing, and to make it possible to copy JAM msgs to areas
with other msgbase formats. Some subfields do not have equivalent
known kludges defined. They are converted to kludges with names I
have invented for the purpose. All subfields can be viewed if you
hit the Alt-I key to display a hexdump of the message.
* The subfields with size limits (typically 100 chars) are not
specifically checked for size. Since all other msgbase systems
have much lower limits for the fields in question, this should not
be a problem.
* Only one OADDRESS/DADDRESS is supported. When reading a message,
only the _first_ OADDRESS/DADDRESS is used.
* None of the file attach or file request subfields are supported at
this time. File attaches or file requests are stored in the
subject field in a manner similar to other msgbase formats. This
might not be supported by a fully JAM compliant mail processor,
but IMHO a mail processor should use the subject field if it finds
the file attach/request attributes set, but can't find any
subfields for them.
* If you change a JAM message which is not from you, and save it,
all unsupported subfields will be missing in the saved message,
and some supported subfields may be changed in content (like the
PID subfield).
* Currently unsupported message attributes:
MSG_FPU "Force pickup"
MSG_NODISP "Msg may not be displayed to user" (always displayed)
Deleted msgs
The original JAM specs has a fairly major problem when it comes to the
specification for deleting msgs and in particular about _detecting_
deleted msgs. The original specs do not define a fast way to detect
deleted msgs from the index file alone.
This may not be so important for a BBS or a mail processor, but it is
absolutely vital for mail readers such as GoldED, which need a fast
way to find out how many active msgs there are, and where the lastread
is, and to calculate how many unread msgs there are. If GoldED had
scan the header file to check a single bit in each header the area
scanning would slow down dramatically, because the header file can
easily grow to many megabytes and thousands of msgs.
Fortunately there is a way out. The specs state that if the usercrc
and header offset values in the index are both -1 (FFFFFFFFh), then
"there is no corresponding header". Such a situation is IMHO highly
unlikely, so I have proposed to use this to signify a deleted msg
instead. This should be backward compatible with almost all JAM
compatible programs, with the possible exception of msg undelete
utilities.
With the header offset set to -1 (FFFFFFFFh), there is of course no
fast way to find the header of a deleted msg. A msg undelete utility
would have to scan through the entire header file to locate the
deleted header (or rather the last occurrence of it, because there can
easily exist more than one deleted header with the same message
number). This is IMHO a price worth paying for the performance gained
by using by changing the specs to specify a deleted msg instead of a
hypothetical non-existing header.
When I brought up this subject in the JAMDEV echo, the developers who
replied generally agreed that this was a good idea. At the time of
writing, I don't know for certain that it will be changed in the
specs, but I think so.
GoldED optionally (since version 2.50.B0822) follows my proposed
method when deleting msgs. The configuration keyword JAMHARDDELETE
specifies which method to use. If set to Yes, my method is used. The
default is No, but I recommend (and use myself) Yes.
Scanning files
The NETMAIL/ECHOMAIL.JAM files are written/updated when new messages
are written or changed in JAM netmail/echomail areas. The files are
written/updated in the JAMPATH. If you don't have a JAMPATH, it
defaults to the HUDSONPATH. If you don't use a Hudson msgbase and
haven't defined a HUDSONPATH, the HUDSONPATH defaults to the GOLDPATH.
At the time of writing, the NETMAIL/ECHOMAIL.JAM files are not a part
of the official JAM specs, but they are used in RA2 and most JAM
compatible mail processors to specify the msgs that need to be
exported from the JAM msgbase files.
______________________________________________________________________
PCBoard Implementation Notes
______________________________________________________________________
This chapter describes details about the implementation of the PCBoard
messagebase format in GoldED.
Netmail
GoldED supports FidoPCB-style netmail areas. According to the FidoPCB
manual, netmail in PCBoard format is supported by specifying the first
line of the msg to be the to- or from- address in parentheses and the
second line to be flags (HOLD,CRASH,IMM,INTL) in parentheses.
The first line can be either to- or from- address, but there is no
rule to determine when it is what. Here is how GoldED deals with it:
When you write a netmail, GoldED puts your own address in the
parentheses. When reading a netmail, GoldED looks at the from-name and
if it is the same as your first USERNAME, the address is taken to be
the to-address (written by you). Otherwise it is taken to be the
from-address (from someone other than you).
Note that this fails if a netmail is found which is written by
somebody on your BBS. Is there some way to reliably determine that a
msg is written locally instead of being imported?
Extended Headers
GoldED is aware of PCBoard v15.x extended headers in the message text.
The TO, TO2, FROM, FROM2 and SUBJECT extended headers are directly
supported and "swallowed" when reading a msg. Other extended headers
are currently treated like normal message text and is therefore not
hidden to the reader. In a later release, I plan to internally convert
the extended headers to kludges.
Long Names
Because of internal design limitations, GoldED only supports name
fields up to 35 characters in length. Through the extended headers,
there can be names up to 120 characters (TO+TO2 ext.hdrs). GoldED will
simply cut them to 35 characters. In a later release, long names will
be supported so they won't be cut off due to internal limits, but
display and entry of long names will probably not happen anytime soon.
Password
Passwords are not supported in msgs.
Attributes
Only the Pvt and Rcv message attributes are directly supported in
PCBoard messages. Through the FidoPCB netmail extensions the following
are also supported in netmail: Hld, Cra, Imm and Zon.
Double-Byte Characters (Foreign Systems)
GoldED reads the PCBOARD.DAT file to determine whether to use E3h or
0Dh (CR) as the line/paragraph termination character when reading and
writing message text.
Message Index
Only the new v15.x .IDX files are suppported. The old .NDX files are
not supported in any way.
______________________________________________________________________
What YOU get when you register!
______________________________________________________________________
* Reminders disappear.
The random pause at the startup goes away. The original screen
will appear when you exit GoldED instead of the shareware
reminder. Your name and key serial number is displayed in the
startup screen.
* The Plus!
A plus ('+') is added to the version number in the tearline and/or
your serial number is added in the PID kludge.
* Tearline opened for costumization.
Allows you to change the tearline to your hearts content. Change
your tearline to a bragline! :-)
* Cookie features enabled.
With cookie files you can add multi-line random cookies or
taglines in your msgs via the template keyword "@random".
* ROT13 feature enabled for msg writing.
You can use the ROT13 feature to encrypt your msgs.
* GROUP item limits removed.
You can use more than 10 of each item in a GROUP. Essential if for
example you want more than 10 random origins in a group or area.
* Keyword limits removed.
The limit of max 10 on a number of GOLDED.CFG keywords (such as
ORIGIN, USERNAME, AKA and several others) will be gone.
* LoadLanguage feature enabled.
You can use the LoadLanguage feature to dynamically load a
specific language setup depending on a group or area. This is
useful to put local language names of days and months in message
templates.
* Access to betas.
Beta versions only work with a key, so this provides free access
to beta releases and through that new features before general
availability!
* You help and encourage the author to continue development on this
user-supported program. Without support from users such as YOU,
GoldED would not exist today.
* You are allowed to use GoldED for more than 30 days.
______________________________________________________________________
End Of Manual
______________________________________________________________________