pcg@cs.aber.ac.uk (Piercarlo Grandi) (06/28/90)
I am tempted of switching to MUSH from ELM, but there two things that I think should be addressed, and one that could; first the important two: 1) Copying the mailbox to a temporary location should be done only when the mailbox is closed, not when it is opened (unless it is the system mailbox); at the very least there should be an option to allow this. The rationale is that by far my greatest use of mailers is to browse thru large (hundreds of messages and of kilobytes) archive mailboxes I have, and I rarely do modifications, but then when I do I'd rather not have to decide it beforehand and omit the 'read-only' option. 2) Curses mode should be redone, or at least improved in two ways: 2.A) It should use *two* windows, a fixed one as of now, and a scrolling one for user interaction. Currently user interaction just dirties the screen; some care has been taken to make this happen relatively rarely, but still screen redraws are painful and confusing (and no, I don't like the idea of piping everything thru a pager, as this would still require a lot of screen redraws. 2.B) When the mailbox is opened all header lines (or at least those displayed in the current screen page) should be precomputed and kept in an array. An option should be available to indicate the current line with a marker and not reverse video, as this would also save the need to rewrite the line to the screen. Now whenever one moves to a new line it is recomputed from the header (which consumes a lot of CPU time) and then rewritten to the screen. When one changes screen page, all header lines in it are recomputed as well. All this makes browsing thru a mailbox terribly inefficient. The optional change I would like to see is for MUSH to be split into a mailbox browser and a message sender components. I almost never use them together, except when I am replying, and this happens rarely. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
rock@warp.Eng.Sun.COM (Bill Petro) (06/29/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >I am tempted of switching to MUSH from ELM, but there two things that I >think should be addressed, and one that could; first the important two: I succumbed to the temptation long ago :-) >2) Curses mode should be redone, or at least improved in two ways: > 2.A) It should use *two* windows, a fixed one as of now, and a > scrolling one for user interaction. Currently user interaction > just dirties the screen; some care has been taken to make this > happen relatively rarely, but still screen redraws are painful > and confusing (and no, I don't like the idea of piping > everything thru a pager, as this would still require a lot of > screen redraws. Of course this (and more) is available in the tool mode. I too would love to see two "curses" windows. A headers "window" and a message window would be super-tuffo-nifty-cool! -- Bill Petro {decwrl,hplabs,ucbvax}!sun!Eng!rock "UNIX for the sake of the kingdom of heaven" Matthew 19:12
argv@turnpike.Eng.Sun.COM (Dan Heller) (06/29/90)
In article <PCG.90Jun28112634@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > I am tempted of switching to MUSH from ELM, but there two things that I > think should be addressed, and one that could; first the important two: > > 1) Copying the mailbox to a temporary location should be done only when > the mailbox is closed, not when it is opened [...] I'd rather not > have to decide it beforehand and omit the 'read-only' option. This issue has been frequently discussed and Bart and I have decided that the current method is the most efficient performance-wise. That is, it's best when you consider the permutations of what could go wrong if you don't. There are future plans for mush to not only optimize this process, but to allow for you to "browse" compressed folders as well as multiple folders at the same time. > 2) Curses mode should be redone, or at least improved in two ways: :-) It won't be "redone", but... > 2.A) It should use *two* windows, a fixed one as of now, and a > scrolling one for user interaction. Mush's curses mode is based on the basic features provided by the curses library that are portable to all forms of UNIX. As you who have done curses programming know, all curses packages are not created equally and are not all "bug-free". In order for mush to work optimally across all unix systems, it uses those curses routines which have been established as being "safe" (via tial and error using mush and other curses-based apps). Addressing your immediate concern: if one window scrolled and one were fixed, you now remove the ability to use an external pager such as "less" or anything you want. There is no way to restrict the pager to using only a portion of the window. Furthermore, most people would be unhappy not having a choice of pagers even if Mush's was just like "less" ... And finally, even the -best- cursees packages cannot do subwindow scrolling as optimally as a fullscreen pager; you would become very frustrated by this... those at lower baud rates would also be frustrated. [reading messages and other actions] > just dirties the screen; some care has been taken to make this > happen relatively rarely, but still screen redraws are painful > and confusing (and no, I don't like the idea of piping > everything thru a pager, as this would still require a lot of > screen redraws. Mush attempts to reduce the number of screen redraws by allowing the user to give any mush-curses command (e.g., those that you can do at the main headers screen) from the "...continue..." prompt. It is not uncommon to avoid screen redraws during 90% of your curses session. > 2.B) When the mailbox is opened all header lines (or at least > those displayed in the current screen page) should be > precomputed and kept in an array. That's exactly what happens. > An option should be > available to indicate the current line with a marker and not > reverse video That is also available. > [...] All this makes > browsing thru a mailbox terribly inefficient. I assume you're concerned that mush does the right thing because what you've described is what Elm does. I don't know, but from what I've heard from other Elm->Mush converts, Mush outperforms Elm quite nicely. > The optional change I would like to see is for MUSH to be split into a > mailbox browser and a message sender components. I almost never use them > together, except when I am replying, and this happens rarely. If you change to Mush, you might find that your email habits change because of the extended commands and features, a tty-line mode and increased performance. -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.