ac>>   * Perform net/node matching in NetAreas.

Oops.  Sorry, that should read "zone:net matching".

ac>>     E.g. I have three point addresses (3:633/267.1{at}fidonet, 
ac>> 3:635/727.4 &    3:632/103.9) all sharing the same NetArea.  
ac>> When I send netmail to    3:635/727.1, I want MsgEd to use my 
ac>> 3:635/727.4 address, and _not_    default to 3:633/267.1.

PE> That sounds messy.

It shouldn't be.  FleetStreet, GoldED and timEd do this.  I'm sure other
editors do as well.

PE> I believe you can change your name dynamically.

I haven't looked at groups yet.  That's something new for me to look at. :-)

PE> How did you expect it to guess the address to use?

This is copied verbatim from the timEd 1.01 documentation:

  8.2  AKA matching.

  This option is  interesting if you have more than 1 address. If you set
  the  'AKAmatching' keyword  in timEd.cfg  to 'Yes',  timEd will  try to
  find the most appropriate address to use when writing a message.

  Say,  for  example,  that  you   have  two  addresses:  2:281/527   and
  60:100/112.

  If you  write a messages  to 2:500/133, you  probably want to  use your
  2:281/527 address.
  If  you write  a message  to 60:100/1,  you probably  want to  use your
  60:100/112 address.

  In this case, timEd would try to find  the address (AKA) that 'matches'
  the destination address best.

  It first  looks for a  matching zone,  and if  more than  one match  is
  found, it'll try to  find an address where both 'zone' and 'net' match.
  If  there is still  more than one match  after that, it  will just take
  the first match.

  This  is always  active  (in  the netmail  area):  when writing  a  new
  message, a reply, or changing a message.

  If timEd  selects  an  address  different from  the  address  that  was
  currently  used  (so  if  anything  changed),  it  will  say  so  ("AKA
  matched") just below the addresses on the screen.

  If you want  to force it at a certain moment, press  F2 when on the TO:
  address field.

  TimEd  will  stop matching  the  AKA's, as  soon  as  you changed  your
  address manually. So if  you don't agree with timEd's AKA matching in a
  certain situation, just  manually change it (while editing  the header,
  you can  'cursor up' to the from: address field) to what you want it to
  be, and timEd will leave it at that.
  It will not match  AKA's anymore after you  did that. (Of course,  when
  you enter another new message after that, the game will start again :)

  AKA  matching  is  only  active when  you  enter  a  new message.  When
  changing a message  (or header), AKA  matching won't kick in.  You can,
  however, still force AKA matching by pressing F2.

ac>>   * Read ^aAREA: line created by the WIMM personal mail scanner.
ac>>     User hits Alt+N.  User gets the area list.  Area list 
ac>> automatically    points to PUBLIC_DOMAIN.

PE> That's a very good idea.  But should it automatically select
PE> PUBLIC_DOMAIN or should it just remain highlighted there, ready
PE> for you to hit enter?

I would prefer the latter for this is how GoldED and timEd work.

PE> I think automated would be great.  I'd even use it myself then.

:-)

PE> But will reading of the AREA tag and then automatically 
PE> choosing the area upset anyone?

WIMM is the only program that I know of that inserts ^aAREA: lines into
a personal mail area.  I imagine anyone who has a program that does such
a thing _wants_ this feature!

If for some odd reason there are complaints, make it optional.  This
would also ensure that if your code happens to break, we can disable the
option and continue using Msged. :-)  FWIW, this feature is forced in
timEd but is optional in GoldED.

PE> I wonder if Alt-Q and Alt-R should automatically reply in the 
PE> other area, but Alt-N should behave as it does now?

Having Alt+N read the AREA line would make the translation easier for
GoldED or timEd users who use WIMM (or similar).


ac>>   * User cannot edit origin line.

PE> MSGED always rewrites the origin line when it is saving to disk.
PE> You shouldn't be mucking around with control lines anyway, 
PE> anymore than you should be able to edit the MSGID.  A definite "NO"
PE> there I'm afraid.  You can set up a different origin line on an
PE> area by area basis though.

Nothing like a bit of contradiction every now and again, is there? :-)

I would prefer "MSGED always rewrites the origin line's network address
but leaves the user-definable text field intact".

PE> You can set up a different origin line on an area by area basis
PE> though.

Undocumented, BTW.  Lucky I can read C. :-)


ac>>   * Alt+H for Help doesn't work anymore.  Maybe I'm too 
ac>> braindead to    know how enable it. :-)

PE> It works for me.

I recompiled the DOS version with my own modifications and was able to
call up the help with Alt+H, but the OS/2 version of MSQ304 refuses to
budge.

From reading the source, there appears to be two functions - DoHelp(int)
and dohelp(void).  Perhaps it is a linking problem that ties in with
case-sensitivity?


ZeeYa...
Andrew.

---