Adam M. Costello on Sat, Jan 16, 1999 at 03:45:58AM +0000:
> In the pager, next-line and previous-line appear to repaint the entire
> screen instead of scrolling it. Scrolling it would be a lot faster.
> The same might be true for the index.
This may be dependent on your curses implementation (I don't know about
slang). For ncurses-4.2, a number of development/experimental options
have to be explicitly compiled in for it to work optimally with mutt
(scrolling was one of these issues). If I gather correctly, linking to
slang instead solves some or all of these problems as well. But, I
don't use slang.
> The documentation says nothing about the dangers (or lack thereof) of
> running multiple instances of Mutt. How about running two Mutts on
> different machines accessing the same spool file via NFS?
Appropriate locking needs to be compiled in; usually configure will take
care of this. Mutt does seem to have code for multiple instances
manipulating the same mailbox, and re-reads to update after a mailcheck
(I use buffy-size compile time option; default is atime check), and will
interacts properly AFAICT.
> When Mutt is suspended and resumed, it sometimes ends up in a bad
> state. I think the terminal is no longer in non-canonical (raw) mode,
> because Mutt doesn't react to my keystrokes until I press return.
Again this may be the cursor library. I have also noticed, though, that
mutt -> urlview -> lynx, suspended, will invariably leave the result in
a strange state.
> It would be nice to have a function for the index screen that causes a
> check for new mail to happen right now (like the inc command of
> mailx). One would then have the option of setting mail_check to a
> larger (possibly infinite) value.
Sync. Default is `$'.
> When Mutt first starts up, the index is scrolled so that the selection
> is at the bottom of the window, but it would be nicer if it were in
> the middle of the window. Sometimes after I change folders the index
> is scrolled so that only the last item is shown, at the top of the
> window. Again, it would be nicer if the selected item started out in
> the middle of the window.
Setting pager_context high enough might do it.
> I hate tabs because they're rendered differently in different
> environments,
I love tabs because one can use their preferred indent length. If it
appears wrong you simply change the tab stops. It's also easy to change
source that uses tabs since they are only single characters. I've
always thought using spaces is ugly, except for in places where you want
to guarantee the appearance regardless of the viewer and its ability to
compensate (ie, in a source file, use tabs; in a mail post of that
source, use spaces, or enough tabs that either 4 or 8-space tab stops
can be used).
It's also a lot less space taken up in the actual file.
> so text that looks aligned in one environment will look misaligned in
> another. I make it a policy never to use tabs (except in Makefiles,
> where it's required). Mutt uses tabs to fold long header fields, so I
> edited the source to make it use spaces instead:
It may be required by the RFCs (if you're talking about things like
receive, etc). Might be worth a look.
--
Scott
