On Mon, Sep 03, 2007 at 10:17:43AM +0200, Thomas Roessler wrote: > You're arguing why mutt should have a completely different UI > paradigm, which -- surprise! -- might even make sense if it was > started from scratch today. Certainly. > However, the question at hand is how to make a specific interaction > fit the rest of the interactions that people have with mutt. Well, Rocco seems to be suggesting that Mutt only use this new functionality in certain places, but I would agree that Mutt's interface should remain consistent -- I think it should pop up dialog boxes like this everywhere it needs to prompt the user... including when it displays errors in a curses context. There are (or used to be) error messages that would pop up in the status line that would disappear before the user could read them, or in some cases even notice they were written to the terminal... The dialog box paradigm is a good way to avoid that problem entirely. In general, I think it's just a much better way to interact with the user. > In any event, as I said before elsewhere, I'd like to see the two > options (center of screen and bottom of screen) in place for a > while, so we can actually see what makes more sense. That's quite reasonable. :) Someone would need to code the alternative, of course... > I think you constructed an objection to including that patch from a > simple remark about my personal preferences. Yes; it did sound a bit to me like you were suggesting that, even upon a re-read. And to be fair, in the past you have by all appearances not included useful features evidently on the basis of your personal preferences alone... I'm not saying you couldn't have had other reasons, but if so you were very often rather quiet about them. > De gustibus non est disputandum. ;) Indeed. :) > >>> Mutt could do some (extremely) basic HTML formatting, like > >>> handling <b>, <i>, and <tt> tags, and displaying inline > >>> images. Yeah yeah bloat blah, but it's just a lot more > >>> convenient if I don't have to launch external applications to > >>> view these extremely common forms of e-mail. > > >> Use "lynx -dump -with_backspaces" as your default html handler. > >> :) > > > > This doesn't display italics on my terminal, nor does it display > > bold as bold text. > > It should actually take care of bold. Well, in my xterm, bold text is displayed as colored text... so it kind of does, and it kind of doesn't. I'm aware that there's a resource one can set to make bold show up as bold, but how effective this is seems to be rather variable, depending on what fonts the user has selected for xterm to use, and apparently also the alignment of the stars and a confluence of other less-predictable events... In theory it can/should take care of italics in the same way too, but again, your fonts have to be right, and I guess mine aren't... ;) I think gnome-terminal and konsole are a bit better about that, but those options suck for a variety of other reasons (insanely slow text rendering, less configurability, lack of availability on various platforms, etc.). As an aside, thanks to Thomas Dickey for keeping xterm in such excellent shape after all these years... :) > > That kind of eliminates the usefulness of using formatted text to > > highlight and emphasize selected text over the rest... I could > > probably futz with my terminal configuration to make it display > > that way, but I don't *want* to. By contrast, the GUI mailers > > just work as expected, in that regard. > > True. They also work as unexpected, if you look at the various side > effects that HTML can have at times. But see above about rendering only *simple* HTML tags. The great thing about HTML is that implementations get to decide which tags they'll render and which ones they won't. They also get to decide *how* to render them. And of course there are well-defined standards that outline how you *should* do it, if you do... If that doesn't cover what cases you're thinking about, I'm not sure what you mean. > That mutt is starting to show its age is doubtlessly true. That its > heavy reliance on a single text terminal is quite limiting is true > as well. At the same time, there are use cases where that > limitation is actually a plus, and I'd hate to see mutt become > unsuitable for these. I agree completely. The sidebar patch goes a long way to getting me what I want. My main frustration in using it is not with the sidebar patch itself, but the way Mutt does new mail detection. As I've said several times before, I think new mail detection is completely broken, and the sidebar patch is a constant reminder of that. Anyway, another sidetrack... The only thing that doesn't get me is the ability to compose a message while viewing other parts of Mutt's UI (another message, or the message index, or whatever). If a clever way to provide that functionality were devised, I think that would be extremely cool... but I can live without it, since as someone pointed out, I can start multiple instances of mutt in different windows (or screen, or whatever). However, if Mutt's interface were more modular, you could include an optional GUI that did all of these neat things, and more, for the cases where the user is running Mutt locally and wants to have them. When the user is remote and/or doesn't want all the extra overhead, the terminal-oriented UI would remain. You get the best of both worlds. > You could keep a terminal mode around, but I would be surprised if > all (or even most) of the benefits of an updated architecture were > to manifest themselves in such a mode. Well, new mail detection, for one, could more easily be fixed. I guess it's actually relevant (not to the discussion of Rocco's patch per se, but the broader discussion of UI enhancements), so I'll elaborate. But this is only an example... there are other such places where improved modularization would benefit even the current UI design, though none so striking as this. Mutt does a cool thing: when changing folders, it cycles through folders which have new mail, in the order you define them in your muttrc (unless you tell it to use some other order), which provides the functionality of telling you about folders with new mail in the order of importance of those folders, if you use it that way (which I obviously do). This is great. But it has some problems. The first problem is how Mutt decides whether a folder has new mail in it or not... Mutt's idea of a folder with new mail in it may be different from the user's. If a user marks a message as new in a mbox folder, Mutt will not recognize that folder as having new mail in it. Notice I specified mbox... this leads to problem #2. Mutt's new mail detection is not consistent across mail folder formats. In general, aside from optimization considerations, the folder format should not change the behavior of the program. In particular, the interface presented to the user should not change just because the format in which the data is stored has changed. This is just bad program design. Problem #3 is that Mutt can not distinguish between new mail and unread mail, regardless of of the folder format used. Ideally, I would want Mutt to cycle through folders first which had actual new (unseen) mail in them, then by folders that had unread (but seen) messages in them. At work, I have to monitor a variety of mailing lists, each with a different importance, and each requiring different response times, generally. With the current interface, if I want to move on to new mail in less important folders than the one I'm reading, but I have a message in this folder that I want to put off addressing (or just haven't read yet), then in order to be reminded that I have important messages that need my attention, I need to use maildir and leave those messages marked as new. If I don't, due to the usual distractions of the day and the volume of mail I receive, I'll forget about the message. If I use mbox, Mutt will "forget" that I still have new (unread) mail in this folder, so using Maildir is the only option. But this is not a good solution, because Mutt will now cycle me to this mail folder first every time I try to change folders, even if it does not actually have genuinely new mail in it. The only way I can tell if it has actual new mail is to re-enter that folder and look. This is highly inefficient, and when you're dealing with roughly 500 messages per 8-hour shift, the effect it has on productivity is not negligible. Granted, it's still way, way better than trying to do it with Outlook, which some of my coworkers do. I don't have any idea how they manage it. ;) > > the current code base desperately needs to be abandoned, and a > > fresh rewrite started with modularity and modernization in mind. > > But that's a project -- and an argument -- for a different, > > brighter day. :) OK, it doesn't need to be completely abandoned, but a lot of the current core would need to be rewritten as a lot of functionality is tied directly to the interface. It needs to be separated/abstracted so that the interface can change without the underlying functionality needing to change as well. > Good luck. :) Indeed... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpEqjewbpPR8.pgp
Description: PGP signature