| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.