Hola Rick!
Lunes 27 Abril 2020 11:02, Rick Smith escribi a All:
So in my point setup I am using husky and golded. In the areas part of husky I have figured out how to sort by group which is fine and working. My question is does that sort pass to golded? Since I have golded pointed to husky/areas? I know how to setup golded areasort but it doesnt seem to pick up the sort from husky areas? Am I thinking about this wrong?
Golded needs several parameters to know how you want it to order the areas.
I have this:
AREASCANSORT TGE
AREALISTSORT TGE
And this area separators:
areasep !Netmails " Netmail Areas " 0 NET
areasep !Personal " Area Personal ** " 0 LOCAL
areasep !A " Areas restringidas " A ECHO
areasep !B " Areas locales " B Echo
areasep !E " Areas de Fido - SysOps 341 " E ECHO
areasep !F " Areas de Fido - SysOps de la R34 " F ECHO
[...]
Note that A,B,E,F... are husky groups.
AREAFILE Fidoconfig ; HPT using env.var. FIDOCONFIG
Read the golded manual for AREASCANSORT and AREALISTSORT ;)
This makes me sort them by husky groups (alphabetical order) and put a separator with comment in the areas that interest me
*********** From Golded Manual *************************************** AREALISTSORT <sortspec> (FYTUE)
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.
P Sort by personal mail.
T Sort by type (in the order net, echo, local).
U Sort by unread messages (try it!).
X Sort by msgbase type.
Y Sorts all areas with "new" mail first.
Z Sort by msgbase path.
- 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 automatically
sorts itself so that all echoes with an echoid containing "GOLDED"
comes first :-)
The 'X' sort type sorts areas according to msgbase type, in the
following order:
Hudson
Goldbase
JAM
Squish
OPUS *.MSG
FTS-1 *.MSG
Ezycom
PCBoard
The 'X' and 'Z' sort types were implemented for internal use, to
optimize area scanning speed. When scanning areas, GoldED starts
by sorting the arealist using the sortspec defined with the
AREASCANSORT keyword.
AREASEP <echoid> <"desc"> <group> <type>
You can define area separation lines between groups or areatypes.
The syntax is nearly the same as the AREADEF keyword except for
the fields after <type>.
Examples:
These five are area separation lines that are designed to list
before each type of area. This works well when AREALISTSORT has
T (for type) as one of the primary sort orders.
AREASEP !NET "Netmail areas" 0 Net
AREASEP !EMAIL "E-mail areas" 0 EMail
AREASEP !ECHO "Echomail areas" 0 Echo
AREASEP !NEWS "Newsgroup areas" 0 News
AREASEP !LOCAL "Local areas" 0 Local
These can be used to separate areas with group letters (it will
also work with group numbers like #117). Areas should then be
sorted primarily on the group.
AREASEP !A "Group A" A Local
AREASEP !B "Group B" B Local
AREASEP !C "Group C" C Local
In these examples, I put a '!' in front of the echoid to make
sure it is sorted ahead of the areas. This may not be necessary
in all cases, depending on the sort order in effect. If you do
put '!' in front of the echoid, have fuzzy sorting as the
primary sort order, and type '!' in the fuzzy search, you'll get
the interesting effect that all area separation lines collect
themselves at the top :-)
The area separation lines are implemented like a special kind of
area, and are therefore sorted in the arealist just as if they
were actual areas. This is also the reason why you can place the
cursor bar on the separation lines. Originally I wanted to make
the cursor skip the separation lines, but I think I'll leave it as
it is, because it can be useful sometimes, especially when using
the fuzzy feature to quickly go to an area, for example, type "!C"
to quickly move down to the group C areas (using the group sorted
example).
When configuring area separation lines, be careful to consider the
AREALISTSORT, so that the lines are sorted into the positions you
want. If you don't sort areas, you must make sure that the AREASEP
definitions are placed correctly in your GOLDED.CFG or
GOLDAREA.CFG, that is, between/before AREADEF lines.
You will note that the separation lines are not fully connected
into the left and right edges. This is both by design and for
practical reasons (easier to implement), not a bug.
Currently the descriptions are hardcoded to the natural location
in the description column. ********************************************************************
Un saludo,
Angel Ripoll
aripoll(at)zruspas.org
--- GoldED+/LNX 1.1.4.7 + HPT 1.9 + Binkd 1.1 en Debian
* Origin: Also in Zruspa's BBS II - Synchronet - 2:341/200 (2:341/66)