TIP: Click on subject to list as thread! ANSI
echo: muffin
to: mark lewis
from: Roy J. Tellason
date: 2003-06-02 12:34:42
subject: Maximus at UNIX

mark lewis wrote in a message to Roy J. Tellason:

 BJ>> Arrrgggghhhhh.....  We're starting to exceed the limitations of the
 BJ>> built in maximus full screen editor for replying to messages....
 BJ>> At least dumping the message to a file and reading that file with
 BJ>> the maximus built in full screen editor still works....  So, the
 BJ>> quoting below will be slightly screwed up.

 RJT> Speaking of which,  it'd sure be nice if this port could do
 RJT> away with some of those hard-coded limits.  I've bumped into
 RJT> some of them in max,  sometimes in a separate editor,
 RJT> sometimes elsewhere.  Mostly it's when somebody decides to
 RJT> netmail/email me an encoded file.  

 RJT> What annoys me more than anything else is the limitations
 RJT> built into some software that isn't exactly related to size,
 RJT> but to line count!

 ml> and its even more annoying if one stops and really looks that the
 ml> specs for fidonet messages... namely the line that says that 
 ml> message bodies are unbounded ie: unlimited in size... the limits 
 ml> and such that are in place came from "lazy coders" who didn't want
 ml> to take the time to figure out how to work around handling stuff 
 ml> larger than their available buffer(s)... reminds me of that old
 ml> bill gates saying about 640K of memory...

Sure.  I guess that some of this stuff is an artifact of what tools were
available at the time,  but still...

I remember bumping into this over and over again,  when I tried various
software that arrived here for the files section.  So many arbitrary
limits,  put in there because they seemed reasonable to the program's
author,  and for no other particular reason.  I guess they couldn't imagine
that somebody else might want to use the software a little differently.

OOTC:  I just saw a message that got me to thinking of something I used to
use.  It had a subject line that started with "re:".  I had a
program at one time (might even still have it),  that would deal with this
issue with *.msg files,  where It'd strip all that stuff out. 
Unfortunately this doesn't seem to be workable with Squish bases.  I guess
a filter could be written,  or something,  or maybe this is more of an
issue with the tosser rather than the bbs,  but it'd sure be nice to have.

--- 
* Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)
SEEN-BY: 633/267 270
@PATH: 270/615 150/220 379/1 106/1 2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.