Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    POINTS    |    Point usage discussion and systems suppo    |    3,070 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 2,706 of 3,070    |
|    Martin Foster to August Abolins    |
|    WinPoint development    |
|    24 Feb 22 09:14:00    |
      MSGID: 2:310/31.3@fidonet f9bb33a3       REPLY: 2:221/1.58@fidonet f9a55e6c       PID: OpenXP/5.0.51 (Win32) (i386)       CHRS: ASCII 1       TZUTC: 0000       Hello August!              *** Monday 21.02.22 at 14:29, August Abolins wrote to Martin Foster:              [snip]        MF>> Out of the 17 "CONS", there's now only 4 which are still        MF>> valid and I can think of at least one addition to the        MF>> "PROS" :-)               AA> Let me know which ones are which. I can start to update things        AA> when I remember how I created that page!              OK, here we go :-)              [CONS] The following can be safely removed:       -------------------------------------------              - internal editor: ^Y deletes UNDER the current line.              - limited to no extended-ascii support              - does not support incoming areafix lists that are in lowercase [*3]              - sometimes areafix is created for "0:8/15" address.              - received nodelists need manual intervention to \WinpointNL directory              - if you don't specify a domain, WinPoint adds "@" to the end of your AKA        [*4]              - when forwarding a post to another echo/area, the Extra/Options/        Templates for the defined header/footer do not get inserted into the new        message.              - when replying to a message (echo or netmail) templates (headers/footers)        do not get applied.              - reply window opens up full screen [*5]              - when message sort order is last "set" by Received date or Sent date and        newest to oldest, the program will always resort by oldest to newest the        next time the program is run.              - when message sort order is last "set" by Bytes and largest to smallest,        the program will always resort by smallest to largest the next time the        program is run.              Footnotes 3,4 and 5 can also be safely removed.              [CONS] I'm unsure about the following:       --------------------------------------              - no highlighting on a search match              - editor on reply removes |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca