On Wed, Oct 02, 2013 at 11:03:44AM -0500, Derek Martin wrote: > On Wed, Oct 02, 2013 at 12:04:46PM +0300, > Alexander Gattin wrote: > > The "old" design you talk about comes from UNIX > > concepts which power all the iThings, Androids and > > Kindles you most probably use and adore yourself. ... > as I said, it has its limitations, and Mutt has, > IMO, reached them. In Mutt's context, the Unix > philosophy works very well for things like > handling e-mail attachments, but it works much > less well for things that are inherent to > handling mail folders, like searching for mail.
I use / ~b <regexp> for searching in IMAP folder. Newer IMAP versions support server-side searching but AFAIK mutt doesn't support this (XXX: one more wishlist item). I did LDAP integration via lbdbq, but currently it's of no use for me because my current client's network security department disabled LDAP access for contractors. I mentioned LDAP because it also supports server-side queries IIRC. > Mutt's design does make it possible for highly > motivated people to solve *most* of these > inherent deficiencies using a combination of > complicated macros and a variety of external > tools... E.g. lbdb. This should be included in mutt's manual. It shouldn't be included in mutt's code IMHO, > but this is a BAD solution. Why? Because you should make some effort? Yes, agreed, therefore there should be some meta-packages/tasks like mutt-task in Linux distribution, which install all necessary tools and scripts for most common set of necessary features. > It's bad because the interface is not uniform or > consistent Please specify inconsistencies explicitly, otherwise it's [weasel words] or [citation needed] :) > it's bad because it requires the configuration > and maintenance of maybe a couple dozen > applications, instead of one or three Number of applications is not a valid argument. How many packages do you have to install in order to have openoffice/libreoffice on your computer? Why not apply the same for mutt, just better? If you want LDAP integration, install lbdb. If you don't need LDAP (like I do inside the MTS UA premises), you can save some HDD space. > it's bad because it drastically increases > ramp-up time and learning curve Just create some "common man bundle"'s, work with distributions (Debian/Ubuntu/whatever). > it's bad because the amount of work involved to > solve all such problems is prohibitive For John Doe? Yes. For ESR? Nope. > > If you think mutt development is dead and miss > > something badly, you are free to fork mutt and > > implement missing features yourself. > > You should really go read the archives, as I > suggested; this has been addressed many times. > Forks are bad, and so is maintaining patches > indefinitely. I know about forking and maintaining patches first hand (I had to maintain some against Linux kernel - usually at some point I get tired and try to slip at least most important parts upstream). With mutt I remain at 1.5.18 because later versions reliably get a segfault against yandex.ru IMAP server, so maintaining my patches is not a problem for me, here. Problem is I don't file bugs until I've got some grasp on the problem, and currently it's too much effort (and time) for me to get meaningful traces for later mutt versions or rebuild mutt with dbg info and try gdb agaist mutt's coredumps. So as you say some rot is forming, in part because of my inaction (luckily I don't have to obey 1st law of robotics) or because of inaction of others, whatever. P.S. My point was that users' forum is a bad place to discuss development. -- With best regards, xrgtn
signature.asc
Description: Digital signature
