Hello. I have been using mutt for a period of 6-7 months,
and I must say it's definitely the best UNIX fullscreen
mailer I have ever encountered. It's also regularly updated,
unlike it's elm and pine counterparts.
However, the point of my message is not to gawk in awe at
mutt. The point of my message is to discuss a very severe
problem (and if you disagree, you are wrong) with mutt and
how it goes about handling text/screen output.
I understand and am well aware of the fact that mutt can use
curses/ncurses or slang. I find slang to be much more suitable
for my needs. I also understand this may not be a problem with
mutt, and may in fact be a problem with slang (which is what I
am using).
The problem itself is apparent on all systems: the operating
system makes no difference in this case. But for the record, I
am using FreeBSD 3.2-RELEASE, gcc 2.7.2.1, and slang 1.3.6.
For example, the menu may contain the following note, where
pipes represent the actual start and end of the text (the
pipes are not printed):
| 167 + 06/07 Majordomo@gbnet (1.0K) Welcome to mutt-users|
However, mutt does *NOT* print it this way. Mutt prints (same
rules as above):
| 167 + 06/07 Majordomo@gbnet (1.0K) Welcome to mutt-users
| |
This happens inside of the builtin pager as well. It occurs
in any text screen size (80x25, etc.).
As you can see, there is a myriad of space at the end of this
line. I went researching this problem in verbose detail, and
found the variable references %| and %>. Neither of these solve
the problem, obviously. (Side note: What's the point of %|
anyways?)
Amusingly enough, the only time mutt does not do this is when
printing quoted text (e.g. "> Foo bar blat")!
Why am I even bothering to complain about this? Three reasons:
1. Some users of mutt dial up to their workplace or ISP, then
ssh or telnet over to a shell to read their mail. Have you
tried using 132x43 (or any other mode) via ssh on a 28.8? I
don't like sitting around waiting 3 full seconds for the
screen to redraw solely because a piece of software likes to
pad the width of the screen with spaces. Not all of us are on
high speed networks. A response may be "So use 80x25" -- this
does not solve the problem. The output is still wasteful and
very silly. I think all of us here like having large terminal
windows solely so we can read our Email in linear detail.
2. Programs ranging from Windows Telnet to VanDyke's SecureCRT
allow you to copy/paste text. These applications, as well as
others, copy based upon what they receive, not what is "visually
shown." Hence, copy/pasting a few lines from an Email results
in a myriad of spaces appended on the end of each line -- very
annoying for chat sessions or when quoting someone. Having to
go through and manually remove all these spaces, even in vi, is
a tedious process and should not have to be done at all.
3. It seems to me there's more processing involved in printing
out a string longer than it needs to be, none the less padding
it with spaces. Logically it should speed up mutt tremendously to
terminate the string appropriately, and limit the output width.
I continued my research, figuring clrtoeol() or similar functions
may be causing all of this madness, but I am obviously mistaken.
I do code in C, but I do not feel like spending 2 weeks going
through someone elses code when the problem can be solved via
someone who already knows the code itself.
What baffles me is the fact that mutt does **NOT** portrait this
behaviour when quoting text!
Is there a solution to this problem? If not, can this problem
be fixed? If so, how? I am more than willing to run a development
release of mutt assuming it rectifies this issue.
If this is a problem with slang then I will gladly contact John
Davis and complain.
Any (and all) help is appreciated. Thanks.
--
| Jeremy Chadwick [EMAIL PROTECTED] |
| Parodius Networking [EMAIL PROTECTED] |
| UNIX System Administrator http://www.parodius.com/ |
