On Tue, Jul 31, 2012 at 02:41:07PM +0200, Vincent Lefevre wrote: > On 2012-07-30 12:42:32 -0500, Derek Martin wrote: > > No, but it makes a difference to the USER. Mutt is already hard to > > configure. If you have to configure sendmail to talk SMTP on the MSP > > port, enable STARTTLS, pop-before-smtp, etc. you need to learn a lot > > about sendmail. No one should need to do that just to be able to send > > an e-mail. > > No-one is forced to use sendmail. Is there any advantage of using > a built-in SMTP-client instead of a standalone SMTP-client? By > that, I mean: is there any advantage of having a single process > rather than two different processes?
Yes, I already more or less gave it, but I'll be more explicit: one consistent configuration interface, more consistent user interface, one manual to read. Less to remember, less complexity to manage. Computers are much better at managing complexity than humans, and I think it's fair to say that the average software developer is better at managing complexity than the average e-mail user. Mutt users are not generally average e-mail users, so the line becomes more fuzzy; but I still believe it's better to put the complexity in your code than in your user interface. Just get it right. =8^) > [...] > > Many of us don't agree. Mutt solves a whole class of mail-related > > problems that other clients don't solve, or solve poorly; but at the > > same time, there are a lot of things that people who use e-mail do > > that mutt doesn't handle well. The biggest one IMO is HTML mail... > > It's very popular, as it allows people formatting options that are > > very useful for written communications. Mutt handles this rather > > poorly. Reading HTML mail is clunky, and AFAIK there really are no > > good options for generating it with Mutt's tool chain. > > Not sure what you mean by that. Is this related to the text-terminal > based UI? Mostly... It's a combination of problems. The text-based options for HTML rendering all have a variety of weaknesses. The GUI browsers generally are much better, but having to switch to a browser to read HTML mail has always seemed very clunky to me. Having it all be text based compounds the problem in practice, even though it's possible to display text in different fonts, styles, and colors, even on a hardware terminal. Changing sizes is harder (or impossible), displaying graphics is only possible on some terminals (and terminal emulators), and other formatting options which HTML-in-GUI makes easy are hard or impossible in a character cell terminal. Also, having plugins to display other types of content directly in your e-mail client is basically impossible in mutt's model. Some people find this desirable... Again, it's all about consistent UI. > There's also the problem of replying to HTML mail, keeping > formatting options. An editor would be needed too. :) Indeed, but in the GUI world there are already widgets that handle most of that work for you. This is one of the reasons I'd like a Mutt GUI, though there are others. It's not strictly required though, but either way, I think handling HTML mail well really does require direct integration. Maybe "require" is too strong, but I don't think it can be done without direct integration and still avoid being clunky. > > Now you can argue that people shouldn't use HTML e-mail, but that > > argument is at best outdated... Based on my daily use I would guess > > that people who use HTML e-mail are now in the majority, and Mutt's > > inability to handle it well is a big weakness. > > Even though HTML wasn't designed for e-mail (formatting is nice, > but there should have been standard specification for quoting, > attribution and things like that), I think that a partial support > could be useful, mainly because there is nothing else. Well, there is: RTF. But not all clients support RTF, and most users don't even know about it. > But you have to be very careful and disable some features for > security reasons (Javascript?, links like <a href="some_url">other_url</a>). Agreed. I'd prefer there be a mail-specific (small) subset of HTML that's supported, mainly for formatting... But we have what we have. > But even before having a GUI, I think it would be useful to be able > to use Mutt without quitting the editor opened to compose a message > (starting a second instance has drawbacks if one wants to modify > the mailbox). I'm sure lots of people agree with this... I certainly do. Actually, I may look into adding support for this. Originally I was thinking you'd need a threaded model to make this work nicely, but that's really not the case. All you really need is a flag to indicate that mutt has children it needs to watch, a suitable place (probably in the input loop) to call wait/waitpid non-blocking, and maybe a couple of configuration options to tie it all together. It actually shouldn't be too hard, I think. Mutt could fork a copy of itself to handle submission of the e-mail, if that would make things easier (it might or might not). It should be totally doable. > > Mutt's area of operation is e-mail... are you saying that submission > > of e-mail via SMTP is not related to e-mail? =8^) If you take this > > philosophy to its extreme, there is no need for Mutt at all; you can > > simply tie together all the other pieces together with some shell > > scripts! So let's do that... let's disband mutt and instead write > > some documentation on how to write shell scripts that tie together > > your editor, fetchmail, and an SMTP agent of some sort, all the MIME > > handling software, etc.; and let the users all do everything > > themselves. That's the ultimate ideal of the Unix philosophy... > > This would certainly be the most customizable option! > > There would be no problems with that if all is done transparently so > that the end user won't notice how this is implemented internally > (except if he wants to look at it). The only problem, in my mind, is providing the user with a functional, consistent, intuitive interface, for managing most if not all aspects of their mail handling. You can't do that with a bunch of separate programs. Obviously there's a balance that needs to be struck between that and between complexity and bloat; but I think Mutt is a ways off yet from the ideal balance. > I think that Mutt shouldn't go the Firefox way, where a small problem > somewhere can make the whole application unstable. Sure, but this is always true. With its current design, if mutt ever has a bug in a feature you're using, it will make your whole application unstable. This is why modular code design is important: You make your bugs easy to isolate and fix. A lot of mutt is very modular, but my recollection is that the last time I looked at the interface bits (which was quite a long while ago), there was definitely room for improvement in modularity. I seem to recall thinking that too much functionality is coded right into the main menu bits. If you have a modular API for implementing your user interface, it's easy to completely replace the existing curses-based menu interface with a GUI, or even something more accessible to people who don't have hands, as one user was discussing in another thread (possibly on mutt-users, I forget). I'm not suggesting that it should incorporate features for every mime handler under the sun, and I don't mind the idea that some separate programs do different things that Mutt needs to do. But your interface will be much more consistent if as many of these things *as is reasonable* are provided by Mutt, configured like mutt, with the same key bindings as mutt, then if they are entirely separate programs with completely different configuration mechanisms. Consistency is good. The trick is judging what's reasonable. Mark this day down in history: I think this is the first time ever that you and I have basically agreed on anything non-trivial. =8^) -- 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.
pgpObUOUsqRNs.pgp
Description: PGP signature
