From kinge@oklahoma.net Sun Feb 1 08:24:36 1998 Return-Path: kinge@oklahoma.net Received: from dns.oklahoma.net (dns.oklahoma.net [208.2.112.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA00237 for ; Sun, 1 Feb 1998 08:24:34 -0800 (PST) Received: from oklahoma.net (qmailr@r116-127.okc.oklahoma.net [208.2.116.127]) by dns.oklahoma.net (8.8.6/8.8.6) with SMTP id KAA10559 for ; Sun, 1 Feb 1998 10:23:15 -0600 (CST) Received: (qmail 3784 invoked by uid 500); 1 Feb 1998 16:26:53 -0000 Message-ID: <19980201102653.30823@king.oklahoma.net> Date: Sun, 1 Feb 1998 10:26:53 -0600 From: "Edward T. King" To: mutt-dev@cs.hmc.edu Subject: pgp5.0 Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Content-Length: 1237 Lines: 34 Am I missing something? 0.89.1i functions flawlessly with pgp 2.6.3, but when I try pgp5.0 I get this msg when I try to encrypt: PGP is now invoked from different executables for different operations: pgpe Encrypt (including Encrypt/Sign) pgps Sign pgpv Verify/Decrypt pgpk Key management pgpo PGP 2.6.2 command-line simulator (not yet implemented) See each application's respective man page or the general PGP documentation for more information. Press any key to continue... When I next try to send I get a seg fault and mutt dumps core. What gives? Mutt 0.89.1i, Copyright (C) 1996-8 Michael R. Elkins Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System info: Linux 2.0.33 [using slang 9938] Compile time definitions: -DOMAIN -HIDDEN_HOST +HOMESPOOL -USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_POP +HAVE_REGCOMP -USE_GNU_RX +HAVE_COLOR +HAVE_PGP5 -BUFFY_SIZE SENDMAIL="/usr/sbin/sendmail" MAILPATH="Maildir" SHAREDIR="/usr/share" ISPELL="/usr/bin/ispell" _PGPPATH="/usr/bin/pgp" Feature patch: condense_pgp 0.88.15 by Stefan `Sec` Zehl From olsenc@ichips.intel.com Sun Feb 1 12:57:26 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA19520 for ; Sun, 1 Feb 1998 12:57:22 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id KAA19993 for ; Sun, 1 Feb 1998 10:23:50 -0800 (PST) Received: from dtthp193 (dtthp193.jf.intel.com [134.134.102.26]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id KAA01930 for ; Sun, 1 Feb 1998 10:20:24 -0800 (PST) Received: by dtthp193 (8.8.8/WW2.1) id KAA24427; Sun, 1 Feb 1998 10:20:24 -0800 (PST) Message-ID: <19980201102024.61979@dtthp193.jf.intel.com> Date: Sun, 1 Feb 1998 10:20:24 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.89.1i] patch: new_addr dequoting has a bug Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=WIyZ46R2i8wDzkSu X-Mailer: Mutt 0.89.1i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! Content-Length: 694 Lines: 28 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii The following patch corrects the problem with the new_addr I identified in 0.89i. The new string was not nulled at the end so you always say a repeated last character with the parasitic quote at the end like this: 12 + Dannenmiller, Jamess" 1/29 64 FW: Beer Quotes -Clint --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.89.1i.co.dequote.1 --- rfc822.c.dequote Sun Feb 1 10:16:07 1998 +++ rfc822.c Sun Feb 1 10:13:33 1998 @@ -64,6 +64,7 @@ w++; } } + *w = '\0'; } void rfc822_free_address (ADDRESS **p) --WIyZ46R2i8wDzkSu-- From eisenbud@allspice.cs.swarthmore.edu Sun Feb 1 16:19:47 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA27208 for ; Sun, 1 Feb 1998 16:19:45 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id TAA18437; Sun, 1 Feb 1998 19:19:43 -0500 (EST) Message-ID: <19980201191943.62609@cs.swarthmore.edu> Date: Sun, 1 Feb 1998 19:19:43 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: [0.81.1i] purify output: evidence of several more (mostly minor) memory leaks Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=M9NhX3UHpAaciwkO X-Mailer: Mutt 0.89.1i Content-Length: 7953 Lines: 124 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Here is a bunch of purify output from 0.88.1i in normal use. It indicates that there are a few more little leaks here and there: regexps may not be freed with the new pattern code, there may be a few residual address problems, and a few other things. I'm pretty sure that these were all produced after I applied my previous patch to fix the mail_followup_to leak. Besides that, it is an unmodified 0.89.1i, so you can trust the line numbers after applying my previous bugfix. I think the UMR with qsort may just be weirdness on the part of Solaris's qsort. I have not really tested the pgp code with this, except for viewing signed messages. I'm also not totally sure that I tested the autoview code too much, but I think I did a little. You can get a 15 day evaluation license for purify from Rational (www.rational.com.) Mine is about to run out, but if anyone else wants to try it out in a few more months, after a few more mutt versions, that would be cool. I'm planning on running a purify-instrumented mutt until my license runs out the day after tomorrow, and I have it set up to email me any errors. I'll send more to the list if I see any other leaks. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --M9NhX3UHpAaciwkO Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mutt-purify.gz" H4sICFAP1TQCA211dHQtcHVyaWZ5AO1dbXPbOJL+HP0K1FRtlb0V0QAJECSzmRtvMrlJXbLJ xs7d7uamVBQFWbxIJJekYnvrfvw2+G6JkihFtmQHmpRHIhovRHcD3Q+azTdxOEPCT0QwnI/Q xTxAb8QQIYKI6TDqYB0R27Z6n0Q6j4P+RzedOOhPJf3PcN0T/jcxctDJuNnSL9PQc6eTMElP e8+Gt8idTpPI94TmJVpy7cbpZBbGQhOjOTqxNPjvLPt7ivwR+uv5ObYIM3rPxmFctfhCDu45 DEyOT46pHmEfM4zRya8Xl6e9124qnG6kb2DADnrtBr6Yol/LKWjc3HuRJO6V6L+F2/uTbAfr mOiEUa0c4i+r7+vn3mXoVKPvXcyH/ye81EEf57E/vnUQRiKOwzhBJxilYepOUeh58zgWgScS mIcAzeZp2rtI3XSeOOjTh96rMEhFkPbfieBKssHgutl75wcCii3e6/0RPqhoH+onaTyfAb0Y ZS2hkwjm1iIGR266yGjDoWY2U6c9hP5YtkE1gi7CqRv7CdKfo1dhdBv7VxNo6tWppNb78Iej T27qhwHcwEU4TmEOBFDGkYbOp1OU0ScoFomIQUw0lLX/Bvjqwd24XgoDBS7PsiZQehsB836K 8u77EzGNfsoqvApnMzcY9adwt05+O30XRW7qTfpYs2yN+NpIaDPXnw7G4XQaXs+jQRr2p8L9 CjchK/TnMIQk7/9DJLtLUCLS1A+uYP76ZZ+yiT7UlNQvK73oexPXD6A5OfMvCUP/C+2gslZ/ Es7EyzNxE4VxeiZ/nCWpOx6flfXPgE6cFcQwq/0kn1UdNad7CnIUJMCuNCwv/frNnc7zufkM A2pSexPhfYXBIxG4wylMbXcBOIVm4NN7lYlbisb+VKCRSLzYj1IpkiB8cP8Osntv3n52FssR BnVI0pEf/NxeTvLycJ6uINBzAlCAFQQUpOBMpN6ZFrgzMZDCA5MzGIVh/NNz9GHw6fWHv7z7 u+QBCJOsK6XIQf8R9/v5PynYcRimkkvoeiJAwxsfjM7nV0g3kJRiM2/mcgJSvjiOazeRSxes ZXIW5Qrn9J4Npv7QG4SRCLLGvsifWhJq5HcoCxJvkMa3cqSwAE7vll6JNLqe+6NBvFxTsmjg B34+ZPRFftU8B9abrBTEr3EDX+RvKKUGl52CtMVpXejFKdHC39unlsHc+8FExH55S6BHUgxW sMLckt7akl6XHZTrA5IrfiXAqYjlsgKiuKou71R3a8Uo1+gL4cbeRCqZbFuycyZgfQdVhXUl 0TTQuff1BbkLGjoa3qZCruoapsT4w+kLFIVy2fahek2HK7I/nEIj7/6rUTWnkUoIV0D2via9 SkCL/lvlcpZdqcUgTkG+pBw881aWJO5YDOpiKZEgVjqzMmkNBm4Ki/QEJD5JoZrwvuUXgIaZ pdCupyMGLQlhMRwNYOLnIKLhLAoT2DYdA9tyhH5Zmm256Iv8JWtjbqwWf8bYGvGXk/ZnOX8o HMMuV864jlIfugHGTF0YbTbDckvEN4RTOsS9gv3oN+FG6Byk6DaBmT+BIQ9BKUEYknkUgdTJ pRo2JTQPGhdyhp320KpPNqKk+C5HtED6Lud+9dGrb4YOpB8bwrRIihtfF1p9G/RhAyl+EMZI /o1zajIg7Xf85K1eZubKeSV/VatG1arNt9e6bHOLw6vYBTvyJls+rv10gpLMBAKDYSQQ1jIy jFwPzKSksKGeoxYbKqdc0Kqyen5tWTPz8j+7ie+VujbPBPLED7zpfCTZX9xR+E3EE+GOTp1i ri3b4tjKxllc0bkBJiMaual7NkxKTjNiYttEEyleJxF0K1epWmJ0MKzkPXtfs7FcTGD1HIFx MIxdGM22gzIJx2DbQfUgmWZ7zUAaI4PIGHh4QAkeSGE4SfJe5NirkZiM8M01o9gHZRfZTVZV OcNgdUPVBIRdpNv1iyiGGehQua1rYjAOJi7Unm3ZK7O4vqFeW4fSKbCzDr3tOjSohemGeq2T i8AmyPgy2pKh+RqxoWJ7lzbLRaHcWGHNnQ+TrJVVfRk6XVmjtRMCikGKKtveGTEw3ly1vVuz ELdZtO10Wrq1qWJrlwa3DUPWvN72Ns28x+tt75FinFX0BlESby01uWJsqHu3417mXq9EFphD 2YGQBZ3xLshCNsJuyMIS6c7IAtPKIT4osvC3fvnjfBllMBndHmUw7RaUgTrYeGwowz8UYgDM VIiBQgwUYrBGMXZHDGrHFGuwC5hbIAZV1QIxyJ1Y06QUK8QgV46RuCnrz+NkUCgB0am5WkXM rP1VKnJc6ACpv5n7QwcqP55Re3/oAK1aNdn2GnYv6MCCBh0BOkB1gk3LWoMOgAeg0AGFDih0 QKEDTxId4A7GDqyLD44OfJKuN7XxRnSgHGEHdKCNdEd0QMdYK4f4HegAyXfF7Bxkp7ADZmKj BAQI0zvu5HorIsAcyhUi8OgQAb02yz6//+Sgz4H0PcFS8v8lCXMjJAZDw6n9EPiXS5rs73qS u+Dgg/wzSZum6Jd/JjABmve7LAkbBniL7yvLB9KekYEdX/J6DuGZ9zAMbwbJbeBJk38KP8C6 h79QznV5ZninSJr+ssg0M6/gZuBNwdNo1Mzq2XyTW8HYzl6FnKZPcCdycmhhf2YLG74R4/FY mCZGUlAnIjf+ckv0fDSSjkWTCKYZHMCihaGYhtfQjjsTYM1me63U8PE88DJ5gLnfgeUKBFIg kAKBWhRjdxAIdsEaBDK3AoF03AICMUwptw4DAsVjz9L1gRfdDtxRDLWy33J55GZd7EagCCNU wTY0WzvHoLyTQSw8P5IgSFnIDB0KRfAN1rMI9FmM3fk0TepyS1+DCNkYl4oSwfVCibKvctAE Vwv7yE+iqXtbt+Dl+38iNcqim9Z/bu6OKq0G9Kig+FC8PDZA78j5Z7eyjxviu/HYjEmzJSZl M5OVweI0mkeNMsPA65XRVsq4lpl6GzNHnNtHyEyLKGY+Crye1t/4/vB6vY672yNeb9anAOb2 xtAWeD25g9c/R/oquL4yk44HrmeMcph/BdcruF7B9Qqu/yHhessB6TgMXM87BPOVI+wG1y+R 7gzXW1o5xMM+JmiaxtYBfBxEcwGuh7nhjqE/Mrj+h8fqgZMKuFXArQJu1yjG7sBtE5Bth2yX 4/vAJb0D9i3XKkFcPjRUJN8PEsm34O6vQwYWgv46IQMM38dzfkwn22vbvUTy4RZkYI2GPUgk n84xXwsNYAUNKGhAQQMKGniy0IDtEH4gaMAyWRdoIBthN2hgiXRnaMDWyiEeGBqwt4cGLDAq lqEBmBvy+DIIyf9r0TS8qgX4hwcMgL8KMFCAgQIM1iiGShD0YyYIMm3d+9ESBHF8H8AB1rfX uh8mQRDmNriMq4EDUwEHCjhQwIECDp4scEBwmSvm4YEDW+cves9aAIB8UE0AoPLvXzf8e8IJ xoZGYFnVf2nx6lcCDI32N0ELv6xAC7aqUCEKb65HhU9ceLngEffegxHU/28RJ+BcOohouIIP LjMnezafpj5Y7unZzL8RoxdoGM6DEWxBL//n7e0/qPlJ963r1//6ejHv/a3/HrxmETvoveyk yNi79iFDysz6IUMTpKXfX2r27nhScZOeRVMw/F6A7+vG4Lu/nCd9N/F8P6uPeguz01s9OR36 KyzRszzstip8XXgf2ay9CWNodpQ9FJfbrZmobsWlQyBnersCLCNgKxQA24RrlBNubaUAjfYf VgHA1ks3CvxaAavY7yfgt/g5+3MfR9q0LzLXVGIVL7Nk1CVP+pZlGX22g3x2MZ65pbdk+6Ym TPQxY3WywuXl31E4T6N5+lxav9mTj2GmVein/rUfjMLr5GUQPnB68EeL6klJUKieQvUUqrdG MXZH9ewartMIMRWo1wnU2wF/c4fcWvfgK1CQMX58D74WM5U2t6eKhHP2+/qUb4bHrAM+laZj ygcikF6hvPVCHvLrsg1MFoShgeHmTcF6h9ehvOD4V1NA2qaAD5lrPcanLDtzfsVtm+RRPo/Y 4baPCmU3q282vgeUnZE9PrjHy1ZNbG+/C94Lym7jB0TZqYTd7qDs2GT6IspOCee2rtLwK5Rd oewKZX+yKHsLkAkbyAb03TxY2J5NbKND2F4+wk5he8uku4btEVMrh3jQsD3LwKwEx3WDdj1I t4z2uD1bZeB7fEF6lqHgPAXnKThvjWJ8R5AeYzWeB/7qFnieabWlYyN07B4ohVeRnSeWCS3z be3Tm1fgl8s8PXGGxVFWSW5BAb74gA9BiBsIjSl9chjdVwEue3aq2UgjRCnOoUMRw70MhuHo ti7k2FiXQ4g9luxeJl6Cao2DQrU5V90iCWgDf9FxA54pqWpYLicyMoh2kM2ZzNU6KOjzhKq1 eBBiGB3lyFBytIRrVzD1ibES16YjkwlciBlrTTw2dnXrQLj2ZhGxOFYSsseVhpL2TcS+X4hb 3KQxGOYVb2A/rVmc4fMdVgtMiZKFPcqCYd3brrMr7l/wtcyeXW8pJMsmWG9LSSS8ZrFtrN21 TKp2rd3l8O5pqrX5NBV2HY7xwm5VVCsIGDWs+z+o/j45bJOk5nmskqSD2j9dzvVha7OGWEVE PPIkyFvznY5tLqp4Dv6YNjqqNrqj2OjsDt7V2GZ65V21pujWjfHBoii62NS2qXagp5cNmvDq kJax/QWV2FVQCdP3FlTCq2zQNubbY7H38+gmY0eXD5pYJiEqH7SKKlFRJSqq5Md8dpNih9kH iR4hmPEuSZ/yEXaKHlkm3TV6hGavb8yGeOCkT7pVJX3q+GIHGLXZEj0iJ8d4ZNEjKtFTk6cq iEQFkaggknWasXsUyd3Mz4RvEUWy4jEf7o5UPuidUj0d18MkCwmc9+P3m2VyJcMyrL35/Sat WmV0B/W5F8d/QT2OIWcTBQ9z7XugmHqaRPn9yu9Xfv8T9fst+aAFrIsP7vdfgFNtwPK70e8v R9jB728j3dHvN4iplUM8qN/PYDxVSiWTdN3LOawRy44/dQxDvQnqkfn7wErl7yt/X/n76zRj d3+fWVbt8HO68qkRizaSxWBeOf060+8tAiYWV3lERFkirqTbrXl52bX8UZY1RbOgQ21lwpVh C1ew+JUn/amceokZ6I0Y4OziIGulQcIIXiQZzwOvScIJ2RQJwHJA4buDlWqWrA4jAUvAdMsw kqrCnTgSbzQy8T2zKpAes2Lj3SDpdnaMqW4fkh1uCivgirLIB1N4RdkwdgNv0l7W3MsU+9dr Ix3bltLGo2GHLnS1OD4sOz7eYceqF03CviXGljIx9j/9x3TowGtM1Or8gkmLbjh0KF8waRFM 9xdsiMtWwTDfwYa/l0OH2rxvniqsUa7jCDdUr4pQxw7q2EEdOzzdYwfuUHKYYwdGOySrKkfY 7dhhiXTnYweulUP8jmMHku+L6IQsbYudDh2oYdfvccBW5wACilujDQ1L5ap6hHGGFJeW2cXb /wS5968kIyYwV9CMUzse8C+XL9nL9SRH9yXsHtnEksab75UGdpCHLAHjslYKVD3JWi4jkuAX 8K4i+JL/hlvLfJJs3ckrDAqawXUss9XGTbemJEvBmIzuODyDKKMfgLU3HiS3iQT9B9/sxvCi cNo8fLjj2iRiCprWXnbxDpoDjySag+sigswokwTJ1A2uNDejgG8bKKQXI5LB9ZVIvcmq0rbC IpIrLTCo3B3Ko8HqSK9V/pJh2B0eDy5XZJQzABT8BETjt88fUR/9BuOYR7mOF6Iyc5OvTkXy /wi+XF5cfjwtpLmYgLytJCd89eEvl1C+vYhuPBojWJ2NqbOxLel5xrrV67V8QdKZvNl1jOzH 14X/LBlZ7RVhOikWQPAgCLcM0tg1s2cAy2bqV9MAoakTulcmgxpWJVA2lj+ypXbcuLzE4GF4 kzVYPWf9RV6qn2ZdKr3JFpKNwA03jF2Bm6cWzVwvbrufbjajlLvEMR8V9rUQRdsF+7J0vC7g lhNYI8sQWcs09oN9cQK9FhiYgaHV7Tm8BfZF7mBf0hVZtPHvRtYeS7QtOBLU1IFuBexFmG1R BXsp2EvBXgr2epqwl+1g7hjmw8Nel+fnxNKZuRH2KkfYAfZqI90J9oLNE3OtHOJho205Nepo W9xxI7cIyMkC8AWzQxxdJWl/fMCX5GZnVMFUoMKTAxWOxgVsSuLuLqBVBaieEI0ZneJbGani W6m+nECbqfjWh41vZWvSpHnWCB8+FlnFcH1nnLKOx2J9nPLINA0VGXkskZGEWQSrOOUfgP2k PbW/Zbh7YP+dogXBUIzac8gsYbZMo6SslqccMkuqOFgrO0XbS8gsNVgBllKO9/bSV0qL8F7G TMp28AruJWTWWrAijyBklmDbMA24ujJklmN1dqDODtTZgTo7eNRnB/8GvC2Z6NnlAAA= --M9NhX3UHpAaciwkO-- From eisenbud@allspice.cs.swarthmore.edu Sun Feb 1 17:21:14 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA13010 for ; Sun, 1 Feb 1998 17:21:08 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA20516; Sun, 1 Feb 1998 20:21:06 -0500 (EST) Message-ID: <19980201202106.52912@cs.swarthmore.edu> Date: Sun, 1 Feb 1998 20:21:06 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.81.1i] purify output: evidence of several more (mostly minor) memory leaks Mail-Followup-To: Mutt Development List References: <19980201191943.62609@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980201191943.62609@cs.swarthmore.edu>; from Daniel Eisenbud on Sun, Feb 01, 1998 at 07:19:43PM -0500 Content-Length: 65768 Lines: 1667 The purify output below includes a new leak I hadn't seen before. It occurred when sending a message with a lot of gzipped attachments. -Daniel > **** Purify instrumented mutt (pid 8137 at Sun Feb 1 16:53:46 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -a patch-0.89.1i.de.mail_followup_to-leak.1 mutt-users > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8137) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8137) **** > Purify: Searching for all memory leaks... > > Memory leaked: 32 bytes (0.0413%); potentially leaked: 0 bytes (0%) > > MLK: 32 bytes leaked in 2 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > main [main.c:555] > _start [crt1.o] > * Block of 16 bytes (2 times); last block at 0x1744b0 > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 2 32 > Potentially Leaked 0 0 > In-Use 1551 77465 > ---------------------------------------- > Total Allocated 1553 77497 > > **** Purify instrumented mutt (pid 8137) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 32 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 516096 heap (peak use) > 2992 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 16:55:45 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id QAA08257 > for eisenbud; Sun, 1 Feb 1998 16:55:45 -0500 (EST) > Date: Sun, 1 Feb 1998 16:55:45 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012155.QAA08257@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > X-Status: A > Content-Length: 3654 > Lines: 87 > > **** Purify instrumented mutt (pid 8169 at Sun Feb 1 16:54:03 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -Z > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8169) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8169) **** > Purify: Searching for all memory leaks... > > Memory leaked: 16 bytes (0.0206%); potentially leaked: 0 bytes (0%) > > MLK: 16 bytes leaked at 0x166440 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > mutt_index_menu [curs_main.c:1246] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 1 16 > Potentially Leaked 0 0 > In-Use 1553 77549 > ---------------------------------------- > Total Allocated 1554 77565 > > **** Purify instrumented mutt (pid 8169) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 16 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 4210688 heap (peak use) > 2928 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 17:00:20 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA08490 > for eisenbud; Sun, 1 Feb 1998 17:00:20 -0500 (EST) > Date: Sun, 1 Feb 1998 17:00:20 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012200.RAA08490@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 1 error (2 total occurrences) in mutt > Status: RO > Content-Length: 5603 > Lines: 152 > > **** Purify instrumented mutt (pid 8269 at Sun Feb 1 16:55:47 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -Z > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8269) **** > UMR: Uninitialized memory read: > * This is occurring while in: > qst [qsort.c] > qsort [libc.so.1] > mutt_sort_headers [sort.c:174] > mbox_sync_mailbox [mbox.c:725] > sync_mailbox [mx.c:666] > mx_close_mailbox [mx.c:797] > mutt_index_menu [curs_main.c:556] > main [main.c:609] > _start [crt1.o] > * Reading 4 bytes from 0xefffe660 on the stack. > * Address 0xefffe660 is 664 bytes below frame pointer in function qst. > > **** Purify instrumented mutt (pid 8269) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8269) **** > Purify: Searching for all memory leaks... > > Memory leaked: 47 bytes (0.0606%); potentially leaked: 0 bytes (0%) > > MLK: 20 bytes leaked at 0x504478 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > rfc822_cpy_adr [rfc822.c:576] > rfc822_append [send.c:456] > fetch_recips [send.c:532] > envelope_defaults [send.c:582] > ci_send_message [send.c:900] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 16 bytes leaked at 0x4e4078 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 9 bytes leaked at 0x4e73e0 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > rfc822_cpy_adr [rfc822.c:579] > rfc822_append [send.c:456] > fetch_recips [send.c:532] > envelope_defaults [send.c:582] > ci_send_message [send.c:900] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 2 bytes leaked at 0x4d7790 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > rfc822_cpy_adr [rfc822.c:581] > rfc822_append [send.c:456] > fetch_recips [send.c:532] > envelope_defaults [send.c:582] > ci_send_message [send.c:900] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 4 47 > Potentially Leaked 0 0 > In-Use 1552 77499 > ---------------------------------------- > Total Allocated 1556 77546 > > **** Purify instrumented mutt (pid 8269) **** > * Program exited with status code 0. > * 1 access error, 2 total occurrences. > * 47 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 4554752 heap (peak use) > 2928 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 17:08:24 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA08757 > for eisenbud; Sun, 1 Feb 1998 17:08:24 -0500 (EST) > Date: Sun, 1 Feb 1998 17:08:24 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012208.RAA08757@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 3663 > Lines: 87 > > **** Purify instrumented mutt (pid 8728 at Sun Feb 1 17:07:32 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8728) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8728) **** > Purify: Searching for all memory leaks... > > Memory leaked: 0 bytes (0%); potentially leaked: 16 bytes (0.0206%) > > PLK: 16 bytes potentially leaked at 0x507b30 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > mutt_index_menu [curs_main.c:1246] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 0 0 > Potentially Leaked 1 16 > In-Use 1552 77505 > ---------------------------------------- > Total Allocated 1553 77521 > > **** Purify instrumented mutt (pid 8728) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 0 bytes leaked. > * 16 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 4227072 heap (peak use) > 2920 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 17:09:17 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA08865 > for eisenbud; Sun, 1 Feb 1998 17:09:17 -0500 (EST) > Date: Sun, 1 Feb 1998 17:09:17 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012209.RAA08865@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 3693 > Lines: 87 > > **** Purify instrumented mutt (pid 8852 at Sun Feb 1 17:09:11 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -a mutt.plog eisenbud > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8852) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8852) **** > Purify: Searching for all memory leaks... > > Memory leaked: 32 bytes (0.0413%); potentially leaked: 0 bytes (0%) > > MLK: 32 bytes leaked in 2 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > main [main.c:555] > _start [crt1.o] > * Block of 16 bytes (2 times); last block at 0x1692c0 > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 2 32 > Potentially Leaked 0 0 > In-Use 1551 77470 > ---------------------------------------- > Total Allocated 1553 77502 > > **** Purify instrumented mutt (pid 8852) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 32 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 507904 heap (peak use) > 2960 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 17:10:03 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA08927; > Sun, 1 Feb 1998 17:10:03 -0500 (EST) > Message-ID: <19980201171003.10462@cs.swarthmore.edu> > Date: Sun, 1 Feb 1998 17:10:03 -0500 > From: Daniel Eisenbud > To: Daniel Eisenbud > Subject: Fwd: mutt purify log > Mime-Version: 1.0 > Content-Type: multipart/mixed; boundary=WIyZ46R2i8wDzkSu > X-Mailer: Mutt 0.89.1i > Status: RO > Content-Length: 5456 > Lines: 156 > > > --WIyZ46R2i8wDzkSu > Content-Type: text/plain; charset=us-ascii > > > -- > Daniel Eisenbud > eisenbud@cs.swarthmore.edu > > --WIyZ46R2i8wDzkSu > Content-Type: message/rfc822 > Content-Description: Forwarded message from Daniel Eisenbud > > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA08862; > Sun, 1 Feb 1998 17:09:17 -0500 (EST) > Message-ID: <19980201170917.47178@cs.swarthmore.edu> > Date: Sun, 1 Feb 1998 17:09:17 -0500 > From: Daniel Eisenbud > To: Daniel Eisenbud > Subject: test > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename=mutt-allspice-8883-5 > > > -- > Daniel Eisenbud > eisenbud@cs.swarthmore.edu > > **** Purify instrumented mutt (pid 7827 at Sun Feb 1 16:46:09 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * For TTY output, use the option "-windows=no" > * Command-line: mutt -a patch-0.89.1i.de.mail_followup_to-leak.1 mutt-users > * Options settings: -purify \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 7827) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 7827) **** > Purify: Searching for all memory leaks... > > Memory leaked: 90 bytes (0.116%); potentially leaked: 0 bytes (0%) > > MLK: 32 bytes leaked in 2 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > * Block of 16 bytes (2 times); last block at 0x16ab78 > > MLK: 20 bytes leaked at 0x16a1f0 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > rfc822_cpy_adr [rfc822.c:576] > rfc822_append [send.c:456] > mutt_set_followup_to [send.c:775] > > MLK: 16 bytes leaked at 0x163c58 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > rfc2047_encode_adrlist [rfc2047.c:201] > mutt_send_message [sendlib.c:1210] > ci_send_message [send.c:1161] > > MLK: 11 bytes leaked at 0x17b5a8 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > rfc822_cpy_adr [rfc822.c:579] > rfc822_append [send.c:456] > mutt_set_followup_to [send.c:775] > > MLK: 11 bytes leaked at 0x17b610 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > rfc822_cpy_adr [rfc822.c:581] > rfc822_append [send.c:456] > mutt_set_followup_to [send.c:775] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 6 90 > Potentially Leaked 0 0 > In-Use 1551 77519 > ---------------------------------------- > Total Allocated 1557 77609 > > **** Purify instrumented mutt (pid 7827) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 90 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 894828 code > 270652 data/bss > 417792 heap (peak use) > 2992 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > > --WIyZ46R2i8wDzkSu-- > > > From eisenbud Sun Feb 1 17:16:17 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA09193 > for eisenbud; Sun, 1 Feb 1998 17:16:17 -0500 (EST) > Date: Sun, 1 Feb 1998 17:16:17 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012216.RAA09193@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 8305 > Lines: 234 > > **** Purify instrumented mutt (pid 8883 at Sun Feb 1 17:09:19 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -Z > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 8883) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 8883) **** > Purify: Searching for all memory leaks... > > Memory leaked: 355 bytes (0.456%); potentially leaked: 0 bytes (0%) > > MLK: 68 bytes leaked at 0x514fa8 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > mutt_parse_messageRFC822 [parse.c:451] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 60 bytes leaked in 3 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > parse_address [rfc822.c:200] > rfc822_parse_adrlist [rfc822.c:334] > _mutt_read_rfc822_header [parse.c:1133] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > * Block of 20 bytes (3 times); last block at 0x4d65e0 > > MLK: 52 bytes leaked at 0x4fa280 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > _mutt_read_rfc822_header [parse.c:870] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 41 bytes leaked at 0x5149a8 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > extract_message_id [parse.c:810] > _mutt_read_rfc822_header [parse.c:1041] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > MLK: 38 bytes leaked in 3 blocks > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > parse_mailbox [rfc822.c:132] > parse_addrspec [rfc822.c:193] > parse_address [rfc822.c:264] > rfc822_parse_adrlist [rfc822.c:334] > _mutt_read_rfc822_header [parse.c:1133] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > * Block of 18 bytes (2 times); last block at 0x4d6700 > * Block of 2 bytes at 0x4d5438 > > MLK: 32 bytes leaked in 2 blocks > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > parse_address [rfc822.c:258] > rfc822_parse_adrlist [rfc822.c:334] > _mutt_read_rfc822_header [parse.c:1133] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > * Block of 16 bytes (2 times); last block at 0x5148b0 > > MLK: 32 bytes leaked in 2 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > * Block of 16 bytes (2 times); last block at 0x4f97e8 > > MLK: 27 bytes leaked in 3 blocks > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > parse_mailbox [rfc822.c:134] > parse_addrspec [rfc822.c:193] > parse_address [rfc822.c:264] > rfc822_parse_adrlist [rfc822.c:334] > _mutt_read_rfc822_header [parse.c:1133] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > * Block of 9 bytes (3 times); last block at 0x4f9520 > > MLK: 5 bytes leaked at 0x4e23f0 > * This memory was allocated from: > malloc [rtlib.o] > safe_malloc [lib.c:273] > safe_strdup [lib.c:330] > _mutt_read_rfc822_header [parse.c:1096] > mutt_parse_messageRFC822 [parse.c:453] > mutt_message_to_7bit [sendlib.c:675] > make_forward [send.c:440] > generate_body [send.c:703] > ci_send_message [send.c:953] > mutt_pager [pager.c:2107] > mutt_display_message [commands.c:184] > mutt_index_menu [curs_main.c:766] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 17 355 > Potentially Leaked 0 0 > In-Use 1559 77552 > ---------------------------------------- > Total Allocated 1576 77907 > > **** Purify instrumented mutt (pid 8883) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 355 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 4186112 heap (peak use) > 2928 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 17:40:59 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA10575 > for eisenbud; Sun, 1 Feb 1998 17:40:59 -0500 (EST) > Date: Sun, 1 Feb 1998 17:40:59 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012240.RAA10575@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 3628 > Lines: 86 > > **** Purify instrumented mutt (pid 10563 at Sun Feb 1 17:40:53 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt eisenbud > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 10563) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 10563) **** > Purify: Searching for all memory leaks... > > Memory leaked: 16 bytes (0.0217%); potentially leaked: 0 bytes (0%) > > MLK: 16 bytes leaked at 0x167ad0 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > main [main.c:555] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 1 16 > Potentially Leaked 0 0 > In-Use 1563 73838 > ---------------------------------------- > Total Allocated 1564 73854 > > **** Purify instrumented mutt (pid 10563) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 16 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 458752 heap (peak use) > 2952 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 18:16:20 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id SAA13458 > for eisenbud; Sun, 1 Feb 1998 18:16:20 -0500 (EST) > Date: Sun, 1 Feb 1998 18:16:20 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012316.SAA13458@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 5802 > Lines: 161 > > **** Purify instrumented mutt (pid 10776 at Sun Feb 1 17:44:33 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 10776) **** > Current file descriptors in use: 9 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 10776) **** > Purify: Searching for all memory leaks... > > Memory leaked: 588 bytes (0.746%); potentially leaked: 84 bytes (0.107%) > > MLK: 252 bytes leaked in 3 blocks > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > * Block of 84 bytes (3 times); last block at 0x5006a0 > > MLK: 84 bytes leaked at 0x4cdd60 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > MLK: 84 bytes leaked at 0x4f4290 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regatom [regcomp.c] > regpiece [regcomp.c] > regbranch [regcomp.c] > reg [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > MLK: 84 bytes leaked at 0x4c4f98 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > MLK: 84 bytes leaked at 0x4c2e20 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > PLK: 84 bytes potentially leaked at 0x4cdef8 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 7 588 > Potentially Leaked 1 84 > In-Use 1562 78104 > ---------------------------------------- > Total Allocated 1570 78776 > > **** Purify instrumented mutt (pid 10776) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 588 bytes leaked. > * 84 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 4186112 heap (peak use) > 2920 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 18:17:41 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id SAA15493 > for eisenbud; Sun, 1 Feb 1998 18:17:41 -0500 (EST) > Date: Sun, 1 Feb 1998 18:17:41 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802012317.SAA15493@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 1 error (1 total occurrence) in mutt > Status: RO > Content-Length: 4396 > Lines: 108 > > **** Purify instrumented mutt (pid 10540 at Sun Feb 1 17:40:38 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -Z > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 10540) **** > SIG: Signal handled: > * This is occurring while in: > _p918static [crtn.o] > sighandler [signal.c:56] > sigacthandler [sigaction.c] > pure_signal_handler_wrapper [rtlib.o] > pure_sigtramp [rtlib.o] > _p_wrap_leaf_syscall_v9 [crtn.o] > poll [libc.so.1] > select [libc.so.1] > SLsys_input_pending [libslang.a] > SLang_input_pending [libslang.a] > SLcurses_wgetch [libslang.a] > SLcurses_getch [libslang.a] > mutt_getch [curs_lib.c:56] > mutt_index_menu [curs_main.c:339] > main [main.c:609] > * Received signal 1 (SIGHUP - Hangup) > * Signal mask: (SIGHUP | SIGTSTP) > * Pending signals: (SIGCONT) > > **** Purify instrumented mutt (pid 10540) **** > Current file descriptors in use: 10 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 5: > FIU: file descriptor 6: > FIU: file descriptor 7: "/export/home/staff/eisenbud/Mail/mutt", O_RDONLY > * File info: -rw------- 1 eisenbud other 8017831 Feb 1 17:52 > * File position: 8016214 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _endopen [fopen.c] > fopen [libc.so.1] > mbox_open_mailbox [mbox.c:453] > mx_open_mailbox [mx.c:601] > mutt_index_menu [curs_main.c:733] > main [main.c:609] > _start [crt1.o] > FIU: file descriptor 8: > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 10540) **** > Purify: Searching for all memory leaks... > > Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%) > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 0 0 > Potentially Leaked 1 8200 > In-Use 71199 1564863 > ---------------------------------------- > Total Allocated 71200 1573063 > > **** Purify instrumented mutt (pid 10540) **** > * Program exited with status code 0. > * 1 access error, 1 total occurrence. > * 0 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 10846208 heap (peak use) > 15984 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > > From eisenbud Sun Feb 1 19:07:36 1998 > Return-Path: > Received: (from eisenbud@localhost) > by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id TAA18256 > for eisenbud; Sun, 1 Feb 1998 19:07:36 -0500 (EST) > Date: Sun, 1 Feb 1998 19:07:36 -0500 (EST) > From: Daniel Eisenbud > Message-Id: <199802020007.TAA18256@allspice.cs.swarthmore.edu> > To: eisenbud > Subject: Purify: 0 errors (0 total occurrences) in mutt > Status: RO > Content-Length: 5743 > Lines: 160 > > **** Purify instrumented mutt (pid 18172 at Sun Feb 1 19:01:29 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt -Z > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 18172) **** > Current file descriptors in use: 6 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 18172) **** > Purify: Searching for all memory leaks... > > Memory leaked: 852 bytes (1.53%); potentially leaked: 84 bytes (0.151%) > > MLK: 420 bytes leaked in 5 blocks > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > * Block of 84 bytes (5 times); last block at 0x4fc8d0 > > MLK: 252 bytes leaked in 3 blocks > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > * Block of 84 bytes (3 times); last block at 0x520fe0 > > MLK: 84 bytes leaked at 0x4d6638 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > MLK: 84 bytes leaked at 0x158100 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regnode [regcomp.c] > regatom [regcomp.c] > regpiece [regcomp.c] > regbranch [regcomp.c] > reg [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > MLK: 12 bytes leaked at 0x4f83a0 > * This memory was allocated from: > malloc [rtlib.o] > realloc [rtlib.o] > regbranch [regcomp.c] > reg [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > PLK: 84 bytes potentially leaked at 0x159628 > * This memory was allocated from: > malloc [rtlib.o] > regblock [regcomp.c] > regwcomp [libc.so.1] > regcomp [libc.so.1] > eat_regexp [pattern.c:221] > mutt_pattern_comp [pattern.c:510] > mutt_pattern_func [pattern.c:711] > mutt_index_menu [curs_main.c:534] > main [main.c:609] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 11 852 > Potentially Leaked 1 84 > In-Use 1435 54709 > ---------------------------------------- > Total Allocated 1447 55645 > > **** Purify instrumented mutt (pid 18172) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 852 bytes leaked. > * 84 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 10936320 heap (peak use) > 2704 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > > On Sun, Feb 01, 1998 at 08:18:09PM -0500, Daniel Eisenbud wrote: > **** Purify instrumented mutt (pid 20443 at Sun Feb 1 20:11:16 1998) > * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. > * For contact information type: "purify -help" > * Command-line: mutt mutt-u > * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ > -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 > * Purify licensed to Purify Evaluation User > * Purify checking enabled. > > **** Purify instrumented mutt (pid 20443) **** > Current file descriptors in use: 6 > FIU: file descriptor 0: > FIU: file descriptor 1: > FIU: file descriptor 2: > FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY > * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 > * This file descriptor was allocated from: > _libc_open [libc.so.1] > _nsc_trydoorcall [libc.so.1] > getpwuid_r [libc.so.1] > mutt_init [init.c:1211] > main [main.c:437] > _start [crt1.o] > FIU: file descriptor 26: > FIU: file descriptor 27: > > **** Purify instrumented mutt (pid 20443) **** > Purify: Searching for all memory leaks... > > Memory leaked: 80 bytes (0.165%); potentially leaked: 0 bytes (0%) > > MLK: 64 bytes leaked in 4 blocks > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > mutt_send_menu [compose.c:479] > ci_send_message [send.c:1073] > main [main.c:555] > _start [crt1.o] > * Block of 16 bytes (4 times); last block at 0x176530 > > MLK: 16 bytes leaked at 0x15c858 > * This memory was allocated from: > malloc [rtlib.o] > calloc [rtlib.o] > safe_calloc [lib.c:258] > gen_attach_list [recvattach.c:56] > mutt_gen_attach_list [recvattach.c:134] > mutt_send_menu [compose.c:309] > ci_send_message [send.c:1073] > main [main.c:555] > _start [crt1.o] > > Purify Heap Analysis (combining suppressed and unsuppressed blocks) > Blocks Bytes > Leaked 5 80 > Potentially Leaked 0 0 > In-Use 1411 48268 > ---------------------------------------- > Total Allocated 1416 48348 > > **** Purify instrumented mutt (pid 20443) **** > * Program exited with status code 0. > * 0 access errors, 0 total occurrences. > * 80 bytes leaked. > * 0 bytes potentially leaked. > * Basic memory usage (including Purify overhead): > 898708 code > 273020 data/bss > 655360 heap (peak use) > 2704 stack > * Shared library memory usage (including Purify overhead): > 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) > 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) > 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) > 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) > 135737 libm.so.1_pure_p3_c0_410_551 (shared code) > 5872 libm.so.1_pure_p3_c0_410_551 (private data) > 802097 libc.so.1_pure_p3_c0_410_551 (shared code) > 34804 libc.so.1_pure_p3_c0_410_551 (private data) > 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) > 0 libdl.so.1_pure_p3_c0_410_551 (private data) > 9576 libinternal_stubs.so.1 (shared code) > 324 libinternal_stubs.so.1 (private data) > 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) > 1300 libintl.so.1_pure_p3_c0_410_551 (private data) > 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) > 828 libmp.so.1_pure_p3_c0_410_551 (private data) > 37933 libw.so.1_pure_p3_c0_410_551 (shared code) > 1628 libw.so.1_pure_p3_c0_410_551 (private data) > 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) > 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) > -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From eisenbud@allspice.cs.swarthmore.edu Sun Feb 1 18:42:30 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id SAA04873 for ; Sun, 1 Feb 1998 18:42:26 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id VAA22838; Sun, 1 Feb 1998 21:42:25 -0500 (EST) Message-ID: <19980201214225.43377@cs.swarthmore.edu> Date: Sun, 1 Feb 1998 21:42:25 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.89.1i] purify output: evidence of several more (mostly minor) memory leaks Mail-Followup-To: Mutt Development List References: <19980201191943.62609@cs.swarthmore.edu> <19980201202106.52912@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980201202106.52912@cs.swarthmore.edu>; from Daniel Eisenbud on Sun, Feb 01, 1998 at 08:21:06PM -0500 Content-Length: 660 Lines: 15 On Sun, Feb 01, 1998 at 08:21:06PM -0500, Daniel Eisenbud wrote: > The purify output below includes a new leak I hadn't seen before. It > occurred when sending a message with a lot of gzipped attachments. Oops, sorry for the huge message, especially for those of you on slow connections! I tag-replied to two messages, and forgot that mutt would gunzip and include the first one. Duh... In any case, it was the very last purify output in the message that was new, the one starting with the heading: **** Purify instrumented mutt (pid 20443 at Sun Feb 1 20:11:16 1998) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From eisenbud@allspice.cs.swarthmore.edu Mon Feb 2 00:28:19 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id AAA09728 for ; Mon, 2 Feb 1998 00:28:16 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id DAA29168; Mon, 2 Feb 1998 03:24:49 -0500 (EST) Message-ID: <19980202032448.38945@cs.swarthmore.edu> Date: Mon, 2 Feb 1998 03:24:48 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.89*] bugfix: memory leak in send menu Mail-Followup-To: Mutt Development List References: <19980201165238.15881@cs.swarthmore.edu> <19980201213444.19525@cs.swarthmore.edu> <19980202010122.31159@cs.swarthmore.edu> <19980202012851.09614@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980202012851.09614@cs.swarthmore.edu>; from Daniel Eisenbud on Mon, Feb 02, 1998 at 01:28:51AM -0500 Content-Length: 347 Lines: 11 I think I caught most or at least many of the non-pgp-related leaks in 0.89.1i (not that there necessarily are any pgp-related leaks, just that I didn't really look.) Michael, your hash table patch leaks hash tables from mx_open_mailbox at the moment. OK, enough debugging for me for now. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From olsenc@ichips.intel.com Mon Feb 2 00:47:42 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id AAA15145 for ; Mon, 2 Feb 1998 00:47:40 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id AAA13801 for ; Mon, 2 Feb 1998 00:50:55 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id AAA27874 for ; Mon, 2 Feb 1998 00:47:25 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id AAA26099; Mon, 2 Feb 1998 00:47:24 -0800 (PST) Message-ID: <19980202004724.09860@dtthp169.jf.intel.com> Date: Mon, 2 Feb 1998 00:47:24 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.89.1i] feature/bugfix: better mailx ~r compatibility Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=8t9RHnE3ZwKMSgU+ X-Mailer: Mutt 0.89.1i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! Content-Length: 1984 Lines: 77 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii I use mailx mode a lot (mutt -x) to send quick notes. I noticed when interpolating a file (~r file) that it wouldn't tell you anything regarding the success or failure of such an operation. The following patch attempts to fix that. It's doesn't match mailx behavior exactly, but I think it is adequate, certainly moreso than nothing at all :) -Clint --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.89.1i.co.mailx.1 --- edit.c.orig Sun Feb 1 23:15:14 1998 +++ edit.c Mon Feb 2 00:44:46 1998 @@ -85,17 +85,28 @@ } static char ** -be_snarf_file (const char *path, char **buf, int *max, int *len) +be_snarf_file (const char *path, char **buf, int *max, int *len, int verbose) { FILE *f; + char tmp[LONG_STRING]; struct stat sb; if ((f = fopen (path, "r"))) { fstat (fileno (f), &sb); buf = be_snarf_data (f, buf, max, len, 0, sb.st_size, 0); + if (verbose) + { + snprintf(tmp, sizeof(tmp), "\"%s\" %d bytes\n", path, sb.st_size); + addstr(tmp); + } fclose (f); } + else + { + snprintf(tmp, sizeof(tmp), "%s: %s\n", path, strerror(errno)); + addstr(tmp); + } return (buf); } @@ -298,7 +309,7 @@ addstr ("(End message with a . on a line by itself)\n"); - buf = be_snarf_file (path, buf, &bufmax, &buflen); + buf = be_snarf_file (path, buf, &bufmax, &buflen, 0); tmp[0] = 0; while (!done) @@ -369,7 +380,7 @@ break; case 'r': if (*p) - buf = be_snarf_file (p, buf, &bufmax, &buflen); + buf = be_snarf_file (p, buf, &bufmax, &buflen, 1); else addstr ("missing filename.\n"); break; @@ -408,7 +419,7 @@ else mutt_edit_file (Visual, path); - buf = be_snarf_file (path, buf, &bufmax, &buflen); + buf = be_snarf_file (path, buf, &bufmax, &buflen, 0); addstr ("(continue)\n"); } --8t9RHnE3ZwKMSgU+-- From reptile@pooh.cs.net.pl Mon Feb 2 04:53:45 1998 Return-Path: reptile@pooh.cs.net.pl Received: from pooh.cs.net.pl (qmailr@pooh.cs.net.pl [195.117.250.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id EAA17312 for ; Mon, 2 Feb 1998 04:53:42 -0800 (PST) Received: (qmail 1438 invoked by uid 501); 2 Feb 1998 12:55:25 -0000 Message-ID: <19980202135521.21791@pdi.net> Date: Mon, 2 Feb 1998 13:55:21 +0100 From: "Robert Richard George 'reptile' Wal" To: MUTT-D Subject: [0.89i] Bugfix(?): too short buffer for backticks. Mail-Followup-To: MUTT-D Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=G4iJoqBmSsgzjUCe X-Mailer: Mutt 0.89i Organization: Me? Organized? Get real :) X-URL: http://pooh.cs.net.pl (Eternally under construction) X-IRC-Nick: Gadzinka@iRCnET.iRC.nETWORK (Gadzinka -- tiny little reptile) X-Phone: +48(0)42 593453 X-PGP-Fingerprint: 37E1D55F 29793C0C B8D39D01 61FC50CE X-PGP-Key: finger reptile@gryzmak.lodz.pdi.net X-Motto: Fact that you're paranoid doesn't imply that THEY don't follow you. X-Disclaimer: I don't answer mail or news articles below some arbitrary mark. X-Favourites: women, cats, Amiga, Linux, TeX, vim, music, sci-fi, poetry. X-Mount-Entry: mount -t human /dev/reptile /earth/europe/poland/warsaw Content-Length: 2982 Lines: 70 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Hi. I've discovered lately one small problem with the length of buffer in wich Mutt receives output from commands placed in backticks (``). I've got dynamic setting of mailbox list because I'm subscribed to a lot of mailing lists and also use mail2news&news2mail gateways. I decided to make it this way, since I was tired of changing it everytime in two places (.procmailrc and .muttrc). It looks like this now: mailboxes `echo ! ~/.mail/IN_*` The list of my inboxes looks like this: -rw------- 1 reptile reptile 0 Feb 2 03:20 IN_bugtraq -rw------- 1 reptile reptile 0 Jan 31 04:02 IN_comp.os.linux.announce -rw------- 1 reptile reptile 17352 Feb 2 13:05 IN_corewars -rw------- 1 reptile reptile 0 Jan 30 14:09 IN_cs-info -rw------- 1 reptile reptile 0 Jan 30 04:36 IN_gg -rw------- 1 reptile reptile 0 Feb 2 12:44 IN_gust -rw------- 1 reptile reptile 269714 Feb 2 13:08 IN_mutt -rw------- 1 reptile reptile 1337 Feb 2 13:40 IN_pl.comp.lang.perl -rw------- 1 reptile reptile 0 Jan 31 22:17 IN_pl.comp.mail.mta -rw------- 1 reptile reptile 721069 Feb 2 13:44 IN_pl.comp.os.linux -rw------- 1 reptile reptile 478981 Feb 2 13:43 IN_pl.listserv.sf-f -rw------- 1 reptile reptile 6011 Feb 1 00:49 IN_pl.rec.humor.najlepsze -rw------- 1 reptile reptile 46268 Feb 2 13:42 IN_pl.rec.zwierzaki -rw------- 1 reptile reptile 108943 Feb 2 13:44 IN_pl.soc.seks -rw------- 1 reptile reptile 41697 Feb 2 13:44 IN_pl.soc.seks.towarzyskie -rw------- 1 reptile reptile 0 Jan 25 01:02 IN_root -rw------- 1 reptile reptile 0 Jan 30 06:54 IN_virtunix -rw------- 1 reptile reptile 20992 Dec 30 04:09 alia.gz -rw------- 1 reptile reptile 47999 Dec 30 13:51 amiga.gz -rw------- 1 reptile reptile 53691 Dec 30 04:09 anya.gz -rw------- 1 reptile reptile 16438 Dec 30 04:09 aqqa.gz -rw------- 1 reptile reptile 7836 Jan 22 14:39 archived-news.gz Right after doing this I've found out, that tail of the line from echo output was eaten. Attached is the patch which changes buffer length to HUGE_STRING. Reptile -- mailto:reptile@pdi.net :) Women are more complicated than PC... :( Look into my headers and you'll see who I am. :) --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.89.r.buf.1" diff -4u mutt-0.89i/init.c mutt-0.89i-buf/init.c --- mutt-0.89i/init.c Fri Jan 30 21:16:13 1998 +++ mutt-0.89i-buf/init.c Sat Jan 31 19:44:05 1998 @@ -413,9 +413,9 @@ char *expn, size_t expnlen,/* buf for backtic expn */ int flags) /* parser flags */ { char qc = 0; /* quote char */ - char buf[STRING]; + char buf[HUGE_STRING]; char *pc; const char *ps; size_t len; --G4iJoqBmSsgzjUCe-- From byrial@post3.tele.dk Mon Feb 2 09:10:01 1998 Return-Path: byrial@post3.tele.dk Received: from mail-in2.inet.tele.dk (mail-in2.inet.tele.dk [194.182.148.151]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id JAA23135 for ; Mon, 2 Feb 1998 09:09:54 -0800 (PST) Received: (qmail 17269 invoked from network); 2 Feb 1998 16:56:24 -0000 Received: from post3.tele.dk (194.239.134.166) by mail-in2.inet.tele.dk with SMTP; 2 Feb 1998 16:56:24 -0000 Received: from ask.ask ([194.239.129.90]) by post3.tele.dk (Netscape Mail Server v2.02) with ESMTP id AAA18752 for ; Mon, 2 Feb 1998 17:56:19 +0100 Received: (qmail 942 invoked by uid 500); 2 Feb 1998 16:52:23 -0000 Message-ID: <19980202175222.22196@ask.tele.dk> Date: Mon, 2 Feb 1998 17:52:22 +0100 From: Byrial Jensen To: mutt-dev@cs.hmc.edu Cc: Byrial Jensen Subject: [0.89.1i] Patch: pager_redraw_cleanup Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=WIyZ46R2i8wDzkSu X-Mailer: Mutt 0.89.1i Content-Length: 5796 Lines: 212 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii The internal pager will update the current index linie and the index status linie if $pager_index_lines is set, every time the showed message is scrolled or otherwise redrawn. This is unnecessary, and the attached patch will only update the index shown in the pager when necessary: i.e. if some flags are changed. It also moves the %-counter at the right end of pager status linie one character to the right, so that the linie can be one character longer. It used to end with 1 space or 2 when the percentage was under 10. Now it ends with 0 or 1 space. Best regards - Byrial --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.89.1i.bj.pager-redraw-clenaup.1" --- mutt_menu.h.org Mon Jan 26 20:56:07 1998 +++ mutt_menu.h Mon Feb 2 14:33:33 1998 @@ -29,6 +29,7 @@ #define REDRAW_CURRENT (1<<3) #define REDRAW_STATUS (1<<4) #define REDRAW_FULL (1<<5) +#define REDRAW_BODY (1<<6) typedef struct menu_t { --- pager.c.org Mon Feb 2 17:00:33 1998 +++ pager.c Mon Feb 2 17:16:14 1998 @@ -1399,14 +1399,11 @@ menu_redraw_index(index); } - redraw &= ~REDRAW_FULL; - redraw |= REDRAW_INDEX | REDRAW_STATUS; + redraw |= REDRAW_BODY | REDRAW_INDEX | REDRAW_STATUS; mutt_show_error (); } - /* REDRAW_INDEX does NOT refer to the pager index. We use it - to redraw the body, because we don't have a REDRAW_BODY */ - if ((redraw & REDRAW_INDEX) || topline != oldtopline) + if ((redraw & REDRAW_BODY) || topline != oldtopline) { do { move (bodyoffset, 0); @@ -1435,19 +1432,14 @@ addch ('\n'); lines++; } - BKGDSET (MT_COLOR_NORMAL); + /* We are going to update the pager status bar, so it isn't + * necessary to reset to normal color now. */ - redraw &= ~REDRAW_INDEX; redraw |= REDRAW_STATUS; /* need to update the % seen */ } if (redraw & REDRAW_STATUS) { - /* redraw the pager_index indicator, because the - * flags for this message might have changed. */ - if (PagerIndexLines && index) - menu_redraw_current (index); - /* print out the pager status bar */ SETCOLOR (MT_COLOR_STATUS); BKGDSET (MT_COLOR_STATUS); @@ -1455,27 +1447,34 @@ if (hdr) { mutt_make_string (buffer, - COLS-9 < sizeof (buffer) ? COLS-9 : sizeof (buffer), + COLS-8 < sizeof (buffer) ? COLS-8 : sizeof (buffer), PagerFmt, hdr); } - printw ("%-*.*s -- (", COLS-10, COLS-10, hdr ? buffer : banner); + printw ("%-*.*s -- (", COLS-9, COLS-9, hdr ? buffer : banner); if (last_pos < sb.st_size - 1) printw ("%d%%)", (int) (100 * last_offset / sb.st_size)); else addstr (topline == 0 ? "all)" : "end)"); - - /* print out the index status bar */ - if (hdr && PagerIndexLines) - { - mutt_status_line (buffer, sizeof(buffer), Status); - CLEARLINE (indexoffset + (option(OPTSTATUSONTOP) ? 0 : (indexlen - 1))); - printw ("%-*.*s", COLS, COLS, buffer); - } BKGDSET (MT_COLOR_NORMAL); SETCOLOR (MT_COLOR_NORMAL); - redraw &= ~REDRAW_STATUS; } + if ((redraw & REDRAW_INDEX) && index) + { + /* redraw the pager_index indicator, because the + * flags for this message might have changed. */ + menu_redraw_current (index); + + /* print out the index status bar */ + mutt_status_line (buffer, sizeof(buffer), Status); + move (indexoffset + (option(OPTSTATUSONTOP) ? 0 : (indexlen - 1)), 0); + SETCOLOR (MT_COLOR_STATUS); + printw ("%-*.*s", COLS, COLS, buffer); + SETCOLOR (MT_COLOR_NORMAL); + } + + redraw = 0; + move (statusoffset, COLS-1); mutt_refresh (); ch = km_dokey (MENU_PAGER); @@ -1739,14 +1738,14 @@ else SearchFlag = M_SEARCH; } - redraw = REDRAW_INDEX; + redraw = REDRAW_BODY; break; case OP_SEARCH_TOGGLE: if (SearchCompiled) { SearchFlag ^= M_SEARCH; - redraw = REDRAW_INDEX; + redraw = REDRAW_BODY; } break; @@ -1819,7 +1818,7 @@ CHECK_MODE; CHECK_READONLY; mutt_set_flag (Context, hdr, M_DELETE, 1); - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; if (option (OPTRESOLVE)) { ch = -1; @@ -1847,7 +1846,7 @@ if (!option (OPTRESOLVE) && PagerIndexLines) redraw = REDRAW_FULL; else - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; } break; @@ -1938,7 +1937,7 @@ CHECK_MODE; CHECK_READONLY; mutt_set_flag (Context, hdr, M_FLAG, !hdr->flagged); - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; if (option (OPTRESOLVE)) { ch = -1; @@ -2011,7 +2010,7 @@ rc = OP_MAIN_NEXT_UNDELETED; } else - redraw |= REDRAW_STATUS; + redraw |= REDRAW_STATUS | REDRAW_INDEX; } MAYBE_REDRAW (redraw); break; @@ -2024,7 +2023,7 @@ case OP_TAG: CHECK_MODE; mutt_set_flag (Context, hdr, M_TAG, !hdr->tagged); - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; if (option (OPTRESOLVE)) { ch = -1; @@ -2041,7 +2040,7 @@ mutt_set_flag (Context, hdr, M_READ, 1); first = 0; Context->msgnotreadyet = -1; - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; if (option (OPTRESOLVE)) { ch = -1; @@ -2053,7 +2052,7 @@ CHECK_MODE; CHECK_READONLY; mutt_set_flag (Context, hdr, M_DELETE, 0); - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; if (option (OPTRESOLVE)) { ch = -1; @@ -2081,7 +2080,7 @@ if (!option (OPTRESOLVE) && PagerIndexLines) redraw = REDRAW_FULL; else - redraw = REDRAW_STATUS; + redraw = REDRAW_STATUS | REDRAW_INDEX; } break; --WIyZ46R2i8wDzkSu-- From mutt-dev@FreeBSD.csie.NCTU.edu.tw Mon Feb 2 10:08:16 1998 Return-Path: mutt-dev@FreeBSD.csie.NCTU.edu.tw Received: from FreeBSD.csie.NCTU.edu.tw (mutt-dev@freebsd.csie.nctu.edu.tw [140.113.235.250]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id KAA10393 for ; Mon, 2 Feb 1998 10:08:09 -0800 (PST) Received: (from mutt-dev@localhost) by FreeBSD.csie.NCTU.edu.tw (8.8.8/8.8.5) id CAA14525 for mutt-dev@cs.hmc.edu; Tue, 3 Feb 1998 02:08:05 +0800 (CST) Date: Tue, 3 Feb 1998 02:08:05 +0800 (CST) From: Mailing List Register Message-Id: <199802021808.CAA14525@FreeBSD.csie.NCTU.edu.tw> To: mutt-dev@cs.hmc.edu Subject: subscribe Content-Length: 10 Lines: 1 subscribe From olsenc@ichips.intel.com Mon Feb 2 11:26:57 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id LAA02731 for ; Mon, 2 Feb 1998 11:26:56 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id LAA09562 for ; Mon, 2 Feb 1998 11:30:29 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id LAA02341 for ; Mon, 2 Feb 1998 11:26:55 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id LAA29753; Mon, 2 Feb 1998 11:26:55 -0800 (PST) Message-ID: <19980202112654.22789@dtthp169.jf.intel.com> Date: Mon, 2 Feb 1998 11:26:54 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.89.1i] core dump forwarding email Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! This is with the new_addr patch applied, so I think we have an rfc822 parsing problem. It's interesting that there's no commas between the addresses in frame #4. -Clint Houston, we have a problem: #0 0x344e0 in rfc822_parse_adrlist (top=0x7b03cadd, s=0x200
) at rfc822.c:460 460 phrase[phraselen++] = ' '; (gdb) where #0 0x344e0 in rfc822_parse_adrlist (top=0x7b03cadd, s=0x200
) at rfc822.c:460 #1 0x2f3b8 in mutt_parse_adrlist (p=0x7b03cadd, s=0x200
) at parse.c:1290 #2 0x36d68 in edit_envelope (en=0x7b03cadd) at send.c:222 #3 0x380c0 in ci_send_message (flags=2063846109, msg=0x200, tempfile=0x20000082
, cur=0x73) at send.c:903 #4 0x2c7b8 in mutt_pager ( banner=0x7b03cadd "sankar (Tony Orlando)hwilson (V-dub Man)gregz@fathom.comjhewitt@isdl.ee.washington.edujhp@cypress.comjyoung@imedia.comkint@engr.washington.edupwarren@uascwa.comrobf@asymetrix.comspencer@hom.netstuartm"..., fname=0x200
, hdr=0x20000082, do_color=115) at pager.c:1993 #5 0xd678 in mutt_display_message (cur=0x7b03cadd) at commands.c:184 #6 0x13abc in mutt_index_menu () at curs_main.c:766 #7 0x22f04 in main (argc=2063846109, argv=0x200) at main.c:611 From eisenbud@allspice.cs.swarthmore.edu Mon Feb 2 11:45:45 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id LAA07826 for ; Mon, 2 Feb 1998 11:45:29 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id OAA10245; Mon, 2 Feb 1998 14:45:13 -0500 (EST) Message-ID: <19980202144513.05425@cs.swarthmore.edu> Date: Mon, 2 Feb 1998 14:45:13 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Thread_hash bug: Fwd: [eisenbud: Purify: 6 errors (18 total occurrences) in mutt] Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=7AUc2qLy4jB3hD7Z X-Mailer: Mutt 0.89.1i --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii After installing the thread_hash patch, I started to get some scary purify warnings like this, and mutt misthreaded my mailbox. It isn't totally clear from the purify warnings that it's thread-related, but I'm pretty close to positive that it is, since mutt badly misthreaded the mailbox when this happened (some messages showed up twice, with their numbers out of order one of the times: I've had the same thing happen in some of my experiments with threading.) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --7AUc2qLy4jB3hD7Z Content-Type: message/rfc822 Content-Description: Forwarded message from Daniel Eisenbud Return-Path: Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id OAA08899 for eisenbud; Mon, 2 Feb 1998 14:27:12 -0500 (EST) Date: Mon, 2 Feb 1998 14:27:12 -0500 (EST) From: Daniel Eisenbud Message-Id: <199802021927.OAA08899@allspice.cs.swarthmore.edu> To: eisenbud Subject: Purify: 6 errors (18 total occurrences) in mutt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mutt-allspice-8970-12 **** Purify instrumented mutt (pid 8830 at Mon Feb 2 14:25:29 1998) * Purify 4.1 Solaris 2, Copyright (C) 1992-1997 Rational Software Corp. All rights reserved. * For contact information type: "purify -help" * Command-line: mutt -Z * Options settings: -purify -mail-to-user=eisenbud -chain-length=15 \ -purify-home=/export/home/staff/eisenbud/pure/purify-4.1-solaris2 * Purify licensed to Purify Evaluation User * Purify checking enabled. **** Purify instrumented mutt (pid 8830) **** FMR: Free memory read: * This is occurring while in: mutt_free_envelope [lib.c:443] mutt_free_header [lib.c:128] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Reading 4 bytes from 0x68d238 in the heap. * Address 0x68d238 is 32 bytes into a freed block at 0x68d218 of 68 bytes. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 0 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** FMR: Free memory read: * This is occurring while in: mutt_free_body [lib.c:54] mutt_free_header [lib.c:129] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Reading 4 bytes from 0x68d23c in the heap. * Address 0x68d23c is 36 bytes into a freed block at 0x68d218 of 68 bytes. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 0 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** FMW: Free memory write: * This is occurring while in: mutt_free_body [lib.c:84] mutt_free_header [lib.c:129] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Writing 4 bytes to 0x68d23c in the heap. * Address 0x68d23c is 36 bytes into a freed block at 0x68d218 of 68 bytes. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 0 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** FMR: Free memory read: * This is occurring while in: safe_free [lib.c:316] mutt_free_header [lib.c:130] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Reading 4 bytes from 0x68d258 in the heap. * Address 0x68d258 is 64 bytes into a freed block at 0x68d218 of 68 bytes. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 0 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** FMR: Free memory read: * This is occurring while in: safe_free [lib.c:316] mutt_free_header [lib.c:131] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Reading 4 bytes from 0x68d240 in the heap. * Address 0x68d240 is 40 bytes into a freed block at 0x68d218 of 68 bytes. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 0 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** FUM: Freeing unallocated memory: * This is occurring while in: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] * Attempting to free block at 0x68d218 already freed. * This block was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * There have been 1 frees since this block was freed from: free [rtlib.o] safe_free [lib.c:318] mutt_free_header [lib.c:132] mx_fastclose_mailbox [mx.c:649] mx_close_mailbox [mx.c:819] mutt_index_menu [curs_main.c:556] main [main.c:609] _start [crt1.o] **** Purify instrumented mutt (pid 8830) **** Current file descriptors in use: 9 FIU: file descriptor 0: FIU: file descriptor 1: FIU: file descriptor 2: FIU: file descriptor 4: "/etc/.name_service_door", O_RDONLY * File info: ?r--r--r-- 1 root wheel 0 Aug 23 1996 * This file descriptor was allocated from: _libc_open [libc.so.1] _nsc_trydoorcall [libc.so.1] getpwuid_r [libc.so.1] mutt_init [init.c:1211] main [main.c:437] _start [crt1.o] FIU: file descriptor 5: FIU: file descriptor 6: FIU: file descriptor 8: FIU: file descriptor 26: FIU: file descriptor 27: **** Purify instrumented mutt (pid 8830) **** Purify: Searching for all memory leaks... Memory leaked: 7889 bytes (10.4%); potentially leaked: 0 bytes (0%) MLK: 1024 bytes leaked at 0x1d2670 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:588] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] MLK: 1024 bytes leaked at 0x1a5fe8 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:587] main [main.c:607] _start [crt1.o] MLK: 1024 bytes leaked at 0x1a6468 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:588] main [main.c:607] _start [crt1.o] MLK: 1024 bytes leaked at 0x1d1fc0 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:587] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] MLK: 1024 bytes leaked at 0x562c48 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:587] mutt_num_postponed [postpone.c:68] mutt_status_line [status.c:241] mutt_index_menu [curs_main.c:306] main [main.c:609] _start [crt1.o] MLK: 1024 bytes leaked at 0x563150 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] hash_create [hash.c:36] mx_open_mailbox [mx.c:588] mutt_num_postponed [postpone.c:68] mutt_status_line [status.c:241] mutt_index_menu [curs_main.c:306] main [main.c:609] _start [crt1.o] MLK: 233 bytes leaked in 6 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] mutt_parse_references [parse.c:136] mutt_read_rfc822_header [parse.c:1059] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 45 bytes (2 times); last block at 0x526658 * Block of 36 bytes (3 times); last block at 0x526530 * Block of 35 bytes at 0x526790 MLK: 204 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mbox_parse_mailbox [mbox.c:343] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 68 bytes (3 times); last block at 0x525908 MLK: 168 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] mutt_read_rfc822_header [parse.c:1089] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 56 bytes (3 times); last block at 0x5263f0 MLK: 156 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mutt_read_rfc822_header [parse.c:866] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 52 bytes (3 times); last block at 0x5259c8 MLK: 156 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] mutt_new_body [lib.c:36] mutt_read_rfc822_header [parse.c:876] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 52 bytes (3 times); last block at 0x525a78 MLK: 125 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] extract_message_id [parse.c:810] mutt_read_rfc822_header [parse.c:1035] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 45 bytes (2 times); last block at 0x558978 * Block of 35 bytes at 0x1f2fb0 MLK: 60 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] parse_address [rfc822.c:200] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1069] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 20 bytes (3 times); last block at 0x525c60 MLK: 60 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] parse_address [rfc822.c:200] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1002] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 20 bytes (3 times); last block at 0x558eb8 MLK: 60 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] parse_address [rfc822.c:200] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1126] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 20 bytes (3 times); last block at 0x5261c8 MLK: 57 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:134] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1069] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 19 bytes (3 times); last block at 0x525d78 MLK: 52 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:129] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1002] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 20 bytes (2 times); last block at 0x5260b0 * Block of 12 bytes at 0x559f58 MLK: 48 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_address [rfc822.c:258] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1002] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 16 bytes (3 times); last block at 0x526020 MLK: 48 bytes leaked in 6 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] mutt_parse_references [parse.c:135] mutt_read_rfc822_header [parse.c:1059] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 8 bytes (6 times); last block at 0x526708 MLK: 36 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] parse_parameters [parse.c:182] parse_content_type [parse.c:290] mutt_read_rfc822_header [parse.c:954] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 12 bytes (3 times); last block at 0x207290 MLK: 33 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:129] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1069] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 11 bytes (3 times); last block at 0x525cf0 MLK: 33 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_address [rfc822.c:258] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1126] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 11 bytes (3 times); last block at 0x526258 MLK: 33 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:129] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1126] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 11 bytes (3 times); last block at 0x5262e0 MLK: 33 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:134] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1126] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 11 bytes (3 times); last block at 0x526368 MLK: 28 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:134] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1002] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 16 bytes at 0x5185a0 * Block of 6 bytes (2 times); last block at 0x5558b0 MLK: 27 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_parameters [parse.c:221] parse_content_type [parse.c:290] mutt_read_rfc822_header [parse.c:954] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 9 bytes (3 times); last block at 0x5268b8 MLK: 24 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] parse_parameters [parse.c:184] parse_content_type [parse.c:290] mutt_read_rfc822_header [parse.c:954] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 8 bytes (3 times); last block at 0x526830 MLK: 20 bytes leaked at 0x518910 * This memory was allocated from: malloc [rtlib.o] calloc [rtlib.o] safe_calloc [lib.c:258] parse_address [rfc822.c:200] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1049] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] MLK: 18 bytes leaked in 3 blocks * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_content_type [parse.c:307] mutt_read_rfc822_header [parse.c:954] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] * Block of 6 bytes (3 times); last block at 0x526940 MLK: 11 bytes leaked at 0x5189a0 * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_address [rfc822.c:258] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1049] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] MLK: 11 bytes leaked at 0x518a28 * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:129] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1049] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] MLK: 11 bytes leaked at 0x518ab0 * This memory was allocated from: malloc [rtlib.o] safe_malloc [lib.c:273] safe_strdup [lib.c:330] parse_mailbox [rfc822.c:134] parse_addrspec [rfc822.c:193] parse_address [rfc822.c:264] rfc822_parse_adrlist [rfc822.c:334] mutt_read_rfc822_header [parse.c:1049] mbox_parse_mailbox [mbox.c:348] mbox_open_mailbox [mbox.c:466] mx_open_mailbox [mx.c:605] mutt_index_menu [curs_main.c:733] main [main.c:609] _start [crt1.o] Purify Heap Analysis (combining suppressed and unsuppressed blocks) Blocks Bytes Leaked 82 7889 Potentially Leaked 0 0 In-Use 1645 67995 ---------------------------------------- Total Allocated 1727 75884 **** Purify instrumented mutt (pid 8830) **** * Program exited with status code 0. * 6 access errors, 18 total occurrences. * 7889 bytes leaked. * 0 bytes potentially leaked. * Basic memory usage (including Purify overhead): 1191388 code 270852 data/bss 5455872 heap (peak use) 3008 stack * Shared library memory usage (including Purify overhead): 617046 libnsl.so.1_pure_p3_c0_410_551 (shared code) 65176 libnsl.so.1_pure_p3_c0_410_551 (private data) 75098 libsocket.so.1_pure_p3_c0_410_551 (shared code) 4092 libsocket.so.1_pure_p3_c0_410_551 (private data) 135737 libm.so.1_pure_p3_c0_410_551 (shared code) 5872 libm.so.1_pure_p3_c0_410_551 (private data) 802097 libc.so.1_pure_p3_c0_410_551 (shared code) 34804 libc.so.1_pure_p3_c0_410_551 (private data) 1216 libdl.so.1_pure_p3_c0_410_551 (shared code) 0 libdl.so.1_pure_p3_c0_410_551 (private data) 9576 libinternal_stubs.so.1 (shared code) 324 libinternal_stubs.so.1 (private data) 15161 libintl.so.1_pure_p3_c0_410_551 (shared code) 1300 libintl.so.1_pure_p3_c0_410_551 (private data) 16092 libmp.so.1_pure_p3_c0_410_551 (shared code) 828 libmp.so.1_pure_p3_c0_410_551 (private data) 37933 libw.so.1_pure_p3_c0_410_551 (shared code) 1628 libw.so.1_pure_p3_c0_410_551 (private data) 14008 libc_psr.so.1_pure_p3_c0_410_551 (shared code) 72 libc_psr.so.1_pure_p3_c0_410_551 (private data) --7AUc2qLy4jB3hD7Z-- From michael@tis.com Mon Feb 2 13:53:17 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA20492 for ; Mon, 2 Feb 1998 13:53:15 -0800 (PST) Received: by relay.la.tis.com; id OAA04883; Mon, 2 Feb 1998 14:04:18 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma004861; Mon, 2 Feb 98 14:03:51 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id NAA06434; Mon, 2 Feb 1998 13:50:12 -0800 (PST) Message-ID: <19980202135011.08325@la.tis.com> Date: Mon, 2 Feb 1998 13:50:11 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: Thread_hash bug: Fwd: [eisenbud: Purify: 6 errors (18 total occurrences) in mutt] Mail-Followup-To: Mutt Development List References: <19980202144513.05425@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980202144513.05425@cs.swarthmore.edu>; from Daniel Eisenbud on Mon, Feb 02, 1998 at 02:45:13PM -0500 On Mon, Feb 02, 1998 at 02:45:13PM -0500, Daniel Eisenbud wrote: > After installing the thread_hash patch, I started to get some scary > purify warnings like this, and mutt misthreaded my mailbox. It isn't > totally clear from the purify warnings that it's thread-related, but I'm > pretty close to positive that it is, since mutt badly misthreaded the > mailbox when this happened (some messages showed up twice, with their > numbers out of order one of the times: I've had the same thing happen in > some of my experiments with threading.) Did you apply the 1->2 patch? I got this same sort of behavior without that patch. me From eisenbud@allspice.cs.swarthmore.edu Mon Feb 2 14:12:13 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA27211 for ; Mon, 2 Feb 1998 14:12:09 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA16012; Mon, 2 Feb 1998 17:12:03 -0500 (EST) Message-ID: <19980202171203.51011@cs.swarthmore.edu> Date: Mon, 2 Feb 1998 17:12:03 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: Thread_hash bug: Fwd: [eisenbud: Purify: 6 errors (18 total occurrences) in mutt] Mail-Followup-To: Mutt Development List References: <19980202144513.05425@cs.swarthmore.edu> <19980202135011.08325@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980202135011.08325@la.tis.com>; from Michael Elkins on Mon, Feb 02, 1998 at 01:50:11PM -0800 On Mon, Feb 02, 1998 at 01:50:11PM -0800, Michael Elkins wrote: > On Mon, Feb 02, 1998 at 02:45:13PM -0500, Daniel Eisenbud wrote: > > After installing the thread_hash patch, I started to get some scary > > purify warnings like this, and mutt misthreaded my mailbox. It isn't > > totally clear from the purify warnings that it's thread-related, but I'm > > pretty close to positive that it is, since mutt badly misthreaded the > > mailbox when this happened (some messages showed up twice, with their > > numbers out of order one of the times: I've had the same thing happen in > > some of my experiments with threading.) > > Did you apply the 1->2 patch? I got this same sort of behavior without that > patch. I believe so. Let me see if I still have that source tree around. Yeah, this was with the 1->2 patch. :-( In good news, though, I haven't detected any memory leaks in 0.89.1i with my five memory leak patches, over the course of the last day! :-) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From kinge@oklahoma.net Mon Feb 2 15:37:10 1998 Return-Path: kinge@oklahoma.net Received: from dns.oklahoma.net (dns.oklahoma.net [208.2.112.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id PAA28965 for ; Mon, 2 Feb 1998 15:37:08 -0800 (PST) Received: from oklahoma.net (qmailr@r116-72.okc.oklahoma.net [208.2.116.72]) by dns.oklahoma.net (8.8.6/8.8.6) with SMTP id RAA08868 for ; Mon, 2 Feb 1998 17:35:43 -0600 (CST) Received: (qmail 840 invoked by uid 500); 2 Feb 1998 23:39:22 -0000 Message-ID: <19980202173922.25970@king.oklahoma.net> Date: Mon, 2 Feb 1998 17:39:22 -0600 From: "Edward T. King" To: mutt-dev@cs.hmc.edu Subject: condense pgp Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i A humble request for the author of condensepgp: please eliminate the following garbage from the output when I decrypt a message with pgp50qz! Thanks. No files specified. Using stdin. Message is encrypted. Opening file "stdout" type text. From michael@tis.com Mon Feb 2 16:37:57 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA21276 for ; Mon, 2 Feb 1998 16:37:54 -0800 (PST) Received: by relay.la.tis.com; id QAA09194; Mon, 2 Feb 1998 16:48:49 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma009178; Mon, 2 Feb 98 16:48:39 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id QAA08803; Mon, 2 Feb 1998 16:34:59 -0800 (PST) Message-ID: <19980202163458.39122@la.tis.com> Date: Mon, 2 Feb 1998 16:34:58 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.89.1, 0.89.1i] My feature patches Mail-Followup-To: Mutt Development List References: <19980201201808.34760@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980201201808.34760@cs.swarthmore.edu>; from Daniel Eisenbud on Sun, Feb 01, 1998 at 08:18:08PM -0500 On Sun, Feb 01, 1998 at 08:18:08PM -0500, Daniel Eisenbud wrote: > index-percentage adds a format specifier (%P) for the status line, which > tells you how far through the index you are. This is particularly > useful when in a limited display, when there's no other way to tell. > This also adds %P to the right hand of the default status line. Redrawing the status line on every keypress seems a bit much. Why not just make it change when you change pages or scroll the screen instead? I've still seen the same amount of the total messages if I stay on the same page. me From kinge@oklahoma.net Mon Feb 2 16:44:10 1998 Return-Path: kinge@oklahoma.net Received: from dns.oklahoma.net (dns.oklahoma.net [208.2.112.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA23410 for ; Mon, 2 Feb 1998 16:44:08 -0800 (PST) Received: from oklahoma.net (qmailr@r116-77.okc.oklahoma.net [208.2.116.77]) by dns.oklahoma.net (8.8.6/8.8.6) with SMTP id SAA12983 for ; Mon, 2 Feb 1998 18:42:50 -0600 (CST) Received: (qmail 1384 invoked by uid 500); 3 Feb 1998 00:46:30 -0000 Message-ID: <19980202184630.63287@king.oklahoma.net> Date: Mon, 2 Feb 1998 18:46:30 -0600 From: "Edward T. King" To: mutt-dev@cs.hmc.edu Subject: pgp50 Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i I just noticed a problem with pgp50. If I type in the wrong passphrase to unlock my secret key mutt or pgp hangs and I have to hit control-C to exit. Mutt 0.89.1i, Copyright (C) 1996-8 Michael R. Elkins Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System info: Linux 2.0.33 [using slang 9938] Compile time definitions: -DOMAIN -HIDDEN_HOST +HOMESPOOL -USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_POP +HAVE_REGCOMP -USE_GNU_RX +HAVE_COLOR +HAVE_PGP5 -BUFFY_SIZE SENDMAIL="/usr/sbin/sendmail" MAILPATH="Maildir" SHAREDIR="/usr/share" ISPELL="/usr/bin/ispell" _PGPPATH="/usr/bin/pgp" Feature patch: condense_pgp 0.88.15 by Stefan `Sec` Zehl From michael@tis.com Mon Feb 2 16:47:51 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA24834 for ; Mon, 2 Feb 1998 16:47:48 -0800 (PST) Received: by relay.la.tis.com; id QAA09681; Mon, 2 Feb 1998 16:58:48 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma009675; Mon, 2 Feb 98 16:58:46 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id QAA08944; Mon, 2 Feb 1998 16:45:06 -0800 (PST) Message-ID: <19980202164506.63451@la.tis.com> Date: Mon, 2 Feb 1998 16:45:06 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980201210418.38528@bofh.belwue.de>; from Ulli Horlacher on Sun, Feb 01, 1998 at 09:04:18PM +0100 On Sun, Feb 01, 1998 at 09:04:18PM +0100, Ulli Horlacher wrote: > I have a lot of hardcore elm users, which refuse to upgrade to mutt mainly > because of one reason: the index does not look like elm, there are too few > empty lines before. Call it stupid (I do so), but they will not use mutt > and stick with their ancient versions of elm which cannot even use MIME, > Umlauts or pgp. Sorry, but this is exactly the sort of thing I don't want to happen to Mutt. Pretty soon there will be 10 variables controlling the layout of the screen and the coding to draw the screen will be an absolute mess. me From michael@tis.com Mon Feb 2 17:33:49 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA11365 for ; Mon, 2 Feb 1998 17:33:46 -0800 (PST) Received: by relay.la.tis.com; id RAA10655; Mon, 2 Feb 1998 17:44:48 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma010653; Mon, 2 Feb 98 17:44:24 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10266; Mon, 2 Feb 1998 17:30:43 -0800 (PST) Message-ID: <19980202173043.48109@la.tis.com> Date: Mon, 2 Feb 1998 17:30:43 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: collapse threads Mail-Followup-To: Mutt Development List References: <19980203015516.08273@bofh.belwue.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203015516.08273@bofh.belwue.de>; from Ulli Horlacher on Tue, Feb 03, 1998 at 01:55:16AM +0100 On Tue, Feb 03, 1998 at 01:55:16AM +0100, Ulli Horlacher wrote: > Perhaps this has been discussed in the past: > > How about to "collapse" threads to single line like tin does it? This would > produce a more readable index of folders with big discussions - like this > mailinglist :-) I actually attempted to implement this a while back but I gave up because it doesn't mix well with the 'limit' functionality. I suppose it could still be done, but it was a much bigger task than I had anticipated. me From michael@tis.com Mon Feb 2 17:34:46 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA11647 for ; Mon, 2 Feb 1998 17:34:45 -0800 (PST) Received: by relay.la.tis.com; id RAA10675; Mon, 2 Feb 1998 17:45:48 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma010673; Mon, 2 Feb 98 17:45:23 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10279; Mon, 2 Feb 1998 17:31:42 -0800 (PST) Message-ID: <19980202173142.17808@la.tis.com> Date: Mon, 2 Feb 1998 17:31:42 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: collapse threads Mail-Followup-To: Mutt Development List References: <19980203015516.08273@bofh.belwue.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203015516.08273@bofh.belwue.de>; from Ulli Horlacher on Tue, Feb 03, 1998 at 01:55:16AM +0100 On Tue, Feb 03, 1998 at 01:55:16AM +0100, Ulli Horlacher wrote: > Perhaps this has been discussed in the past: > > How about to "collapse" threads to single line like tin does it? This would > produce a more readable index of folders with big discussions - like this > mailinglist :-) I actually attempted this at one point in the past but it was a much bigger task that I realized because it does not mix well with the `limit' functionality. me From michael@tis.com Mon Feb 2 17:37:17 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA12615 for ; Mon, 2 Feb 1998 17:37:16 -0800 (PST) Received: by relay.la.tis.com; id RAA10783; Mon, 2 Feb 1998 17:48:19 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma010751; Mon, 2 Feb 98 17:47:51 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10303; Mon, 2 Feb 1998 17:34:10 -0800 (PST) Message-ID: <19980202173410.52931@la.tis.com> Date: Mon, 2 Feb 1998 17:34:10 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: collapse threads Mail-Followup-To: Mutt Development List References: <19980203015516.08273@bofh.belwue.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203015516.08273@bofh.belwue.de>; from Ulli Horlacher on Tue, Feb 03, 1998 at 01:55:16AM +0100 On Tue, Feb 03, 1998 at 01:55:16AM +0100, Ulli Horlacher wrote: > How about to "collapse" threads to single line like tin does it? This would > produce a more readable index of folders with big discussions - like this > mailinglist :-) I actually attempted this a while back but it was a much more complicated task that I had realized. The reason is that it does not mix with the `limit' functionality. me From michael@tis.com Mon Feb 2 18:39:47 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id SAA04716 for ; Mon, 2 Feb 1998 18:39:45 -0800 (PST) Received: by relay.la.tis.com; id SAA11355; Mon, 2 Feb 1998 18:50:48 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma011352; Mon, 2 Feb 98 18:50:23 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id SAA12457; Mon, 2 Feb 1998 18:36:41 -0800 (PST) Message-ID: <19980202183641.39227@la.tis.com> Date: Mon, 2 Feb 1998 18:36:41 -0800 From: Michael Elkins To: Mutt Development List Subject: [Announce] Mutt 0.90 released (devel-only) Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=zhXaljGHf11kAtnf X-Mailer: Mutt 0.90i --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii This is a development-only release of Mutt. It can be found at ftp://ftp.cs.hmc.edu/pub/me/mutt/devel/mutt-0.90.tar.gz ftp://ftp.cs.hmc.edu/pub/me/mutt/devel/diff-0.89.1-0.90.gz Note that the `devel' subdirectories are NOT readable, but you can chdir to it and get the files. This is just so that random users poking around the ftp site do not find development versions since they are more likely to contains bugs. Please confine all comments on development releases to the mutt-dev mailing list in order to avoid confusing those only subscribed to the mutt-users mailing list. me --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Changes Changes since 0.89.1 -------------------- - [patch-0.89i.me.pointer.1] fix to use `unsigned long' instead of `void *' for arguments where the data may be either an integer or a pointer. this was needed for 64bit systems where `sizeof(void*)!=sizeof(int)' - [patch-0.89i.me.pattern_hook.4] the pattern matching language can now be used in send-hook, save-hook and fcc-hook instead of a single regular expression - [patch-0.89.bl.alter_weed.1] improves the mutlipart/alternative handler to use auto_view, and adds viewing of MIME headers for attachments with 'display-headers' - [patch-0.89.1.sec.expires_hdr.1] added support for the Expires: field. auto-deletion of expiried messages is controlled with $expires - [patch-0.89.1i.co.mailx.1] added feedback for the `~r' command in mailx mode - [patch-0.89.r.buf.1] buffer for backtic expansion of `mailboxes' was not long enough - [patch-0.89.1i.de.mail_followup_to-leak.1] fixed memory leak in freeing the mail-followup-to: field from the ENVELOPE struct - [patch-0.89.1i.de.list-reply-leak.1] fixed memory leak in the list-reply function - [patch-0.89.1i.de.send-menu-leak.1] fixed memory leak when attaching files to messages - [patch-0.89.1i.de.remove_user.1] fixed bug in removing the user's address from the list if it is the only recipient - [patch-0.89.1i.de.pattern-regexp-leak.1] fixed memory leak with regular expression compiled by mutt_pattern_comp() were never free()d - [patch-0.89.1i.de.beep_new.1] adds the $beep_new variable to control whether or not mutt will beep when new mail arrives - [patch-0.89i.de.fcc-save-hook.1] adds new command `fcc-save-hook' which creates a hook for use with either fcc-hook or save-hook - [patch-0.89.1i.de.buffy_sanity.1] fixes a problem with the buffy code - restored blank line between the "----- Forwarded message from..." line and the text of the message - [patch-0.89.1i.de.tag-subthread.1] adds the `tag-subthread' command to the pager --zhXaljGHf11kAtnf-- From me Mon Feb 2 18:55:11 1998 Return-Path: me Received: (from me@localhost) by turing.cs.hmc.edu (8.8.5/8.8.4) id SAA10151; Mon, 2 Feb 1998 18:55:09 -0800 (PST) Message-ID: <19980202185508.34576@turing.cs.hmc.edu> Date: Mon, 2 Feb 1998 18:55:08 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: collapse threads Mail-Followup-To: Mutt Development List References: <19980203015516.08273@bofh.belwue.de> <19980202173410.52931@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <19980202173410.52931@la.tis.com>; from Michael Elkins on Mon, Feb 02, 1998 at 05:34:10PM -0800 On Mon, Feb 02, 1998 at 05:34:10PM -0800, Michael Elkins wrote: > On Tue, Feb 03, 1998 at 01:55:16AM +0100, Ulli Horlacher wrote: > > How about to "collapse" threads to single line like tin does it? This would > > produce a more readable index of folders with big discussions - like this > > mailinglist :-) > > I actually attempted this a while back but it was a much more complicated > task that I had realized. The reason is that it does not mix with the > `limit' functionality. Whoops, didn't realize mutliple copies of that. Mutt was crashing when sending mail with the thread_hash patch I was testing and I thought the mail didn't get sent out. me From michael@tis.com Mon Feb 2 19:13:57 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA17069 for ; Mon, 2 Feb 1998 19:13:49 -0800 (PST) Received: by relay.la.tis.com; id TAA11447; Mon, 2 Feb 1998 19:24:49 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma011445; Mon, 2 Feb 98 19:24:48 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id TAA14379; Mon, 2 Feb 1998 19:11:06 -0800 (PST) Message-ID: <19980202191105.59266@la.tis.com> Date: Mon, 2 Feb 1998 19:11:05 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] feature: new_addr (EXPERIMENTAL) Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=OXfL5xGRrasGEqWY X-Mailer: Mutt 0.90i --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii This is the updated version of my `new_addr' patch which includes a new rfc822 address parser, changes the ->mailbox member of ADDRESS to be more useful, and adds the --enable-exact-address configure option to make Mutt regenerate the addresses as parsed instead of rewriting them. Changes from the last patch: - fixed problem with rfc822_write_address() not behaving like the previous version and adding commas between addresses between invocations me --OXfL5xGRrasGEqWY Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-0.90.me.new_addr.1.gz" H4sICAqI1jQAA3BhdGNoLTAuOTAubWUubmV3X2FkZHIuMQDUPXtf4sbaf+unmFJ3EbmYhCQQ rdu1Lu36q6v7E7c9fd+el41hgJyFhCZBpdbv/j7PzOQGCQZlbY+nLWQuz8xzv8yE07cHA1Kf eWQyC4K61DCkfdOyXGdgDxujuLHh0Nue2e97id7ter2eOW3rg+uQH+k1IQqRpQNVP1CaRDaM 9na1Wl0NMzW1faBqB5LKp759S+rtZq1JqvDfFnn7dptsk/09cjWixKP+bBwQd0Bsf+rZTrBb gW9k5nh0bJvXY/o92dvfJt/OnD4dkLOLk+OzTrf3/vjk5+3qdhWAdBwcReidaQUAbUgd6pmB DXsBmHRi2mOCG6W+T31i+mRqej7tf0/I+cVV54AEI1jNo3/MbBiyXSWE+PbQsQe2ZToBmbge JRMKH3NyO6IOgU3YDu03cFNVsanOv45PrnrH795ddrrd7X4GVwATv2Flko93LfKDt67PjIx5 nBNazAm5VZMVUsUPmfECcCHIkW9txxrP+pSUEHRjVAIMU009JO8ddiRHfze97TdGb5ItfgCc HLLG7bofADsscnbavSJ7x7jDM9sPyBE5/3R2drhd3yZihKAg2Ru77pfZtMewIbsgXzDcGpke 2fMr2+QedkyOz06PYSSCYSCpf8iQazZrCiDXVPCDIQfMDWaeQ3ZxucohNIDQOC7xZ9aI8CVQ wB4SW402wpCmd1PT6fPdUL/nkd2o36xsV9eeUxOk2INBDsOnTuLpI2r2ASmpBmQwGZnwawD/ 3h6ieC4ORKziseJJDAdc+VIz9p2R0D5E5hGQZhu0ZhcwgAe2BULsATTU34xcgPX6NWxVfD86 IuW3ZWz6Bpqm1PNdxxxXmLawSclmHAaPqHjX7h0+gTRYI4+BFq01hFdBuIwpuAXC+Yp/iEha BOKZFbH9cOWgEj7db4XfoAfJdsiRwr+BC8vPQllB8TskM/gHWmb1Nw69CwQyqcGMQcsDyRbs dIsvj6hNpmnUYGDfDEyGnlRBaeNYmGMPWDYH+GA2mMxtIdIotbpSkyVS1WX8QKnduo+RIWx5 3xzQ3sQcj10LlrX/pGDddpG7lcphaixfPZwBG+zPpgsUrKeGI1Yp0iT7k/o6O4yJlJzJ6ZTs Yy18BiJ5C1+9gdVWlJ41nYOp8pBxsI7oy1GZWxhSfWRIjTAtOow4gmpRYU+EoFJEu7zlY+jY p4zmLR1cUbWlCYe0hWNMHIO0M/k0fIwhCHu1xfYy8CjtCcdCdl8HbK8CyYw+sgVmLLCdGY24 9RB+ibZkSDUdfKQRSQFHaXeK3BRKdD0bDKgHClQrVyohontTLvD4lFTFBSHgc3Gn39qDZc+F tMatM2m5AQXn5OcPEf7Vb6kDPg7WeljA5IG7F6ldk1XwL7IsSMuxcKfMKe9efLz61O28u/hw fHpeEdaHTWdm+Zb8MQP+DuagLmOwApaZdN+gNPVIRZElyO1DAtqMD0GooXUS2zRhJhJWLUhZ tUo4DMZvMWpxEuzeuDZo6V6FvBYTmMBGk9OU/fGPvhMr1gP/8sBVQghFiBeT0BoRMzj1km6K CTB3ZrKi1gygpCKFErHKy6T9knCTYUvA9JN7A6GcjJ1I9alHb2x35o/nhEOkfRLCDFxiMkqA QZ5yT4nIBfkqaXI6xEoyRuux+zqyJBW2lVUQauS10OpqBqBQ4WOSMQVDMjKiGS1UbNlQI/GD +AhEw5zQDIUIHQrzfX1PiANb1Lcn03FCkWF0jYSmF6fWCM4Qlg9gDsC6iWHQkXAJyUl860zn mbBA2/9K/xb6yzBQJGaaFKkZYZAkg/CJrwGr0PRzQghpqkcix0JdNLeCcowOiE6NsE0KGawK CmFPbKkXJqfnLlCN+XzEOBkEfMO2bPs9JINgHtJLeOwMeoWzlwjGqKJrLLRT0Fm2BV2ywsCk 2JvTQy6wPEohf/3FQpgwOBGPTLuRDJmjKkkaCyPIYIoQik9lJmnZFKXMmzW3YEIw8tzZcMQM XGzaYGmWisA/JhnCiGkcnDKRNKccLk4RliaM4aYiemF7SI2DWYd8pjlNbGnBOmJfIl7DR2Et mYtG1wOk5YHONCHWCRqxYCdvAgJjoxmheVwUhguc5DCI4yyWj3fDXFDhHaBDFIxC1gscUwQ4 DJ0V60wwKzTGEaslZlVYVqGrNXBpTa1VUwwhemmzLYMaPYiMlDf55OryU4fzlZKhfQPZY2hK runYdYbMumLnzKcezyhtzDlRbXAk6g52JQ17H01U9R6px8J5tB5nF+c/9bpXl6fnP/37EPfA hA0FNVoQpcr3ZxOw7LDmNV1YNmQDh07SaCU6EzqRHCVFo1KM6qds4CdYDW1wiv+pZXyHFQAG mZa29Mp/+8ovxXBq5D1IE4NYZHmEsrGVY8P59FXD2cfjAMEG1G9MzQC/M6knwuhAwk2t1CgP 5T69DKSIPPOT8nFMCXVGkcJyJxNwxDl1irh3oVQRdyxUKzTtQGuvrFbkTF0qWChKk/lDpZkK KD2LGWruPysLjnCFFzQj/1d6W+JcNFc4PjPh8sKRmdEXjwWYUUj6dIZBE3xWE1DgnyK2JxDs ke9JqUQOSMkvVRLLIH5skTn1Xc9xye7UcydTsKJyhXxzBP9NpO1Z+UgiMMlOSsRu8e/krHN8 eXZ63sGE8rzTrcuZcQXDjK11DRmsBdkoQDKH4IBGYSBUf2Qzj2yFzY2glj7wb6/AXrIF+w1Q whTFRNiXLc1T16e5wsw7l2WZt6fkUT5Q9AN1deEte+ayJEu8PIWfUQyDf5y7IDClKxdQi3JE EZK9ps5N/U3gRu3XHjW/sNoZ/qH1Ie/fXfZOTg6WIZ5YuRAt6zGIP2SC/MHKh3n9ONDLzsez 364uMgBf0ul4Xl9BAw8H9HIpAUmtORsHEeSE0QvzU0Vp1drcmrQT1oTJ3pCC7Np03I/1LcMh fOixsJMpopSODiVhejK0gDnXWEWWrMyyVcrUFgEGuvcEYbLA7aUi9YWxi4ZrT8CMIvpEqn7e 6UDo8e7y+FeI2zP1jBf/G7aTrRdR95KuRT1rl7nz5nJ902N9M5pYUIH/ivT5+WcO5B955lCN UHNmk2uIGGEb1/MA0woIOgkGmw2SxKl7+j+dix97GDmGaXNTZrWGpgYki05o3rGlUSjm7oyM zBseOWLuFtiQTw/ALiPeaejvj3/pYED649Xphw6oZn0lJCcMntLA6gvAzk+Ou52TDx9X7yyY T6nJSuMrtnb128fO8fvO8bt8iZ4hD/IkDzozpRnaF4Og1oHaKiDLizOXJFllkqzGNqtep0wI 66xGRv36wL4TRq+QiJPSNjGt3oiOp0elHfGNA761g1Edw866D43jo+77DqQS8NedUouX5kQw StgAMBTnZ78hK/avbWffH+FK1577hTqV0nZ1eZVqYvtMh+qhecM/3vGYWvEzKHLq2IENluxP 2IsLAnljegw9n/g0AB0g3Jb5DRyMhIkHxDKIlSEM7JmuYouYVCNICkZ/TcNCcVXTWiIG7X76 4ZfOZff04vyoXMa9UGvkEkTRISVrRK0vtjNkGfnUA1G9K5UajQbrt0pEfvNa366zGaVIACBi Ng5I1lTy5rW2XV0arssrhrPEk4IvuNvhzWD9784vzjuHiKEDASjzBdZNj3cf4daE+xRN23Fl WtNZSUrT2wL9b0nnLvDQ/CG9BrYHK926Xh85VRpaFkRqvkvsAJy+g/mmiU5+6JkTRmhGV2J6 Q+QLMqo/m0zmBOYdolAioKMdZQVNd8SoIlRtSQtkiibn0LWlrJyAlKVYES8x+v5e+swglHfK 5fsy7gRJ6g4hGCtXAbeH8uffS1h4pEEppD1JYbZrmbBcv5LCI0F7g4ue0YrSn5XUfyLxvwrt jUWJfoT2urQo038v7XWVpZ66Gh4TDexcXQdfDSt4jCUnBDMCe4zFm52TE7Jz8uPZ8U9dsnP2 jn2pILu++AVIqKutBEWeskYOpVVjE3AJ8yL0Ljiy0CiIoWD/HTdgwQegNp2CEFrmDKL/+rBG 6hc1QgOrASJI2TDgp90nOCwy1oz2WhNvKFR1ML3ipoLlub7f49uDbTObFbLcgq/YjVuyzIC8 IYgsikljh2+RfPcdBD0QWIwxctC1VoIeeNdBNBup5sStCGwFC+mzCxDgjZzdyj2P+3elyiEk ogw6SOg92WVCymieIDka7N+ZG4SlvvxeqiDPtUMxOmyvEIW1PmAxlIl53Y9wEVJcXbVKc1Or YPKVIjBj/NEcglZmhE4H5JaikSlDFDzDSDPw7Btwx6G9qWE/shmer8HrzsnMR3EzOScjQWuE mUdjP94CvbMD3OV+n97sO7PxWOyKyUaLX2LRWwZ+cqt4TxaFnFDPc70DEEQ/MMdjEUt4EbV4 A25uTCcHSckHpFA0LcguAwz0qTULWNjQYIqq8O0R+RALEGgUNmASWOmfEaYeDi1iINrykxU5 a8Ucc9Fubn4VwS9ELyiVspQ5NMhFFX8lF4QschH86fwTOSlEXj0D8QxQeXRrrzG9qHuDQGlD /s2QmX8z4tLqnJ2hhYf8sUlDJnnzo/LO/clJ3bIeSL0TW1irfJhrjwwttEcwP8scQXNkjdAg /UXo0KNT3AmJtR9HyCnz9/QdtTa+o7SpBP5wKxke8y70OS6/gsIPeltSO6I+DPQhL+lxJYKc iX8pYZ9oW2TxknRF9DAti04DH7xuAUFvyVKGpGbBypb0lqysM7+oqIN2Dzcj662myqjd1IvH cjv3H45/7tQn5hf6gCv75Hfe9FCEos0s3V8BMoewajZjVoNJRPbJoSzGx29Hn4XxVUog3j7t k/L8VWO/Wn/V6017r8qfC3MIofV27gXchx4s/ByGMVYZEmOVoUTpZveXS5Xsz3xvf2Zd7wuH XsMjcGuEYQe/q4IxJjolx3XAP/sBdQJxmF6CCYMBxnOksThdpEkYLDiUX4Thjr+PFQTEigw8 dxJPbPijxooMySQ/dN8xtwgBBtYyxLQiMmOoCwlQLrAcaTH0tQBEdYL6nyAMp+fdq+Ozs4hf BUTADEY9AfG5bG/zbKsdZVsr81wfXBTWhJ6U7YaTN5/ztlMJW4Gct62uTpKLMqHbOX/34fj0 bDPWst3mvGhHFyRXMmM6nH55EiNw4ldgQntdJrQ3w4SPP338eTMMMBQWHBhKGBxsPcqBpzJg 8/Q3mmsW3Yzm84tugv4bIr/OogVD1yPyr6b/UJaeVvSUpa9Af729Jv0fqZK+OP1lSeb3OCXZ KOINbH9Kx0/zBXzq5pkgS8rqauYSF2BGcyNsOO1+7JxtyBPIkqZyTmgFIueRe4uBGJaDeHVg ComT51rU990i5QxYJSm6q8HlUVGX1gMBonXhkO4Mj3zwGAnPNn2yc/LxY3guRPq2R63A9eaN RMgEiOOgUlxD64uWmNLwdCToqBvsFpAsteTwGhDhS+PGzum/rmrEsjCNhc3ykyjL7cc3RnkD r6CUxamyV+NAsFr1n5kfRIOt6ZSV1YrUQmFHzaxiKLRrhaqh8atfpg97CtirX925E5h3pIM1 OF5JCFN2XuuZTpe3lcquo153FpS26znpPGzSWCOf367mwmnL68BhhW/PO/rMSgP1G1L+P7JX LZPkrj8vxNd8SkI6DsJ3JnQhGu12LBrehNS9QQRwLxSnUrLiUQeT2LexkGmO60DTUnGmG1I2 0w3lv4DpmOdsgulG++9iuiy3mV3F9zu4XQ2nAYPRVfX8sekMmREXFjyGgf2wQ6BqPLKUWxoC wHU8tJ+M7WsSXz4p5MVkJRma5ULKscWyohaevdK7hcfV137f9kcbcm0yD7LhMy7BrTpIwLAC LS1zJrjHMLzgV/GTpxqAbsZRQVgQLKSgcjNbQeXmugrqz/19cBfmhL+Ty3FvGhx3NXxRKyz6 Pn6UBZOef8qEbatPfFadc8EWtJfYQiRXaQFM1Hc5NTUhSVooSenDjfTsUBK34J/cULNbP0Ol LqKi+mL0LubmKaW+mG0lx5Ot0A7tCCsDOobHAuHNkagfwp0d37MgNtpvNPaZDYoHRRdMWPvR 4sB9eBZvuUlKTdbZe24qfmHZFkLIIw4sf8pUUQRDePCI2+kiDqFKFqGbIulp41QAbA5JFan9 NFBkq5AtAPiZtkCRpUK2AIwr3i1kp9b4SlL3TNx3RWtsOwOX7OIV0MP4JmsRM6DIz9fBx4+0 YZnWBs+0s8KqlLKCrC+7CkWYSyUyl/i/fO21HTvwLfwEl+dYMw8vrRWRSXUxBcyElCeGaBQL ziaMbNe9G9MTpwGiu9wrh7OefDSAgHfiBZ5bGgbEWoL8xtJh2dnpD3hUhh8g6fwpwpWQsKOY nmlytp5pzUJ6tr9HLm4gWrChx3TYnTYFVQ8vTLJ7EYGLd1TjF2vBSLDgQtxThfm/slezxPtd 4uIMU157OEIVDiyeCgpNZeDcAb42CGsJamk8tFT0KLTkDN2trK/j6CxeQMd19WvrOJPYTPFE b15KaXsbUnRGwXYTvyAJ++42F7lBfHoGz6O+l3uEtrKMhBOLGIT2okpHq+bYgMzidzShgPLi BWrqMQIhts8PtotGvEpOSqqsnZIKlN98zRxUWetqQ34Oqqx1IWEzOeiSgvCXAPAFNfxxoGZT DS9WrXZzfmB6EOW542LVvWZz8XgyCSBHoJvNxWr20qQCQo0vBPQSE19Oqptqtk9pqoV9Snfu B3RCuGKi8+AvhZAeYDS7BqeAqSf4kj4ZuVM6ADGekwG9jR2OX+O5bXzijUuMbSvgVXHmbRLU gWiQvaZ8y/0Slw7mTUA4dCUKgdZ0Js3NWflVzqSp6y/oTBYla8mbNNuaUKt2K1SrLXY2b7HJ GJzFb65cfxn28XQC4xe8TUEmNDAxJIju57NVfO6RVroYBF5ILTOPP9nsPJ00ss424hlFFTKc 9YLaaKjZ2mjo/yxtDEmTpYqqzI7n4VN7qiqqm0uqVqmiKhsvrYoh4Zb0UFUlroeqquTpoUfx bU/MijeoX6q6eK3nMf1S1UVH+d+iX6pqZOqXupBZ/bP1S+cJlNqSnqxfrRfJm9TWS+ZNj+iX IX5bUjWMZPiYq0PH591TchIyemCPi9VItKXXhLIA5WiWJi0WWHInF0+V/KD/giqmSXqmimkL RcICBwNBH1LgpZ/v7Jse+/lOxlVN5mGfJkfXMaOhg7Fr8oO/r5dmabK6kTRLk9c6MvyKaZam 8GKWphgLJ387S1KVrr3jUX935lx0idq4I+HvrIKjovyVqz61xiZ/f3yvhssGnunN0YSikDcK FsG0ZnbCojWLJSyZvwSLC3Ds2f1OwF5tPQH70+4JURpSQyGh7C5jjz+Z8AzscxyYVtCBZWpX jD1/lVaO36XFA+E19b+VXSbRWuuWSSz0llz9hY897Z5d/Nq53LUqZLdslsl3RwS/40EZfMBT +c9yRaDSEmLcCsWYnXTi23D892Iec5Fa+/lvxD3zFFFrv8hBZuLsP+EvdUnjVUZdav3NVUZd ysoAV1QZdTkrAfyvqDLqcnYGqMvFMsCXrTLq8mauN+nKy19vynZ/+FY1CxPxverHwsSFUw78 pRTY7giC/zH1CkWL6VeoH4GXJ+2pS/pFYBRQAJzf45NfUPg1JVv4NXVd7zb391mytRg+Moyi 8FHXubvX9cjdOwH7HfI1EypdjxRBHKtnCbHoSry/92gKpbfkpwPOSZqWOHyEp30p4x8WBfW4 KLgyWQJ6Iyz2C0880uHvL9sOCUmOLzfPHBjQB14VUY2lut+6i+Tpy1J58EmACygRwuolgL+g JuUUEvWChcS1NaklKUyTWlL428b8/xVh4g/xZ9h3kySuEvkJ9zlakv51VKwltb+Sii3yf/Fi Vkvht9dbip64t5GpZFj4Q3v+/9V96XoaSbLob/kp0pyxBQI0bJJAst1W23K373i7kjx3+tj+ OAWUJI4R0BR4+dx+9xtL7pVVlGS12+2ZFlCVa2RsGRkZgfGyilDPXss+l3JqZ5DFnnMvJl2j AL5zLLo+1rkhJ8i9tkSrtgmZ/eM4Qe61w7aOvfY1bB3jGVEYu0HJ2fOlQ/jc0bPHseIuppAr 5F7n2+3o37iJ2et8u439KpuYFCbe/x9cS1UX+vwfB8F2OzLlDOx9i0i6+XiEflgFKDB1z4mr ZpFf6paTVbyowkZVvp+U2cu4mrF35asZvpQ5Eyenjx/1MRDe0fEJL1W3IU9Iug19QuIdkMBs 4/PxSCQL0Hc7XTRCxeztf2PHJd3GVY9Luo2/63FJtxG2NnWbf6Pjkm6Lj0u67Wsfl3Tb3+W4 pNv+cY5Luju7kth2ulnEpiKTmyDjN0lnKb/xtXSW8hz/29DZ7k6Yznb3/kZ01mVlttvdvTad dbvfhc56jR+GznpNqX/0mrsZdHa2BG0W8Ci+QerqNUOXsPOoq9fKp8cfl7p6rbCW0msV01J+ COrqdVoydVDnutTV69yY41kedfU6N0bE305dHCmhaUIlKMxxLlVMZxqxsohreEE7YrqpUCRg bjMd5sBtIovMUtuAQLX07YhPm/1NWfCHuRbR25Mou2f27lHutYhPV7wQ0dsL7797e8X23z/G hYgeh7OBzx1tOsOVvMZ9iF73u/jN9brf029uzX2IVkNmjW1hOI4MVVUGhb85CdoKB9DIkaCt cACNv4EEhZEH6QyeF6azv1yCthrs2gGfe9eUoFD1xvA+h7xajZ0bC8b7rRK01aCTMYDabu8b JahOzECSDHhkkZhzrcZe6rAm3U4Wwe35BJdVNy1Q8R3IVF3hR5GqMCmJxnt7BaUqTuVqghUa Dxp+Wo1uYcPPXy9YW42uTFbZVe5MajmvLlpbjZvbNObSfu/GTE03IFoxDgOJVgzEoINZp7zS z/FE5QZlazN1z3idbG2m7hb/XWRrsxO8PN9q7hS7PP9DyNamlBJNLSWuTF/Nve8RgR66uckQ 9N8mW1vtLicP7DQ0K1eBKTAAKIZLu6/iXBi0CtPYx4sYcxbAslIymnECzG5WLIwODMCLjxxu KYP2Ws4FkvzahcLoqLnfzBlyqyWRs2UhZ074jn/4w8A5fJwtJiPxcTGmSPuFYOooLgXbzYKw o8hcpa1C8KaKWO8G/BxlGjvWUVqWjvLDnNrDqMLKTaugclPANwaeJ0u+fMAA6fYYID0VoGOD 3ZGbxQ7yoeJfHdOoZd0o/64xjQx2eu4zrXaTrHvwqQOhMiJggJ4rkTfH4b4Kebeb3QIk6bWb Qd5tx7R+lbYKkTdVvEnybrdaDPfWD+iUA6MKGyvaBY0V1yDvdps3Gu1293rk3e58++biG8m7 3fn2jcd1yNtgZ4q89ySaWfZjHbcLNNJ4NF5cUT0C3Xi+WopoMbyADoegnsb18XQUz2P4A5vL UbSMCl/1g4HtphSfK/SQxQ32ut/caiG+oGB4Q1yhQ1pstdXpqKt4dO8gN0DHbPg+XrIxhr8X AXv6wnKgnQzgpq8uZ9VNm4T4LRqFuMoPYxLqdHgf0dlpFDQJyRlczSjUCXvnw/Ni3vk/hlGo s8OqWGdXqWIMjGuYhDo3l84sjzN3dm8skN0NmIQ6Xd5NdbpqN8URt7Op/DxeXsyS5eAzxTnn WG9JIeNvJ+Wpn9FWFrX3fDtSXv1AzLkEbcBunR+H6jn3ZqvTK2oIhulcleR74a3STuPvZAfe 4VxW8KnUM2dJr0H5O83vYgzeaf5IxuDdVhMTPcNnu9a08tPz9WgVjvW2F4+V8IwRjdFCopi+ 1Hv0n6NHnMa5pBoBRMMi1VvVDWAuVfwP//df4hHSss4zlZGoeYZvRuMk8OpjBPuo8Yd4uk1w p5GX/vGFm+lTWZXOPhDauqoSQH+g4NahWiUspGGiSztXxathoLylKRuoWEnURdMoUwCMvMzg ucnu+X1WfvB0uvudXdj2F0sRHs53v2eyhLd3dmodUcWPnkxacvio//joydMXR/3XL/7v65en R4/LGhlqFjZUaNrvKpjhHuocHv/SP3px+POzo7KzujXx5gaSd7+rwQK9Wb+EevBlZ6kqhLMw 1uotAUVevj599fq0/Dx6H6N6Lhaf/qm+V0LrCPr4cnsYgjS/8daOHzqAb+7D/2Grm7dqgWqp 9YL9cq1Lm3yd1/0Lb/QxGSrtIWJk5H0OoyDK5dUU74SBcOSbXxWxvJzXBN/EEGX4UamBKHpx dFJv1kSnJhoVcf8+/JXmg1t1+uQtHkZJUDQlynfj+oPlDPbSdhFKMQFlFnSnTJapcaelhyUo XeXSi7Nht9XKalIWop+wxqGmTcu4nQ+Ujz/No+moH03GEUZ1Lau2ZVmo+KbxDgo39CM5Jtr3 mkEFAKaaYg68Q0tCH8rscpWWhkM1qL9mDan/NWs4HF5pDalJs4bDYfYaypadNTTlA2towPXN a0hN0Rp2may6rWuu4eCGF3Hnqos4KLKKgysu48Bbx0HeQg5CKznIXcrBDa7lQC9mu71HacDl J0k1gaIElkKUj4DLzha/xhMaKLwYLOLo/QFFVQcldnOwuX+rvpEBw8vkvP4gnn6QszWAxAr2 uwww+fXlEIJVfXg5hcJjHxYbe87QC4w8PPAi484a9sUm5zdp83lMW+9hnR6S1eB/4+ESdb/o LEa6Gq3mopyxjEsJColC2cBAGZIBDBIl4Qa8+ilwZEshu0x46CsYekAJucC+p3FYD9EvPVVE P/d0yA7okLu52ki4Zlohaclj3L3arlozNR89oz8293HTOI9GuKeMp5SAjfassJ2sU52kWmVg wMbxvtjSP5GbjkDnm8RT2Bg/evnspKLs0LVWEzWhXRUHJ9RzhGhgaCIZX84nFisZrM5ahpfg L2AmMHO5QpjDVa6RvlZVPrtcmirwA2qU7ty5A7uMGiYKOxt/QkbsVIGGnV6gCrVCHTLWrS/s Dqv+ABXkweyTh0MuL2CsJHKGnfTyM93AzZh2Ga/lVrgb2EBgJtz6AwD7+fLiejAQV4FBcA6P 9BzWdz26etc0VaDH6UwFPzCDYBMFGyV3Ogq3eVgjGJb6/sX6/kYPF5Fd54wT/xhFIL/OZotL 2GACAXDYF3Hnv8maskEq/AbKO9YM5kAAMMqDEBPAoPxhDsBvPPLnh/5OpLXf6uTSfqBamvA7 0gmt0zM+aOq0R+5JAAwzZWhCaxDA5MN4tkoE7NxWTPxZKg3I9foD/KkUkLCSYheDQhRDTCjG S6kf+8vZe+AdISQAtg/ceWoe4y94/rxP+17xB3w7eXX46Agbx6FmCBM9CMJmS7nSLzLliFuV +pEq5CRKllL3w6/1B1M0BN7HNoOYgWHjgohBLzy8oGceWrQa+zt7uWiRrtVFQdJoGayQKTiV MIAlJrceY4jEZtEIWXcf9XH//8k96eUXnJPDfzO+jDlJDTu69WpttIE1u6pfZTgsJ/Ks91Yd kJEfJuL0+PUR2YMAJ8nwpAwN5EI3PafM4PhylcSLbcJTMm7ieLBkf5z08ZUoK1PQFuHgrTqp 6WwVXZ29efbyxS/9k9Pjpy9+eXeAcohI4sXrZ890h+NEREmyuoxJNA5ir1vGhduydWEm1pTt 6ddGIDjlGlY5cyNYlJ0qNfE6QePvZaz2HHW947A6QOOs+OMPnqz8CcU3H27CUxB56faxSE38 Cn9N4/lln/w+mlqD8GaMFK6nczghi/USsGMeLfG7PW6Ev9pOGC4TUAB8riC5iZ48YWY8dPpb fJKk3qjRclq7tYxBOwuCkxBkWd8iXXYYTSYz6AEH0l+K6WV8OeBhwS/8AEZALJXrzOU+B8RT Czhwu5VC+4ZCeqoQ4K8ab7fmCmv1o6VEGfYDKVMJDVZkQTgA+kGDx4Zhe8tDg23tXeBV83iR YHrJyrqCRonJLxeN1reFCKQKkRDFoTPfzK9aUYtE6yIjJK1ktitKgofRvUUZtCLAeH6f1MSr w+PD50enR8cCQcQLhKdZ5QMxh//DAObcO2usHXTWRltrr4OfuF7e6oByB+xnDqM7evHvo2cv Xx3x+nDTRIjwU64xjTkkOXnWXIhy+1bWFFU2vOwSyraQXWKwvkiCXhGLdaWkyr1mbvPJ5/76 YSNygdoFtPVxNe8ru2JYkQhBbU3hIg0qA0pemUGRQhp6a8pJ+K2dp4bgmpIBGGYSkhwp79PX F7yEfqLzuD8ecVmzkFKvUmM9ixfxFDRpad/ZaTSI73V22prvGYFfTlrIiZErV8RPIG72QSux lQCyJuGRpj5+Gi8vZivOEa4YF2f/RglsaNSXHcwItAQBVg3fYcNUE0GtADUIeEs4i/9hTS2e tJRF+Zojz6kw3pcZzj9L6eVJch4DkwZumu9j8YnUgPkxFxH1+3o8OJSq+YmjsWT83buOyL9N Il8Oy9tlKQiUHt7BvaCpVXHEnkWzaBcBefTs6eGJze3kg6Vc8hadqnd0GhlbFIkgwxe5soLU EVsx8PcVhTYf9tZDCO5nqXciX2noe7s7ZI3EUHzSGqk3epa6P5vTyVf55avTk8N/H6lzq0qO 7gIiaAIgVmPUWAHPIwshJjwgb2uWV1qrPuU5o8/wYkEFN+9sVmBIVf/9fLB4TwVg2UtYQtpv aVEaCh5qGoCOs48oT5GgAzsZjLUW3srwG28vww8D9q38zUygGu9xu9Zupteo9fAOeKPW3HES 3lI0rFF8Jn5+/eTJb/2Tp/99hGCbr5awMKWqeSp3gmfpN0IAgSTLEbAeXKH/ogUybdQz26hn tVGVo8NDeR6dcwiKbahhOC9KXBf7N0XqqSLW5KGUpPrSydGLx88Pnz67/7Z0J3lbejuFEaln yiDfbNZaqPnAvrDFqco3jK2H/7EF5Ym0oGjsfA4LtxjWBJBHtDg3qjo/r5DNJtzUmd8UCDGQ oOmm+HleU3gk4DxQtjXi2pfJeUVZf5XRF7FMXvyiJKm6JFnwdHH6ZdcxGiDZEMM2gzFtugab IN3cAwkQda6VH5rY2OCBq1krOzcOSDVUCZ5frDN80wkGN0stMv6kDwXWteM0k7UEI3VE0OEs i+3OrlKiM2r8KtdotIjOlk9wJ3NfdpPdy1itK9sZCta6lLVAt0hAkZjATj56T8auYTxCxYWM YGL7knAWPVeW4yki4EygW5gYL2nbMIlwk0EWQUCF59H5eGg6F6Z32kvsNUke7rXVSclabNKD pi3KmJseT0cHYizuCehjCN+q1Uom2nlnJlDjw5vxO4NR1zg3kW3Yo3MIhZoC7eO2c4akin4J Cg+QYhnCg974woMeXl14pKux8OhZBtKdNluP25bOok2Ueq7GrG9tPnDS1s83jXc56xJsoSac H2qRwr1lrdb6llNL5x2eAGa6T0xfwJSxp4xepOjokHNgtdPoOkC8/NRfzcmqTicVn2Csw+Wn 1GCGq8W3gzerkQwIZ/aZBeRC7edPTYE69TAA7azuFMC7pPLghwK4tANFCLVBJeRyhCoiGfLs fYjZwLDFzy/J9r6B3B6Ey6jtGJXTRqVw2WjExdBUhBKtWFuam6j9Y8OAOgLwRWo/EeI1WZwm wGfCXKadz2XW8pher41+K/jBq0Ur8xwUtsNfjijMNynfuPUsb+Ft5wqoTuptTTx6+eL06D+n +JVjuootVv9pf4IOGcZ4bRkI56SOmp+Ct9vUFcZxgJ3wUgIxgc318IKPcBEhQKjJKMqNRhuV 6ip8aZkDJClTn/ef//zyP1rropgGINgAmfogz6Yk3aT5QDuLSPFYd5sBLfTx0+NUS4CZo/Hi qo39mmrnomgTMhGnbmBECrQoN2sInMHqHJ0PgYtcpmdYruxTf7RBXE1pF3iJzkUjkuWSytjH +s5oGzVw9OPEPg3QJXk3Gy1OSt+AHfWuvHataRmlLBXHPb4GHt0fO5tE54m4C09h3ftPjl8+ r/ieSQEHHmz1Ak0gWmSzKhzmQHKEfP8ePtvGpQBxzFRiY9iBvlmaKoC870DzCG/fHPAfmjPR bxgRhsrb+EM8Yl3deYSHcBh8pkw2JgVXmW2+0Wk6kkoOcOlXEgpqZ2onxat1hr4oT5B130kE 2VAkWH/CL6Dhq5Oamhhyg3eXFeOktba1OTQ016w5uz2lq8g/NI0ACyRZFuaC8pXHCOVT7+yx 0VmncYXqpdlhi8Pjyk+zCsYZhNcYxMJUHz+hI0oV6LA0h06Ariaf68vZPsCq2dYueBtf8ryJ 4oAbUZyrB8ee4xBemCDMauKDrxKzRZGxIq7TaHeKjxbrpMfragzpEcta2WO2dii9NvEZ/vAX YrBmIYZDnNAVoJ/2xovzt7Gx74GXPxkm7l5nLzCZ4brJ4FxaxecSmkr+TNZMJBuT0O0FepLO PjDMPTVM5mnNJvO0ZjMw7zM979tOwyWJj6aDTuXHwMlmY2en1mzjjPiLFC7pOcix78Bg6KhE MoRepeL46/j+LcdU9nQG8nocT0Z0fkAFM5x27YMsKpcNHVXUg1CO8659xkMlrWd5ELV6klBN wZWEwgZLhXzoqZMjxVFbGoLrJuwfPKUmHiiTN61Ae/nT+ypxZk+GXJdfCGccsgpOHunKwpxu IRLIWORrL1weM8geNSpkdVTIaMWaBUdu7VvTg1+/C0618U1TYEVNAZ7WscnXDeXnVVYRdU1s arcQJFg3TQOBn+fNX9f8lqkvo+UqUaPliUt9utnuBrj4co30ml1Ret24HmTz79YeryF/uo5e sT7jNSeMXmeW0wvlerWdOeyfZJC4VdXFc9vym1IHmPbD3w+kp1qzhUdJDZxCr2GrqAvl2Ue/ pMWlvODjteXsvSgDYpTE22WpUsHNGe0ivP1XGMIwPqgqj2DlLmGeuR5Y2lzJWNg7+9R2oJ7b aeJ2mttlwqXIF4GXc06LGdpwnM8zthv4wt9s4LOA2aWZv9VI1aKNBiybORjEzSk68/CXtrWR ppsmC94Ib75tbGpgesukZTV7f6r9KB0oM0HI8rl+zKUjvGQk3sefnz4ma8CdZF+UtBNb9Rua mDsu5nIO8pMOf6EG+jidz/tR8h7dm/v4pPzqfP5qNVjQEcdoIP3keJL/OvrtybPDX/qPDl8c vXh0/Nur00pFO2vYNgJsdDiZJfFoAFvZAXGH0Fn+XegRsaiiN/tp/2DiQ5new9S0RDoL1SWe C6G0gJ2G3N5bd1PgH/SvoCOHgo6hI8vrwoxQSEfAnHHmuDlzAwHAGBZodZVFO1Akk3zoXZqC 6HGAiPIvswYrpumox2DtmSRAvntL6dUvrxC2CQsHvEtXclGYgYAoOa84TCnby1PUHa8YpjfX i4LqzC2Ddk5918NCcOqdpepXejfF0xUIu/GSzhTJv5/s7bsNcg+hz4aWB9KP8PbZbDUdoQHu d3EA/90XvyuXQkUrPqfOEQblu0CD5TIA9DWQ+lYFG8MYRRXlgu7eCszg2OXcRgyvgCmQf8jC nobnGEn7APYkMTYpLGY8jyLnRaRfyA2EleZIlO3liqzzB3I7htoZdfgkIlInEaTq4BlDNTQ0 ZzxyK1J4ENQssw77SEJO2fqp+IvjJm2fYczt8xBqmrUzPh3u0DYXj4fVjkUIc4VgwsoWXp5f qltWZfynF9Ws6XKxQnCLxqdGuyLuiTaOlZ2V0FcJajz69ejRv06PX58gM6eTGRp5+bYFN3Rq mxsH8tuR+yrSr1Rta+KZAIWaGcXdBa1U1DKlxuSMQ5Uq0LfcxYKmBsqppa0q0ZF1Vxco0CKw NKvn97b8Udb58u3ReISRB6ckZfFQXBPV+/oDZZ5XEvbk9c/wVb7EWiiogjIBo71gqIsQD5fv fJkgHzusvb2/s7Pfzj/PClZMyQSQsLuAu0rO4inJ76topBzk4Dcb61313L9mqd8ivItp8q4i j538/PLxb7LSaDXvD2YjEAz80HuNc+TXqJrgS3WgpmsrfyDrpA2ny/m5uuo0xmxe5IwwlIzy NXVHmB6v5VsZg6x8NZs/xygaekzWe3J66l/MZrpx1KHWXxfwmgm4cAZK2IALvR/OJuSUAkt9 Blojfg7O9cmK1LwaKQjJ8zHXMb8mtre33T6Uo/Fy1t8bYABIHklNPHn67MiH3OX7ZYzcNgSU zP1k8YXhJvD+khm+hRF2yfE8toeOsS2twjVxcnp4mhr+nAI1uSBRkJSXs5q7KUgmF/Fk0o+T YYTeQml0SS5mH/uy5cBbSjrdx1uD+vVav2nlNG15S3utkimjT7aNVJ1sAC+jQULgmkfDOLHW 0Slz3k9iQD7gmoR2hHNhb9RFPPwQLZfR8CKsONvvPUZpv7qyAp1ZOcUwKc5BT8Y76JkIUOXF kIQc34Sq2G7y+fcZo/RNxijnDmNk3V5UJYM8OVLqoX03ywhCL8xD8GqWbMBsaEGmXM6tG8H8 G7e1P4N4HMZCUtAdutN3JwHm8BPsH8qAAuInUUpKAja7pYo1Ae3V8jlOZovpzPTRJNNLU7rA ZPqOR+v8xiOjJj96dnR4jFE/RFnG/lBv9EJJVWBA0+kzSuDxf9+CPswG/szmdKe5knktRo8s d1zkofbPLdhvvY9FJKgbjN02mdAhB/R1DjtcM5BkW1Ag4eVFRJcoEqiFweYxtnAcTYJEdTbE jD8ZFKVe+uSkngdoqZdPS8GaTEhN22OPHfb0XhRdKtCNmjhHPB3ORujbopmRF9FFcSc+3QdV O4ZNOb9aJvN4OI4mCUDfefEcBMGJfifsdz/vdh7BZ/LmHak7yA7HQx7K7305GBVchhsbpYaU 6KspeCeE7yOQENhzTzK3Ps6XC4DdfbHZNxarj7PFCOpRKAZLr9VG6K2ENgZdvNLJt0vxnoCe aw2todpYKa8NrKlsw8Ov7+54sQ05QPHgvthr5PuFMsZnIhy9S+MbPb4OuqUrprANxPDOHh4s 7db2duTFkC2awBNU7CkSWk08nQ63a2J3b0c8j4BIDz/ENfEouhwsxqNz+Pr8UDQoH4x4fXK4 rS9c1wMXrq2HJrF91TwbIrb7MbUJv1IPR3gTHB7WA7WrgV744pXEC0LNRNDB7vGTRwApOie1 JfpCoRAgZOnhvQflChDB/nbt7du3pdKB1UVJgpqugmMfz58+PxK6tt/uMqfdn/55n5s+myLJ SzuQCf0nH5Sj2qA2rIgvdFyifx9Eb4b15rv7jYOv+hqGvG4GOJo9oo/2iIQekpmp7P3k9Pjx 61flqCL9MCOU6CDAVBQceLFPdCJ7rd/gP6D6LbVSKPqR4yxmqyWMK8F3/zRQO/nX01f/78Qa Nv0uA7zoSKM8Tkgt84JhVbaGlcqwWrUhJ9mdDStWO4azSxQ6qdu4/EW+ddmeuX835b26Hi9B TI+WLuY37FEwm5GNSuMiNFmvH6CAJO/9xQzwGM11JBvjxeUYLThvG/L6vjkp4ct4oPFU03OT 8lghw5t3hKDbtf2Dew/evENkKFdsdBgnqmz5U0Xe0Cp7jdQ+VXgK6h53AiwYgcBLeUTaPA/o VtUGpvWeR/IFWXcJr0iCGnAZX84Wn0s1enY5TtSRHfsjgfQfJ+mXv69my1g9H0Qjwh+K9Hvv gfVUB0XIeI5TK92qfqUhkySUcx7F1IOFHOowrkqDl8SGZnmqqw2sW8kBhh6yVTopnPBqzNu3 m9ZtN3iIVx/fljb9kzeKVlQ3cuk2dV2XZ5eIKqPZdHMpLmeAMPMIIB2J6WpCpGNJM2weh7xB I91KtKXoY54IxoGWN3XgARLXVSxZFTxlXOGvPsRywgEwyOxwAAQxKxxAVTBOmDuY9CN1BzPz GhpPeFl/8CGaVLTvIt+f5IfWbTaruDZ5pupYEQfsCvoOrV/eHG1VrecVBTqCV4AH3armciFt QsxgR+oB3ZGVz+Sjy+iTAj3fFP4QTyS34pNRTcbI/+m1vRAeMsjpUjGNPD7WVFKIjJzNRuSp PPe3sLRel0MzsQn5zE6G7FJ3pITE1yDaPj2huDrElCTm6jEAtQxnk0k0h7IfMbECiQxMU0Jb uEigAJrI2NMqhJCQooYvlVozYAGgRlnfUCvAyq7YPOD+ph/ixdJpnnslDy7m+KoVbd3Fqyfj 6SqWb2RkEqvblMKreYoLdWdMSPZ1tXrUrwX821vVKnEIG8rYscEBg2HinotbatT06I1dslKt vpNdU5lEoowVbMWVgaquvL9uhTcpy7N8BoKHpK7kOTo+7j9/evL88PTRr/1Xh8dHL9Su2T6O VaxMPkyUl0emgkCSIEM9oHeucpBH5XlNUVgpQ9j00yZrekCA59nT4qhSsDTmPTNS/PnGlJBL slni7Zglw4VL89lNZjaqJYuFliXDNPRKqqhoXtEABqcEYCH55wvALOwOklFp02cciZR85hsh Tg7SUZivAwu7JMplc3+Uayqi2DeiRdWghce31QJ4oiZhFy/Zg2lZN2koz19Ut0WJ1ldoz+ib kmVXbw4JfXRT62arrU5vchNBr9B4kBoc96sv4DAW3cxgHcwyLKn6VV3okMxfPEA7YR5vkQrI aIanc2lksn5O4TvPD/ULVjBkkCLbNwHRTT6wEU4+gkn6ta+nnDgMV2nTwbWyJbKGvjL0WJMi M4/0AkLdJoRsFqKoPlO04wlVwvL1ItUWmBjoJFt+buSITtQktHcdbuZtRkHrKWFtw9hq3RLl dZeXqbAMWS1rHLDX3iy6Dfvb88QHppax0CX6ZSTGTYkBqHaIIlMC067CwWk7LF4RR8scKjGH RjeoZ1vVvUg9wsTvk7savglJXKHZ6r6jZzYr17t6bS1QQVFM1JSHm7bTZlWCOsQFMITKNmz2 S0SrG4oh1cRdV5DQzTV8UtEF12NYVd10cIWCRAFPdDzctPfEW3MiJBVKT/lrBEIxm82X4bLu iEWdWKPNb1VZSUsPN22UDMJJejtvl9+8M7BaDy3s2ypeCGYe1ILqKX64U5GnW1XhxmeCp2zK UyOyIe9yIhkFytnySs6qGJFVw/SnetTeRKZLpcQbIjfmqYw1lT68hN2RPQ2nlGTxhXV0HCHy +BvkFGRRooYDzGLj+oxiI49J4EFms9HqvDuw+IZy76trTiEDbt13jjP1xt6WkymDHe2Hz8bT EdkXZehsyqxEFjRWoDPpNmQisjfa4/PpbBGrGaPhLcG7TNDFvQfW3trQoVFGTeBLs/9V8mqd oq63XxJhQ0w2j83K0T95+RIIenmhY6gm+gySLY6jujwgGyf08Gy8ALwgizxwEXiiGhNbQqHk tnkWmL+rOqeOqCu2ohEKvYb/gtgAE1HR10jSMxJBN+ZpBoD3QwvL9nmY+PRstm3NREXkUhML xkeLnHibRPfw26d5Z0420mfNUYelo571jjFjWg9C05L4r7QCa4WsDair91/J8JS8H8/poNsy PIU6sZplXDXGOUWEyvU+V9S/eVcu1a4qtW5KbjlW7f2UAj3Wq8abmfqG1AIsddqoqaF99s+H j/vHL1/LLbY/BOI/0w/RZDwyzEwwdP29lmJyZQNOOwzeGnjI6xDWVYN8/ee2RL88w5WeG5m1 sw1XpO7JiTj7xXz7MkWZZgkZEGbXl2WeKOMt3bcAVauVZJbeUn8RhLVN68dBAXji4Ponr44e FbMDOkBE7nWrCkMK6RZb5BpjfmJAdVe/mF8soiQ2G4Nv2SHrfoYry2lKeQcQeI3wp2sL/pLL 0axfAughjNU2QnMkeXopf2hPcKhPIzGMDEFlvaDy1u+ArnoFxRRaKaiXKjmlDCuSGXGkJhI4 7oYzksJYXTlTpMVUsxoooWWv+SA+H09dNAD5oonCVVKsiJ1pYzeFlifj5nIRUbp0T4AYEwlK sAeCumZbh7RleSfiYotK4lZJe85MR9J0wZKV31NL9HROcW04kDiW0NY03voHmR5eS7mk6y5A HxIeLKaxwTfO8jk389Yp996pYiHlXhcPuxmaA8lZ8M6lHaEIQ6VYgfBsulN6Ot3S83T3LHUe y9r6PP521RvDCwMYxnYy2aAiEVR0a4IpPWVa4MdS6bXJX6+GzWRqmkz1sqYN3w3JEmRJAOKB hZb0FM8VdaoJiS+yuHmOFFBNGfcYoel4XaRPK9bvRUI7jLU6NiE2ZdAwm+T6hvMgR2nN26/4 5sVa+sQjY0swrynsMON0T85V03qNrVPU+sacdMwN2QYR/IZEEl1B0eSGK+7uEmHcZeGWEiF3 fdk1s071iNFYh7ZymBo2nmWCsSF1GP/FspGmBcCGWyvI/qt6AHm+A3aCFNUs5wK1OL2kvcT3 JBAhaiKJYtOcfmpruBaSyyeKCuiNGv9XY7gNHu98sWfhQtYxPgcXKQjitA2aDZF5huj1+GBr FhvpzYNjMdYn/aHdqUs5ICzPQd+f68BlMjFS5iaVCDrD8KSSddhb3ziJ7dYcBo7/8rg34cca tc0gS5okdQshix+XrrjFGBbs6JGN3p6+piAN7119Df85Kls+HRWnHZFPJj5NCYt63G15YVrK w6qDEFZJ44CLXJlYpWLcy+Cfnj5JMeL4UqyKXm9XtFGyAFNHFxOYPaYd4HNvANXis8C01zRY 6Ta4nLFDC4swueRBJeY7ygTDkg3a/UUy4U+QCKr6P8kAGFyOK3AFaxBm9gEC3rBJVKj5adPm FgYepWggGun8Q/I8DeZeyHIG2vqC/DfxSkbAgJZNHbS6V9OybpQr19Mql8FvjuXIqped/ycD NLUUaG6KK3zjFP8i5ppnHA0qMfdSjNfxu7PBOEe7jzQz2bPLEZqFCCzMYm3fgoV7A8W4Fsjr 4qFy5Xnd0XjqMtKRN5O6FbtM4YplIVWjUbilvQz1M0ux50df6RP/fpUBBxwrCd9dZxO9+wL5 CJpQz8THWJwD5iWzy3hJATIm4/exKD0fw4YznojjbXE0eT+eJiVtpVAHJMQBdHSUlBe1UVg2 skw3uohci69pDTR9PicJtrgcYktXjkL6p2hOV6HJNSpxwLbuoo7BZG1lT+0EtQNqmBrSSsEV 9gVKN7irK1t3KnmNr7UpqPo8Qj3Vxk9rAnpvlMcpsrUJSV83rf58VRbSgmrPlyLjLKb45Cg9 nq5xFU3esq9q/14j9Aj+heSe1oT1NP74w92tqd94fKi+s7WP3UqMomO7ImQHSAp5GsufZNCy AsCtMSIWM0naLf2+iibjs89ezs9QNc8YOcdZbkVuDHWj3knr0Jzudc0jZX2T60D8UycxTHsH yHsspGfQX6l0WGGCJNdhm6gVJCjlMR84B7rLCparXPGZhWZaanzWWtqrKZd5Hjnv82admrc2 x0mfGFbToaKS5I6PDXtcecci2uhirLrKWK4O6Z1GKiCi1AsOC1QVrYonaciqvqFPXCQD1FfT MTN1YidC0wN0w/GxdHe71y999yF12UYF4/v6J9/4w1v56Rt/dc6Iq5JLREvrDrK0YY/kaVUm jSnty6Mzq7FQbj27BUojndUo4706xpHEM7GcMkaMzyPKfMdfJzItnsXg7PRmunHHm88pJYek S9oUOMq7OihvDBoKG7EVsOWnlC3X9bZcp2lo7ey+w3OGoaIxeq0caDD8hr3rQF4K4q2tvWm2 RqyovsXbBvZQ1XhcnoPiY8g1Skq1kHyIE3sDZXKn8oG8YOcpQCmDu3zMbcibBpRv2DzRd++M 1m/BacMDUh3VKTW3t6SFq4lVN/Qc6E11g0eM72QH+qKPlv2yK1L1/Y4kqxvZyhs/013KIrJf npV+7HX/NYAKzTAq1LMWcWtkKRzpJWN0Ue/dwHfE9rXPjmI3hqnr0iOSDiN53mGJ53C7kjxM y8S+LFbiRYlxAhjYiTU9puHEDunLK1zFM3S6vMLiEXpXmxguEWAS0mMKf37xAMT5FSk5jXUo lOqD6pg+Ur2YmwWE6pkH1JxUlFyxzMOhc3Z/29qUO94CIZ81PAe2s4NWU+lDc0zMSrE09zy/ eEgxt1KYfqDcPAozqgoIZkRzPaT0oNLDUjCzVIbUHYHEMf6kGaztBeUY9QjQTE/7xD24jOIs OrWrNl66RI38QdVVq61ZhBP5xUYxY3A2B1regpsJmy2JcI5gbSmb1Jis7LxNH42QA4Zbz+c5 10RjFZnPLJKWn+7ga/7N+FTSGZIYkZeZNrB2Qq0dCw1DSPZSllJLSWKN+KQ7sAPinpgQS3nI NQ4EclgTI1sjly+VqtKsRPyXeiUhJ3/xnfMNRrMUBm4oBFSyRI9dSjF+bk+BEa+6of767anW TFvMMDbSDXFYfIy6qBD4IQlVoyxseHyPIzFKxreRQpcNjSsbBlHYCmaGyANMLZM7OCv4ov0R sL2kzh+NjT/Ilqy8YQ5vyuNOIf4U5lBf7ctMDqPROxZr5pYlx0xe2LTAiN1eRwMGOT3UtDq7 51GDBrDRdnw2Zh4J+5Fltv7qXD2Q8kizA5eFaX5nli/nmC9bsKRzY3+rcBFhkZzJf29a5jzw GZVaGtsBIUMEpn0Qrirf1pCnCJJnYIjasGZpBoXI4CBIBg5yKjw80MqwwcKvjhMfS2lLZqd0 Ui8w3Tdopt9RJXW0USCb+SL+MJ6tEmhndcakISIyUkYY9yCJ59GCTqh5pHw0kFI92/lbEAn0 mgG6xw0c7JejbmXrrwbCIcVUm0E943Fh1XAtotVCiFaYcsQaKjWoqFJsXtGkJ3Up79A9d0vE fFHhnO34cnO6NhkDzQ22oOqdo4payl9aF83YdwcVUU8VDSijPmpn7epDQs0IyTBnN9hdD0za 9rTniX+PObbWz/HBpt2UdezkTM++AOMeqH/nOcrBaDZnszVlWiN8VINZTSf48TEWF2iDizL8 hSRpKVRW392zDvM0HaKeQhOU7QjjRBEmJnkabIXxsFZI30rhYWHGVbthkS+cVXLS6poXRhz/ eTbty3EyjCeTaBqjJFQokTJt+57oOnmyI+ULlLIkeSpdbk25qcsjmZQcsB3eTZ2Qp/fVJMbc 0lX5BFE4qLjW+8yUY3Ozc0wjhHPunu/PEfIut1DGPkSSfWWOSR9y5bglOd4TpnyWb6l9GmNK B65Cuhcm9SlnoJh78MMLK4GQBalsrzf7zFcdHxtz24Hr95x54OxtV5zz6bQPa/CUigsrT1ZL 6pvzc/uU1kRLcViBmmlDKtB0jsbXorzDW8pyI+/pqAsMY2lPUkrgagnwK93Hf6V8MBIdjBMv Gp06xSsxfN/cSd5hZmVhSh6kQ9Txy5QTpG7LAr/XYCh+Hb/x3Ux1Y2ZxvLa81TFN2TtAqyG1 cG/ujOxmuLRa4jFT6tihVBUpDzdLfK0Vv0WL86GKh7QFPz6kbsZhM0brx2s3eIKl+ZnsLHyE z3ywJJR7k/JuEg/FcpxsDzEf6Fvt/MTv3pbEvUt+8lAWelAj3UCK/30hX0PV420oHnObgVqX 8cNhsn1xOdyORytRVvW4QgX73k8+J7gG0MxDgIiILiviQ3weJTDWMnZ6Ts7AqCPQaGVfqqkK 1oJilShezMp8P2w4W8wr27PFuajpMT1IdX5Qsxp5W+I78ILvwMNgtkEXOAfkeyjeiGZrb7sB /wPUmA2jCfGlpnhXA1kyE/dm05hFA0b1Lc/OKg8lSyrjsKG1yoOSuVymaU+kaVYmpKradww1 4rk3lGTucvvekvTwCEYrNy2nUSYgblwyszhaSQFxsS3hWLJrpFmgqiCL2cHsq97ui2EQiGRv Br9ucszIZHR6S09S0VbiT5h1ocFnaYohZQfADiZ6Ue/CAbAv0gGw1yR6CVYMBcBuNSj+dWfv ZsNf6/i+ErgXJnKueWKHkR7OpmfjcwwjDY/RWDJLkvEA5AqdVyakYNnIiubGeLq6lHyNgsod PX95/BugQbOmHznBDdOPKfycfqxvlKefkLxyHuur0jIarg5VD8S+GurdTn/phDSSuHxgnoDa Yv1CLmD91Icd2dJT+2EcbKAzKh/UWxEagOcR+x5xmGgtLr0ONsh9GsgSM9F7ER6q/ug3KDcB U2U0HZEzjVcBpRArIDQsZ4v3k4wz4ENKbEknq69KTpGmUjU/ikXQRbLM9xtLpS8pfPXVv/ca qJqxCzkoYJUMp2QJ1ONRFa6UBanQwCzvn3C2l3TulyL7NdTNC7kFrulMZW/w4mibF9mBtA88 q/LVZ5rjJxFehbVG7IzF85glJf7BQOPOhD69SxW0xG4ZdBvyrys3ayz6FJArFJZc1fQ3c1CP 9kxD6ZzXNJLT1JeMhC5dSH6ORB2QephTOZz0gd94Eo8fOmJrd7/T2m/m5+oJVOtiPrSOlaWn 16w1d0QVPnZN1l9j8jDREa10f+bgyko951etC+cUjVP+WG621s5fl0FT1MBxxdUtNgMOnE5n Xy3POHuwfNSrWlWZOO0Zmh7IwkM6QHuH8+i2dvHTZCShLLCL+IM2JAz0tmNjoB9K00kw9euA zjPD6hVnlB2gOyX04Uerto+NeSS8UYe/f84g2HfZGYPMO8vZ4Zp7O066FlrLSRx9iPuz6eQz LnmEfyxrjhy3ZcrJG2ahNLlBGKmrbBJC6HtIqXTajVpXVFutJnzIRN1FszzFU0wKXnGTMZ1j uq5xPBmB/n06owTFgarP+5SFjvwzG1nJr5RVNexorntX71NJzqecs9xNkBWGnG4MFfWpzIQe atVqlCfulvYzaRkQKSCp9IgvX50envzr0SOZ/b3V4XVom3W44koMh2rtg2vxaFhoLTRW+kuQ vQjUsSkRWobh0F+GvIWgBqkM/8pZCtmwmrlbPrQYCkqKr7V2mgT3Tuu6cB+sAfzPwz8N8oMC oB9cDfYDF/iDXOgPAuAf5MN/kFoA4JyYV7kFrLMpsyspO/nqAv+D5lYXjoVcA5ty+yjRVlrO 9gHOWBZz4tZEWybc1dIxnEUvnn5gmlY1RVW0vRzLskymrSvYhgaLcqBxhwt4ce3hIuDXDZcW Ime4fhtrhjvwx9u5wngHXmed0IAH60acakWjksKmdqNLGZVbvR5+GkkMGujrJF6Ii4iz04yB PPEAErTbaDVZiieL2eW+2mNuC/FLDAr5WAXxVK2ILV1BFTWv9H3iMLnC+DGVljmWyYMXlnSm uuMn/c6gYNOLDVnK4ZUL2nSHlfQRTwArFvF88rnuU15PoQZV/bIWMNRKX0nzdcBRpZ3x9ooD yOrNBpJ6nA+ocOfFgBVgULc547mVRjyfQ6jynJK+jUpnZ6ejEyHKWF+4nZSIihNyAuzVxNGL fx89e/nqCMOofagZG4wfMfcsXrw5OT1++uIXDIBFuTXVb3Mm4D8XbNQZSxctpfbIDnDYO41m rYeJo1uOrgy0Re5NUyRLlXIXnpDijMZ4fAUULMPqyhJAqqcX48RqBAb0YTwCeROJj9FnbGE0 o3CzIVKVs1RmYRtP/Wy4XNQR4fCblIAgBhdJfXqMtTjf6U+sImCTGi2v0YQzGPuESU6d7hXj 4vy+ihef+3bCbtBI+8dHr579dvpSLTffIn7e/+3oBP2llUljPsdVKiMu+ZOX3WgCGHMDL17K tW9RVssdzKUo116Kcz4yxgDKdJ11PD0n61WCJ1UsWseOkuuN5e5steRi8gJqFr+RO6hsFqE3 UeYmDY2SMzODntjEXJBNUNRtAYNm0eF4PubozISiC0z/JqYzgdsgUGhQAyelEJZxhmlZY4Aw 4fxqPsfOdVPjpRh8FitK4BdNBZb7TK1QdYXHCosvk/P6A6OghOPQBApmHMEIv2jmuXtpNR2N k+FklsSjupl+SYPfaSQ3TE66uB1uKbOx7CnIk+sQBpiWcF6YYX0y+7iaa4EQRovcWs74/Pdq 0pTI2npcVlXs7aEsiVSgso5DsZo4A8xXPlkZ5jPM9ZlpQaOXASMaPb/yuVG4Jh8ctayE15Sn t23y9Cpj4uOnJ69enjw9ffryRfk/FfGf+/fxyeHp6eGjX38qmYzFpf3SeIqJxUu5mXot86ud l1ZnZ7SSM3L2UBjK0Endu9vh/ImwCpuHmzWx+TP+eYR/HuOfI/zzBP/8gn9+xT9P8c//wT// wj/P8M9z/PMC/7zcrDEMmg0CAn0YaXc2Xy2Horx5AGXPFAJkSyTbFJ0piObk7oDX9jRwUvpQ 0RZsONrDM3dUjZMv1rVuYaPrzXK5GA9WyxifoxlRokOT8aEpQbGxZLeSszFUjC5jLT5uABjL 60NhmZ6+WjQpjnE3fSDUsO/TzXEtvKmo2pD0Ol20L+AHz1kl7f64QNG1ENECT1GZQzgGBzSw z9D9cQgi4AI20njKCTJbTKLFeUxecprnChaVH8fLC8z+OY3jEckOcbFCJQoEyGwRQVUeI8bU 5+yg7EiHsPnmpuiwjk5u0lPx3YIoFfqTp89AAz2bswKKRM53X4gI3fALBMguKbu9rq01SnX7 TJ+9AzFpE2ikXZzteAbs/bww9vXI9oTWP3x3Hnkf045psLYijULnwZYz1EkeDQ+obcphk4rR 2tuttXpoaUeLiDqD8J0u7Zw+BPArX8uVyXbtW37uIUTqtl5KsVXuwiZ6gnUUYpzoUscU3t0z XUXfu3XvHdk3KuuZIyAjm+8KGLgIjfH8D0q6M3RqdXK2O5gbF4Ekr7EJYEDsS3mIchJQunho +3cG18y4X2fcPq76D6OwExn0Rt7EVgIfrCWfKY1KRpT2F4Ej1yGPqjZRPR3O5rwBM0GzOQYC t6tdvHlppQM4U6DtNShPkXbJ2tdsgyLdaki1QAOToKI2rmS0oGwXKdfciDxns1RJr1iWknhL 8YgsN9TjOJogfzfOS54B//XJ0eOXzw+fvnAS7elgDye/vjw+7ds7ZnXXyyAwh22x4j1Y1IQG K+wfeOXvI30bLnLDjDgj1psb58ZWfh3VC7PNgiXrsmTIezYIIPETTULsSyuNYWnIjSvOSeNe l05g4UvbnDU620RzDgd7e8c1343CQozZZvaOG7H6LV/SBeDbzmGpeyvRCSaaU4EPWE0MJeeO Z2qA3pDIPb/wKJxDREzfuZpPxkPrelhN/O8KZifzB40p7CEdNwoV81BspBzRD77DiaQVFFxb 9nki/x9wpo8o/WYBAA== --OXfL5xGRrasGEqWY-- From michael@tis.com Mon Feb 2 19:17:19 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA18160 for ; Mon, 2 Feb 1998 19:17:16 -0800 (PST) Received: by relay.la.tis.com; id TAA11461; Mon, 2 Feb 1998 19:28:18 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma011454; Mon, 2 Feb 98 19:27:55 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id TAA14395; Mon, 2 Feb 1998 19:14:13 -0800 (PST) Message-ID: <19980202191413.13067@la.tis.com> Date: Mon, 2 Feb 1998 19:14:13 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] feature: thread_hash (EXPERIMENTAL) Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=gBBFr7Ir9EOA20Yy X-Mailer: Mutt 0.90i --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii This is the update of my `thread_hash' patch which fixes the threading to use hash tables instead of doing a linear search. Changes since the last version: - fixed segfault in mx_fastclose_mailbox() when closing nonthreaded mailboxes - fixed hash table cleanup when reopening a mailbox - optimized hash_delete_hash() to only check for the ->data member if specified me --gBBFr7Ir9EOA20Yy Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-0.90.me.thread_hash.1.gz" H4sICN+J1jQAA3BhdGNoLTAuOTAubWUudGhyZWFkX2hhc2guMQDsPGlz2ziyn+VfgXhqJzpI RZLlU3FqvBln461cZTs7OzWTp6VIyGRCkVoePl7i//76AMBLsp3jw/swqVmTAoFGo9E3GusF 87mw3+SJWORZZg/6+4Mnr51Pch6Esh9ERWs/8xPpeFPfSf1yjw3btlePbb2OI/FCzoQYieHg YLxzMIKX/f29jV6vdz/gyvD9g8HoYKyG//KLsLf2rV3Ro7+//LIh3v79n2eHLcfzklkcf+rH wgkDJ8VnljmuDy+zIPLwkcRXqUzwLZ/Pb+DpxmGMv//cEPqfGy8WTuSl9HWxDGUm1Wuc8tuS RuZJOg2DmX5dOEEE755D3QFeS3pBBq8yymjKeehcINAgomZYqGpP4gU8LmTmxQrInxt2ywcc Qurge0kYRAjVB1LJJKW3cIkPXu8nebNw8DfjY6D0ylCAwt8FTLQWs/gaW2SU4wPBLbBh6VzQ FEsnIQotge4y0aOAbNkypimXSRDh2hPpXpq9Sebu3mikOsOP4fZozM2jwXgX3lJJm4cPRikN LiInxJc4yWigt4KRacHuGlbjjzX25cbWb9ITv0pXbA3FcOdgMID/gPV29u/gXDXyTqYdWAPR G1rDwRYybe9Jd6MnuuI5cFMSXPiZaD/vYOcde0+8DlzfkaE47Yvj8FMQpeLpQv7ipn1/4fal lz/DoTQc/537QQqkjS8SZyHgdZ5ICaSZZ1dOIifiJs6F60RAdC9IsySY5ZkUQSaAM57EQLAY iHdjgMGHPAK+EJkvBeziIhXxnH7848178Q8ZycQJxbt8FgaueBW4MkqlcGB+bEl9IN2sAIbD XiA2Zwob8SIG6E4WxNFEyAC+J+ISmBB+A83URAqqJeLEQGo7GS4kEfESB3cA+xsRgqyZ8X3q u5Yoxdo9kECax4+XsEQfIMOir4IwFDMp8lTO89AycGCE+O3k/OXb9+fi6M3v4rej09OjN+e/ T2BE5sfwVV5KhheAsggAPCw0caLsBtZjwLw+Pn3+EsYd/f3k1cn577A08eLk/M3x2Zl48fZU HIl3R6fnJ8/fvzo6Fe/en757e3bcF+JMIoLSQLljC+a0lUBhT2ZOEKY1cvwOTJACuqEHiuBS ogTK4BKQdUif3b/HBpITxtEFLR5GFDSeiGAuojizxFUSAINlcXP3DYyCCyxxErl9S+zsbovX TpqKo0vY+OfOYpYE3gW8vj4Sg9EQVL14f3ZEi3oCq9ro/RREbph7UjxNM1IL/rNaYxBTW6l1 k8TU38RGUESkEqfIFrCgdh6hWgGKgOgloptaArtEnY3eZ5iVfvjiUAwm+OvKBzMl2t20g78E fOkdwphej74mMsuTSLR98TcAAE23OOPLo7OXoktzuqA5gEZtmkGGcqFn4T6ZMwPoh6B6wzB2 RTsN/lfCBrXxa6dDU1AX+xkNhp70LH/QIFwFgjpYQkOCReeuIgCB6Cq4CnUarhE3pAJFJJOM 8VBYWopcYDQscRkHnujCxjp6Pc15llmyYmX1fgobTfTKRtV3qiNo8jJFcDSOh8nsZ/AVQMDf iWlCFKENH0VjJK8zaCwT8A//Q4Oo0Aa9YESZXr6mFZOA8J2Dz0HWoUYwTc4S6e4jV3V++Mpo ocy3J4SL4I5mIcSXn5k5Ayawu1iKNpFKk6UjDoGhFQsXbGtIxJtwW1rnm/evXlWWSqh6Ep2k B671a9hkzbqb3UMnxb1T6D2YMk+6SJz/ICqP0UhcgEoElRSCI0QgHGDUzPWR7RTTLORiBr6O YN0XpJp2QKD/5gGYWBqHms91QCtfgYGDv5KV7iIPswAcSnQJk0CmWouCtXYW0oBChu0+Kfau TTP//LPgl8PDgok7HfHli9Cbq/fVEvXN/ayBIzwkFrS38GnY3tBnorvKELV+q7kHK3uT04EY dCZVflI/b/mhNkqLz+0KXoLVxDeaj5ARyio4mBRqcsk729XAmmzBSq+bLZZKIRBfBKjGBRgs 8VQs1UpQfYqg1ytzB3VWCpb7MRGCD+C70IA6dWEi6Gt0MVORxuOjRjFgpVSCNoVBlhis182d To3IMKBTpir9UfQ3G6AkyAjsWg/Zv8ul9Vd5yP43e8j+gzzk8fAvB/kvB/kvB/n7HOS6GlFK 1Nhh0hKFKV6jQZXGuiX9md0spSfnqltJKxfuZxNC1/iSpLYJ0E8AJYikMH5SW/kLZLeq3pP+ dLcP2HQBGVhjNvZVSvNZZEcbjsx3TWsJ5d3c4/VPviIOmXybIz75Zp908mNcvMld1h0boccq 44Rva40Tf6wZJ26smJitg+3dg/HefYnHFSMbxmm0Y+2IHvzlnOOGKMJKlcGCwLLUCMo+o1iz GX7iYMWT56fvj8Ww+P3i6NXZsRjwjHv71hAs4mh/gE+cVYijX389RaXYTeQyvJlm8aTSugDV Np3HEF1d5Uv9VXFSPvsoXZBmW7cAAcIpNk/YF47nc/RIlKrDr0INUv5ofVirde8oM/1Cpqlz IaeBRxi8Ojk7R1BzcJAjV6YTwkB1EkU7igv8RBsmwSiA4e0gWAMBzFHiewmOJwj4WzAxPZ3i VNg3piT0HzxlrzEljV83obgVx2/+dfzq7bvjCe54VXlirhR8fjDPtNXj4QC5azwcWntqo4Gs 04ycQtrDl8dHvx6fosjgzOWWDCwIoIK4ZPGS9wFZW+AHhTiLW8DszniTKHOaYHYjFumFQJEt 9cZNXNu/usOoA7qXo0ShsXCWS9RlmNkWl0GS5cATWcy8ATNFcWkcrGfhXKuRUY7hFa5hGQeY N0/RF8Ell0YABBfsY9YYo7Yy1f4LCsMsvsahKzXM9dr0MH6qa5frWoKXDzW27tUt9XENzbK9 t4Wbjw8j5mq5IFhTduhE++27c/CEnh+fHr8AWX/ZQa7qEc8rw1LskOZ4N7u2n6ld12kUbYVG 27scKVAns9lrum2o2PER9YZQV0IIyWEMrHqqhai9eQoLx73/W9rv9zcthr50Mp/wxeXugK8C y90Zl5aLoKnnwrkAlwoi19fTk9dH79QcAXDUdA6hoxvGqZzqfcUhCPYnGcH+IiXenx3TOLV+ A9YsT+frKsbo51qfSWWsot8dI3UPEssixOQIk5elWZZjzIJwGIpMWWtoaMjtEGMytNSZyynH dm02qt2OKPpBJyTp3u4eHojt7WnrhP+oUySvOGlZNIE6ji5AV9Wa8XjKNNsm/g0OITT9eIiL ebpqKUWkTGuGvg9Y+md92lawlFq1/Yw9Da+ju3ymFe4PtnCF+6Agh2NaYusjZltVp1v9wkkL PbKH+iGRixiTL4pFSSlRdFMTl5bZcYOLjC7tZ8bcYc5ElN2hOnMpbl8zvPoVmWzdjIWpXDel 4riVExajGzOK1v1M16tQ9LbEIXonYYM/amEeDvZ2rSHszHA4GOGLMl4hIIha+7BAgawg6as0 WOQYmmJshQKtDPpDJKd3nwSu6VAT7jvECsxYTQGgLo+j8IZY8jPLxr0AbM3eNRA1eblHUFZq iQrLdDoTJCkElpSmBCvrxY8UQZU42KLYQ7UpJlF6z1qUjiFGsBHQihXdRw8Fo1cWziYuxBu6 GRwCIg6KL9DKBU7B8wIKiNHQo1Yru1pNBh2wYgSu3EVjMxyORsazaijGpv5bqSt/pEGl5aZX Qeb6ZcunWIxQ39obWGNAfWt/t+QXCB84TLlUh9CLcPVp7eBWHdZYqUEaOqFSboPjeZyh0KpR pSSafgTuur9KORmLqCPSqnZqjoG2Qrr8FRp2NcSSim0MYpBidYqTSxLWuXnqa83TU60Vp214 MBgfjHbvc/ZWDW34e3s7EM+NwFzDU/Fkt9VCMbCQ/hGeF2AqMFGulCN0CYWntwpTf3S2Jz0e TVaNdAVWnShdkbY7Io0RnMpsfZJyCeAwNFXxGo/GGMauxTB9EOwu/o9GtVpDZA9mGQhlYSq5 aWRQMc6mjow2aQpUggzcw4OQSMzyIKQVleUXdaEn3diTdupcSpqV3F9bh0+iO6WVEZk51jbK 8MXJK/g+t0w0BNNzTgKxBn4qgHwVDBBEclKK4XQgiyAA+SlwoAzjpWyzcuS4sHIIRU7L9tga bYPXsj3AJ3ktALVljuQiPCSioxusyentWWITw8QD8Ju39fkNdgej09L2BJDDs6BHan3ldu6M /4gPp24MIVSUTRGmaC8tDKRAp3EruQNkYfCIi3TckJtu6S8q67vwTJwohYjZhpA5xk1FpId7 34V1GT2Ucgas6Q5Iup+mprW9/M4VhDK6yHxEe/cHYs1QARUni4PvRxLcGDcJKAIkAo++A9XP BuXV1rq6kNLMZg31xZb6wLoIKizDy5e8cJKBvTE57mDM2Dl88MqDFNReoFf+I+WhBPqrxIId 3tEuLgieW6VgS/B57+Pw8QF0prCmsSzRE0NYGLylvKIO6QO7tW4htWUQmggobbBXDVmN6nhE hmY42Nqz9pn6SHtD+bU4spWxA4+YblDDVKFol3YC3InfJJkHh7T75msF4gRA1LS/YxwO1PKt 9QwpK97GRPWttOLR6jXoItfkILCR6GLTniEdvxk5HPww1LDnQxFbuWEP2RUnCG3YjzFsBzu3 u2BXKPbawQySkq4VoJFsQI8Sl5EnAM+m7OFENmZYZIKbDxr9EcmdrRgAiHky1y5KiWxIWE06 +HrlgA0GvwBtOnrvvHkYjYfyEr9p+69ydTXfQXVn/mDzqg7X7Wcm/4ohScsUY+F3WBE8dKEH 8wuPM80Tw8Z4jl5hYtOnbOoRm7ZhvpXAbukvx1qaRTWS3HslQOpMoFQ9UkWB4mbQtAh9Bn7L JxyilA34ak4eZqhr1CdqVnI/Go3BsQS22C/ng7jYxYmA4jYdHtiwPVeOqXoh+0pbJokPgwyP hdX2FNlxhUKXvUgnRI/qpi/M6SaKGQxlvxOP1T1wG8VMYkmw+BjPigQ18E1fQ3tSBMyPNG8G 0VQfcvwx+AAtQAgib3u5RrpKIzrEt+iLdYpKmgbErwYllCHlf4SuxFjEnB18+ULy1q62sqSR kFU+8NZbYqmkTAn2CB1GVNyj0dAa7qkDJz2j5HhIupnBR4X4qmZ6yv50uaclyu+AC/gpFUio YsqlOxekRqaZWNLLH8MPGLTapXUrIyA0Cq3Vg3o/CjWtwWAaeS1d0T7F/TnFX8t+cl0FA1qM cbCAqspzsFlHm8CRtYk+yehppAcf+sliKmOUPSPTa8dNNAVuyyVW34xjr/VVGFZLte5AUqEo jCp4TtJORRFBmqIKh9cgunRC4H66xCBQz6syN1PRBmoihtgHAnMMHm2lCrA/n7hoAwBqxVRQ gEp5f/4cy2nwsIwLSmCeXPY1gCem9u1bIekDE8Wb5CohrGmKPl1NbD26h9AeWm1PzvILvHJi bTYjw3bnAFQaozTHggwLZkVKFfgEC5VQxvOzVOKhXhYnf0abnTWn2pwgWHesrb6uzEf4zcOn rfHD8hH3nGyPwTfsjZUDsaGPa+vRMvkhKlbWZ/1ctAby3mX51KfYa0Lt9tzyO2JdMI9fLRTT h8f9RchOMT8bVWTut2/Oj9+cq1VcyMy4/kE0j0UbfoHt4jXMI2cBhpaY8MHJgmJizuUhI0zR Xk6JGyoT1Im1hjN429amqvTnGm/o5hXMce/J5MqxzbqHLWsfixC2rBEnIYsiexcTC1hkDxQA qlNF2TyPXAqsFs4nMHwopqoyYA4mlkX2NaADij5OZLrq+B2vlZGnWDqBB4Pcl32L60czvD2V pFmnr8rY4D88JV0EERYfAH7sglLOKww+UVKJR0Wcv1rEAAbFGI+Ti+wneJKuLzbdPNlkhAB0 lspwTskw1lI/Ei2E911osdpLMycLXMOSVORj6Cnauh3GWywa/wbRwLNTleQyhRF0XpMnJsNq KiUo9Y/ltxYe/ZjCMaq8FebUc4LYpfwXIOHDuOLGS+H4oXw8D2RSbiQRILyhe12gXttpDusG A0AhGgUYMAQCjwS0b9qxjP2peKgID6kLcIB2Myk+5kDVmZxj8R/ZsTxJShQGuYwNpFQ6CRd8 zxz305WTePrAsJQnp10GQ4j7SPFNGoMdQB1gLJoB+CbO5AFOiQa+OLhhMnPS/kNhBu3Syas6 SP0onmIkJz7ioZBdcfcCvV0EZ6JHq6rxj+xSiP8xJzaXSFdurThuKoDq9RpnUUXYd+9RJfvn DPSRdnaZBdjHvfugU0dr+hJC7VSSwiDtaNklr6e5DNsOxLNKyPr/Dnd63IpSiT9Xa5savfpB SoFLp1O/r1EIYeWSBnl79irVoP3JqmIwBUZYNsQpdLRXsDbiN/25kuQutAKAoOOnwaR0TljS JNorRUIz9u2V3x+VFZAJAL58AZ+uVAdz9vb0/PS40+mUFUv9UJVKp/gstSY2GPvDImF3SCjz pCINeECNQl1WFSZdWIS1GB06LhWKB5QPoX1zkBW6xbURtQRqxWSGplMwWcnOBd2M84q8rLAt t5Y4FmhDu4JU4jsdRbenqwZDQFsebjqs2CvdRwvFij2z1gEwcVdBW8U9akCdBiwWmn34mkrF cBgbSu54+XqOCapUtUdVX+uSD84sKc2Mbkm8DMGch0XlGIYWc6x05/p30Cfmjg7hrkFyWsTA omJPdSkokV6ObgyOKWrT2LDoZswxUfDgJLgSYzYwhaLimv8g/z7Ga+Epno/BuvAiuanNX6Yy 9+Ip+3B40KcdLwOKjGZW9slSpSFSmCayUYRLlsdwArHoB71LiIWwxZA3izZHqRmkBzRiYQDu zRntDaJ2kThL8FhS8nvB6UN/hWrqHQ7WxLPR9rYlTriR6gLJMGUxHvypGEumrrMEyyr/m7NX mOG98pTph158suBygExdK5/KKAkw8akqqdsdTC51lQ+7bY2Gojfc2ba2hyojBjbOZPvuUJlV QhdKE7e8pDXxSsNNoTYtzFUZ4YHVYZCEzxewFx283FJ4fTOZkoZJAyyuJJZWt88gfFOOCvLc zMGT1HyJaojZvU+mICB3KuGMrLljxmnglI6URRxJ5UViPE2agVk6k7iKWZ4RpLucpICcea9P fvCdZqXsYhYUIjUrKrYEy1UPBROSjVCXLkPhO4h1CAE3XUCg9zXXC/TlLwOTANTvA5aOcaPL kpNb3DLFOleujKAUW0MT9rTVahqsB9uq4mpZuTBk/b3WlfVjphSidNfVmD92I+r9yvcn19+J bNxjM7cMJ+XUFn5jK01kAR5/RDnsOcR7Skr0hxWGTGW7CyOG/e6xX5UxbLt6OnO+YqNahbVq GKrmkNod2M/qXiSn7am0isSTpRKs/xy3xuSrbuvX8Cq6sXfLKVPlmCKjd4zsUARVVy5V0Vmh Nz5XeB1PpdR2UxV45SMJFztzDxGujeJaOw4qF7tR9GJKOuAfpf65xZyDGFeWmaeqEmh+pSLJ q6xn53kKswg2Raqlcm9y/RRIMVQyzWy98jJwYts2NaOwtXgVzPVXOAtB9jg1KtBUnmkzqfwT 2k7waYgKSwivtGLB96rMEEF7LV5Ns6souiIhAH/YPTxzNX2MpaIWpoco/EZ1Q2XI90VGxS0C AkuVVEWN9s8kBooHaGcMgxmgJSIF82pCVj5GU0P/7y2ot3y820hsbBPIBM+SYMCNphV6NZKT tzM9kH8G4NqwiUMUhHLcQKvnVKWEnlm/gGKIrxlYU0NxsPqqeFh3opP075i/nJ0mFbt6doMU XgoWWpeIlpEw7k6vZv9aasNVa0mDdtQFICp6Ho2HlUqDcmlu2SEDninqD7X8YBsn/ms2m5QL qbp2SWXwxOPRLpZZ97b2tovSwzLYsr+kk77P359W4mT0C0nJUS6VddlqPUcxZBRkOh+l9R5d NY3ccrhZMvOV33xbhcs103p8St9AWchrU8hZdRcA9Ym+XQLBbBx6iAI16ZJlmYkzdlL5wr50 48hzkhuQi8yPiZ3SfLmM+WSE+tMynPz6UKUMbXZGx+MxienW/p7KuQs9I6B3pic+K34f5deM i811m1wLK/Esl3QqMaaSQXO0aqHgom/hFnTHhOR8rkSJDkrKjsr56cnz8/OXp0CaM50gqpGV Tqj1/3lHtea2ay6wm9R4R51YA84XSA9DM1wr6g6mHcgYx9SPMxUSMLoklHzOI+kUhi/GaIVE F6/SpXSDOV4qDjJ9b+b/Krma1oSBIPpXFgpSmwS0REWhSA+52YsWLz0UJQS9KDQU6b933nxs Zq2B9ibEZDOzb97M7MyElTzVgSprsfzHaIaGQcDzS4JonYMR1dHlG5M1o4/M+QZCkX0xmfhY 0UAEFy35p8ZN7VlyP9AnFCKiEE7QYV9ORr4P+Devwysug2P3sNAWbIkC6I3zoDbVMT3LIevH phGhlyLm3apx87U8Ld7wcWtX8FeZ8O0Mok8ZFEvK+r1QQ3Wc30Kfr3ir48mBB+FHZ8xZhizV bFeLm39AtUU1js9u4zCnNb947qjEq7KnBZ4k83dLpz7/o0dTGk7eeZtk49SmTudLhAu5PRxW sDiYOf/GhpDRUV6Y24kVM8z+h4PT4skG6khfTDWDgEzlc/W6eRcnMHmeo4uknJWRpvQelAJ3 X1zMYnGdtrrG/ix97rraVutNRQBNaaMIY4LpaCgt3AS5B3xdocG2QlAwslQBd+2xjgnGY9Lu 2x6wUH2MP0nrqjx2KVd715SK51AAAA== --gBBFr7Ir9EOA20Yy-- From eisenbud@allspice.cs.swarthmore.edu Mon Feb 2 20:08:10 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA05847 for ; Mon, 2 Feb 1998 20:08:06 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id XAA21776; Mon, 2 Feb 1998 23:08:02 -0500 (EST) Message-ID: <19980202230802.61262@cs.swarthmore.edu> Date: Mon, 2 Feb 1998 23:08:02 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.89.1, 0.89.1i] My feature patches Mail-Followup-To: Mutt Development List References: <19980201201808.34760@cs.swarthmore.edu> <19980202163458.39122@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980202163458.39122@la.tis.com>; from Michael Elkins on Mon, Feb 02, 1998 at 04:34:58PM -0800 On Mon, Feb 02, 1998 at 04:34:58PM -0800, Michael Elkins wrote: > On Sun, Feb 01, 1998 at 08:18:08PM -0500, Daniel Eisenbud wrote: > > index-percentage adds a format specifier (%P) for the status line, which > > tells you how far through the index you are. This is particularly > > useful when in a limited display, when there's no other way to tell. > > This also adds %P to the right hand of the default status line. > > Redrawing the status line on every keypress seems a bit much. Why not just > make it change when you change pages or scroll the screen instead? I've > still seen the same amount of the total messages if I stay on the same page. I thought that's what I did. I certainly meant to only redraw the status line on a REDRAW_INDEX, not on REDRAW_CURRENT or REDRAW_MOTION. But maybe I goofed it up? I don't have time to look at the code this moment, but I certainly agree with you about how it should be done. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From michael@tis.com Mon Feb 2 20:15:51 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA09123 for ; Mon, 2 Feb 1998 20:15:48 -0800 (PST) Received: by relay.la.tis.com; id UAA11678; Mon, 2 Feb 1998 20:26:48 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma011676; Mon, 2 Feb 98 20:26:22 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id UAA16033; Mon, 2 Feb 1998 20:12:40 -0800 (PST) Message-ID: <19980202201240.42545@la.tis.com> Date: Mon, 2 Feb 1998 20:12:40 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90] feature: sort Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb X-Mailer: Mutt 0.90i --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii This patch enables the use of $sort_aux for sort methods other than just threads. In the event of equality on the $sort function, the $sort_aux function will be consulted instead of returning in a random order. So now you can do silly things like: set sort = from set sort_aux = size and it will do what you expect. me --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.sort.1 diff -ur mutt-0.90/mutt.h mutt-0.90.sort/mutt.h --- mutt-0.90/mutt.h Mon Feb 2 13:57:48 1998 +++ mutt-0.90.sort/mutt.h Mon Feb 2 20:06:27 1998 @@ -235,6 +235,7 @@ OPTBEEPNEW, OPTMENUSCROLL, /* scroll menu instead of implicit next-page */ OPTEXPIRES, /* honor Expires:-Header ? */ + OPTAUXSORT, /* (pseudo) using auxillary sort function */ OPTFORCEREFRESH, /* (pseudo) refresh even during macros */ OPTLOCALES, /* (pseudo) set if user has valid locale definition */ OPTNOCURSES, /* (pseudo) when sending in batch mode */ @@ -248,10 +249,14 @@ OPTFORCEREDRAWINDEX, /* (pseudo) used to force a redraw in the main index */ OPTFORCEREDRAWPAGER, /* (pseudo) used to force a redraw in the pager */ + + #ifdef _PGPPATH OPTPGPCHECKTRUST, /* (pseudo) used by pgp_select_key () */ OPTDONTHANDLEPGPKEYS, /* (pseudo) used to extract PGP keys */ #endif + + OPTMAX }; diff -ur mutt-0.90/sort.c mutt-0.90.sort/sort.c --- mutt-0.90/sort.c Mon Feb 2 10:46:33 1998 +++ mutt-0.90.sort/sort.c Mon Feb 2 20:09:14 1998 @@ -26,20 +26,31 @@ #define SORTCODE(x) (Sort & SORT_REVERSE) ? -(x) : x +/* function to use as discriminator when normal sort method is equal */ +static sort_t *AuxSort = NULL; + +#define AUXSORT(code,a,b) if (!code && !option(OPTAUXSORT)) { \ + set_option(OPTAUXSORT); \ + code = AuxSort(a,b); \ + unset_option(OPTAUXSORT); \ +} + int compare_size (const void *a, const void *b) { HEADER **pa = (HEADER **) a; HEADER **pb = (HEADER **) b; - - return (SORTCODE ((*pa)->content->length - (*pb)->content->length)); + int result = (*pa)->content->length - (*pb)->content->length; + AUXSORT(result,a,b); + return (SORTCODE (result)); } int compare_date_sent (const void *a, const void *b) { HEADER **pa = (HEADER **) a; HEADER **pb = (HEADER **) b; - - return (SORTCODE ((*pa)->date_sent - (*pb)->date_sent)); + int result = (*pa)->date_sent - (*pb)->date_sent; + AUXSORT(result,a,b); + return (SORTCODE (result)); } int compare_subject (const void *a, const void *b) @@ -59,6 +70,7 @@ rc = 1; else rc = strcasecmp ((*pa)->env->real_subj, (*pb)->env->real_subj); + AUXSORT(rc,a,b); return (SORTCODE (rc)); } @@ -70,6 +82,7 @@ ADDRESS *adr; char bufa[SHORT_STRING], bufb[SHORT_STRING]; char *fa, *fb; + int result; if (option (OPTREVALIAS) && (adr = alias_reverse_lookup (pa->env->from)) && adr->personal) @@ -95,15 +108,18 @@ fb = bufb; } - return (SORTCODE (strcasecmp (fa, fb))); + result = strcasecmp (fa, fb); + AUXSORT(result,a,b); + return (SORTCODE (result)); } int compare_date_received (const void *a, const void *b) { HEADER **pa = (HEADER **) a; HEADER **pb = (HEADER **) b; - - return (SORTCODE ((*pa)->received - (*pb)->received)); + int result = (*pa)->received - (*pb)->received; + AUXSORT(result,a,b); + return (SORTCODE (result)); } int compare_order (const void *a, const void *b) @@ -111,6 +127,7 @@ HEADER **ha = (HEADER **) a; HEADER **hb = (HEADER **) b; + /* no need to auxsort because you will never have equality here */ return (SORTCODE ((*ha)->index - (*hb)->index)); } @@ -164,7 +181,8 @@ if ((Sort & SORT_MASK) == SORT_THREADS) mutt_sort_threads (ctx, init); - else if ((sortfunc = mutt_get_sort_func (Sort)) == NULL) + else if ((sortfunc = mutt_get_sort_func (Sort)) == NULL || + (AuxSort = mutt_get_sort_func (SortAux)) == NULL) { mutt_error ("Could not find sorting function! [report this bug]"); sleep (1); --/9DWx/yDrRhgMJTb-- From nneul@umr.edu Mon Feb 2 20:22:39 1998 Return-Path: nneul@umr.edu Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA11545 for ; Mon, 2 Feb 1998 20:22:36 -0800 (PST) Received: from infinity.cc.umr.edu (infinity.cc.umr.edu [131.151.37.9]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id WAA21803; Mon, 2 Feb 1998 22:22:33 -0600 (CST) Received: from (nneul@localhost) by infinity.cc.umr.edu (8.8.6/M.3.01) id WAA08054; Mon, 2 Feb 1998 22:22:31 -0600 Message-ID: <19980202222230.20659@umr.edu> Date: Mon, 2 Feb 1998 22:22:30 -0600 From: Nathan Neulinger To: mutt-dev@cs.hmc.edu Subject: Problem with mime - I've narrowed it down... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mYCpIKhGyMATD0i+ X-Mailer: Mutt 0.89i --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Here is what I have been able to come up with. Depending on which of the two attached mailboxes I view with the following mailcap, with one, 'cat' hangs when trying to auto_view the second part of the only message in the mailbox. With the other, it works fine. (The content-length and line counts are wrong, but this shouldn't matter.) There is a ONE line difference between the files. ---- application/octet-stream; cat; copiousoutput text/plain; cat; copiousoutput ---- I tried to get the file as small as possible and still reproduce the problem. I did notice the following - and the reason I'm including it is because the counts are right near a "magic" number so to speak. infinity(12)>wc -l mbox.* 255 mbox.broken 254 mbox.working Now, I have gzipped and attached the mailboxes. I'd REALLY appreciate it if someone else can look into this as well and AT LEAST see if you can verify if the problem exists on your side as well. Ugh. I just found out something, this problem only occurs on linux. Or at least, I am only able to reproduce it with this particular mailbox on linux. In case it helps, I'm running on kernel 2.0.29, slackware 3.3, libc 5.4.33. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 --mYCpIKhGyMATD0i+ Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mbox.broken.gz" H4sICKuZ1jQCA21ib3guYnJva2VuAOxbaXfiVrb9nPsr9Kq6s1JdbUoSYBtXhgIhYQkQ1jy8 pBMNIIQGKBBgyOv+7e9cSQy2wXYlWet9eFUrxAZ0zz1nn32mK5mbTxMiGqbjT0GYBsN5xUtG lXQeV1JntakkYUwQ/WlKcEOXIGiCqt/Q1ze1K4JqNK6RPPSG4Wro3xAjLGWZzCtDf0l8Nx7O k+Gi4nmV3Uf/TVWpClWHV+Xy+pd3xCp0CFbpq3eEuyGeXv7ddeW6cvWhV6lVqMY7IvSJQbNJ V2vXlx+xNv8ETbBCWAmCqt3UqvAfcUFekiTxHaOo7x5rds607859AfrWKjR5BWpQl9SrFZYr eNVOYbD38rTC9NUNWXtO4XR4v1yc0Dd31Jkvj3Ru/PIOfQOKnrUbq1v/kP//HbEOs3FpHCh+ B4pf07Ur9M1oOie+T9PhMv5U2vnjCWuAEZc3NWxNHVvDYmv6w8XCCYYXPNjzPb6MpEka/rus 7KSfY9uPSJ3eEKKTjZ2UEGHr/LLHaiBl6U6GXnZDyMMboskpF906AeQiZk7mjYmRE8bL+XBB ID69mA9n8eYiA6nWdDknkkI1Yjoi3uS2kMfGVG+qjRuKJMAnlTeIOP63t4OqVhsUWSHpq2ty rxGBzAvO8UCbN+xq8ebXzkz45Zd/3ivv3L+p9Fv929+7o7tfQ/o3Nb6bW3/jV433qvRfl+9/ +8/7+N3bK/4deT+nfqyNR/7vb8lWDX1j8Gl1on10P8cff6e1z3/frusuV/vp79y3306uP3Ud 9ae3q1Yn+veSvPr+/eWH3yrcRfXXTvPTZetzPRAbP79ffPzVR98E7Z8Vg3j7Syj+qpFEV0sG cuXu+/9ZJvXN3fdD5+2/3ihC9yPzj3+P+vzH/uo7JxzQ2/800sr6p08//xixM6X96R/D31Cf 77MX+nC+CKfpDSBNImaaZsM0u1A3MzA6WcZZOHPm2YckvB/6Hwl3ukx9Z7754c0F/kf88Kuz /0e+2a/m25ggVI2sXF9f1oBAtXqFPEPwH1HbyWCvp14DCtZv6o2CgoiDALohusOUuJ3O00U2 DFPi+zxwnkpUMidbLoBGA/Df7k1zr15vmAbZ+IZo0OTldR31wnQI31NU46qO0MXFCdMe4ZIN 77MPs9gJ04+EN3bmi2H2w5vl4sJZeGH4PAzUWRjQj07qE9kYLIQgmfr+ntROhj8G8LMMkogD TsjyS1bDub8cEtgXbyqv09yZzeLQczJw+Ieplw2zi0U2HzrJszrTZ3XerWoPF948nGU5j9Lh mlgVpMLxmEyxt+ZFEB/UmTvpYjScX7CpN/UhHdwQrrMYXtYQUox6ZJvBJc8JnKTJoizNIsew E56hJjzTgO+slZvqC5dpzb2Ep3pUeZ06ve9NrG43nH7eXYfyC5ux6NK1QE70kGeaG77NUoMJ uxlMtC38Xh+oQbenkBnfyTbWRFtpkd6SWYpjNHvjKK2BW7WC/oQNUF+VLvvb6LI/8YK+GtXF 9fQz3u3Rq9Cg3Qzy98E0A+FBX1nf9yd8gDfqSdM5Ak0CnmnN7LA57d6KYz/RR5YhR17cWDim SPJtMuh2xKll8ljQjO9QY7dzv7I2461jzmKXtqYWPR57YfMz6ipNsHm89A1qbHfkjbdpzsG0 WVeJgjuV7HY3TYGRovIVD3Ttvt9VWldMuAgYw157Sbz0O9bUq8oRsk1h02OaoUOLmd2eBm5y HbiGnrlVoW52amFXXeQCvUQnfVNYdhnyvvwswFaNwDy+CS/4HcxsJW4VTOiAJkpzPdi0Znx7 HYBjstzctH/Fd6J5dxMFwzVeGJ+FBClaXVMpkQezCo+1ebLX7q95hsQgd2HHid3RE8eoxzzX uNUosaWxsWSSmSJN9JHCXeNr8GtVOmD3akmWKZCOIVJuh9vwrE25iQjvG0tvU4PNAF/W1tVI HMmkrmmsr2gAzW79I2GHlwbC/E488Y178FSr4xv1CbwHAveXTAgehs90rd42SYpTNVHEQs8K 27+41thL5ZlV1ReYHnKqL62qPHPp+rYHfOOZaSDH+kCiGiJSNU4ahC8IfCUEaIeBBhjokaDL cUORdZvTYpGTj/B4DQQIcwZ2bTCgHROeCKUg/xn0txINXqb6TDP/HHADbzdJcdtciG2vhr2P Cve3IiuhRnYn3thJfdXtyGFXAq2aMStFAHYih4M1vL/NyTqBrLLEdOE5XZX1BqNDxpHheuTR wcrpcFuHqU8Y3Y9tptXyDRz0fXhZl6LqXYrt/iuSQESjXptd98Od6s3ANsckhNiSZ2UGPIW1 Hpk4kOnxyK22YjccA4Hv4x6OnA6XehuIFgPymbIOEDA7ceEDu2MvLMPfluZNsOt9pjVxsOeY WS4ATB3jcHJTaduPGyRfrgHBmUvLMYJfIju5H9vV/lXuBEMEYkLqYcctjRwLamTfgbCZm9ir wTpaAVlVr6MDbtyC78gzSADYk7Rt9gNkJ40N3xE3tsGRNnClVwINFBAgrWx8AwTfiqRlSgG8 H/sdgbInizKOI7qECcdx9jUFfU1B/89TECzY2KZMeUlt2mXGvM5yOFvM7A6f3eXVWt+4Cbfo KuR7O23OBpi4jBi7t2KcV3VTiP1buCYMpqjLChp0Ndw5AVYqj+xEOghJ5JkdYC3J7r4du9XB EesVAgGbXp6vjpIkXpBYQc/oB05VCEWlQQHAix4th/2wAU2MOC3XLK0t7tPYZV+p3aNdz+Wb wB1o2qwJXwotFyX9S7hwUzinbPiqhSaPFUFYk0EpGXYQVOANz84oF7wLqeVe3E6pQXt6L26a 9wM1qhZePC30aw34WgO+1oCvNeBrDfhaA77WgP+rGvBncTqGCX0BTkEJB5hHAR00bGYhfFtY giwa8lFVChSWUxU2HsjRNQR2vLST6ytGuf7Mc+LaNsSZZeDdIY7BbMe0Y29TFCKrKsSWKcdg 0So3c7jONdv6twJlVUtsmNbW73CklerJ4Fl+Wdt+uKb72yBAZc4CYbnAPIQ8ptngH2QQYd1T 62CqHHtJfey2C7Mcw4ISienhzbDTEK80BcbIwcYLYi8Vlu4GhEHmgIUrfEola/FAj7h+ntOa 0b4gw4aQkYU7LYxyWiHGJAsaHC7ItTNpbmLR+tbbjEtt1wWuUDtlXVrAdawUS1Cl4rltRtgZ Y+R32BlO3QVvDvaXB2xfZD46Z/8j86c+13gRAvQcBl8KAXoOgx0EJ2jxuUiWTVpsRwtxotXB 7M+YGrvGQ8jz2m0Td0NThZNbEk5Nhhx6DPkewiYPOSBvmRDiBBTII4BnrIQvwskLeJUMtLgx UMmGIeuCqUWxJit5CzXGMJSbQLE5YIX7OtzL3SktDjopQ9LWV3kEMNK+3AVdVle0qKEUxbkp jIq4LXqyzt4hZcA3E55tjCRNbKtag0VyceoZqBS0BSxox0WnvHnak3qL0yLyaqcQekGjg8aF VtApihPbFLd7Lcu0BMIbiOeEkRo17vRIV3RKEHRWC+7WxQmxOJHqvbZFDZQi+RX9CAa/EJQf CLNjTdLwgXAcISttPqjiRfwVGOX5C3ARwnJ3hm2c2HwPC/pSlr8q0PNwYnaMhialyKoBaHVn klxbIqk7GWsB2GAPapF8p0b3dnE0zWIHTNFusXMLDcqBOwcNWV0C7okvaYWVQq+NvRK/Bmyk mGT9TqVwd+krii5zfPs6Dzl0NuZwRzgJ1jjmXhty6LmYO8Zjj+VpKAQ1tltILfPZoQNsTgEj RaX4WUmTxmGTYHqI06I1gCDH0dOSSBFad1LmukqOxZ1JCaxK1vvGFwS5BpGjllGDXtSo6KqP MNzPVE8wRF+St05heEwpdArIP4ojOgXk63EckyZ9wBKdA/NlLJ/WBbQbZwZtnG4CSlQOLem5 VHM60xQTyiHd5IFt7VqnXW3oKAClzhxSEaTrcRlWnMFJJ1PQn0o/u0DHg1VkQwoqewkVyr+m 6KKmaKJa8qyG6+OgrVFHPHsSp+hZjj3imbc5ZaotwGyq4dqJdu33ISXrls68TIM/XjcZEQYz ObbDFi/pIm9SoibpsqBRsiBR/f10h3bj3Ynpbvol050D8xXajXcvT3fBi9Pd8SA2/bPTHTpp 3tnpTnt2ukPleEfmYwtzFEqmPsJUGXAwcDGz0DF86NviUdHK5zOUZhvU2q0KYy+NAgk+h9lJ h9nJXnlhi1E0L3BovQ4cKmaoZkyZNMRgm6VNmA9A6Nbr3M+gWIe+YZVDhxy7ZmvlJdwGDZUW fGEntskH+VB2K67dTkweCWzrEJuQNYRuKsae3phAOG1hOimEsSLlpSJWhgIH6FGpWVEzq7Cg mO4ezJaMURAWTBR6m2kgY9LCuKPiczZsHT4kKQXlhyEwR2UeHnEMYYa1Gyp77Y6E1mOfapRD Wo6dgI8nLJojER46cZ9hJ1LgwO9Wwk0cwMne4NmpsbGVFt4MZ5Ongs3idM9O4oWtLgSEVcbh 4BjwRUff8rf+FEJrijH0aS1wEx3ThHTxFHerA3VauVY8WFCEYiQw+JCuo9eQY+J2/Xo32e4o cmjuvoAiaMeRv4IiaMeRv4IiaMeR11PkkNdKMzlI93jdAPkGFWJtcEOcawRDv6q0YF6n1jAu jy3wlGPKeJxZlZkXzO1vwFyghF41aRtopOXaIZ4FGnTiCZ6zYe6GStVKwHsz+D2ENn0O4Kf4 KAIABg/iYwvItCcEezRHI1s/TUDMP58ex35nHIMJVeDb0jYAilt5hVO9D1DAT6xVYJlS2QUB T/DxqG2OZz6DMZphgfGwPQ3OJUqTFmY2ncVD5eFZG3o+HcNEksQppkl5jlYevL2UaYEzBSGj 8rSOL44aXkjnx1qiv+ogDiuFnmi1jk3bkALJ1GG4YvGjPPRgolUHE4kuHuvxzk7GkLab20Hb WvS30eaoTYeWSl75nfsYtITeI/8551lBkMmMM7R7Tg3HayjescdEuxFxhnAHdKjapf16HnOz XVawUyG2lcMotHMK4EXZeePyaNx5eEF+flGeVk1nrsEt3E5j0r3daXvQBivDl50UglbqQVop jr+iB51jT2Vnu5YK31+xqq360Yi9X4+wAJ5ZBG5HX/aa5WNN2wAfitd3J3alFhBS8sI2arhZ yX92Nzhd+T1Zj/uyVpsiyPmpbTb3OxcnL093faC1YW9sQ3uCNdqBPXjSQj1wRt7Q+XoDp6Ia TpDQ22aWcb9w6f4UagWJLUO71qns6ccvefbQhgZZX9k7IoPUPUHebXSOGhgTjM3iuZsOYru5 7rWltZg/5bVv0/N28wGgOzzzUbrdnO2OXMtrn/AOlcQrLpLiBMyIzzpAfXJ48uB79PBhtQOo GNDuiWnlrIMAEoT5MgA+7cEsTxN2HsKb5T+Bi1IU3yqkbqusPujetsY2ra8Pp4LSGvWZNdlv W0fHgkWInFyYD2fNdTEqHsLpaKr7c8F9/D16FNxl5R6PcD3oGvuH/TBFZidGnrPCPpR565Iv b4genVa9GJeYRqiMy2eOm2Fs2KxJUY2Cw2nzyRiOEK7ar+BadHTd1bksgkp1WRhfWo9dfoKg R0KfJlD0mgx6QrudFYeZC3A+yhpU7BrieviIDjbucQ+BvzcNSt4Ti1BBxvWOxXuwDyQ+DfYp rNEfBfsU1ugLwD5H6N1GM/Qg9zPcObz+aKbFB+TcaFe19tmDIfOsIbOcJj2s6Asmwg0jtO4D 6GeP2qmZm4gL35Bj/L4H84GVkEunefRc8qmuyKhPYEaIkK3AByEFkoWsnHaf6cHipUXfU3ZH w+8zaApDVymH3qA4czw1f5/WsH24y8po1MoNW10fPMu3eRhqvUskqqAN8KqccPOK/mrhzYft Fzr0X9r9S/0XtF9VkVlXB8qDe+n4s5oIIxLa9RJ4PmKUh/fTea4x0phgKrOCiIO5vIGPq7rA dwAvPT++xgPFyKSa+NY3HiKanwHQUxdPgBZjDx9elgseX9/dNPNhzIEWHt/fxL1XNR8eOscP J7RACIyIdH0BcxUNJXBml0+dSKmMG5dsd28A4yaz/Abhu/T44QQHxjwbZ44Uk7Z4LqOYRBYB jgTfIHfa4huCG7+DO+yH2ua3cSEGKVeJirv4+BbRrZ7t8HMhOk4t7Oah9HAjBDutARMaF5Yz gI9MUh/IXIOVNbGvlUeC+0cHQoxZc2ySdRZJEYUfesmn4cfPEhSsh7Y+zKME35mFOctbOkx9 5gZPQwwdx5hLC58LUoorN7Fn9qY+7SXx8mjwOEXolZVM8/DKb+PC9J9CXC4do3YJJmdu1Y7t ZtF/Pbf48Vq0D2yp+IMDJcXpJv+DAxwVtcGE30fG8R8cnLIIPTapDOCObfBlAGuX+JSqPyme Pxg0zxdsHJsLUfX2f5HAMzC8d86AHkKGYH3wor7BkzOQeAwarqBm/m8n19acqBKE3+evbG0V l3VPeAQCCkYSBQblTSFBBC+JiYK/frtnQAF1z+4+WCllmJ7p7unL1z3Brpwl+M2iB5pfLiQG 3zAegFnOcZVW34ZnJvBL2YaBCZK2kAUIAnyCenDCBkyKpXJXE8ii1BCyEkApMT8X8IyhzsWS UgLlbCHRE+blsa7JkKd/PKVqBaqoqxhVCXxHVYsfgtVQ8QEeViMMIOeG8xj3H5LZgH5FUr6B LWU2AwLUh0jOT0/ypBf16Qkk+A20/gBn88uGvAC7cbAgk9+iBhP9DKkiYN8UfhjMVXd79SHa HuSH2EUMJMytwWQL29SIlzu2ZYySOZgamL3kiABQvkHAFyfGWFSsiW8aE2p7XUKkRQki7mhg H1gBS2IQDsMzwBwhvzL8O59OttVKQLlZ+wW4x94OhLAiM7SwMDuaodkmF2DQej61T+C1IXzP P+C7Ax77EIHdm7nacrEewwo1zc9GezjDX9UYG2vpZKHzATQzZ0MX9IjZMJhcplWLU/ziZxNv KmBKDdbDyDUvqVXDERccpj4hj0mTyecJBvSN3XpJWi+IU9nZwnaF7th5tTvS/BHM91d4vKJa p4UtYTTSxfPvBB/gzCMvfIvVzkouAFxrIjb+ZF+NJ/wFhjQNKwW+6Jrs7F7XlL90RYjlW63x BJZ7mveV8uaqrn4rwMJEV0RrTJLcYiY+aP3ev73dim+FkysdAfRb2+2+wCHChsbT/hKUvScu AhvxtQOsPCWvFaIHBnHJJtRv6ZpjBxl9meSK7eVn3raMA0ae5DVQRAsC5JhZC6SGIbx4wO/h uafxx8WOXXhojWlo8qZJ8YVm/m0ThFRuEPmIZITr1btESIfKE1gG06Pq8I+JgDFggc1aKUkz WLlldlzDDCZU8bD9kJXTkpsmG610jyxkoNg3JbThaLJfwBJgb2yo97YvqVbb/oQh67cMgbHU aEbfqN+zCRq8qVBdwntUqzTnChE9xoPsAAmIEA0mCGYOISBcgyn/nJWXQJpgTMEGSHEeD9Cx NBsCrbZHl/G5soFMDievgM7xGegkDe/cpX4J45PqemGfrvBqIXyE55VawudH09t3+xy7E1YI 6SSflWrhuPB53JbP3rZEtJQjpM0ybhcoWo32zqqRj/Ne2nOSOuKV7FUYFKcQVSfjApgKsUmo qfmBy4Fv9qK6XVZ9s+9YV3nBGgpCObqVQHCSxymuPv98kpw9hA65lR55s40Zu+TNUN68DBTV MEOIFFkZyDU1GlTIuiWB1BoqANJ3wdU5LIJsXopchxnBHu2RDtuCLwz3YQ1/SXpeRV/8YaUF q6dT0X6AVYBToaMxhRgYw/YcoigImOfTEQTIx0Z8mtRdN5xv59T6D/lGkHF/wTeIGKnE9C0Q wFmj5fVTiNjZysnV0nmRwfJNOsNz2qlmn8/p2Be9M/E+wyvfCaOsI4x1fxWLKfCQd9xM/Q3w D8L0iV9oAeQCeOB9Cbz91N6RqKylhgc3X/+2Q9oziqdHo3hu1EHZygZCgvyDTJgDa5xXedWR 77B+A2ujFdHGgQQ/lF8H+U/fNF1fHKfP5W4VPe6TmazW3fkIGvD29EjWSlaQT5enBZqjAOGH Y9pQ0lmgWzUwzAhHUoFFPyx8LVgsFyhr0pKQa+2mLmIYjDLDOvg2nD0GdYgoBNwxgzdKmsSO VprHDA21T+qmwjeqDG+WDHnb6/aygtne0kNIyqxdpegVhmRj++xH3U3IJmDVMH2JAC8qZTJ3 1QeWcoMbHJZ7BvhyA2oU7LKxl3SVWgETRPeR5HMmckW1q4lXvEnSPkYY/A2oFMvL3muuTVjj wmr/DgL4zwJh1cRYL1XFl8sF4ubWUn4JG+1bYCZpjRvd4iW5ZmaWggLDdsyYoctr5/h/UqyF SJgUp2prgn8VCOlK5G8Ect19cwFAitHK2I88S27Vn3jR4f1yhrH22QOn3RNDDjHycay+2Y8x L0JeMW/OQLlpi7Hg/ouGwXxIh1TAMsgm1qMW4EmwN5vB9Q3JAP++1ZLCZ6EMiQSiymeAnLMC 7RmoFTPZKGXOM7dpCNXP0RmWN0p+Gz66BjT13TrUkY/qDnTtAEnFDu/w53XHEQ5EhxJKCqQx Wt0uwKo+v1OJpxIkqkMYOrqz/3/ZPrm3/3vbv/NPGr5/J+QXcaenTLJHAAA= --mYCpIKhGyMATD0i+ Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mbox.working.gz" H4sICKuZ1jQCA21ib3gud29ya2luZwDsW2l74laW/pz7KzRV3XlSXW2XJMA2rupKQEhYAoS1 L5NMogWE0AIFYs10//Y5VxKLbbBdSb5N1RNiA7rnnvOe92xXMjebJEQ0SEc/BWEaDGaXXjK8 TGfxZeosN5dJGBNEb5IS3MAlCJqgarf0zW31mqDq9RskD7xBuBz4t8QQS1kks8uBvyB+GA1m yWB+6XmXu4/+m6pQl1QNXpdXN7+8I5ahQ7BKT70n3A3x9PIfbi5vLq8/dC+rl1T9HRH6RL/R oCvVm6uPWJt/giZYIawEQVVvqxX4j7ggr0iS+IFR1HePNTtn2g/nvgB9q5c0eQ1qUFfUqxWW L/GqncJg79VphenrW7L6nMLpYL2Yn9A3d9SZL490rv/yDn0Hip61G6tb+5D//x2xCrNRaRwo fg+K39DVa/TdcDIjPqXpYBH/VNr5+YQ1wIir2yq2poatYbE1vcF87gSDCx7s+YQvI2mShv+u LnfSz7HtM1Int4ToZCMnJUTYOr/ssRpIWbjjgZfdEvLglmhwykWnRgC5iKmTeSNi6ITxYjaY E4hPL2aDaby5yECqNVnMiKRQjZgMiTe5LeSxMZXbSv2WIgnwyeUbRBz/29tBVSp1irwk6esb cq8RgcwLzvFAmzfscv7m1/ZU+OWXf66Vd+7fVPqt/v3vneH9ryH9mxrfz6y/8cv6e1X6r6v3 v/3nffzu7TX/jlzPqM/V0dD//S3ZrKLvDD6tjLWP7pf44++09uXv21XN5ao//p37/vvxzU8d R/3x7bLZjv69IK8/vb/68Nsld1H5td346ar5pRaI9Z/fzz/+6qPvgtbPikG8/SUUf9VIoqMl ffny/tP/LpLa5v7TwHn7P28UofOR+ce/hz3+Y2/5gxP26e1/6unl6seffv4csVOl9dM/Br+h Ht9jL/TBbB5O0ltAmkTMJM0GaXahbqZgdLKIs3DqzLIPSbge+B8Jd7JIfWe2+debC/yP+Nev zv4f+Wa/mm9hglBV8vLm5qoKBKrWLskzBP+MWk4Gez31GlCwdlurFxREHATQLdEZpMTdZJbO s0GYEp/ywHkqUcmcbDEHGvXBf7s3jb163UEaZKNbok6TVzc11A3TAXxPUfXrGkIXFydMe4RL NlhnH6axE6YfCW/kzOaD7F9vFvMLZ+6F4fMwUGdhQJ+d1CeyEVgIQTLx/T2pnQx/DOBnGSQR B5yQ5ZcsBzN/MSCwL95cvk5zZzqNQ8/JwOEfJl42yC7m2WzgJM/qTJ/VebeqNZh7s3Ca5TxK BytiWZAKx2Mywd6aFUF8UGfmpPPhYHbBpt7Eh3RwS7jOfHBVRUgxapFtBlc8J3CSJouyNI0c w054hhrzTB2+s5Zuqs9dpjnzEp7qUuV16mTdHVudTjj5srsO5Rc2YtGlq4Gc6CHPNDZ8i6X6 Y3bTH2tb+L3WV4NOVyEzvp1trLG21CK9KbMUx2j2xlGafbdiBb0xG6CeKl31ttFVb+wFPTWq iavJF7zbo1ehQasR5O+DSQbCg56yWvfGfIA36kqTGQJNAp5pTu2wMenciSM/0YeWIUdeXJ87 pkjyLTLotMWJZfJY0JRvUyO3vV5am9HWMaexS1sTix6NvLDxBXWUBtg8WvgGNbLb8sbbNGZg 2rSjRMG9SnY6m4bASFH5ivu6tu51lOY1E84DxrBXXhIv/LY18SpyhGxT2HSZRujQYma3JoGb 3ASuoWduRaiZ7WrYUee5QC/RSd8UFh2GXJefBdiqIZjHN+AFv4OZzcStgAlt0ERprPqb5pRv rQJwTJabm/au+XY062yiYLDCC+OzkCBFq2kqJfJgVuGxFk92W70Vz5AY5A7sOLbbeuIYtZjn 6ncaJTY1NpZMMlOksT5UuBt8DX4tSwfsXk3JMgXSMUTKbXMbnrUpNxHhfX3hbaqwGeDL2roa iUOZ1DWN9RUNoNmtfyTs8NJAmN+Ox76xBk81275RG8N7IHBvwYTgYfhM12otk6Q4VRNFLPSs sP2La468VJ5aFX2O6SGn+sKqyFOXrm27wDeemQRyrPclqi4iVeOkfviCwFdCgHYYaICBHgm6 HNcVWbc5LRY5+QiP10CAMGdg1zoD2jHhiVAK8p9BbyvR4GWqxzTyzwE38HaDFLeNudjyqtj7 qHB/M7ISami3442d1Jadthx2JNCqEbNSBGAncthfwfu7nKxjyCoLTBee01VZrzM6ZBwZrkfd FrvqhbvdGoFtjkiIigXPygyAizcamjj26NHQrTRjNxwB59ZxF5O9zaXeBghuQApSVgECMiYu fGC37bll+NtSozH2ls80xw4Gm5nmAkC7EY4AN5W2vbhO8uUaEJy5tBwj+CWyk/XIrvSuc9wM EbgE2YIdNTVyJKiRfQ/Cpm5iL/uraAn8Ur22DqZyc74tTyFmMfi0bfYCZCf1Dd8WN7bBkTa4 t1tiA14TIBNsfAME34mkZUoBvB/5bYGyx/My9CK6hAmHXvYta3zLGv/PswYs2NimTHlJddJh RrzOcjhbTO02n93nBVbfuAk37yjkezttTPuYuIwYu3dinBdiU4j9O7gmDCaowwoaNCLcOQFW Kg/tRDoISeSpHWAtyc6+g7rTwRGrJQIBm26er4IlpJutw9TGDF6QWEHX6AVORQhFpU4BwPMu LYe9sA59hzgp1yysLW6t2EVPqa7Rrk3yTeAO9FnWmC+FlouS3hVcuCmcU/ZolUKTx4ogrEm/ lAw7CCrwhmenlAvehdSyFrcTqt+arMVNY91Xo0rhxdNC0QPzdD+2mWbTN3Cv1oOXdSWq3pXY 6r2id4vobzXgWw34VgO+1YBvNeBbDfhWA76iBvxZnI5hQl+BU1DCAeZRQAcNm1kI3xaWIIuG fFSRAoXlVIWN+3J0A4EdL+zk5ppRbr7wnLiyDXFqGXh3iGMw2zHt2NsUhciqCLFlyjFYtMzN HKxyzbb+nUBZlRIbprn12xxppXrSf5Zf1rYXrujeNghQmbNAWC4wDyGPadT5BxlEWHXVGpgq x15SG7mtwizHsKBEYnp4U+w0xCsNgTFysPGC2EuFhbsBYZA5YOESHyzJWtzXI66X57RGtC/I sCFkZOFeC6OcVogxyYIGhwty7UyaG1u0vvU2o1LbVYEr1E5Zl+ZwHSvFElSpeGabEXbGCPlt dopTd8Gbg/3lmdhXmY/O2f/I/InP1V+EAD2HwddCgJ7DYAfBCVp8KZJlgxZb0VwcazUw+wum xq7xEPK8dtfA3dBE4eSmhFOTIYceQ76HsMlDDshbJoQ4AQXyCOAZK+GLcPICXiUDLa73VbJu yLpgalGsyUreQo0wDOUmUGwOWOG+Dvdy90qTg07KkLTVdR4BjLQvd0GH1RUtqitFcW4IwyJu i56svXdIGfCNhGfrQ0kTW6pWZ5FcHFQGKgVtAQvacdEpb572pN7ktIi83imEXtDooHGhFXSK 4tg2xe1eyzItgfA64jlhqEb1ez3SFZ0SBJ3VgvtVcagrjqVat2VRfaVIfkU/gsEvBOVnuOxI kzR8hhtHyEobD6p4EX8FRnn+AlyEsNydYesnNt/Dgr6W5a8K9DycmB2joUkpsmoAWt2bJNeS SOpexloANtiDWiTfq9HaLk6TWeyACdotdu6gQTlw56Ahq0vAPfElrbBS6LWxV+JXh40Uk6zd qxTuLn1F0WWOb93kIYfOxhzuCMfBCsfca0MOPRdzx3jssTwNhaDGdhOpZT47dICNCWCkqBQ/ LWlSP2wSTA5xWrQGEOQ4epoSKULrTspcR8mxuDcpgVXJWs/4iiDXIHLUMmrQixoVXfURhvuZ 6gmG6Gvy1ikMjymFTgH5R3FEp4B8PY4j0qQPWKJzYL6M5dO6gHbjTL+F001AicqhJT2Xak5n mmJCOaSbPLCtXeu0qw1tBaDUmUMqgnQ9KsOKMzjpZAr6U+lnF+h4sIpsSEFlL6FC+dcUXdQU TVRLnlVxfey3NOqIZ0/iFD3LsUc88zanTLUFmE01XDvRrv0+pGTd0pmXafDH6yYjwmAmx3bY 5CVd5E1K1CRdFjRKFiSqt5/u0G68OzHdTb5munNgvkK78e7l6S54cbo7HsQmf3a6QyfNOzvd ac9Od6gc78h8bGGOQsnUh5gqfQ4GLmYaOoYPfVs8LFr5fIbSbINauRVh5KVRIMHnMDvpMDvZ Sy9sMormBQ6t14BDxQzViCmThhhssbQJ8wEI3Xrt9RSKdegbVjl0yLFrNpdewm3QQGnCF3Zi m3yQD2V34sptx+SRwJYOsQlZQ+ikYuzp9TGE0xamk0IYK1JeKmJlKHCAHpWaFTWzAguK6e7B bMkYBWHBRKG7mQQyJi2MOyo+Z8PW4UOSUlB+GAJzVObhEccQpli7gbLX7khoLfapejmk5dgJ +HjCojkS4aET9xl2IgUO/G4l3NgBnOwNnp3qG1tp4s1wNnkq2CxO9+wkntvqXEBYZRwOjgFf tPUtf+dPILQmGEOf1gI30TFNSBdPcXc6UKeZa8WDBUUoRgKDD+naehU5Jm7Xb3aT7Y4ih+bu KyiCdhz5KyiCdhz5KyiCdhx5PUUOea00k4N0j9f1kW9QIdYGN8S5RjD0q0oT5nVqBePyyAJP OaaMx5llmXnB3N4GzAVK6BWTtoFGWq4d4lmgQTse4zkb5m6oVM0EvDeF30No02cAfoqPIgBg 8CA+toBMe0KwR3M0svXTBMT88+lR7LdHMZhQAb4tbAOguJOXONX7AAX8xFoFlimVXRDwBB+P 2uZo6jMYoykWGA9ak+BcojRpYWrTWTxQHp61oefTMUwkSZximpTnaOXB20uZFjhTEDIqT+v4 4qjhhXR+rCX6qw7isFLoiVar2LQNKZBMHYYrFj99Q/fHWqU/lujiSRzv7GQMabux7beseW8b bY7adGip5KXfXsegJfQe+c8ZzwqCTGacoa05NRytoHjHHhPtRsQpwh3QoWqX9ut5zE13WcFO hdhWDqPQzimAF2XnjcujcefhBfn5RXlaNZm6Bjd32/Vx526n7UEbrAxfdlIIWqkHaaU4/ooe dI5dlZ3uWip8f8WqNGtHI/Z+PcICeGYeuG190W2UTyJtA3woXtud2JVaQEjJc9uo4mYl/9nZ 4HTld2U97sladYIg56e22djvXJy8PN31gdaGvbEN7QnWaAd2/0kL9cAZeUPn63Wciqo4QUJv m1nGeu7SvQnUChJbhnatU9nTj17y7KENDbKesndEBql7jLy76Bw1MCYYm/lzNx3EVmPVbUkr MX8wa9+m5+3mA0B3eOajdKsx3R25ltc+4R0qiVdcJMUJmBGfdYD65PDkwffo4fNlB1AxoJ0T 08pZBwEkCPOlD3zag1meJuw8hDfLfwIXpSi+U0jdVlm937lrjmxaXx1OBaUV6jErsteyjo4F ixA5uTAfzhqrYlQ8hNPRVPfngvv4e/QouMvKPRrietAx9s/nYYpMT4w8Z4V9KPPWFV/eED06 rXoxLjGNUBmXzxw3w9iwWZGiGgWH0+aTMRwhXLVfwbXo6Lrrc1kEleqyML40H7v8BEGPhD5N oOg1GfSEdjsrDjMX4HyUNajYNcTV4BEdbNzjHgJ/bxqUvCcWoYKMqx2L92AfSHwa7FNYoz8K 9ims0VeAfY7Qu42m6EHuZ7hzeP3RTIsPyLnhrmrtswdD5llDZjlNeljR50yEG0Zo3fvQzx61 U1M3Eee+Icf4fRfmAyshF07j6FHiU12RURvDjBAhW4EPQgokC1k57T7Tg8ULi15TdlvD7zNo CkNXKYfeoDhzPDV/n9awdbjLymjU0g2bHR88y7d4GGq9KySqoA3wqpxw84r+auGNh+0XOvRf 2vql/gvar4rIrCp95cG9dPxZVYQRCe16CTwfMcrD++k8Vx9qTDCRWUHEwVzewMdVXeDbgJee H1/jgWJoUg186xsPEY0vAOipi8dAi5GHDy/LBY+v72wa+TDmQAuP72/i3quSDw/t44cTmiAE RkS6Noe5ioYSOLXLp06kVMaNS7a7N4Bxk1l+g/BdevxwggNjno0zR4pJWzyXUUwi8wBHgm+Q O23xDcGN38Yd9kNt89u4EIOUq0TFXXx8i+hOz3b4uRAdpxZ28lB6uBGCnVaACY0LyxnAhyap 92Wuzsqa2NPKI8H9owMhxqwxMskai6SIwg+95NPw42cJCtZDWx/mUYLvzMKc5S0cpjZ1g6ch ho5jzKWFLwUpxaWb2FN7U5t0k3hxNHicIvTSSiZ5eOW3cWH6TyEuF45RvQKTM7dix3aj6L+e W/x4LdoHtlT8jYCS4nST/40Ajopqf8zvI+P4bwROWYQem1QGcNs2+DKAtSt8StUbF88f9Bvn CzaOzbmoevs/IuAZGN7bZ0APIUOwPnhR3+DJGUg8Ag2XUDPxUzkjqJvr/+vk2poTVYLw+/yV ra3isu4Jj0AAwUiiwIC8KSSI4CUxUfHXb/cMKHjZs7sPVkoZpme6e/rydU96oPnVTGLwDeMB mOUSV2lbDjwzgV/KOg5NkLSNLEAQ4BPUgxM2YFIslXuaQGaVhpCVAEqJ+bmAZwx1LpWUCigX M4keMS9PdU2GPP3jKVdrUEVdpKhK4DvqWvwArIaKD/CwGnEIOTecx9R6yCZ9+pVI5Qq2VDgM CFAfErk8PsnjXmLRI0jwG2j9Ds7mlwN5AXbjYEGmvEUNJvoZU0XAvin8MJir6fayINrul7vU QwwkLu3+eA3b1Ihfuo5tDLMpmBqYveKIAFC+QSAQx8ZIVOxxYBpj6viXhEiHEkTcSd/ZsQKW xCAchmeAOUJ+Ffh3Go3X9UpAuVn7BbjH3gaEsCATtLAwO5qhyaoUYNByGjlH8NoQvpcf8N0F j71LwO5NPG0+W45ghZoWFMMtnOGveoyDtXQy0/kAWpiTgQd6xGwYTC7TusUpfQmKsR8JmFKD 9TBKzc8a1XDFGYepj8hj0mbyaYI+fWMXVbLOC2Iku2vYrnA5dlrvjrR/BPP9Fe+vqDZpYUcY rXTx9DvBBzjz0I/fUvViJWcArjMRG390rsYT/gJDmga1Ap91TXY3r0vKX7oixPKtzngCyz1O LaW6uaqr3w5gYZIrog0mSW4xEx90frdub7fm28EtlQsBWJ3tXr7AIcKWxlNrDsreE2ehg/ja Dlaek9ca0QODOGcT6rd0zXXCgr6MS8XxyxNvO8YBI0/yGiqiDQFyyqwFUsMQXtzh9/jU0/jj bMfOPLRHNDZ506T4QovgtglCKjeIfCQywvXqXSLkgsoTWAbTp+rgj4mAMWCBzVKpSDtYuWV2 PMMMx1Txsf2QldOymyYbrXSPzGSgaJkS2nA02S9gCbA3NtZ765dca2x/xpD1W4bAmGu0oG80 6DkEDV4k1PfmHtU6zblCRPdpv9hBAiIk/TGCmQMICJdgyj8n1TmQJhhTsAFSWqZ9dCzthkC7 69FlfK6sIJPDyWugc3QCOknLO19SP4fxWX0j0KILvA0IH+F5oVbw+dH29pd9jpcT1gjpuJxU 6sH14PO4rp79dYVoKUdI22XcS6BoMdy6i1Y+zntpT0nqkFeyF3F4OMaoOgUXQCSkJqGmFoQe B77Zi+p6XvfNvmNd5QVrKAjl6HYGwUmZ5rj68vNJcrcQOpR2vufNNmbqkTdDefMLUFTDjCFS ZGUgz9RoWCPrtgRSa6kASN8DV+eyCLJ9j3EZFwR7tIc6bAu+MNyHNfxl+WkVlvjDzg+snk5F 5wFWAU6FDkcUYmAM20uIoiBgnkZDCJD3rfg0a7puON9OqfUf8o0g4/6CbxAxUonpWyiAs0bL G+QQsbOVk6ul8yKDHZh0guf0opp9OqejQPRPxC2GV74TRllHGOv+KmYR8JB33ETBCvgHYfo4 OGgh5AJ44AMJvH3kbEhSNVLDg1suf9sh7RuHp0fj8Nyqg7KV9YUM+QeZMAfWOK/KuiPfZf0G 9ko7JCsXEvxYfu2XPwPT9AJxlD9Xm0XyuM0mstp05yNowNvTE1mrWEE+nx9naI5ChB/2eUtJ J6FuN8AwI5xIByz6YeFrxmK5UFmSjoQ8exN5iGEwygzr4NtwtxjUIaIQcscM3ihrE9vbeZky NNQ5qqsa36gzvEk24G2v6/MKJltbjyEpsze1otcYkoPtsx9NNyGbgFXD9DkCvKiU2dRTH1jK DW5wUG0Z4MsNqHFg94P97FKpFTBBdJtIAWciV1SnnnjBmySdfYLBX59KqTzvvZbamDUuLLbv IID/bBBWQ4z1UtV8Od/5bW8t5/em0b6FZpY3uNEtXpJrZhY5KDBsx0wZurx09/8nxUaIhEkx UjsT/KtAyKVE/kYg1903ZwDkMFwY26Fvy536Ey86vJ/PMNY+e+C0e2LMIUY+jtU3rRTzIuQV 8+YMlIs6jAX3f2gZzId8QAUsg6xSPekAngR7sxlc35IM8O9bIyl8FsuQSCCqfALIOSvQnoFa MZONUuY889qGUP0cnmB5o+IX2JNrQFPfLGMd+ahuQNd2kFRs8Np92XQc4UB0KLGkQBqjNe0C rOrzO5V4qkCiOoShwzv7/5ftk3v7v7f9O/9X4ft3Qn4BeS6mbmVHAAA= --mYCpIKhGyMATD0i+-- From eisenbud@allspice.cs.swarthmore.edu Mon Feb 2 20:22:44 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA11595 for ; Mon, 2 Feb 1998 20:22:41 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id XAA22251; Mon, 2 Feb 1998 23:22:38 -0500 (EST) Message-ID: <19980202232238.08166@cs.swarthmore.edu> Date: Mon, 2 Feb 1998 23:22:38 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.89.1, 0.89.1i] My feature patches Mail-Followup-To: Mutt Development List References: <19980201201808.34760@cs.swarthmore.edu> <19980202163458.39122@la.tis.com> <19980202230802.61262@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980202230802.61262@cs.swarthmore.edu>; from Daniel Eisenbud on Mon, Feb 02, 1998 at 11:08:02PM -0500 On Mon, Feb 02, 1998 at 11:08:02PM -0500, Daniel Eisenbud wrote: > On Mon, Feb 02, 1998 at 04:34:58PM -0800, Michael Elkins wrote: > > On Sun, Feb 01, 1998 at 08:18:08PM -0500, Daniel Eisenbud wrote: > > > index-percentage adds a format specifier (%P) for the status line, which > > > tells you how far through the index you are. This is particularly > > > useful when in a limited display, when there's no other way to tell. > > > This also adds %P to the right hand of the default status line. > > > > Redrawing the status line on every keypress seems a bit much. Why not just > > make it change when you change pages or scroll the screen instead? I've > > still seen the same amount of the total messages if I stay on the same page. > > I thought that's what I did. I certainly meant to only redraw the > status line on a REDRAW_INDEX, not on REDRAW_CURRENT or REDRAW_MOTION. > But maybe I goofed it up? I don't have time to look at the code this > moment, but I certainly agree with you about how it should be done. I looked back at the code, and either I'm missing something about how the redraw flags are used, or it only redraws the status line on REDRAW_INDEX like I meant (or I made some stupid typo or something.) If this isn't working right, I'll certainly look into fixing it. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From notting@xenomorph.dyn.ml.org Mon Feb 2 22:21:49 1998 Return-Path: notting@xenomorph.dyn.ml.org Received: from xenomorph.dyn.ml.org (notting@dialin2-115.wustl.edu [128.252.82.115]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id WAA23989 for ; Mon, 2 Feb 1998 22:21:45 -0800 (PST) Received: (from notting@localhost) by xenomorph.dyn.ml.org (8.8.7/8.8.7) id AAA08095; Tue, 3 Feb 1998 00:18:40 -0600 Message-ID: <19980203001839.17866@xenomorph.dyn.ml.org> Date: Tue, 3 Feb 1998 00:18:39 -0600 From: Bill Nottingham To: Mutt Development List Subject: Re: [0.90] feature: sort Mail-Followup-To: Mutt Development List References: <19980202201240.42545@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <19980202201240.42545@la.tis.com>; from Michael Elkins on Mon, Feb 02, 1998 at 08:12:40PM -0800 Michael Elkins (me@cs.hmc.edu) said: > This patch enables the use of $sort_aux for sort methods other than just > threads. In the event of equality on the $sort function, the $sort_aux > function will be consulted instead of returning in a random order. So now > you can do silly things like: > set sort = from > set sort_aux = size > and it will do what you expect. This patch causes lots of segfaults for me when sorting mailboxes. Unfortunately, the core dumps aren't particularly useful. GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-redhat-linux), Copyright 1996 Free Software Foundation, Inc. Core was generated by `./mutt'. Program terminated with signal 11, Segmentation fault. #0 0x0 in ?? () (gdb) bt Mutt 0.90, Copyright (C) 1996-8 Michael R. Elkins Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System info: Linux 2.0.33 [using slang 10002] Compile time definitions: -DOMAIN -HIDDEN_HOST -HOMESPOOL +USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_POP +HAVE_REGCOMP -USE_GNU_RX +HAVE_COLOR -BUFFY_SIZE SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/spool/mail" SHAREDIR="/usr/local/share" ISPELL="/usr/bin/ispell" From aaron+mutt@schrab.com Mon Feb 2 22:26:47 1998 Return-Path: aaron+mutt@schrab.com Received: from mailgw01.execpc.com (sendmail@mailgw01.execpc.com [169.207.16.9]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id WAA25811 for ; Mon, 2 Feb 1998 22:26:45 -0800 (PST) Received: from fnord.execpc.com (windowpane.execpc.com [169.207.1.11]) by mailgw01.execpc.com (8.8.8) id AAA02647 for ; Tue, 3 Feb 1998 00:26:44 -0600 (CST) Received: by fnord.execpc.com id AAA27158; Tue, 3 Feb 1998 00:30:33 -0600 Message-ID: <19980203003032.38853@fnord.guru.execpc.com> Date: Tue, 3 Feb 1998 00:30:32 -0600 From: Aaron Schrab To: mutt-dev@cs.hmc.edu Subject: Re: Problem with mime - I've narrowed it down... Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980202222230.20659@umr.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980202222230.20659@umr.edu>; from Nathan Neulinger on Mon, Feb 02, 1998 at 10:22:30PM -0600 At 22:22 -0600, 02 Feb. 1998, Nathan Neulinger wrote: > Here is what I have been able to come up with. > > Depending on which of the two attached mailboxes I view with the following > mailcap, with one, 'cat' hangs when trying to auto_view the second part of > the only message in the mailbox. With the other, it works fine. (The > content-length and line counts are wrong, but this shouldn't matter.) > > There is a ONE line difference between the files. > I did notice the following - and the reason I'm including it is because > the counts are right near a "magic" number so to speak. > > infinity(12)>wc -l mbox.* > 255 mbox.broken > 254 mbox.working Yes, it does seem to be because of a "magic" number, but not that one. Here are the character counts of the decoded attachments: 140)fnord$ wc -c /tmp/broke /tmp/working 12291 /tmp/broke 12234 /tmp/working Those are on opposite sides of 3 * PIPE_BUFF(4096 bytes). My guess is that what happens is: - Mutt fills the pipe then blocks while writing - cat copies that data and blocks for reading (it's *just* filled its outgoing pipe, but hasn't tried overfilling it yet so the write doesn't block) - Mutt again fills the pipe and blocks while writing - cat empties the pipe again, blocks while writing - Mutt again writes to the pipe For the smaller attachment, the final write will finish, and mutt will go on to reading. But for the larger attachment the final write blocks and there's a deadlock, both mutt and cat are waiting for the other to read. And when I tried this on my Linux machine strace showed both mutt and cat waiting to write. > Ugh. I just found out something, this problem only occurs on linux. Or at > least, I am only able to reproduce it with this particular mailbox on > linux. In case it helps, I'm running on kernel 2.0.29, slackware 3.3, > libc 5.4.33. I doubt this only happens on Linux, although it did work here on Solaris 2.5.1. What else did you try it with? -- Aaron Schrab aaron@schrab.com http://www.execpc.com/~aarons/ Everyone can be taught to sculpt: Michelangelo would have had to be taught how _not_ to. So it is with the great programmers. From notting@xenomorph.dyn.ml.org Mon Feb 2 23:34:08 1998 Return-Path: notting@xenomorph.dyn.ml.org Received: from xenomorph.dyn.ml.org (notting@dialin2-115.wustl.edu [128.252.82.115]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id XAA18595 for ; Mon, 2 Feb 1998 23:34:04 -0800 (PST) Received: (from notting@localhost) by xenomorph.dyn.ml.org (8.8.7/8.8.7) id BAA11648; Tue, 3 Feb 1998 01:31:00 -0600 Message-ID: <19980203013059.58693@xenomorph.dyn.ml.org> Date: Tue, 3 Feb 1998 01:30:59 -0600 From: Bill Nottingham To: Mutt Development List Subject: Re: [0.90] feature: sort Mail-Followup-To: Mutt Development List References: <19980202201240.42545@la.tis.com> <19980203001839.17866@xenomorph.dyn.ml.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" X-Mailer: Mutt 0.89.1 In-Reply-To: <19980203001839.17866@xenomorph.dyn.ml.org>; from Bill Nottingham on Tue, Feb 03, 1998 at 12:18:39AM -0600 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii I said: > Michael Elkins (me@cs.hmc.edu) said: > > This patch enables the use of $sort_aux for sort methods other than just > > threads. In the event of equality on the $sort function, the $sort_aux > > function will be consulted instead of returning in a random order. So now > > you can do silly things like: > > set sort = from > > set sort_aux = size > > and it will do what you expect. > > This patch causes lots of segfaults for me when sorting mailboxes. > Unfortunately, the core dumps aren't particularly useful. Upon investigation, the problem seems to be calling AuxSort when it hasn't actually be defined yet... the attached patch fixes this. Bill --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.wn.sort.1-2" Only in mutt-0.90-1: mutt.h.rej diff -ubr mutt-0.90-1/sort.c mutt-0.90/sort.c --- mutt-0.90-1/sort.c Tue Feb 3 01:30:31 1998 +++ mutt-0.90/sort.c Tue Feb 3 01:28:59 1998 @@ -179,10 +179,11 @@ if (init) mutt_clear_threads (ctx); + AuxSort = mutt_get_sort_func(SortAux); if ((Sort & SORT_MASK) == SORT_THREADS) mutt_sort_threads (ctx, init); else if ((sortfunc = mutt_get_sort_func (Sort)) == NULL || - (AuxSort = mutt_get_sort_func (SortAux)) == NULL) + (AuxSort == NULL)) { mutt_error ("Could not find sorting function! [report this bug]"); sleep (1); --LZvS9be/3tNcYl/X-- From efraim@desire.argh.org Tue Feb 3 00:08:33 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id AAA01036 for ; Tue, 3 Feb 1998 00:08:28 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0xzdPR-0008Ow-00; Tue, 3 Feb 1998 09:08:45 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0xzdSr-00071RC; Tue, 3 Feb 1998 09:12:17 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0xzdKC-00029k-00 ; Tue, 3 Feb 1998 09:03:20 +0100 Message-ID: <19980203090320.36811@deadend.argh.org> Date: Tue, 3 Feb 1998 09:03:20 +0100 From: Alexander Koch To: Mutt Development List Subject: Re: [Announce] Mutt 0.90 released (devel-only) Mail-Followup-To: Mutt Development List References: <19980202183641.39227@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980202183641.39227@la.tis.com>; from "Michael Elkins" on Mon, 02 Feb 1998 18:36:41 -0800 Sender: Alexander Koch On Mon, 2 February 1998 18:36:41 -0800, Michael Elkins wrote: > - [patch-0.89.1.sec.expires_hdr.1] added support for the Expires: field. > - [patch-0.89.1i.de.beep_new.1] adds the $beep_new variable to control Since I've been of those asking a lot for these features, I want to say thanks. Alexander From efraim@desire.argh.org Tue Feb 3 00:08:33 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id AAA01035 for ; Tue, 3 Feb 1998 00:08:28 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0xzdPO-0008Ot-00; Tue, 3 Feb 1998 09:08:42 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0xzdSp-00071RC; Tue, 3 Feb 1998 09:12:15 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0xzdG6-00029E-00 ; Tue, 3 Feb 1998 08:59:06 +0100 Message-ID: <19980203085906.36905@deadend.argh.org> Date: Tue, 3 Feb 1998 08:59:06 +0100 From: Alexander Koch To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> <19980202164506.63451@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980202164506.63451@la.tis.com>; from "Michael Elkins" on Mon, 02 Feb 1998 16:45:06 -0800 Sender: Alexander Koch On Mon, 2 February 1998 16:45:06 -0800, Michael Elkins wrote: > On Sun, Feb 01, 1998 at 09:04:18PM +0100, Ulli Horlacher wrote: > > I have a lot of hardcore elm users, which refuse to upgrade to mutt mainly > > because of one reason: the index does not look like elm, there are too few > > empty lines before. Call it stupid (I do so), but they will not use mutt > > and stick with their ancient versions of elm which cannot even use MIME, > > Umlauts or pgp. > > Sorry, but this is exactly the sort of thing I don't want to happen to Mutt. > Pretty soon there will be 10 variables controlling the layout of the screen > and the coding to draw the screen will be an absolute mess. I understand that but I, too, know three hardcore elm users that won't use mutt because of that. Alexander -- "The truth is usually just an excuse for lack of imagination." -- Garak, DS9, "Improbable Cause." Alexander Koch - <>< - aka Efraim - PGP - 0xA78FB1E9 - Wedel - Germany From sec@matrix.42.org Tue Feb 3 00:28:42 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id AAA07554 for ; Tue, 3 Feb 1998 00:28:33 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id JAA07727 (sender ); Tue, 3 Feb 1998 09:28:30 +0100 (CET) Message-ID: <19980203092829.51621@matrix.42.org> Date: Tue, 3 Feb 1998 09:28:29 +0100 From: Stefan `Sec` Zehl To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> <19980202164506.63451@la.tis.com> <19980203085906.36905@deadend.argh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980203085906.36905@deadend.argh.org>; from Alexander Koch on Tue, Feb 03, 1998 at 08:59:06AM +0100 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Tue, Feb 03, 1998 at 08:59:06AM +0100, Alexander Koch wrote: > I understand that but I, too, know three hardcore elm users that won't > use mutt because of that. Then let them use elm. It's not that we need to get religious and convert everybody :-) Btw. i think if you would convince them to use mutt, they would start complaining about every single difference there is, because they are too lazy to get used to anything new. CU, Sec -- man wie haben die nur windows programmiert, haben die des hingschissen und dann eingescannt ? From notting@xenomorph.dyn.ml.org Tue Feb 3 01:12:15 1998 Return-Path: notting@xenomorph.dyn.ml.org Received: from xenomorph.dyn.ml.org (notting@dialin1-36.wustl.edu [128.252.112.36]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id BAA22667 for ; Tue, 3 Feb 1998 01:11:57 -0800 (PST) Received: (from notting@localhost) by xenomorph.dyn.ml.org (8.8.7/8.8.7) id DAA14689; Tue, 3 Feb 1998 03:08:44 -0600 Message-ID: <19980203030844.41770@xenomorph.dyn.ml.org> Date: Tue, 3 Feb 1998 03:08:44 -0600 From: Bill Nottingham To: Mutt Development List Subject: Re: [0.90i] feature: thread_hash (EXPERIMENTAL) Mail-Followup-To: Mutt Development List References: <19980202191413.13067@la.tis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ibTvN161/egqYuK8" X-Mailer: Mutt 0.90 In-Reply-To: <19980202191413.13067@la.tis.com>; from Michael Elkins on Mon, Feb 02, 1998 at 07:14:13PM -0800 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Michael Elkins (me@cs.hmc.edu) said: > This is the update of my `thread_hash' patch which fixes the threading to > use hash tables instead of doing a linear search. > > Changes since the last version: > - fixed segfault in mx_fastclose_mailbox() when closing nonthreaded > mailboxes > - fixed hash table cleanup when reopening a mailbox > - optimized hash_delete_hash() to only check for the ->data member if > specified > > me More segfaults here. I must just be lucky. Mutt 0.90, Copyright (C) 1996-8 Michael R. Elkins Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System info: Linux 2.0.33 [using slang 10002] Compile time definitions: -DOMAIN -HIDDEN_HOST -HOMESPOOL +USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_POP +HAVE_REGCOMP -USE_GNU_RX +HAVE_COLOR -BUFFY_SIZE SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/spool/mail" SHAREDIR="/usr/local/share" ISPELL="/usr/bin/ispell" Relevant patches aside from thread-hash: - sort (patched as I posted earlier) - Sec's quote_sig - Robin's save_dir These segfaults all occur at some point after opening one particular maildir mailbox, which is attached. FWIW, this mailbox is *NOT* sorted correctly when first opened, and you can't even see all its messages. Bill Example segfault with backtrace: Program received signal SIGSEGV, Segmentation fault. chunk_alloc () at malloc.c:2600 malloc.c:2600: No such file or directory. (gdb) bt #0 chunk_alloc () at malloc.c:2600 #1 0x400a7af8 in __calloc () at malloc.c:3299 #2 0x805eaeb in safe_calloc (nmemb=1, size=52) at lib.c:258 #3 0x805e60c in mutt_new_body () at lib.c:36 #4 0x8069f49 in mutt_read_rfc822_header (f=0x808f828, hdr=0x8093440) at parse.c:870 #5 0x8062d03 in mh_parse_message (ctx=0x8092620, subdir=0x807c1ef "cur", fname=0x8092f0b "886076285.1005.express:2,S", count=0xbffff170, isOld=1) at mh.c:73 #6 0x8062f72 in mh_read_dir (ctx=0x8092620, subdir=0x807c1ef "cur") at mh.c:193 #7 0x8062fb5 in maildir_read_dir (ctx=0x8092620) at mh.c:206 #8 0x806428e in mx_open_mailbox (path=0xbffff3d8 "/home/notting/mail/GG", flags=0, pctx=0x0) at mx.c:597 #9 0x80536aa in mutt_index_menu () at curs_main.c:737 #10 0x806014c in main (argc=1, argv=0xbffffd7c) at main.c:609 --ibTvN161/egqYuK8 Content-Type: application/x-tar-gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="g.tar.gz" H4sIAFbe1jQAA+yc+V/jOLLA59fxX6Fh972G7cTxbSfQDCFcoTtcSXP0MMMotpIYHDv4SAjL zt++VXJCEgjXDNDMe+jTBzhSSSqVpG9J5ayv53546UQ0yTR18gMhxDS0if8HSSLE0AwdkqFr hMiSqag/EP3FWwYpiWIaEvKDH8Sx6zfvzPfQ53/TtL6es5PwZW3gCeNvmJIK4y/rsvQ+/q+R BuNvWYZk6pJliZomi+yiE7IoKiiZ6nPUIUuSIUl3jr+qyjfnvy7Lyg9Eeo7KH0r/z8d/j9nM 7TKnQBph0CZt6nqKGDKnRWPRhgezt578IufzomypoqLBH/PXOeHHep8MTEa0mS32QKeeyJyE zFqiJeq5Uq2a3Vz9LIvKHOm5cYtUK7Ud4jpkrViUJE01hR8bQUgWesyXlyYkLM6TWivJECVP NqlPoGqLSHpBtwqSQbLcrGZL1dqcMOrH7Dk2mSiGrkjE9bvBGXMItDCB+nRJnpufECbLBd0o 6AoIgwRiIubH2RUas8K0fPJkvpJdICGz3Y4LvxHPjWICdkKiVtDzC2ReqCxvH2a/uD4IW0P1 Nv2gzbKYLxuy84RF8RJ/JAZhk2BPeYVQr2RgdVqeVy5Ume+wEKoKnGDpjIae64vtRkO0E98V 7UuhApqnTZYtrxTIgqqtSGaxBMrW14yitKpOKbEopD28pVtZhUoLkk4+SjBrBWx0gexRh52R lSDx3DOy4PD/pwrdYx2vn60FBXJnJmE7bFLfvaSxG4CKKmtr5Otn4TBbgTHDLlaCS9fzKNFE 2Ah+Yf6vZPZQludJeZ6AHpMLooiyaCnE1S1jTqiUK6vZfRZGXJgsSgJWXnHtFmUeWUu8eug2 WzFZaEeNpZENLwqlUmFsMEaDIFST+imzY+g0qGd9a7uySmrbK9vDse0RmsRBG5TnCKXAj9EI av0O5I3ZRZzreNT15wlUH0Ys/uRGQday9HxWGWUOqR81WJhd9e3AgQWlQMy6Gw8NamIkZ4LK bv0MeiXWa4Yo94zz85mlm/NxcVg0HaupnRrkGA3P1FzpIECTwGIj0MDCtFyLhIZ2C2ZazgMl RHFOl0wo+SUIOneKPYXZnKVZzI56inAdFXZg3jCH+TboDksMGzm09fumCsj8uvelQFpx3Cnk cr1eTxx9Jtwe/l4YgLULiwT+lEmLdhmJW+zW8F4PLQ50hkQB5KIxCaCNBCZIK0hCEIAlYcsM ccbzsg2wXOJGMOrMxrUmSKBMg5T2q1DKIXbgd1mIUuOAbNQqX0BG4I81oMfqkRszkVQZm9ql nMO6zMvFMPvFqBW3PRG7IpRh6aGe14fGn/EORWysC3ELtByJMMWpfxYRXF/dWBSEA+wSrWMj R5kjO2TMh2UrjkgH7I/8TIrQ9Dbt1xk8CHmHBu0EvSShzSJYWwXs48+CwBcIQRCyWSJcM10t IIkfJXWQ7dZhkPmqfO8CyLeGkYDJNDMmbIbQiCtwMFuhW997H/27pnH+MxRLF2HZ158ZAB/g P02VlFv8Z8rv/Pca6fvy3zrwn4w89ST+Mwoy8J96P/+ZVt58BP4pBRk4y3wQ/6bmezn8M3l1 Wop/E1CATyRZyUuarGsmUJJuSkunQFtU1C9TILiD7SStIOtpH6xrtltnUDcjC6dueEaXhhKQ EdLNqUKRCHjXpvPAU4ip4kL5CVx7mKGSKEsj23XHGTGJYyKJls6Esj9GNY9D3/nU0iegFvZj rq5U/ZlUX7BPSnKKwzuVARBPxbS1oG6UENPWerLolsw3iWmy9MYwbZE8A4w9D449C5BxuuSA +SewjJd8VjRbJAM46zPaIqJIeq0+X52o4xA6JpY4boi6wOwiJGgP6cG0gFWTEUYjl4XYTAH1 A1btx/CX8RJoMPAIekmJz3rwcEwq6roDPQFpLlduyFC8wEexR/uDRxT+tgP4Z7yfs1iYP006 WJEDmoAhYtEcb0mHBR0YY/jAC4IznKcoWEiXspRCs8+aBqLJF1b3biyV4/aRPsrxz3PP3YSD Ftp1BBaIYz+aNzC8IVFgUyLkivyTsDa1I6ETBnWPtTOk3QewyoKDSajXadEPEWnC2GC5K1Kn UauQFijAtGi3UetoIY0g8R0hFZyHLV5WJMswTTKQOmLyK3K0Wv3pp3fy//umEf/LSBWAdKap P/MJ8AP8rwPu3+R/xXjn/1dJ35f/t4pFsDftafwvqwVZw7PR+89/5bxqPMIByKMw1XjQAZia 78UcAKgLqxs4ABzHp4I6NuAFQB3ALfQmwO3UbXdc+4xvcLc5nsw2GUABBxZQddzOMgf2HFOU JWPuBuS3Ey92EVxykdv0mTOP+0oc2IH3aYZ2Op5r87PhXKfZyWIOGichm5kXSB23JRr2P80M P8pWhrJOQHcnoLsTJX8iy6g7WT1B3WXlmXnSBple8xMWazv6g2exKaJvum2yA11GlbeXxvo/ dLBuXA9gnUPfasItSUcOtt526jUgsM084J3NTDp9lukrzUZs+lRsRI2lBuzC0FxxolFoZrCR q+aYp7TuJxHp6qImGkbucBW3emAFUYEsaxSRnmxczpRM81hXFzKJ/J/SH59W1nrVf6w4p7Ih H37xjIOf1KZ5cXrR+tfOh9/X1n7Llo92Dw//Sf91AHl/s8Juf+aPBfVSIF/Z7vl68L+fv7Ff /uNtNn8//lhdqazv7Ze/bv6xk/nH7KfeH/2j7r+befd/Zs6ujjevTo/2u93fli8bveDTUtFx wpXK9sLF/km56P0+K5DagTl/1d0wPrtnsxnXO/WSQ3YhdUO/Uqgyp7zk1Ytsq1u54+BcO68d quCRrVd0cffzypv0yFT1jXlkQHFPmlmP8N6/VrPFaqlcFoZ4fhOfeyH4LVEB3cHnclRSn/AZ XJVF8gzOyiKZ7q5wj2/ospQ/gKOXNJsMHV/ovJ/FTkJ/Yb0Owr5IeKfdyP8Qkya4lzFKcQIw B8jUaERQn1B3fRq6LAIkLrUYLM4ZQSBZXMb+8sjeuSw/uJSmXtDy6np5i+ys75DKarVaXF9N XZrrHUQRDVGlIKzdBmEFshMG4MVG6WaCc8sO+52YqKKWQd+fr2M5FAdDzMIGrGSC4O6W9ou9 r8tbWyv7yx93L01TOu+XG5vF3fWzcnHn405H/dpN5POeqW1ZmnKZSEcfi0q4Uawmlt44rQtK 7XxjR9F2S9sbxqXieOHHjYNlw6ru7CmRGh/plidV5LimWOXlRvRt3+h8O62tmxcft2sbW6et nX0h3Kp1Vz+vnp4f9bakb82+n+vWYv2ibypHQe1bY2tnwzw/WPlyoVzshp93t4+UVedzcKAt nza2G/XalzXhoNOTy7K5tSvZn4RPm5vrB6n6VrdWbivvqUOKRd7dtPd0I034f5ZuioqlWdqr +n+qpOq3/L/3+5/XSd/f/wN7e7L/pyAs3+//qZIEhR7j/ynqY+J/puZ7Sf9PUa/jf67h1hm7 AJLzii5uF4uSKSsK0O0p8qEterQeTVDundj6eH+QoEMTcgiOQdpRkIQTzsxUT2inWhNnJjeL x/gx5K/dEt0V1wT61NM7Q/367usRcUJTvQvfNZwm3vewTVPUa2/Uu9DemndRJjandRgvIGUY GRdYsZ0y7AB0+X3IOFy7jSE+I3tz3IMqmSOiuPQMPABHoQ3oXv7QTidfQM6gPF7pwP8dlB+H FPx4sFTqeeMXRsJEVekVEKeWoBE3sMIK7aCciZ6IpEiiPjSiLfS4VzBoYB08EJtf/MQMqmkz 8sFNm8hdjrFufUjdFgHclhbzOo3Eg+6shGCPZ0yYtMB3ZntPL5rG+Y/H/1iaZr5u/I+qyrf5 TzLf+e810vflP8QXS4Ot6kn8pxVUqyDJ9/OfnDcU7WH+U6SCaj6C/6bnezn+03l1csp/dwdr QyZFgjaZ0KaplKhIqikCZsuaKRtLHYohBH4AlOh7YjPoLk4JoX4CbT3uJL1CwzOyTj0aRS5Z CIOIei5dsvtNP4lGjPqYqG37eVB2LGToqTQ9OlvfrxBDVPOwHwMYkdHZuihPp8ZKv+Hu4Jm0 FWji/tHq26TGtxbMzcllYBqjeKEnMt+kkPGIoccB4GT5O2iQPEiDk2LuQ0MygYYHuGRS0gwC h/iUEzOPYvLxQJbM8jijTotGMP/sFthctgfmxLosFJtuY47APLwW2glgDtbT0+goCHkoSPs6 uGrQdhsWGDxPh8Y3XN/hGoFmClGcNBqopl4LOoGP+7ex/J1X/1Zpkv9kTbRk65X5T5M09Xb8 9zv/vUp6A/wn6/kn859R0B44/5PBoh9x/odcZxSUR/Hf7Xwvyn8Got1D/Gekh1r38Z8x4D8p /6b57554Cx7lMu36OPMSwS+TgPiY0Is/D4VRd2WnjFC4e6SJ2uEbhULjLULh4l+LGBjKGAUO /ImwgaGQKdED5NHBA0Mhd8YQ3BFBwMvBrAEs/tPhAyMZwzgCMhZHUEPwc22WRq0PQtNTUbeA MYlSdA4ZMKbLD3M5pjsCBuRHIi5voIYPEY4QbAIAkLMzdjfig5Y9q/O4fQTWGYJnwDDWaaVI t2nQOIAldnToAfD4/rkBi7ZAj1ALbwHvQD99D2AQsozVlwGDXUBxNBSAYxiqtIlOMOp73Aqg G2mDBWENGuIEdoJBCTz4ITMxdlzaWBA+1r0S2Ms4RMNiUUbA8BAoMABw1B7AexwGnsecTNoS tzGCab5/gPpg0wK+5S17p+r39FJpxP+KBB6AIcqSln/d+G8Af/N2/Pf793+8Svq+/L8LYCpp 1r3nv2uhmyGqNIa9RkE3C5ryQPy3KuXl6fw/LkxRUJiiTuP/h/M9L/9DT3mFUK9s8uoG578p +IU0ilk4fjk4hfhVSVF0Q9wDxYI3Ly8BpgLrx7cPMtMu3lauyb94REsvysnsaqrcIVbebsM1 WK+vfCbltufWAbE9oCrQepasevBZ6Nqrfdicw8FzkfwSI1Mpv94ZnJAZPKW+HyRAkDeR8yGv pbZ6WBt6LaWN4l51tTaKRZ1K4l+/bdcokviJo4sbrfqbJHEz/8ZI/AjJbg2AC086yx+AzByY Dk76dqXH4sH7jwpUG8d4LAoGAOiEHAkZ9raLFXxXEXkDaAqPDycMBjAT7LLcxjiTrsv5O0u2 tmv4FF8wCEIRsA6zOSx9mQClAmVRwcMbhB7j9wguF1APg16UYj2GslB78DbdgNwaYGbIeOBJ xn18eLgvCiA8QUMe2XYW8NULelkP3wAdSPYCij5vBmgNUZ//GNncJQXAi20RWlMPkUk5x5ZJ Jxi+gAqCh11oUDcEJUY4YzngQs0ZHpt8/aHQoNEgXDkAZTQSD9sDvw5RFHx1HFJneJbdSDBK F982dYfaDDrMF2BZdFOkveFfIMWPOjvk0h6sILwesBqHtJlgp5G6UYZ0+JQG3oVuEJqexkOd PqL7QIiPfgBpQr+Gisey1zrJpl7WiPgHGsD6oDl4BA7eFP6GvQcT2RlW2fNR88NXbH1neKQO dfQh3x5r0tCJUjdmjy9cberDY4dswDAUnS6FGeGQFRzKoIONIl9wmUxLgNWjRprciLn6CoIw NgturKg5xtJ3gYWpb6CSUoAGC/YQNgNw1trQ7xmMiHFgkLmD2ED3D3U4Q6a+ADpceocd4Ztx mnLHJycn8C+B/3JXV/y3E/5z+smUZbtEQ3jkgybc+NKDaTFKVwRk5U5OjlHe1RWK4j/Cz/gJ ITc1KCiylYO9CpZg9JtXQliyroVdgSwoTI6P4S/IvoKHIC2H0kDWLe0LpRbtwNTaQJPeKhHF 1GWNfK0WubDj42ModIzNy5GrExSWG3T6GH7Oy3miayaRJFnByUAUSxE+ymQWPpgjeSVP8pqm ZghslERT8woUQSevA5OErPp8zWA+NmVsnCcUniP/x3yxcf7Xpbwuypolvy7/K6Zh3Ob/9/P/ V0nfl/+reDBtSU/kf6sgaWkoxn3xv4phqHfwvzz22p2EwjRpKv8/mO/l+D+P1anW+Pn/VEWo 1y/CTvUG8Mt1VBHUrMqapC5RWE18KvqJDZiViIlP22L7YvE6HraZwMrrwDZk00tKFtr8wdKt 7Ii1JfEgWcKbdtFhd3+d3kTcMH4/i6KWlnVR16xSfjmvDgUsgp0N4om5GZagmc0s7ASAAwcJ nsxh54UfJzwyuaBZBV1Nv5llbvKEf5v/DAaRLZHZoAEcE3Rcew5g9sD1gRwivE7BM1l+cscD UTssRkIWp7sHX/a2WxZ4B8mlKVaa9pv0Dqw390LhIinBcFG/HyTs+oQamLseBGcRan58nH5O uSvwgYKz4EZgG3jOYdhHNAjxGC/UCYNmSNs8KIKfSjMh8Bns6HVocCud+UXHcSMod8AiD2gW 2LjOWtRrYAO2kBJg/DGgmGM4vwvqgvophkkMvhcG+4UvwTG+AvZYnQy+bqXN0qiPlLeFPdqJ Aqd/3Sp24wAZaknn1Js50h3t/6qhK7Dzy1Zeyr/y+z/ylO9/kN73/9dI3/3+H+3t3v2/mvgZ IpM1mHTX1/9qQXng6x/yinTH17+NicJLfaWgTP3yhwezPe/eD73kFUK9ePev4FHj7Xd/2tLF pSGF0A75cHuztGQHgeey4WFeBW+olFG7JR3UVJDysEPmUVOfUVPp5sS31l4QkL1+QhbsXthP lqgD2/sZhQaK1BbPwheODXjce0lbrDe4d+y5DvjiD9y1y3lRBbOcvofT7aPtFdjDi6uKuOWt hG9wDzfeXABmuiti7OFPglDFA7Ph10Clw+LKli8SssxsiodHg2Nb/hH8HmEYY5fFrk1JAwxC gHXCc2039voZvDG3Kd5J11l6zNZLAx09sM0EWbCXXsdCuXRnjoX/tnf1bYkjSfz+XT5Fj7v3 rO5ATDohvKyojCi+jIIyKt7tLhNCgEhImLzoMLe73+W+6VV1JxgFROfU8XkmPeMzIyTdneru 1K+66lcNmtoKwg0u0OksubLEroA+gG3eCPT+zf1QqeuRIW4vdYwuLEV2JcxSvJ0/5GrPH7g6 dz6jj5htpSEzh0Vbml3m1vfQZdsFxe0yUACvk1t3LWMYKtvEQuf7FXOYO6nqh4O38GXZBsTR MUAFc6HA64F7nTdWEANMVmIq9VogQVK+oxLDfxQQmCzkVPWJ4d/C/R9FnTr/gUrZBP+9RPm2 +K+ChAtVzT4G/4lyUcoBQlq0/ZPLzqH/xOsqYF1SYQEAnH3ZswFATAUFzeXnZf/FSA1RKcgF QVHyCkgMNy/sjhkMcYAEzY0A4ZToRExnK+NzyBMWdGljckyBtHG8seu4mm46rf0S3W7VjdKO pG2UyFofPh4Zs5pajOPuYjjhqyjeN728D1rmEVpOpQrOqcZsSLhf95plCphwr5UTTj35VWJC +tq8vv/ddSwN4OCW4cG7s6+hax8TOaFDCVFFHASGQ05Cr10PfUOYjjQMZUR6iQGIK/AIslYw Gm/sBCzgcBAhTIQnP0DBqVk3Epj0lOVG/yuiLGULAs3Tpz4AapH+V6f3f6ScnOj/lyjfVv+/ A/1Pc4V7z3+a2tWQingC1CL6B6XynPCveF05rGtO9s9Flz2t/j90Qv1PiUhZc0rc+TO1C1Yo ZgtFmpvr+6EIE2A9f0CIpYjKZluzNdsxO/O8PzugK1xTd8ihYWtkrRv+Otv7wzp+96sbjV93 PB9foSM/Tc4vGnvnF1UeyjJyTZspp5nauNzwhwo77yhDhYx49Bq1cU7MvzJtvAv600mTXjBm sS4maFLDGPBwnB7LEeg75Npx2TEHQ22An1RMD6NkSLU/GSl+CaYsrLK6CSlbVjz1Xxjzbxuw oDDFfTSyUXQ7ZwCYEZE2FQUf3elJRBSo+oNKvRHiA1413Ns2WEIYHhRidFIRL6N6cbaNO0+h GmaPGbkMMbDJ8hzGQ7XD2DPPd0bsxmjGwS/Q6U7k0WHLtZhZQRbFcaC5vql/l8Aipv8lETSw kJelF+Z/qqI6df4PFZVE/79E+fb2f14WH6f/wf4XF4Z/SDlJmpf++5ZhD3/nZP+YuuxZD3+M 638Fm4uSv92cxbM2U+ve4TbyVvh+9YT+NMn3vHr8V2ls/SW1rnJ2feVz08k2L6v5t761WQrO gpyTDdSV7u9fjjbervXfvTkQhoXiv//8ZSQrl2dHH2u/Fpv/ap41xuurv52sf6r4y37++k3G /M/yWFz6eLlz/UcwyJv2l1rhuqm1Oz9vdS5Pz7tbv1V3zaJq13652MoXfsx8qqwfK+4/C2/O ltZOLvZLucqPPy39+qn05fB99uc3peur5uCPnz6qOx9K2a1Dp3vcXDk/PfDFUbF2YAnDnVrz 82rlwRnIJQH/0Ls5yO9NVcyBBZ4c1Dd6m200a10PVKovwFjCywIjaNjSOIBLyKFAdo1eG6zZ 4UqI1cQ7aLXA0epUYvATp224oKvKljY0OtqdDOENDcBTPASJSsWsyN150owM4ZZ9FeQvNYXR VOf2enaecNCAnmdqYb5wUaA0li08u9yGCiis3QxZqroYSgFdbfgAGozO0mwkN7hWxW0AcrWy IjTc2qsEctJry5C3joUshdNiiZRKd6cIWdP4fzbN9lCAcY0l0EZVihlSOMEVcBu+m5BHih6s Lgbh4LRimyuOhVHcfMMFkRq/VcNwXh/G0FuNEojgHYHHgrL1vgG3AGxhHSYhZoxcbVEVgPeg Jw12MUwSLxghZzYW0I3+O5yaeLLRGFr7jOhtiF67GBFXSwEO7Jk2iyKPxdIwToHmIoLDsCJy wxAl0I6FxNGtdOhFxKwvpo99GKEcLLbONR1XRZjw29b9gMfAu8GEoYpsToz/NdB3iczf1OTR 4SYY1VHUUegMe8Ug9Ezzc6lQuFEHDRMe3NBd3O7EjJmMJIs84TD9jAeddVg4002L6TCYn3lB Q6kNjLHnu6DF0inSB0yLLequ43nYAazLGTHCLeMLp6OoeY6n4QrMIsM95IBzkGuMt0CFgY7g PCI/hDLGsdvr8nB0RtRlcVpIRkVMP8a0n9BXLWQ2Y4A2UjzwqaEDLCCfk6IZ0GYDifRcC7qF h2Jx0kAHB8TuMD4xJoTEZ8TDvDy2IYgfOzDxcD63+DRqQZUt6FKr7Potp9uq30R8tdL4rg8z AzQQ6fdgYFAEFc02DZgBdQEjB40Ohm+DIdJ4d0TEjJhD6JClNNOEZpBdwPsK7Y5Dvy8SdDsB I4SgFONRZuzhAe6AxvXC5ZQKmQf86C7SN3t9nDWOYxHPGfUZsRtauAxsE/7h1BGQ/FDz+/Bj 6h4bN/7M0dCwx97DzDqwkHn0GD79ljOESWS4kRg8LoNdzYVFnSLltmFhqBvKoArqEBb6Pph5 jcDzQAR8au0HlmlEH6UjoVCVZkRJysoZMUWWD/c+kDoCuhWM4I/JTUS6XkaFK/Sqq12zMP2V mBQx+C6cVG0M9ptIEgnhOuu8xmk2ICET36JMGbOJliLsnRPuJKdvS1oj+ELTLD2wArSdXCcA KU8+QFlyyUahdahvfKf4VXo89n6+de3q32F1qbrj+vDy66RJ7YQgPSFVMdomiLh6dAqoQxak t32YMJNDq0VBlkn5sEIOsqR+kpFkOXWOCygyuuHHgcqYHNKhoEAWyC3ns4N4A5Ogzk3o4El5 uhLz/+dVSvNCQVZf+PxfOatM2/80if98kfJt7f9TsP8LcpY+xv9PRZYafcHxv7iZNYf+EbfO MM6yKM9kfyy87Nn8/2DoQXM0d9/+P14jFSV6i6fNLaltyzKhH+8Ng6wB/ECBb+qBzsQJBkhk p0RfAUI0Pws6DB2/JkzG+UAqiK7fpoKkZ9tSDyJnzMrM+VAGyy3zsw5CF94fNUENF7ICj5ig klSAipQ8ze1ksFJRnHr0xRGvjFdef1/eO5qxcTDTEt52AjUA9T9qU+Es2HuNlrCap6/MEq7Z U2yn9NScvHYdWBn8IOFH0UzY0UtPQjVZJ19JNuEnBf//hJN18gDKSc2NHgstrtEYsz/F5K6b ri4EnmAE7GzjwHMzlgPAOuO5+irU5a0yvMlfKxiH8UOcHXtDgE4tMZm2r0wnBOQGs24A6rfB IhxEmH2SjLQTo/5iolaWdRTZ5uMU2FxdDY0GYmlo3IFtB+NpB8M2rE0BGdLkHcLnKs5grrpY 6ydICC/3wf5ML5GRQCiAmSSw9p4C+M82rleftQ2iYH7CufgPyt34Twl02j9I9ll7FZbvHP/B +PvD0fOPfy77uPGncjL+SUlKUpKSlKQkJSlJSUpSkvKU5X/LuEPJAKAAAA== --ibTvN161/egqYuK8-- From efraim@desire.argh.org Tue Feb 3 01:58:32 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id BAA09065 for ; Tue, 3 Feb 1998 01:58:30 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0xzf87-0003FZ-00; Tue, 3 Feb 1998 10:58:59 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0xzfBY-00071RC; Tue, 3 Feb 1998 11:02:32 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0xzf5E-0002Tj-00 ; Tue, 3 Feb 1998 10:56:00 +0100 Message-ID: <19980203105559.16100@deadend.argh.org> Date: Tue, 3 Feb 1998 10:55:59 +0100 From: Alexander Koch To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> <19980202164506.63451@la.tis.com> <19980203085906.36905@deadend.argh.org> <19980203092829.51621@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203092829.51621@matrix.42.org>; from "Stefan `Sec` Zehl" on Tue, 03 Feb 1998 09:28:29 +0100 Sender: Alexander Koch On Tue, 3 February 1998 09:28:29 +0100, Stefan `Sec` Zehl wrote: > Then let them use elm. It's not that we need to get religious and > convert everybody :-) wygiwyd? Well, you certainly got a point there. Alexander -- "Luck is my middle name. Mind you, my first name is Bad." -Rincewind in Interesting Times (a book by Terry Pratchett) Alexander Koch - <>< - aka Efraim - PGP - 0xA78FB1E9 - Wedel - Germany From roessler@sobolev.rhein.de Tue Feb 3 02:10:51 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA13249 for ; Tue, 3 Feb 1998 02:10:47 -0800 (PST) Received: from sobolev.rhein.de (roessler@sobolev.iam.uni-bonn.de [131.220.223.85]) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with ESMTP id LAA01004 for ; Tue, 3 Feb 1998 11:10:52 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id LAA13900 ; Tue, 3 Feb 1998 11:10:41 +0100 Message-ID: <19980203111041.45942@sobolev.rhein.de> Date: Tue, 3 Feb 1998 11:10:41 +0100 From: Thomas Roessler To: Mutt Development List Subject: [Announce] Mutt 0.90i released (devel-only) Mail-Followup-To: Mutt Development List References: <19980202183641.39227@la.tis.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=3V7upXqbjpZ4EhLz X-Mailer: Mutt 0.90i In-Reply-To: <19980202183641.39227@la.tis.com> --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The international version of Mutt 0.90i is available by ftp at the following locations: ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/mutt-0.90i.tar.gz ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/diff-0.89i-0.90i.gz ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/diff-0.90-0.90i.gz Detached pgp signatures for these files are available as $FILENAME.asc. tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNbtH9ImKUTOasbBAQHMhwgAuBUg/i+6J8U3pXWAuz4j4yZN23fpRqng 8rVxvpkOPQS0OuNwUpWoSdCVQmsLHM2iSh0Ve6m5sJMCRbrBDlY5uY9Ileotioqb ioAc6z16U/gcPzWXAoU8bNnr3y86kkrSa26pwOzTKBzjpaSTBMYrwfseMdLDnlp/ 7NBoV+2kbdZgrEKxkFFzC1yyUSfjLmYFOrAil7iLyz7hF2cxIBYOEpv6oKQGKbov fmq5APPbQhVXbs5Lz+5vqM7vDOffTTonDgLxuvmHBPoAakSeQry7YbMoHHT2tjfE OR55meHQNy+e9qitJXULPXCLzbNGLgyJ4JmaeWo9hLW0gG3DbtfGow== =SEdb -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From olsenc@ichips.intel.com Tue Feb 3 02:26:54 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA18345 for ; Tue, 3 Feb 1998 02:26:52 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id CAA24837 for ; Tue, 3 Feb 1998 02:30:31 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id CAA28015 for ; Tue, 3 Feb 1998 02:26:49 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id CAA08206; Tue, 3 Feb 1998 02:26:47 -0800 (PST) Message-ID: <19980203022646.48773@dtthp169.jf.intel.com> Date: Tue, 3 Feb 1998 02:26:46 -0800 From: Clint Olsen To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> <19980202164506.63451@la.tis.com> <19980203085906.36905@deadend.argh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980203085906.36905@deadend.argh.org>; from Alexander Koch on Tue, Feb 03, 1998 at 08:59:06AM +0100 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 03, Alexander Koch wrote: > > I understand that but I, too, know three hardcore elm users that won't > use mutt because of that. I think Michael's philosophy of "Mutt is not going to be the mailer for everyone" is a reasonable response here. That'll keep them happy for the time being and keep us from having a big huge cruddy mailer like exmh. I've explained the virtues of Mutt to many people (even some MH users) who did not initially see the benefits. It was after long-term observation that they realized their MUA sucked more. Only one dumbass is left, and he's still a silly crusty ELM user because he whined about trouble with Ollivier's alias format converter. Life's too short to deal with people like that, and I told him to continue using ELM :) Whiners will be sent to Microsoft. -Clint From roessler@sobolev.rhein.de Tue Feb 3 02:41:45 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA23343 for ; Tue, 3 Feb 1998 02:41:42 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id LAA01105 for mutt-dev@cs.hmc.edu; Tue, 3 Feb 1998 11:32:54 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id LAA15218 ; Tue, 3 Feb 1998 11:29:44 +0100 Message-ID: <19980203112943.47260@sobolev.rhein.de> Date: Tue, 3 Feb 1998 11:29:43 +0100 From: Thomas Roessler To: "The mutt developpers' list" Subject: [0.90i] PGP flags Mail-Followup-To: The mutt developpers' list Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=qlTNgmc+xy1dBmNv X-Mailer: Mutt 0.90i --qlTNgmc+xy1dBmNv Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" --0F1p//8PRICkK4MW Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable At some points in the code, the PGP flags weren't handled correctly. tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-0.90i.tlr.pgp_encrflags.1" --- send.c.orig Tue Feb 3 11:24:49 1998 +++ send.c Tue Feb 3 11:25:08 1998 @@ -363,7 +363,7 @@ #ifdef _PGPPATH if (cur->pgp) { - if (cur->pgp =3D=3D PGPENCRYPT) + if (cur->pgp & PGPENCRYPT) { /* make sure we have the user's passphrase before proceeding... */ pgp_valid_passphrase (); @@ -933,9 +933,9 @@ msg->pgp |=3D PGPSIGN; if (option (OPTPGPAUTOENCRYPT)) msg->pgp |=3D PGPENCRYPT; - if (option (OPTPGPREPLYENCRYPT) && cur && cur->pgp =3D=3D PGPENCRYPT) + if (option (OPTPGPREPLYENCRYPT) && cur && cur->pgp & PGPENCRYPT) msg->pgp |=3D PGPENCRYPT; - if (option (OPTPGPREPLYSIGN) && cur && cur->pgp =3D=3D PGPSIGN) + if (option (OPTPGPREPLYSIGN) && cur && cur->pgp & PGPSIGN) msg->pgp |=3D PGPSIGN; } #endif /* _PGPPATH */ --- recvattach.c.orig Tue Feb 3 11:22:29 1998 +++ recvattach.c Tue Feb 3 11:24:37 1998 @@ -457,13 +457,13 @@ =20 #ifdef _PGPPATH =20 - if(hdr->pgp && !pgp_valid_passphrase()) + if((hdr->pgp & PGPENCRYPT) && !pgp_valid_passphrase()) { mx_close_message(&msg); return; } =20 - if (hdr->pgp =3D=3D PGPENCRYPT && hdr->content->type =3D=3D TYPEMULTIPAR= T) + if ((hdr->pgp & PGPENCRYPT) && hdr->content->type =3D=3D TYPEMULTIPART) { STATE s; =20 @@ -568,7 +568,7 @@ case OP_LIST_REPLY: case OP_FORWARD_MESSAGE: #ifdef _PGPPATH - if (hdr->pgp =3D=3D PGPENCRYPT && hdr->content->type =3D=3D TYPEMULTIPART) + if ((hdr->pgp & PGPENCRYPT) && hdr->content->type =3D=3D TYPEMULTIPART) { mutt_error ( "This operation is not currently supported for PGP messages."); --0F1p//8PRICkK4MW-- --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNbxldImKUTOasbBAQHG8Qf9GF6MUGcHNVKMp5FBO45tHDIcUarZ7Pqv PLMHNwl3GtBKbduU6M0sD5n965XkzO8Aawn/HGPAJ4rxYl+OInsCRdNTYf8WO2jz qDA+UEAXGvx8ow2RSy7icmDXi+XfRp13hXpe2fcl7Xxi1x+j8N4CjaSHkyo24KiN fYBJCQfwmLg+4Gt2CIyMoz4XlwxuEBy86n7E0lOO2ri5EZA9XTTAtlzyDLrAyYru nId4spt7meC/1j6wS2K0ZgwuKBBm7WAb7wNLoPOLMb6vOgyloh6i7XH0aA20p29R 64EhonK6F3hXp5SLklAoW9t2tl8fQXqu4C5VuTDnXUqNDDiLcg89pQ== =niFu -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From steve@gbnet.net Tue Feb 3 03:18:38 1998 Return-Path: steve@gbnet.net Received: from ns.gbnet.net (qmailr@ns.gbnet.net [194.70.126.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id DAA05313 for ; Tue, 3 Feb 1998 03:18:36 -0800 (PST) Received: (qmail 5159 invoked by uid 100); 3 Feb 1998 11:15:37 -0000 Date: Tue, 3 Feb 1998 11:15:37 +0000 From: Steve Kennedy To: "The mutt developpers' list" Subject: difftime Message-ID: <19980203111537.03459@gbnet.net> References: <19980203112943.47260@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.15i In-Reply-To: <19980203112943.47260@sobolev.rhein.de>; from Thomas Roessler on Tue, Feb 03, 1998 at 11:29:43AM +0100 Organisation: NetTek Ltd Trying to compile mutt-0.90i _difftime isn't defined ? (in parse.c) SunOS 4.1.4, gcc 2.7.2.3 Steve -- NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103 Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU [ IndiNIC info - please email indinic@gbnet.net ] From kinge@oms.tinker.af.mil Tue Feb 3 05:04:38 1998 Return-Path: kinge@oms.tinker.af.mil Received: from ocdiss1.tinker.af.mil (ocdiss1.tinker.af.mil [137.240.177.81]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id FAA07982 for ; Tue, 3 Feb 1998 05:04:36 -0800 (PST) Received: from oms.tinker.af.mil (oms.tinker.af.mil [137.240.87.84]) by ocdiss1.tinker.af.mil (8.7.6/8.7.3) with ESMTP id HAA21727 for ; Tue, 3 Feb 1998 07:04:56 -0600 (CST) Received: from OMS/SpoolDir by oms.tinker.af.mil (Mercury 1.21); 3 Feb 98 07:01:47 +600 Received: from SpoolDir by OMS (Mercury 1.22 beta); 3 Feb 98 07:01:22 +600 Received: from sgpfo14.tinker.af.mil by oms.tinker.af.mil (Mercury 1.22 beta); 3 Feb 98 07:01:15 +600 Received: (qmail 1364 invoked by uid 501); 3 Feb 1998 13:01:21 -0000 Message-ID: <19980203070120.45707@sgpfo14.tinker.af.mil> Date: Tue, 3 Feb 1998 07:01:20 -0600 From: "Edward T. King" To: Mutt Masters Subject: 90i Mail-Followup-To: Mutt Masters Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i Reply-To: Mutt is not prompting for a passphrase when pulling up encrypted mail. I get the following error messsage: "multipart message has no boundary parameter!" I have to use a macro to decrypt the displayed message. Mutt 0.90i, Copyright (C) 1996-8 Michael R. Elkins Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System info: Linux 2.0.29 [using slang 10002] Compile time definitions: -DOMAIN -HIDDEN_HOST +HOMESPOOL -USE_SETGID +USE_DOTLOCK +USE_FCNTL -USE_FLOCK -USE_POP +HAVE_REGCOMP -USE_GNU_RX +HAVE_COLOR -BUFFY_SIZE -EXACT_ADDRESS SENDMAIL="/usr/bin/sendmail" MAILPATH="Maildir" SHAREDIR="/usr/share/misc" ISPELL="/usr/bin/ispell" _PGPPATH="/usr/local/bin/pgp" From hildeb@stahlw00.stahl.bau.tu-bs.de Tue Feb 3 05:20:39 1998 Return-Path: hildeb@stahlw00.stahl.bau.tu-bs.de Received: from stahlw00.stahl.bau.tu-bs.de (stahlw00.stahl.bau.tu-bs.de [134.169.69.220]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id FAA12810 for ; Tue, 3 Feb 1998 05:20:36 -0800 (PST) Received: (from hildeb@localhost) by stahlw00.stahl.bau.tu-bs.de (8.8.8/8.8.8) id OAA21734; Tue, 3 Feb 1998 14:20:00 +0100 (MET) Message-ID: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de> Date: Tue, 3 Feb 1998 14:20:00 +0100 From: Ralf Hildebrandt To: mutt-dev@cs.hmc.edu Subject: configure problem Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=llxdKGCiKxUZMO8X X-Mailer: Mutt 0.90i X-Mailer-Info: http://www.stahl.bau.tu-bs.de/~hildeb --llxdKGCiKxUZMO8X Content-Type: multipart/mixed; boundary=e7rgc7IsuDeGjOzx --e7rgc7IsuDeGjOzx Content-Type: text/plain; charset=us-ascii Hi! Since sometime back in the dawn of mutt I have the following problem: configure says my system has "snprintf" - but it definitely hasn't... So after each configure run I have to change config.h and Makefile to UNDEF HAVE_SNPRINTF and to add snprintf.o to the list of objects to build. System: HP-UX 9.03, gcc 2.7.2.3, GNU make, GNU everything... Find config.log and config.status attached -- Ralf Hildebrandt, R.Hildebrandt@tu-bs.de (PGP Key @ request ) http://www.stahl.bau.tu-bs.de/~hildeb Institute for Steel Structures @ Technical University of Braunschweig Beethovenstr. 51, 38106 Braunschweig, Germany --e7rgc7IsuDeGjOzx Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="config.log.gz" H4sICHMW1zQCA2NvbmZpZy5sb2cA5VhLc9s2ED5Xv2In6TSSGz1I62m3nkkTT+Np6xyUtNOT AoEgiTEIsgAYRU3y37ugSBWgHI9jO5fWB1sG9r3fPqDXKdcQc8GA5tIQLjUQuYWMaU0SpqFQ eVRSFsF6ixRZgZRKwybFvx1VSsllYjljnpSKPQWTA+ERRGxdJom94/G/15CRKxRJIOPa4MdB p7O/O5lMFidAU0avLFucK1TNYv7eJZmNWiQJpc79dDxz7jcpMylTgL/g+d526CIPQA82ubrS LvM0OLHyoJ9XFhumDeBP83mAXMHZdxOXZR7cXh+3jlOVa91v7jxR02tEbRgQDFup7eHPl2/g ucuymNQGnztGOgSzYHSNTMtBKGWF0dBPXPLj+TXkNmWgGRJ/++G3Z7+cf3I5FuNWPgj8tHxR +U4MXyOoEE+GCOEwzb0kWSbNZJQR7hHN20RFUlw5BIvj0SGBcx+MwqBFwHXBPEuC0cT1OM03 Fr4I6jqFiD9EP8VKyJXHNlvsA+/C42wYsXdDWQoB4dn+PC+NyxyEoaMTq6MvDFOZ4GuLEMX+ KrlikccxPj4EZj+B/qvwZnhCjEHFykUnEkUy2BB90nksuGQQBMcjeLQnfdR5zCUVZcR2hxGL 9SB1Tn/QWz0sCEoZpGedDmZLQrfX+YAUlthmvfMNe88NdEe9085jJjRrDoLqQEY87nzy/Jq2 U7js/0qkC8kgHE39aF0AJbIpLoRbFYylZWvc9NiDyS1D1xdaWCF9kbXDGExGbSg9u1xeIEBS RiIsEds9tccQjO8OkMk8eACbp6N2N9UmIioZpB5VcA8kX6MCQcJzasRDavHahWKmVFif24JB HoPmiSQCUiIjO5Y8vmmjlO6j5+g+iNf8GmdWKF/gqMJxRgWC3/BcYker1Q5SQLJSIkHkOzyz qL21briQEJeSVtLf2tJ6cuJLw47x1jHnCSrdWYTF3Y25QgtLzbBr2VFeS+odiOieE5q6rDxi 0vCYM7VrPUWuDB7nUmzxF2UHEmxYmBWyNxfrmxQFI7gScDno3bL5TBfjL24+NuXaNh/nuE7D WWd4BJfM2NFTO6e99GHKmjQNAI6GTdd6+ez389Wby4vl6xerl47ghvis6VtcGrCJ6fbgQ4em RMFRphP4EY66rp7vwfa60walo1PwGt4sdMeN5n9XGBa53/JmFvD3rv/ZdN6ejzxaeZU1H40P BrFhCfeGz/w4vLs1QjBqkF9EdUgQDwFUUwG3AlPqznDN5VBEJ/BGaiwvjWCMMHXZOhcIF9RQ mwRdmkfstviajxa3wBeCZrnVhmVNH8fhj3dWwmqlTbnGlNt9DffhCJeDgsXYqbYQs41VavIK kU+tkXYdxqrYTSYZC04NbLjBEwuV2oVu7xTWTOSbBoIN2ojWTJkaxq/eMaWwMKslHOMeInhx P7Bdbq+0WrLf5RgVVIjkudqJRPY/WNUJKr1rRon9pwIvT1ILYYNm2uWm1UdJpapyZV1yYbBg rNNIaUscI6CSMsNm4diwyUtMqzYcuze2ALHd2dDyuOOXjjXxNaqvVlnAnUcRta2Druv+hThs 2ouuA4t44VkhmDVBV1baCIgN2eoKBrtgn1++Wv65RDOWecYcGXaDJtSUxGZPkgy3KytCIxVq tJVoiDLVzmvFrFaN7yBzlWHgLU+1vmNUBCd630NqyxGdO8Csasd78PHjwd1qf4tBynGpzli9 JznhqvvN53vINUWr0Nzx/MGK9iZVRlVw+wq6DnZBLQuF2Ik9qvn86+gyihLNaFY8vLZF0G7E scEnBiXGm6+L8fT+ysLDRw+6FhueMY9qvHgAXeE49J+LWGYSe6N9ydlq0Sb3HzJhOAv8ZX5Y ajVs6PE9jg1lo7gh+HD0+BaffwD1L77takUjrnpD9f4LzD+eTQ/Mx65SlLjRKJpyg6MLCfsc 96UCq9J2v4gYcrDth+PxQZ3k9IpVawdaUH326Kd3c6eRBfedtc+JfGLQD+xyTQu2Vl9j6w1D NhxPwtsN2f/GSKtCczjRmvPPduxwvGjXZIJzJ9dmvd0NFosSqd0vJsKJ/ebmThBBQV8PH76V N4JjsfgfgcNL6CFGWtctqPwDnYOn+YEVAAA= --e7rgc7IsuDeGjOzx Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="config.status.gz" H4sICHcW1zQCA2NvbmZpZy5zdGF0dXMA7Vr/d9pGEv/5+Cs2MopraiTbl95d7ZAHAexwxcAD nEtrO0TAAqqFxElax2nL/36z38SuvpCmr6/Xe++aV7Pa/czoM7Ozs7MLB8+QPXV9O1qVDtAV 9nHoxHiOHBIHayd2Z47nfULTT2gW+At3SUJsAW5IfBSv3AgtXA+jOEAhnoUYBKEXoxkJQ+zH iQioCXwqNqYicxfAcRB+Qh+daKcWXgnqAs8LPkbHgA18tAqiGEWxs/I+npyclw6g17ITAYSq 1U2IF+5TzSYRDqMz2wuALnR/dONVNXySrchz/CU8YN+Zeri6CTZMVzNYb4B+iAISb0iMNmEw JzMgolp7jED3gnhALURzPCXLpesvQVpBgFGun1CzvGCJ3AVyY4Sf3CiOrFLJmU1m0YREzhLX jBv6cb7Dg4UxidBttQqOWeHZwz1tP4JF4DbWXmFvc2+UKAXQFGyoP0vzoITQzIkwMspJrwFM oFtqQr+gak5710xasiE++ccRqEIIRgNkhMT3wXJU/rnZ7112riajN+1utypiZ/t7zQw8+EFV BBNrAynCXGFwNk9A8r9HAl1cUP+K2WFuyrZ3zaQlG+KTf6j+TYfDMlmKEI50NdJhJN91Zp2e SX9AoJ0IWjRQmGq1IT75h/rKshKWxoWmqXK0B3PKMThyZhCFPmbxvXQfsT+Jwhms75q16+n0 RuNGt1sztFlgM+b6YKsHMzIzSqU4dDboMFyj6iJE184DZqklfLKTtvDPijViHMUVyecQKJ2h 029KsC4HYRBDfkHO0qH60RTTqA18lplCd7mClOLOMQoWyEERuDciU4DBAtb8b5Xo2GFkm3W7 XrcvUGTXTdkyl2W7voQm/C3bkX17d/fcvLfhr70Ez0QUZwqhOpVjLYCaS/sQvUoMsOi70cuX d812/7Jkv79Ff7mvvB00xm9Yq3b7/vy+UrbnpVJk1puX3cbVqG5W/8V8tsFzx4f8jKoQu/0z c8kwg4FEdcpf8ck4siHUxfC7d2KYP7falxTaetN4256IFfWGD3VbGrLbeQ1tVPXEYvHWvJ+u xglfZnWz/DNvbfmY7NYmXg4Fy9BZT2DS/QjS2nriO2tcN6PjJ/jHMRAhwJ5qVV6ypYHDx6MC QJQgPHdKR/JAYojj5k7sCFCiZOWEWLznU0TnKwXAsRBmyDkNGpyCzALhJGZ4HuLRCROmBSz5 uOvPPDJPi4teDgm8uYoCp4c6wPUXQUbBIuCDa8dPjUGPCJpm3VzOhLWj9nhy3fiuLeNCrO7J YNi/GjauqQLRtdUBrca4oY6i6hr97cULqbXXum50uoI2mG1H2J+vHVfEy+Bq8F3d9IPkKRVV LJ1slhs+3h9ArO7CHx6R9mSBAo582x6OOv1e3Tyxvj0RhEcD2FLy9LvRBntestCYV1C1nSyQ /ut/0jUCNKyA/nX9x+AB8/YD/sQbGzINISHBAwTO6XwJSYBWT5H7E0VCugPjwyfLQbANWYEa YoUBen0zHk+uhv2bgZwV1jNoD687I27e37/5BkZKLM1AjhxtPEibNCGy5OfGhNYOtIqBUm7q xrhK+czRxsUzHLHSB7JhhOh2CeLRmmYgCG8aNcgn6ynsa567duPoGD4fME23LXfpQnZH/dGl fYoo8M2gevOO7Qxr52kCCiez9TyqfXuCDiDhP7lrspbKIDl7rg+vBj60NIPsLJL1LHQ3MVNC 94TaKcj2EhlZeNIhhpniJYNcuiHkeKqSGZPBQbDVyiliINalAg6kajDP2atgHYR4wijXzulz Yp1hlD6u6O5V1lAXiJVvUCbSfYANAlfI5bCbXdCZ8dk+TU02To/LP/Px7fwCsTbw3f7bSO0j 6r5SFg6i27QX4Z2yLxZfuArPZ6ga5cAUxrovFo58OdvYP0NQvqX6E687pBMNRT97w8671KZc vaI4kqpTYqp2qIs+o4W5gGlgMfcBP21CJCHoa3T6QY7TeCtzB8suGlo7CXgCgXSofeB+ZrXU 552gWjJz4hJIlsTmfdnptke1pDpmj1Ujr5oytvI4wUbo+cVCZVWOhmgyJcZT4hL0rIaeLCuh A+mEbDZBCCA4SFHI7TlsLMqnZVn398YxHJ8WDvFiWo/xgZqUsFzfsLTjDH8VO8xUzqEaFV0T 1wdvJpUpQ/3CKzWTVUvnpnn4QUy5MmP5EudWhcKTkld5CV8o9GlLySkVLzO5Mf+RgFscSN0e HG+hoOf7yzFkrM1EtmnWExseT6JkKk+/LqbnQqpqiNcByLMEA9VVtGJiNMPGKyeWR2I4TloI 9YKYjUBNEuN1hFYOSIJKWj1ZPDRo+c3tleZKa+3b9/Y9/b9SFk5KZrfMBdncKu5//jxn3FJW Iz3SY34JwA/BjmrjJ4uBZOaYK3pA8/oBWrsuuV6gPYnIgp7bDHtnCHRLO97fWTY1wBAUGnB4 smyDeRg7cJTd3TAAo7Km00peE8RRTVMvEJq3KiZoNpfMWUku0Ukmyvga1oJYPROJYLaOEEoO STxK0yueahOrXYmmBE55qP2KESCY0GdzfAGUeOjaEN5CIENNdwB99U57jh1ytdDQFcG/ceIV 56eKUT6feRcPkNTr8uRSKzDtY7HKhJNv7fI9EEyOnjk4aYSG0V+sY+WbmbfZ1QDNY4a6U/A9 TutKriMgp0AhUzOKbtgWYbBG+roFETmbVoVFvH4PZxQmTJnkeUqDQg0WZc04de/uoHorpzgZ avoTWN3kHR+AR7V8llXgAWvTTE+cbRpi7NxE2cGlQdeWVFBOKNAyNkUUyt9UjyiPQ3HE4w3e uYspGNg9aIcSGBEt6DZUi6idUBd8hR+hgtW34SMolJLiZeHSXRJ27XR5Uymx604Ms0NtE7Vy hKBoh8US0T4obSN+62k0UK9x3Uav+UcTvW10b9qoBVvmxxUOMahiA5Bi2fXqZoPWziwMxN0G bKtQbM3ZtsElBRDIE0zvIeGZQ5nvLXb7ScMdCMQa1EfGAVfH38jUGbwWZ3XuvFFjGfgrdkFx d3QgWlyINsXAIUO/rh1ygOi9fU8/zbvTg7szjmgC4q+82aodQqrl1AiKSQgnEuOA+KCbsTHY +QPFIRwLqTFTz/EfxKEljzYjTAoI3x0xxRo7RoMknO+OOFGuWbAkQBjxFvC9e5EwxoWMocb5 QtL4S0ljIF3OYYsTtlh4t7Tb82WV+KbdaME5+GsIhi3b4aGR7PE6pmbISziDlp3FFaTA/7+G LKwh9X0kySilzFFpETrL3ZO4p2RtMPwPyc5wyMgkx1cqpZIAvUqxfvmS3TgwN8wbW3nNw59f p56bWyNz+8M9OG9tuQ6S0kFSOkixDiJ14JQOnNKBi3VgqQNsmQyuBvSiVtqiP3Md2fuprD2a HEnpIfv1qDZpcjilB+/Xo9olbsSkWdojaKH3ZG7WChVGdCmiS6mcVRjWpbAupTLkF3SSoPqU ayW/tctSVgSJpoZ8Vo1qgyKINTX4s2qoUWx9oMwFRGbNv0qv+lSSYElu/aihfsMKvRm1J6Nu o3c1ad4MR+2R9HJ+f3N7mnFrLpIUaCBSg+rRXCQu0IClBjVCxNcZ3f5Q8k/35DFPYUhGKpdt CoMzUrkMR+NWU+6RSTbM9OWxzKBIjmQu0wwK50gW+xOgjSFs7JpL9c5Cr2owkidb7FsNhvNk Nc5/sgXF2X4/mnT6zXE37b10f7EDU0hSoGGPG1NIXKAhNwCG7fGoczX+ftCW/NM9ze1j4M4z 5FMwkhEkiqDKOQXDGUGsCGorq/MD+H/S7feukoWV7mpuX2TXVQpEsnJEymmrKgXCWTks5bJr atjotV78Qw8Kta84IBQUyZHcEwgKCudI/vlX03jYHg5TuV3v3JOIFBjJk92XiBQYzpPdkzx7 g2GnN77UOWudxZxVGMmT3cNZheE82X0Jf9hsjNrN60Ha01r3Pl+rQJIvv9ffKhDnyxfzvxwP b3rNxrit0U/1FrLXcSRXupi7jsO50v8LC+1y3Llup6df6dw3+TsYyZPdO/E7GM6TzZ10Wh9e 9W4mw3dq1ar2FNWrCoZkpAprVAWDM1K5DOkZUz0z6s/y3Jl/7tWwJCVLsrIqWw2LU7I4K5v2 aqs/7vab36lu1bqK/KqCSFau0LMqCGfl/swLh3Id9Aeqq5LHIjdJANHxhe6RAKzjCxfFZbM3 7qqMlI4iTjsIScsU8tpBcFpG4xaZ/IduB+wvu9FM7jNvnepPjeoPk3vZOKl+e18x7Qp6jiq2 +YdO9957uJW8wjOAm7wcs9Cv+wU1AlsMleNKRJdmQmo8zwIXOtYb+qOM5OcIOxl09sqe40fb J56nfGer32PS7waIP1s5/hLPjbyfaqzU7z5/36+rd9+m/uqvrNUvTH/z19a/8ovrL/rqWvxI hDtP+XWLHmYrpP+0JvkCCf7jv78t/Qdjy9H+kS8AAA== --e7rgc7IsuDeGjOzx-- --llxdKGCiKxUZMO8X Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNNcZeknh/jPvZzKNAQFfpgP9HHfR6jYRTstE+CGg5aBhFaQqXkdpyBwI GfPzCIZJ+ZuWeJH6XTWfCaMhDikxsm5186i0ulpvA1N13YqpN8idCZLzJWqyD7gJ 1RErlzfG+gM0N+SNpvndjc4sTqYQ40CgCw32Vpd4RdCPLfhRaGgdmbgtNMwf7CNL jQVZFcqpIu4= =tHC/ -----END PGP SIGNATURE----- --llxdKGCiKxUZMO8X-- From steve@gbnet.net Tue Feb 3 05:52:05 1998 Return-Path: steve@gbnet.net Received: from ns.gbnet.net (qmailr@ns.gbnet.net [194.70.126.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id FAA22122 for ; Tue, 3 Feb 1998 05:52:03 -0800 (PST) Received: (qmail 8833 invoked by uid 100); 3 Feb 1998 13:49:04 -0000 Date: Tue, 3 Feb 1998 13:49:03 +0000 From: Steve Kennedy To: MUTT Developers Subject: Further info Message-ID: <19980203134903.49160@gbnet.net> References: <19980126010834.26179@iil.intel.com> <19980126011901.02656@iil.intel.com> <19980126171421.41841@ask.tele.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.15i In-Reply-To: <19980126171421.41841@ask.tele.dk>; from Byrial Jensen on Mon, Jan 26, 1998 at 05:14:21PM +0100 Organisation: NetTek Ltd Here's the actual output of make gcc -o mutt addrbook.o alias.o attach.o bind.o browser.o buffy.o color.o commands.o complete.o compose.o copy.o curs_lib.o curs_main.o date.o edit.o enter.o flags.o init.o filter.o from.o getdomain.o handler.o hash.o hdrline.o headers.o help.o hook.o keymap.o lib.o main.o mbox.o menu.o mh.o mx.o pager.o parse.o pattern.o postpone.o print.o recvattach.o rfc822.o rfc1524.o rfc2047.o send.o sendlib.o signal.o sort.o status.o system.o thread.o pgp.o pgpinvoke.o pgpkey.o pgppubring.o sha1dgst.o resize.o snprintf.o rx/librx.a pop.o -lnsl -lncurses collect2: ld returned 2 exit status ld: Undefined symbol _difftime make: *** [mutt] Error 1 Steve -- NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103 Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU [ IndiNIC info - please email indinic@gbnet.net ] From nneul@umr.edu Tue Feb 3 06:21:10 1998 Return-Path: nneul@umr.edu Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id GAA01144 for ; Tue, 3 Feb 1998 06:21:09 -0800 (PST) Received: from infinity.cc.umr.edu (infinity.cc.umr.edu [131.151.37.9]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id IAA19578; Tue, 3 Feb 1998 08:21:08 -0600 (CST) Received: from (nneul@localhost) by infinity.cc.umr.edu (8.8.6/M.3.01) id IAA09695; Tue, 3 Feb 1998 08:21:07 -0600 Message-ID: <19980203082107.43516@umr.edu> Date: Tue, 3 Feb 1998 08:21:07 -0600 From: Nathan Neulinger To: mutt-dev@cs.hmc.edu Subject: Re: Problem with mime - I've narrowed it down... References: <19980202222230.20659@umr.edu> <19980203003032.38853@fnord.guru.execpc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203003032.38853@fnord.guru.execpc.com>; from Aaron Schrab on Tue, Feb 03, 1998 at 12:30:32AM -0600 On Tue, Feb 03, 1998 at 12:30:32AM -0600, Aaron Schrab wrote: > At 22:22 -0600, 02 Feb. 1998, Nathan Neulinger wrote: > > Here is what I have been able to come up with. > > > > Depending on which of the two attached mailboxes I view with the following > > mailcap, with one, 'cat' hangs when trying to auto_view the second part of > > the only message in the mailbox. With the other, it works fine. (The > > content-length and line counts are wrong, but this shouldn't matter.) > > > > There is a ONE line difference between the files. > > > I did notice the following - and the reason I'm including it is because > > the counts are right near a "magic" number so to speak. > > > > infinity(12)>wc -l mbox.* > > 255 mbox.broken > > 254 mbox.working > > Yes, it does seem to be because of a "magic" number, but not that one. > Here are the character counts of the decoded attachments: > > 140)fnord$ wc -c /tmp/broke /tmp/working > 12291 /tmp/broke > 12234 /tmp/working > > Those are on opposite sides of 3 * PIPE_BUFF(4096 bytes). My guess is > that what happens is: > > - Mutt fills the pipe then blocks while writing > - cat copies that data and blocks for reading (it's *just* filled its > outgoing pipe, but hasn't tried overfilling it yet so the write > doesn't block) > - Mutt again fills the pipe and blocks while writing > - cat empties the pipe again, blocks while writing > - Mutt again writes to the pipe > > For the smaller attachment, the final write will finish, and mutt will > go on to reading. But for the larger attachment the final write blocks > and there's a deadlock, both mutt and cat are waiting for the other to > read. > > And when I tried this on my Linux machine strace showed both mutt and > cat waiting to write. > > > Ugh. I just found out something, this problem only occurs on linux. Or at > > least, I am only able to reproduce it with this particular mailbox on > > linux. In case it helps, I'm running on kernel 2.0.29, slackware 3.3, > > libc 5.4.33. > > I doubt this only happens on Linux, although it did work here on Solaris > 2.5.1. What else did you try it with? Heres a breakdown: Linux: hangs HP-UX 10.20: works Solaris 2.5.1: works Irix 5.3: works AIX 3.2.5: works AIX 4.1.4: works Irix 6.4: works HP-UX 9.0.5: works (Now, this isn't the best test, since everything other than linux was tested with 0.88.14, and linux was tested with 0.89 but the problem has existed for a while.) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From roland@spinnaker.rhein.de Tue Feb 3 06:46:07 1998 Return-Path: roland@spinnaker.rhein.de Received: from uran.informatik.uni-bonn.de (uran.informatik.uni-bonn.de [131.220.8.49]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id GAA08456 for ; Tue, 3 Feb 1998 06:46:04 -0800 (PST) Received: (from root@localhost) by uran.informatik.uni-bonn.de (8.8.8-ws3/8.8.8-ws3) id PAA28676 for mutt-dev@cs.hmc.edu; Tue, 3 Feb 1998 15:46:03 +0100 (MET) >Received: from luv.rhein.de (root@localhost) by gatekeeper.rhein.de (8.8.8-ws3/8.8.8-ws3) with BSMTP id PAA23379 for mutt-dev@cs.hmc.edu; Tue, 3 Feb 1998 15:38:16 +0100 (MET) Received: from spinnaker.rhein.de (roland@spinnaker.rhein.de [193.175.27.89]) by luv.rhein.de (8.8.8/8.8.8) with ESMTP id OAA29273; Tue, 3 Feb 1998 14:25:54 +0100 From: Roland Rosenfeld Received: (from roland@localhost) by spinnaker.rhein.de (8.8.8/8.8.8) id OAA01976; Tue, 3 Feb 1998 14:25:51 +0100 Message-ID: <19980203142551.53488@spinnaker.rhein.de> Date: Tue, 3 Feb 1998 14:25:51 +0100 To: mutt-dev@cs.hmc.edu Subject: Re: [0.89] Feature alternative/header Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980128103541.45545@shell9.ba.best.com> Mime-Version: 1.0 X-Mailer: Mutt 0.90i In-Reply-To: <19980128103541.45545@shell9.ba.best.com> Content-Type: text/plain; charset=us-ascii On Wed, 28 Jan 1998, Brandon Long wrote: > The following patch does two things, one it improves the > multipart/alternative handler to better search for a part that mutt > will handle. Previously, it would only choose a text/plain, > text/enriched or text/html part. Now, it first searches for a part > for which you have an auto_view set. Then it searches for a text > part as before. And finally, it will search for any part that mutt > thinks it can display (using the mutt_can_decode() function). I didn't try this patch before, but now it's in 0.90i and so I have to use it... The behaviour isn't the way I like, because when choosing between text/plain and text/html the new mutt will select text/html, where I defined an auto_view for (using lynx). This has two disadvantages: 1. lynx takes times, which isn't needed, if text/plain is used instead 2. The output of lynx isn't as good as the text/plain message because there are no quote chars used but often the quoted parts are simply indented a bit. So I want to have a chance to define text/plain as the most liked MIME-type. I tried by adding auto_view text/plain, but this results in a message "auto_view using cat" (or similar) in _every_ message, and that isn't what I want, too. Please switch back to the old behaviour or add a configuration option to set a priority list, which defines what part should be handled with priority in multipart/alternative. BTW: I could remove text/html from auto_view, but this isn't what I really want, because it would stop the chance to view a text/html part of a multipart/mixed mail without entering the view-mode. > The second thing the patch adds is when you are using the > 'view-headers' mode, the headers for mime parts are also displayed. Very good idea! I used "|less" before to look at these, with your patch this is much easier. Ciao Roland -- * Internet: roland@spinnaker.rhein.de * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF From nneul@umr.edu Tue Feb 3 07:01:08 1998 Return-Path: nneul@umr.edu Received: from umr.edu (hermes.cc.umr.edu [131.151.1.68]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id HAA13018 for ; Tue, 3 Feb 1998 07:01:06 -0800 (PST) Received: from infinity.cc.umr.edu (infinity.cc.umr.edu [131.151.37.9]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id JAA05072; Tue, 3 Feb 1998 09:00:44 -0600 (CST) Received: from (nneul@localhost) by infinity.cc.umr.edu (8.8.6/M.3.01) id JAA09839; Tue, 3 Feb 1998 09:00:25 -0600 Message-ID: <19980203090025.32942@umr.edu> Date: Tue, 3 Feb 1998 09:00:25 -0600 From: Nathan Neulinger To: mutt-dev@cs.hmc.edu Subject: Re: Problem with mime - I've narrowed it down... References: <19980202222230.20659@umr.edu> <19980203003032.38853@fnord.guru.execpc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203003032.38853@fnord.guru.execpc.com>; from Aaron Schrab on Tue, Feb 03, 1998 at 12:30:32AM -0600 > > Ugh. I just found out something, this problem only occurs on linux. Or at > > least, I am only able to reproduce it with this particular mailbox on > > linux. In case it helps, I'm running on kernel 2.0.29, slackware 3.3, > > libc 5.4.33. > > I doubt this only happens on Linux, although it did work here on Solaris > 2.5.1. What else did you try it with? I just got a different message and the symptom occurred elsewhere (on an HP-UX 10.20 machine.) So it is probably occurring all over the place, but the file sizes which trigger it are different. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From fox@fuzzy.rsn.hp.com Tue Feb 3 09:44:51 1998 Return-Path: fox@fuzzy.rsn.hp.com Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id JAA05999 for ; Tue, 3 Feb 1998 09:44:42 -0800 (PST) Received: from fuzzy.rsn.hp.com (fox@fuzzy.rsn.hp.com [15.99.4.115]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id JAA08077 for ; Tue, 3 Feb 1998 09:44:29 -0800 (PST) Received: (from fox@localhost) by fuzzy.rsn.hp.com (8.7.1/8.7.1) id LAA01242; Tue, 3 Feb 1998 11:44:27 -0600 (CST) Message-ID: <19980203114426.09820@rsn.hp.com> Date: Tue, 3 Feb 1998 11:44:26 -0600 From: David DeSimone To: MUTT Developers Subject: Re: Further info Mail-Followup-To: MUTT Developers References: <19980126010834.26179@iil.intel.com> <19980126011901.02656@iil.intel.com> <19980126171421.41841@ask.tele.dk> <19980203134903.49160@gbnet.net> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=ylu36WmvOXNoKYnQ X-Mailer: Mutt 0.89i In-Reply-To: <19980203134903.49160@gbnet.net>; from Steve Kennedy on Tue, Feb 03, 1998 at 01:49:03PM +0000 --ylu36WmvOXNoKYnQ Content-Type: text/plain; charset=us-ascii Steve Kennedy wrote: > > ld: Undefined symbol > _difftime > make: *** [mutt] Error 1 What OS are you running? On my system (HPUX 10.20), difftime() shows up as a system library function. double difftime(time_t time1, time_t time0); difftime() Return the difference in seconds between two calendar times: time1 - time0. I guess you could try this, if you have a suitable-defined time_t: #define difftime(time1, time0) ((double)(time1) - (double)(time0)) -- David DeSimone | "The doctrine of human equality reposes on this: fox@rsn.hp.com | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division | PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44 --ylu36WmvOXNoKYnQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNNdXbw0lGhIp2tThAQHRXwMAwgUCWodXqjdW1hdgkfYbzsA5V9ti0IxC VpElWFqt29Cnz2+LPSGeft5uVaTQR1VogjmB7/YkfN5z2tXRmvzwiPS1UZ+IDEUn 9+n978EGfQrbeI5/2Xqnj6ayVk+7Oto7 =TaQn -----END PGP SIGNATURE----- --ylu36WmvOXNoKYnQ-- From steve@gbnet.net Tue Feb 3 10:18:30 1998 Return-Path: steve@gbnet.net Received: from ns.gbnet.net (qmailr@ns.gbnet.net [194.70.126.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id KAA16907 for ; Tue, 3 Feb 1998 10:18:28 -0800 (PST) Received: (qmail 14929 invoked by uid 100); 3 Feb 1998 18:15:28 -0000 Date: Tue, 3 Feb 1998 18:15:28 +0000 From: Steve Kennedy To: MUTT Developers Subject: Re: Further info Message-ID: <19980203181528.30259@gbnet.net> References: <19980126010834.26179@iil.intel.com> <19980126011901.02656@iil.intel.com> <19980126171421.41841@ask.tele.dk> <19980203134903.49160@gbnet.net> <19980203114426.09820@rsn.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.15i In-Reply-To: <19980203114426.09820@rsn.hp.com>; from David DeSimone on Tue, Feb 03, 1998 at 11:44:26AM -0600 Organisation: NetTek Ltd On Tue, Feb 03, 1998 at 11:44:26AM -0600, David DeSimone wrote: > Steve Kennedy wrote: > > ld: Undefined symbol > > _difftime > > make: *** [mutt] Error 1 > What OS are you running? On my system (HPUX 10.20), difftime() shows up > as a system library function. > double difftime(time_t time1, time_t time0); > > difftime() Return the difference in seconds between two > calendar times: time1 - time0. > I guess you could try this, if you have a suitable-defined time_t: > #define difftime(time1, time0) ((double)(time1) - (double)(time0)) SunOS 4.1.4, gcc 2.7.2.3 Sun Sparc10 Steve -- NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103 Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU [ IndiNIC info - please email indinic@gbnet.net ] From olsenc@ichips.intel.com Tue Feb 3 10:20:15 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id KAA17407 for ; Tue, 3 Feb 1998 10:20:12 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id KAA26640 for ; Tue, 3 Feb 1998 10:23:43 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id KAA21445 for ; Tue, 3 Feb 1998 10:20:01 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id KAA12349; Tue, 3 Feb 1998 10:19:58 -0800 (PST) Message-ID: <19980203101958.43794@dtthp169.jf.intel.com> Date: Tue, 3 Feb 1998 10:19:58 -0800 From: Clint Olsen To: MUTT Developers Subject: Re: Further info Mail-Followup-To: MUTT Developers References: <19980126010834.26179@iil.intel.com> <19980126011901.02656@iil.intel.com> <19980126171421.41841@ask.tele.dk> <19980203134903.49160@gbnet.net> <19980203114426.09820@rsn.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203114426.09820@rsn.hp.com>; from David DeSimone on Tue, Feb 03, 1998 at 11:44:26AM -0600 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 03, David DeSimone wrote: > Steve Kennedy wrote: > > > > ld: Undefined symbol > > _difftime > > make: *** [mutt] Error 1 > > What OS are you running? On my system (HPUX 10.20), difftime() shows up > as a system library function. There doesn't seem to be a difftime on SunOS 4.1.X. -Clint From steve@gbnet.net Tue Feb 3 10:32:52 1998 Return-Path: steve@gbnet.net Received: from ns.gbnet.net (qmailr@ns.gbnet.net [194.70.126.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id KAA21862 for ; Tue, 3 Feb 1998 10:32:50 -0800 (PST) Received: (qmail 15497 invoked by uid 100); 3 Feb 1998 18:29:50 -0000 Message-ID: <19980203182950.30807@gbnet.net> Date: Tue, 3 Feb 1998 18:29:50 +0000 From: Steve Kennedy To: mutt-dev@cs.hmc.edu Subject: difftime Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980114131001.29721@aha.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980114131001.29721@aha.com>; from Karl Hakimian on Wed, Jan 14, 1998 at 01:10:01PM -0800 Organisation: NetTek Ltd Hi, used the #define and everything compiled. It's definately NOT in SunOS (4.1.3U1 or 4.1.4) Steve -- NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103 Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU [ IndiNIC info - please email indinic@gbnet.net ] From fox@fuzzy.rsn.hp.com Tue Feb 3 10:40:21 1998 Return-Path: fox@fuzzy.rsn.hp.com Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id KAA24051 for ; Tue, 3 Feb 1998 10:40:16 -0800 (PST) Received: from fuzzy.rsn.hp.com (fox@fuzzy.rsn.hp.com [15.99.4.115]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id KAA06127 for ; Tue, 3 Feb 1998 10:38:45 -0800 (PST) Received: (from fox@localhost) by fuzzy.rsn.hp.com (8.7.1/8.7.1) id MAA01377; Tue, 3 Feb 1998 12:38:44 -0600 (CST) Message-ID: <19980203123843.35685@rsn.hp.com> Date: Tue, 3 Feb 1998 12:38:43 -0600 From: David DeSimone To: mutt-dev@cs.hmc.edu Subject: Re: configure problem Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=ZAtKRhVyVSsbBD2z X-Mailer: Mutt 0.89i In-Reply-To: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de>; from Ralf Hildebrandt on Tue, Feb 03, 1998 at 02:20:00PM +0100 --ZAtKRhVyVSsbBD2z Content-Type: text/plain; charset=us-ascii Ralf Hildebrandt wrote: > > configure says my system has "snprintf" - but it definitely hasn't... If it definitely doesn't have it, then why does configure find it? Configure compiles a short program like this: main() { snprintf(); } That program is evidently succeeding to build. If so, then which library does it pull the snprintf() code from? And why doesn't it pull that code from the same library when mutt builds? > System: HP-UX 9.03, gcc 2.7.2.3, GNU make, GNU everything... I don't have a 9.03 system to test with, but I do have 9.05, which is known to have snprintf problems, let me go try it.... Hmm, okay, my 9.05 system somehow does have snprintf(), and it is found in libc. I even wrote a little test program to see if the snprintf() works, and it works (almost... it appears to be a simple pass-through to sprintf(), which means it is completely unsafe - you are better off using Mutt's snprintf() in this case). So, I'm not sure what to tell you. My system has it, and configure *is* finding it on your system, so you will have to do some work to find out which library it comes from. -- David DeSimone | "The doctrine of human equality reposes on this: fox@rsn.hp.com | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division | PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44 --ZAtKRhVyVSsbBD2z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNNdkLg0lGhIp2tThAQEhlQL8CjGNunSQphyAwqKHRhDdognzMNKGakLZ wDQOIqFEUwNQD61/m8UhQq3G8fSV16TWn5J0rnDlk5PboUzy/+EYaYlXVFxfT38J Yn73J/ExmDqJeB7yOUisluFMcQgoW4Tu =RQhF -----END PGP SIGNATURE----- --ZAtKRhVyVSsbBD2z-- From eisenbud@allspice.cs.swarthmore.edu Tue Feb 3 11:17:15 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id LAA08140 for ; Tue, 3 Feb 1998 11:17:11 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id OAA05594; Tue, 3 Feb 1998 14:16:55 -0500 (EST) Message-ID: <19980203141654.58127@cs.swarthmore.edu> Date: Tue, 3 Feb 1998 14:16:54 -0500 From: Daniel Eisenbud To: "The mutt developpers' list" Subject: Re: difftime Mail-Followup-To: The mutt developpers' list References: <19980203112943.47260@sobolev.rhein.de> <19980203111537.03459@gbnet.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ReaqsoxgOBHFXBhH X-Mailer: Mutt 0.90i In-Reply-To: <19980203111537.03459@gbnet.net>; from Steve Kennedy on Tue, Feb 03, 1998 at 11:15:37AM +0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 11:15:37AM +0000, Steve Kennedy wrote: > 12 > > Trying to compile mutt-0.90i > > _difftime isn't defined ? (in parse.c) Here's a patch that just gets rid of difftime. There's absolutely no reason that we can't just use < with two time_t's; we even subtract them in buffy.c, and nobody has reported any problems. This patch also does some minor reformatting and cleanup. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90i.de.difftime.1" --- mutt-0.90i.orig/parse.c Tue Feb 3 04:43:53 1998 +++ mutt-0.90i/parse.c Tue Feb 3 14:12:47 1998 @@ -1001,11 +1001,9 @@ ENVELOPE *_mutt_read_rfc822_header (FILE break; case 'e': - if(option(OPTEXPIRES)) - if (!strncasecmp ("xpires:", line + 1, 7)) - if (hdr) - if(difftime(parse_date (p, hdr),time(NULL))<0) - hdr->deleted = 1; + if (option (OPTEXPIRES) && !strncasecmp ("xpires:", line + 1, 7) && + hdr && parse_date (p, hdr) < time (NULL)) + hdr->deleted = 1; break; case 'f': @@ -1225,7 +1223,7 @@ ENVELOPE *_mutt_read_rfc822_header (FILE * list already. if not, add it so we can do a better job of threading. */ if (!keep && in_reply_to[0] && - (p = extract_message_id (in_reply_to)) != NULL) + (p = extract_message_id (in_reply_to)) != NULL) { if (!e->references || (e->references && strcmp (e->references->data, p) != 0)) --ReaqsoxgOBHFXBhH-- From manojk@pentagon.io.com Tue Feb 3 11:50:03 1998 Return-Path: manojk@pentagon.io.com Received: from pentagon.io.com (manojk@pentagon.io.com [199.170.88.5]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id LAA20007 for ; Tue, 3 Feb 1998 11:49:16 -0800 (PST) Received: (from manojk@localhost) by pentagon.io.com (8.8.5/8.8.5) id NAA22161; Tue, 3 Feb 1998 13:47:50 -0600 (CST) Message-ID: <19980203134750.62654@io.com> Date: Tue, 3 Feb 1998 13:47:50 -0600 From: Manoj Kasichainula To: Mutt Development List Subject: Re: [0.89i] empty_lines feature-patch Mail-Followup-To: Mutt Development List References: <19980201210418.38528@bofh.belwue.de> <19980202164506.63451@la.tis.com> <19980203085906.36905@deadend.argh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980203085906.36905@deadend.argh.org>; from Alexander Koch on Tue, Feb 03, 1998 at 08:59:06AM +0100 X-spam-bait: postmaster@warez.io.com abuse@warez.io.com On Tue, Feb 03, 1998 at 08:59:06AM +0100, Alexander Koch wrote: > > I understand that but I, too, know three hardcore elm users that won't > use mutt because of that. To add to the other comments, I'll mention that you can always keep your patch around, and add it when you compile new versions. Several people on this list have been known to do just that for their particular pet feature (pil was like this for a long time). -- Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/ "I am the key on the sardine can of justice!" - Darkwing Duck From eisenbud@allspice.cs.swarthmore.edu Tue Feb 3 12:09:59 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA26970 for ; Tue, 3 Feb 1998 12:09:54 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id PAA06733; Tue, 3 Feb 1998 15:09:43 -0500 (EST) Message-ID: <19980203150943.27028@cs.swarthmore.edu> Date: Tue, 3 Feb 1998 15:09:43 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: [0.90i] bugfix: buffy nits Mail-Followup-To: Mutt Development List References: <19980202111333.01745@att.com> <19980202133233.45583@cs.swarthmore.edu> <19980202140932.47994@cs.swarthmore.edu> <19980203004907.02831@ask.tele.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203004907.02831@ask.tele.dk>; from Byrial Jensen on Tue, Feb 03, 1998 at 12:49:07AM +0100 On Tue, Feb 03, 1998 at 12:49:07AM +0100, Byrial Jensen wrote: > On Mon, Feb 02, 1998 at 02:09:32PM -0500, Daniel Eisenbud wrote: > > On Mon, Feb 02, 1998 at 01:32:33PM -0500, Daniel Eisenbud wrote: > > > The attached patch adds a bunch of sanity checks to > > > buffy.c that should help prevent this kind of thing (including a > > > possible infinite loop.) It also fixes the minor problem of buffy > > > sometimes checking twice in a row after opening a mailbox. > > Here is second version of this patch which furthermore removes some > superfluous assignments. Michael, Byrial's 1->2 patch below should still go into 0.90.1 or something. -Daniel --- buffy.c~ Tue Feb 3 00:32:55 1998 +++ buffy.c Tue Feb 3 00:34:42 1998 @@ -339,12 +339,10 @@ /* this only checks for new mail each BuffyTimeout (def. 3) seconds */ int mutt_buffy_check (void) { - time_t t; /* fastest return if there are no mailboxes */ if (!Incoming) return 0; - t = time (NULL); - if ((t - BuffyTime) < BuffyTimeout) + if ((time (NULL) - BuffyTime) < BuffyTimeout) return BuffyCount; return mutt_force_buffy_check(); } @@ -383,11 +381,11 @@ */ void mutt_buffy (char *s) { - int count = 0; + int count; BUFFY *tmp = Incoming; mutt_expand_path (s, _POSIX_PATH_MAX); - switch (count = mutt_buffy_check ()) + switch (mutt_buffy_check ()) { case 0: -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From eisenbud@allspice.cs.swarthmore.edu Tue Feb 3 12:48:18 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA09494 for ; Tue, 3 Feb 1998 12:47:10 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id PAA08157; Tue, 3 Feb 1998 15:47:05 -0500 (EST) Message-ID: <19980203154705.55341@cs.swarthmore.edu> Date: Tue, 3 Feb 1998 15:47:05 -0500 From: Daniel Eisenbud To: mutt-dev@cs.hmc.edu Subject: Re: difftime Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980114131001.29721@aha.com> <19980203182950.30807@gbnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203182950.30807@gbnet.net>; from Steve Kennedy on Tue, Feb 03, 1998 at 06:29:50PM +0000 On Tue, Feb 03, 1998 at 06:29:50PM +0000, Steve Kennedy wrote: > Hi, used the #define and everything compiled. > > It's definately NOT in SunOS (4.1.3U1 or 4.1.4) Could you reply to your old messages, instead of replying to random messages? This topic is already spread out over three unrelated threads... -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From eisenbud@allspice.cs.swarthmore.edu Tue Feb 3 12:57:34 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA13244 for ; Tue, 3 Feb 1998 12:57:12 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id PAA08311; Tue, 3 Feb 1998 15:56:40 -0500 (EST) Message-ID: <19980203155640.03576@cs.swarthmore.edu> Date: Tue, 3 Feb 1998 15:56:40 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.89.1, 0.89.1i] My feature patches Mail-Followup-To: Mutt Development List References: <19980201201808.34760@cs.swarthmore.edu> <19980202163458.39122@la.tis.com> <19980202230802.61262@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980202230802.61262@cs.swarthmore.edu>; from Daniel Eisenbud on Mon, Feb 02, 1998 at 11:08:02PM -0500 On Mon, Feb 02, 1998 at 11:08:02PM -0500, Daniel Eisenbud wrote: > On Mon, Feb 02, 1998 at 04:34:58PM -0800, Michael Elkins wrote: > > On Sun, Feb 01, 1998 at 08:18:08PM -0500, Daniel Eisenbud wrote: > > > index-percentage adds a format specifier (%P) for the status line, which > > > tells you how far through the index you are. This is particularly > > > useful when in a limited display, when there's no other way to tell. > > > This also adds %P to the right hand of the default status line. > > > > Redrawing the status line on every keypress seems a bit much. Why not just > > make it change when you change pages or scroll the screen instead? I've > > still seen the same amount of the total messages if I stay on the same page. > > I thought that's what I did. I certainly meant to only redraw the > status line on a REDRAW_INDEX, not on REDRAW_CURRENT or REDRAW_MOTION. > But maybe I goofed it up? I don't have time to look at the code this > moment, but I certainly agree with you about how it should be done. I used gdb with a breakpoint on menu_status_line(), and it is only called when switching pages or otherwise redrawing the whole index, and when (as before) changing flags, etc. Given that, could this perhaps go in 0.90.1? -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From blong@shell9.ba.best.com Tue Feb 3 13:12:09 1998 Return-Path: blong@shell9.ba.best.com Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA18843 for ; Tue, 3 Feb 1998 13:12:06 -0800 (PST) Received: (from blong@localhost) by shell9.ba.best.com (8.8.8/8.8.BEST) id NAA12191; Tue, 3 Feb 1998 13:11:45 -0800 (PST) Message-ID: <19980203131144.57166@shell9.ba.best.com> Date: Tue, 3 Feb 1998 13:11:44 -0800 From: Brandon Long To: mutt-dev@cs.hmc.edu Subject: Re: configure problem Reply-To: blong@fiction.net Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de> <19980203123843.35685@rsn.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980203123843.35685@rsn.hp.com>; from David DeSimone on Tue, Feb 03, 1998 at 12:38:43PM -0600 Organization: Fiction L Networks X-Pgp-Public-Key: X-Uri: On 02/03/98 David DeSimone uttered the following other thing: > Ralf Hildebrandt wrote: > > > > configure says my system has "snprintf" - but it definitely hasn't... > > If it definitely doesn't have it, then why does configure find it? > > Configure compiles a short program like this: > > main() > { > snprintf(); > } > > That program is evidently succeeding to build. If so, then which > library does it pull the snprintf() code from? And why doesn't it pull > that code from the same library when mutt builds? > > > System: HP-UX 9.03, gcc 2.7.2.3, GNU make, GNU everything... > > I don't have a 9.03 system to test with, but I do have 9.05, which is > known to have snprintf problems, let me go try it.... > > Hmm, okay, my 9.05 system somehow does have snprintf(), and it is found > in libc. I even wrote a little test program to see if the snprintf() > works, and it works (almost... it appears to be a simple pass-through to > sprintf(), which means it is completely unsafe - you are better off > using Mutt's snprintf() in this case). > > So, I'm not sure what to tell you. My system has it, and configure *is* > finding it on your system, so you will have to do some work to find out > which library it comes from. The problem isn't with snprintf, but with vsnprintf. Mutt only tests for snprintf with configure, and then uses vsnprintf in curs_lib.c. HP-UX has snprintf but not vsnprintf. So, configure should either check for both, or check for vsnprintf (which should work for both). Brandon -- Brandon Long "Here's a nickel, kid. MD6 Crash Test Dummy Get yourself a better computer." Intel Corporation -"Dilbert" by Scott Adams 6-24-95 I'm too low on the totem pole to speak for Intel. http://www.fiction.net/blong/ From michael@tis.com Tue Feb 3 13:55:28 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA03910 for ; Tue, 3 Feb 1998 13:55:26 -0800 (PST) Received: by relay.la.tis.com; id OAA23222; Tue, 3 Feb 1998 14:06:19 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma023218; Tue, 3 Feb 98 14:06:13 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id NAA22051; Tue, 3 Feb 1998 13:52:22 -0800 (PST) Message-ID: <19980203135222.26634@la.tis.com> Date: Tue, 3 Feb 1998 13:52:22 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.90i] feature: thread_hash (EXPERIMENTAL) Mail-Followup-To: Mutt Development List References: <19980202191413.13067@la.tis.com> <19980203030844.41770@xenomorph.dyn.ml.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0 X-Mailer: Mutt 0.90i In-Reply-To: <19980203030844.41770@xenomorph.dyn.ml.org>; from Bill Nottingham on Tue, Feb 03, 1998 at 03:08:44AM -0600 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 03:08:44AM -0600, Bill Nottingham wrote: > More segfaults here. I must just be lucky. > > These segfaults all occur at some point after opening one particular > maildir mailbox, which is attached. FWIW, this mailbox is *NOT* sorted > correctly when first opened, and you can't even see all its messages. Thank you! This really helped me figure out what was going on, and I have fixed the problem. This turned out to be a problem with the pseudo threading code. If you have some real threads, such as A -> B -> C they will all be in the same bin in the hash table since they all have the same subjects (at least for the example case that caused problems). The new pseudo threading code will look through all the messages in the bin (because they have the same subject) to find the best match. However, this means that message `B' or `C' could be returned as a pseudo thread match for `A', so I had to add an extra check to not match messages in the same thread. I'm not really sure why the old code doesn't have this same problem, because it used to store all the messages with different subjects in a lookup table. Consider the case where you have A foo \ B bar \ C foo In this case `C' could be a match for `A'. Perhaps we have just never seen this because it isn't likely that anyone would change the subject back to the original topic. One thing that I am not sure about is whether or not to keep the previous behavior of only matching messages in which the subject has changed. In the first case where all messages have the same subject, should psuedo threads be attached to children of the thread? Or only to the top parent of the thread? As it currently stands with this patch, you can get things that look like A +->B | +*>D +->C Since `B' might be the closest in time to `D'. But in the current code it would get threaded as A +->B +*>D +->C Which is more correct? Daniel? me --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.thread_hash.1-2 --- mutt-0.90.patched/thread.c Mon Feb 2 19:15:47 1998 +++ mutt-0.90.thread_hash/thread.c Tue Feb 3 13:24:14 1998 @@ -165,6 +165,15 @@ msg->next = NULL; } +/* returns 1 if `a' is a descendant (child) of thread `b' */ +static int is_descendant (HEADER *a, HEADER *b) +{ + /* find the top parent of the thread */ + while (a->parent) + a = a->parent; + return (a == b); +} + /* find the best possible match for a parent mesage based upon subject. if there are multiple matches, the one which was sent the latest, but before the current message, is used. */ @@ -182,8 +191,9 @@ for (ptr = ctx->subj_hash->table[hash]; ptr; ptr = ptr->next) { tmp = ptr->data; - if (tmp != cur && - !tmp->fake_thread && + if (tmp != cur && /* don't match the same message */ + !tmp->fake_thread && /* don't match pseudo threads */ + !is_descendant (tmp, cur) && /* don't match in the same thread */ cur->date_sent >= tmp->date_sent && (!last || (last->date_sent <= tmp->date_sent)) && tmp->env->real_subj && @@ -196,6 +206,23 @@ return last; } +static void unlink_message (HEADER **top, HEADER *cur) +{ + if (cur->prev) + { + cur->prev->next = cur->next; + + if (cur->next) + cur->next->prev = cur->prev; + } + else + { + if (cur->next) + cur->next->prev = NULL; + *top = cur->next; + } +} + static void pseudo_threads (CONTEXT *ctx, sort_t *sortFunc) { HEADER *tree = ctx->tree; @@ -208,12 +235,7 @@ if ((tmp = find_subject (ctx, cur)) != NULL) { /* detach this message from it's current location */ - if (tree) - tree->prev = cur->prev; - if (cur != top) - cur->prev->next = cur->next; - else - top = cur->next; + unlink_message (&top, cur); cur->subject_changed = 0; cur->fake_thread = 1; @@ -228,12 +250,7 @@ if (curchild->fake_thread) { /* detach this message from its current location */ - if (curchild->next) - curchild->next->prev = curchild->prev; - if (curchild->prev) - curchild->prev->next = curchild->next; - else - cur->child = curchild->next; + unlink_message (&cur->child, curchild); curchild->parent = tmp; insert_message (&tmp->child, curchild, sortFunc); } @@ -321,23 +338,6 @@ } } return top; -} - -static void unlink_message (HEADER **top, HEADER *cur) -{ - if (cur->prev) - { - cur->prev->next = cur->next; - - if (cur->next) - cur->next->prev = cur->prev; - } - else - { - if (cur->next) - cur->next->prev = NULL; - *top = cur->next; - } } static void move_descendants (HEADER **tree, HEADER *cur, sort_t *usefunc) --k+w/mQv8wyuph6w0 Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-0.90.me.thread_hash.2.gz H4sICGSL1zQAA3BhdGNoLTAuOTAubWUudGhyZWFkX2hhc2guMgDsPGl32ziSn+VfgbjfdHSQ iiTLp+K8dqedieflerazvf26sxqKhCzGFKkhKTvexP996wBAkJRs5/iwHzqvx6RAoFAo1Ikq TBBOp8J9s0zFfJnnbq+733vy2ruU0zCS3TAuWrv5LJVeMJ552czuseG67uqxjddJLF7IiRAD 0e8dDHcOBvCyv7+30el07gdcGr5/0BscDNXwX34R7ta+sys69PeXXzbE21//dXbY8IIgnSTJ ZTcRXhR6GT7z3PNn8DIJ4wAfaXKdyRTfltPpDTz9JErw918bQv/zk/nci4OMvs4Xkcylek0y flvQyGWajaNwol/nXhjDe+BRd4DXkEGYw6uMc5pyGnkXCDSMqRkWqtrTZA6PC5kHiQLy14bb mAEOEXWYBWkUxgh1BqSSaUZv0QIfvN5LeTP38DfjY6B0bChA4e8CJhrzSfIJW2S8xAeCm2PD wrugKRZeShRaAN1lqkcB2fJFQlMu0jDGtafSvzJ7k079vcFAdYYf/e3BkJsHveEuvGWSNg8f jFIWXsRehC9JmtPAX8PYS2+QpjKz+NFPUimAAmv4jT4HIAMy3QhWiAKRzF8zmD9WBIAbG7/L QPwmfbHVF/2dg14P/gPm3dm/g/fVyDvZvuf0RKfv9HtbyPadJ+2NjmiL58CPaXgxy0XzeQs7 77h74nXozzwZidOuOI4uwzgTT+fyFz/rzuZ+VwbLZziUhuO/81mYweYkF6k3F/A6TaUE4k7z ay+VI3GTLIXvxbBtQZjlaThZ5lKEOVL2SQIES4B4NwYYfFjGwFkin0kBfDDPRDKlH/988178 U8Yy9SLxbjmJQl+8Cn0ZZ7BJMD+2ZDMg3aQAhsNeIDZnChvxIgHoXh4m8UjIEL6n4grYGH4D zdRECqojktRAano5LiQVyQIHtwD7GxGBtJrxXeq7lijF2gOQYZpnlixgiTOADIu+DqNITKRY ZnK6jBwDB0aI30/OX759fy6O3vwhfj86PT16c/7HCEbkswS+yivJ8EJQNyGAh4WmXpzfwHoM mNfHp89fwrijX09enZz/AUsTL07O3xyfnYkXb0/FkXh3dHp+8vz9q6NT8e796bu3Z8ddIc4k IigNlDu2YEpbiRIhcy+Msgo5/gAmyADdKABVciVRhmV4Bch6pBHv32MDyYuS+IIWDyMKGo9E OBVxkjviOg2BwfKkvvsGRsEFjjiJ/a4jdna3xWsvy8TRFWz8c28+ScPgAl5fH4neoA/GQrw/ O6JFPYFVbXR+CmM/WgZSPM1yUiyzZ5XGMKE2q3WTxHS2iY2gykipjpEtYEHNZYyKCSgCopeK duYI7BK3NjqfYVb6MROHojfCX9cz0FWi2c5a+EvAl84hjOl06Gsq82Uai+ZM/AMAQNMtzvjy 6OylaNOcPmgOoFGTZpCRnOtZuE/uTQD6ISjvKEp80czC/5WwQU382mrRFNTFfUaDoSc97Q8a hK9AUAdHaEiw6KWvCEAg2gquQp2Ga8QNqUARyTRnPBSWjiIXmB1HXCVhINqwsZ5eT32eRZ6u WFm1n8JGE720UdWdagma3KYIjsbxMJn7DL4CCPg7Mk2IIrTho2iM5accGm0C/jn7UCMqtEEv GGHTa6ZpxSQgfKfgtZB1qBBMk9Mi3X3kKs8PXxktlPnmiHAR3NEshPjyMzNnyAT25wvRJFJp srTEITC0YuGCbQ2JeBNurXW+ef/qVWmphGog0c164Fq/hk3WrLvePfIy3DuF3oMp86SNxPk3 ovIYjcQFqERQSRG4UgTCA0bN/RmynWKauZxPwFsSrPvCTNMOCPSfZQgmlsah5vM90MrXYODg r2SlO19GeQguKTqVaQi+jtKiYK29uTSgkGHbT4q9a9LMP/8s+OXwsGDiVkt8+SL05up9dUR1 cz9r4AgPiQXtDXwatjf0GemuMkKt36jvwcre5HQgBq1RmZ/Uz1t+qI3S4nO7gpdgNcmN5iNk BFsFh6NCTS54Z9saWJ0tWOm18/lCKQTiixDVuACDJZ6KhVoJqk8Rdjo2d1BnpWC5HxMh/AC+ Cw2oUhcmgr5GFzMVaTw+KhQDVsokaFMY5Ijeet3calWIDANaNlXpj6K/2QAlQUZg13rIs7tc 2tkqD3n2zR7y7EEe8rD/t4P8t4P8t4P8fQ5yVY0oJWrsMGmJwhSv0aBKY92S/sxvFjKQU9XN 0sqF+1mH0Da+JKltAvQTQAljKYyf1FT+AtmtsvekP93tA9ZdQAZWm419FWs+h+xozZH5rmkd obybe7z+0VfEIaNvc8RH3+yTjn6Mize6y7pjI/RYZZzwba1x4o8V48SNJROzdbC9ezDcu+/o csXImnEa7Dg7ogN/+dRyQxRhpToDg8DSagRln1OsWQ8/cbDiyfPT98eiX/x+cfTq7Fj0eMa9 facPFnGw38MnzirE0W+/naJSbKdyEd2M82RUap2DahtPE4iurpcL/VVx0nLyUfogza5uAQJE Y2wesS+cTKfokShVh1+FGqT80eqwRuPeUWb6ucwy70KOw4AweHVydo6gpuAgx77MRoSB6iSK dhQX+Ik2TIJRAMPbQrAGApijdBakOJ4g4G/BxAz0IanCvjYlof/gKTu1KWn8ugnFrTh+81/H r96+Ox7hjpeVJ562gs8P5pm2etjvIXcN+31nT200kHWck1NIe/jy+Oi341MUGZzZbsnBggAq iEueLHgfkLUFflCIs7iFzO6MN4kyHxNMbsQ8uxAoslZv3MS1/cs7jDqgfTVIFRpzb7FAXYZn 4+IqTPMl8ESeMG/ATHFijYP1zL1PamS8xPAK17BIQjx5z9AXwSVbIwCCD/Yxr41RW5lp/wWF YZJ8wqErNcyntcfD+KmqXT5VDng5LbJ1r26pjqtplu29Ldx8fBgxV8sFwRqzQyeab9+dgyf0 /Pj0+AXI+ssWclWHeF4ZlmKHNMf7+Sf3mdp1fYyirdBge5cjBepkNntNtw0VOz6i3hDqSggh OYyBVY+1EDU3T2HhuPf/yLrd7qbD0BdePiN8cbk74KvAcneG1nIRNPWcexfgUkHk+np88vro nZojBI4aTyF09KMkk2O9rzgEwf4kY9hfpMT7s2Map9ZvwJrl6fO6kjH6udJnVBqr6HfHSN2D xLIIMTnC5GVpluUYsyAchiJj1hoaGnI7xJgMLfOmcsyxXZONarslin7QCUm6t7uHKbW9PW2d 8B91iuU1H1oWTaCO4wvQVZVmTHCZZtfEv+EhhKYfD3ExT1ctpYiUac3Q9wFL/6zzdQVLqVW7 z9jTCFq6y2da4X5vC1e4DwqyP6QlNj7iaavqdKtf+NBCj+ygfkjlPMHDF8WipJQouqmIS8Ps uMFFxlfuM2Pu8MxE2O5QlbkUt68ZXv6KTLZuxsJUrptScdzKCYvRtRlF436m65QoemtxiN5J 2OCPWpj7vb1dpw870+/3BviijFcECKLWPixQICtI+ioL50sMTTG2QoFWBv0hktO5TwLXdKgI 9x1iBWasogBQlydxdEMs+Zll414ArmbvCoiKvNwjKCu1RIllWq0RkhQCSzqmBCsbJI8UQZU4 uKLYQ7Up5qD0nrUoHUOM4CKgFSu6jx4KRscWzjouxBu6GRwCIg6KL9DKB07BfAEFxGjoUavZ rladQXusGIErd9HY9PuDgfGsaoqxrv9W6sofaVBpudl1mPsz2/IpFiPUt/Z6zhBQ39rftfwC MQMOUy7VIfQiXGe0dnCrDiusVCMNZaiU2+AFAZ9QaNWojiTqfgTu+myVcjIWUUekZe1UHwNt hXTNVmjY1RAtFVsbxCDF6iNOLmpY5+aprxVPT7WWnLb+QW94MNi9z9lbNbTm7+3tQDw3AHMN T8WT7UYDxcBB+seYL8CjwFS5Up7QRRiB3io8+qPcngx4NFk10hVYt6J0RdZsiSxBcOpk61LK BYDD0FTFazwaYxi3EsN0QbDb+D8a1Wj0kT2YZSCUhankppFBxTibOjLapClQCTLwABMhsZgs w4hWZMsv6sJA+kkg3cy7kjQrub+uDp9Ee0wrIzJzrG2U4YuTV/B96phoCKbnMwnEGvipAPJV MEAQyUkphlNCFkEA8mPgQBklC9lk5chxYSkJRU7L9tAZbIPXst3DJ3ktALVhUnIxJokodYNV PZ09R2ximHgAfvO2zt9gdzA6DW1PADnMBT1S67PbuTP+Iz4c+wmEUHE+RpiiuXAwkAKdxq3k DpCFwRQX6bg+N93SX1TWd+GZenEGEbMLIXOCm4pI9/e+C2sbPZRyBqzpDkj6l2PT2lx85woi GV/kM0R79wdizVABFS9Pwu9HEtwYPw0pAiQCD74D1c8G5dXWurwQa2azhupirT6wLoIKywiW C144ycDekBx3MGbsHD545WEGai/UK/+R8mCB/iqxYId3sIsLgueWFWwJzvc+jh4fQGcKa2rL Eh3Rh4XBW8YrapE+cBvrFlJZBqGJgLIae1WQ1agOB2Ro+r2tPWefqY+0N5RfiyNbGTcMiOl6 FUwViq61E+BO/C7JPHik3TdfKxAnAKKi/T3jcKCWb6xnSFnyNkaqb6kVU6ufQBf55gwCG4ku Lu0Z0vGbkcPBD0MNez4UsZUb9pBd8cLIhf0Ywnawc7sLdoVirx08QVLStQI0kg3oYXEZeQLw rMseTuTiCYtMcfNBoz8iuXMVAwAxT6baRbHIhoTVpIOv1x7YYPAL0Kaj986bh9F4JK/wm7b/ 6qyu4juo7swfbF5Vct19Zs5fMSRpmGIs/A4rgocu9GB+4XGmeWTYGPPoJSY2fWxTj9g0DfOt BHZLfznW0iyqkeTeKwFSZwKl6pFKChQ3g6ZF6BPwWy5xiFI24Kt5yyhHXaM+UbOS+8FgCI4l sMW+fR7ExS5eDBR3KXngwvZce6bqhewrbZkkPgxzTAur7SlOxxUKbfYivQg9qpuuMNlNFDMY yn4nptUDcBvFRGJRsfiYTIoDauCbrob2pAiYH2neDOOxTnL82fsALUAIIm9zsUa6rBEt4lv0 xVpFJU0N4leDEsqQ8j9CV2IsYnIHX76QvDXLrSxpJGSlD7z1jlgoKVOCPUCHERX3YNB3+nsq 4aRnlBwPST83+KgQX1Vdj9mftns6wn4HXMBPKUFCFWOX7lyQGhnnYkEvf/Y/YNDqWutWRkBo FBqrB3V+FGpag8E08pP0RfMU9+cUfy266acyGNBijIMDVFWeg8s62gSOrE10JqOjke596Kbz sUxQ9oxMrx030hS4tUusvhnHTuOrMCyXat2BpEJRGFXwnKSdiiLCLEMVDq9hfOVFwP10DUKg nldlbqaiDdREArEPBOYYPLpKFWB/zrhoAwBqxVRQgEp5f/6cKvlBK3JBCcyzlF0N4ImpfftW SDphoniTXCWENc7Qp6uIbUA3GZp9pxnIyfIC7x04m/XIsNk6AJXGKE2xIMOBWZFSBT7hXB0o Y/4sk5jUy5P0r3iztSarzQcE69La6uvK84hZPfm0NXzYecQ9me0h+IadoXIgNnS6thotkx+i YmWd6+eiNZD3NsunzmKvCbWbU2fWEuuCefzqoJg+PO4vQnaK+dmoInO/fXN+/OZcreJC5sb1 D+NpIprwC2wXr2Eae3MwtMSEDz4sKCbmszxkhDHayzFxQ2mCKrHWcAZv29qjKv25whu6eQVz 3JuZNGPPl5LHbmHFxGB40B9adQ9bzj4WIWw5Az6ELIrsfTxYwCJ7oABQnSrKpsvYp8Bq7l2C 4UMxVZUBUzCxLLKvAR1Q9Ekqs1Xpd7yYRp6ilYEHg9yVXYfrR3O8f5VmeaurytjgP8ySzsMY iw8AP3ZB6cwrCi/pUIlHxXx+NU8ADIoxppOL00/wJP2Z2PSX6SYjBKDzTEZTOgxjLfUj0UJ4 34UWq70s9/LQNyxJRT6GnqKp22G8w6Lx3yAamDtVh1ymMILyNcvUnLCaSgk6+sfyWwdTP6Zw jCpvhcl6jhC7jP8CJHwYV9x4KRw/2Ol5IJNyI4kA0Q3dDAP12syWsG4wABSiUYABQyDwSEH7 Zi3H2J+Sh4rwkLoAB2g3keLjEqg6kVMs/iM7tkxTi8Igl4mBlEkv5YLviedfXntpoBOG1jk5 7TIYQtxHim+yBOwA6gBj0QzAN0kuD3BKNPBF4obJzIf2Hwoz6FqZV5VI/SieYiQnPmJSyC25 e6HeLoIz0qNV1fhHdinE/5iMzRXSlVtLjpsKoDqdWi6qCPvuTVWyf85AH2lnl1mAfdy7E506 WtOXECpZSQqDtKPlWl5PfRmuG4pnpZD1/x3u9LgVVok/V2ubGr1qIqXApdWq3tcohLB0SYO8 PXeVatD+ZFkxmAIjLBviI3S0V7A24jf9uXTIXWgFAEHpp97IyhNamkR7pUhoxr658vsjWwGZ AODLF/DprDqYs7en56fHrVbLVizVpCqVTnEutSI2GPvDImF3SCiXaUkaMEGNQm2rCnNcWIS1 GB16PhWKh3QeQvvmISu0i2sjagnUiocZmk7haCU7F3QzzivyssLWbrU4FmhDu4JU4jsdRben qwZDQGsPNx1W7JXuo4VixZ456wCYuKugreIeNaBKAxYLzT58TaVkOIwNJXfcvp5jgipV7VHW 17rkg0+WlGZGtyRZRGDOo6JyDEOLKVa6c/076BNzR4dw1yD5WMTAomJPdSkolcES3RgcU9Sm sWHRzXjGRMGDl+JKjNnAIxQV1/wb+fcxXizPMD8G68Kr6KY2f5HJZZCM2YfDRJ92vAwoMpq5 7ZNlSkNkME3soghblsdwArHoB71LiIVwRZ83izZHqRmkBzRiYQDuzRntDaJ2kXoL8Fgy8nvB 6UN/hWrqPQ7WxLPB9rYjTriR6gLJMOUJJv5UjCUz31uAZZX/WbJXmOPN9Izph158OudygFxd TB/LOA3x4FNVUjdbeLjUVj7sNiXi+jvbzq4+EQMbZ0777lCZZUIXShO33NKaeKXhplCbDp5V GeGB1WGQhM8XsBctvNxi9qJPd9D4AponMKUi4wBPSJvA2lHQsio6/z15TG6oQpF0bza2h2h8 vAK1ib4/hcUU2tPESlEIDlFFKPdcTcFerjKlHpbupRRBk83BQ0rTVrrqStfSJuauqz3VRGak QLMQa0dJYtXlOoUAyBSK1MTDRPFygVqWpblLs4aEX8oHzuYKHZ9yZ5QxF0kslZOMxwWk+Fhi c4mbNFnmBOkuHzCkWCXo2vRdbTVtD7qgMlkRUTKVSONDwXzCNrZNd73wnbbW4fsV9L7m9oS+ 22ZgEoDqdUcrSx1fWT58cYkWy3i58INOEGuKvqONct0eP9gUFzfn7LqX9dd2V5bHmUoP6yqv se7sJVX72ddD11/5rF3TM5coR/bJHX5jJwTIwgXGQRI/zhXj6sua1SzRIzrHn0LMqzQFja4M ZlUitCrRQysiTFuM7IQgKhCU8icMLIEFKCucBpVZKBwG7HePr1Aaw35CR2cpVnBNo/AMak5B fUjlvvFndQeVUyRUxka6gpcKntYU+cScDd5WrzyW7FDnlo+nleZCqWsZQaZodRlHYXxZlCoX Dm+yqMixutmkfbEFhE528R9Fc6bEBf5RKoRbTF7IuPbMbWUdQtpAmQzysqvZCjOvMVHUoq5j FYGDaTVUNS08Xo/E9+I6t67E+/x1kKyyQaXdbKyK67w22av2s6w+V5jGzyV9h4lXJfJ00aH0 kVDgeOUhCtaybDjI1li8pWYGdoVUS+ne7votxeUg99SzRcrLxY12XVOzjKIt8f9FZ4WzGuaP M2OjTOWjdtOUf0wsDj41cV19r62uuDpACujV4hhkPW+VYuvGqk3Gf1VZ+plkCFc/0jkGxT+K PuN61bnqYOtMSlnzZau+M+iLzgAvCQytKguuCrQnRjWjNptYwHCSmcYieDgtJxfkY/Qr6P/L CI3UDO/pEr+6BDLFvCgMuNFkQQ9dciJiogfyzxDcdPZnEAWhghAw4UuquMMoo1tAMRupOVVT WbGq+qqYVXeiqpDvmN/OtJA9XT27QQovuAutq0XDiBJ3p1fNF1zzUrRau9oyVW93c/wahm8Y FrYm1Ccu5VZbClSzEoUaEFbpVSBVoSgtsZLjLwi2oi8axpqMFCMcM0CVg1gosE/MJpFrBe9h efVm870qABrs0aWJwfZeqVLJLu23AzqQ4aJ+Wes/bOPEYcUpJs1N5rtp6WNOYG9BnDXYEp3/ q+TaVtsGguivCAoNiS1wY7m5lFBCMLTQvkhuXvJQXEeq9RKZSKYO/fnOmctqVrFL/BbHl50d zc6Z29lpNtG2UrxIlGgdC85SjxqAc+rB+T/ezc3l93jXn8XDyGnJrxUd/x73S6Fetg855bc5 kfY6wRl2kWHrtcKYF9XvDEmZnw8gldp+SGM7hUfcmCE4x72/8ws42NH0ctYPmXsD8Jmxtffu fuRRRRSCi8Tomokg++GeM9anujPpBkJ7RbmMJ3otvESBkzYZVCL5PYLlchdG9uPMiUT/ZDzC egyeCkTgfxk5peySQsoREmuXq4b0//xC/qpbN+xs2+1m00gPnD/P21hudzfaHEql7JBlGRN4 p1eX4RjoiiReYQsX/evb7U5kSWVCX1gPuAVPokV224pQYYhmDCtEmrXq9Y7WU1Up0HBL3Ods i/zr3WLxJSfVFNYKGKiVZ5HsmqaYXXEWrioJTdBTnU0imX9DH0Fn2CuQVXRHCCTV05NOiz8i LkOWdPRL7rcLBdLgmim27aZc1RWuj6g7Y0iykj8qddaG6Y8g4WnwB3u+iSxaGY+iOnp7CGgK iSGu+A64HaR3aCCZEeHIS6VRI522kSofggsoRLZCdgIuVTabeMbHawjAMf6cOCBIrpVsI46B JB4n5ghCHMT7kPXDeKAAQRoqrKpxi2r5XpCKG2v9aJfuCbckUXAhlOBogOugqWEOiqUYRIXB cXojfOgP82iEeqSdXR1jeYNVGyQ4fzZMR5zW/OJj50q8Kg+QnWhn/tvCyeJPHNCUJrN7pIke nJ6pp+ZPMBcKClGW5u3gdpEtHggdunVJDl57E+xhfr1wapyeGXWa9MWu5n2Cos3Pb7fFQuB6 dn6FecHsIgtuSr+DoY/lM48t8HadtnoK1yj+3Xx+P8+LORlo7DbS5AOZ6eRUyDpkcu9wj06F x4qNwiPLvMeyrR9DShB8DBM72jUWeqzDn6R1VR5Dyj8lUh+lE1cAAA== --k+w/mQv8wyuph6w0-- From michael@tis.com Tue Feb 3 13:59:47 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA05829 for ; Tue, 3 Feb 1998 13:59:44 -0800 (PST) Received: by relay.la.tis.com; id OAA23499; Tue, 3 Feb 1998 14:10:50 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma023468; Tue, 3 Feb 98 14:10:37 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id NAA22094; Tue, 3 Feb 1998 13:56:46 -0800 (PST) Message-ID: <19980203135646.22111@la.tis.com> Date: Tue, 3 Feb 1998 13:56:46 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.89.1, 0.89.1i] My feature patches Mail-Followup-To: Mutt Development List References: <19980201201808.34760@cs.swarthmore.edu> <19980202163458.39122@la.tis.com> <19980202230802.61262@cs.swarthmore.edu> <19980203155640.03576@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203155640.03576@cs.swarthmore.edu>; from Daniel Eisenbud on Tue, Feb 03, 1998 at 03:56:40PM -0500 On Tue, Feb 03, 1998 at 03:56:40PM -0500, Daniel Eisenbud wrote: > I used gdb with a breakpoint on menu_status_line(), and it is only > called when switching pages or otherwise redrawing the whole index, and > when (as before) changing flags, etc. Given that, could this perhaps go > in 0.90.1? Ok, I must have just looked at it wrong then. If it is indeed the case that it only gets redrawn on refresh or page change then I have no objection and I will put it into the next release. me From michael@tis.com Tue Feb 3 14:19:16 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA12918 for ; Tue, 3 Feb 1998 14:19:14 -0800 (PST) Received: by relay.la.tis.com; id OAA24219; Tue, 3 Feb 1998 14:30:19 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma024174; Tue, 3 Feb 98 14:29:51 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id OAA22295; Tue, 3 Feb 1998 14:16:00 -0800 (PST) Message-ID: <19980203141600.01167@la.tis.com> Date: Tue, 3 Feb 1998 14:16:00 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90] feature: sort #2 Mail-Followup-To: Mutt Development List References: <19980202201240.42545@la.tis.com> <19980203001839.17866@xenomorph.dyn.ml.org> <19980203013059.58693@xenomorph.dyn.ml.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=uDoXvLw7AC5HRsxe X-Mailer: Mutt 0.90i In-Reply-To: <19980203013059.58693@xenomorph.dyn.ml.org>; from Bill Nottingham on Tue, Feb 03, 1998 at 01:30:59AM -0600 --uDoXvLw7AC5HRsxe Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 01:30:59AM -0600, Bill Nottingham wrote: > Upon investigation, the problem seems to be calling AuxSort when > it hasn't actually be defined yet... the attached patch fixes this. While this fixes the problem, its not the most efficient since when there is a conflict while threading the $sort_aux function will get called twice. I don't think its worth adding a third sorting method for this, so this patch just makes it use whatever is hardcoded in the insertion sort routine. me > Only in mutt-0.90-1: mutt.h.rej > diff -ubr mutt-0.90-1/sort.c mutt-0.90/sort.c > --- mutt-0.90-1/sort.c Tue Feb 3 01:30:31 1998 > +++ mutt-0.90/sort.c Tue Feb 3 01:28:59 1998 > @@ -179,10 +179,11 @@ > if (init) > mutt_clear_threads (ctx); > > + AuxSort = mutt_get_sort_func(SortAux); > if ((Sort & SORT_MASK) == SORT_THREADS) > mutt_sort_threads (ctx, init); > else if ((sortfunc = mutt_get_sort_func (Sort)) == NULL || > - (AuxSort = mutt_get_sort_func (SortAux)) == NULL) > + (AuxSort == NULL)) > { > mutt_error ("Could not find sorting function! [report this bug]"); > sleep (1); --uDoXvLw7AC5HRsxe Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.sort.1-2 --- sort.c.orig Tue Feb 3 14:14:32 1998 +++ sort.c Tue Feb 3 14:14:52 1998 @@ -29,7 +29,7 @@ /* function to use as discriminator when normal sort method is equal */ static sort_t *AuxSort = NULL; -#define AUXSORT(code,a,b) if (!code && !option(OPTAUXSORT)) { \ +#define AUXSORT(code,a,b) if (!code && AuxSort && !option(OPTAUXSORT)) { \ set_option(OPTAUXSORT); \ code = AuxSort(a,b); \ unset_option(OPTAUXSORT); \ @@ -180,7 +180,10 @@ mutt_clear_threads (ctx); if ((Sort & SORT_MASK) == SORT_THREADS) + { + AuxSort = NULL; mutt_sort_threads (ctx, init); + } else if ((sortfunc = mutt_get_sort_func (Sort)) == NULL || (AuxSort = mutt_get_sort_func (SortAux)) == NULL) { --uDoXvLw7AC5HRsxe-- From roessler@sobolev.rhein.de Tue Feb 3 14:34:54 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA19000 for ; Tue, 3 Feb 1998 14:34:46 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id XAA06059 for mutt-dev@cs.hmc.edu; Tue, 3 Feb 1998 23:31:35 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id XAA11877 ; Tue, 3 Feb 1998 23:26:41 +0100 Message-ID: <19980203232641.37697@sobolev.rhein.de> Date: Tue, 3 Feb 1998 23:26:41 +0100 From: Thomas Roessler To: "The mutt developpers' list" Subject: [0.90i] Attaching PGP keys Mail-Followup-To: The mutt developpers' list Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="UHN/qo2QbUvPLonB" X-Mailer: Mutt 0.90i --UHN/qo2QbUvPLonB Content-Type: multipart/mixed; boundary=envbJBWh7q8WU6mo --envbJBWh7q8WU6mo Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable When using the attach-key function on the send menu to add the 6th body part to a message, mutt would dump core. Please try the attached patch. Thanks go to Roland Rosenfeld for noticing this one. tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-0.90i.tlr.pgp_attach_keys.1" --- /var/tmp/mutt-0.90i/compose.c Tue Feb 3 10:43:48 1998 +++ mutt-0.90i/compose.c Tue Feb 3 23:23:52 1998 @@ -426,7 +426,10 @@ case OP_COMPOSE_ATTACH_KEY: =20 if (idxlen =3D=3D idxmax) + { safe_realloc ((void **) &idx, sizeof (ATTACHPTR *) * (idxmax +=3D 5)); + menu->data =3D idx; + } =09 idx[idxlen] =3D (ATTACHPTR *) safe_calloc (1, sizeof (ATTACHPTR)); if ((idx[idxlen]->content =3D pgp_make_key_attachment(NULL)) !=3D NULL) @@ -732,6 +735,7 @@ case OP_FILTER: CHECK_COUNT; mutt_pipe_attachment_list (NULL, menu->tagprefix, menu->tagprefix ? msg->= content : idx[menu->current]->content, op =3D=3D OP_FILTER); + menu->redraw =3D REDRAW_CURRENT; break; =20 case OP_EXIT: --envbJBWh7q8WU6mo-- --UHN/qo2QbUvPLonB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNeZn9ImKUTOasbBAQFp4Qf/ax98fWlSq6QrDxRCj7hfv1oFG+HdR4go Q4y2vS7AO4VJi/kwTH9tIGSf66EUune2oaptIdcSYSCU3PRKCtOZoETGTlb1b6LE K6/yg9Iiqr89NZcSJWhGWvGSobJXGgAjvL2QCGq7lMdIcabovdjw+Ph/ZLREjCBS +KHmdFgEEGy+FdBPH8hp5QkVyD5SYJMTyHwpf/C7DbYPK1j4nRAoDEGrrMVJarWW FukQwnXUmXpFWx1OOphS9gUJVui1l9vKLVxmlQ/fwwz3Ev9kT6UkUgZugH9R7Pds v8Pgu4bVccBFMJkhvc2uhW4s3V4nTck5vHgEg6N2znQG4oxizZIylg== =cvmj -----END PGP SIGNATURE----- --UHN/qo2QbUvPLonB-- From fox@fuzzy.rsn.hp.com Tue Feb 3 15:05:56 1998 Return-Path: fox@fuzzy.rsn.hp.com Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id PAA29689 for ; Tue, 3 Feb 1998 15:05:54 -0800 (PST) Received: from fuzzy.rsn.hp.com (fox@fuzzy.rsn.hp.com [15.99.4.115]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id PAA12154 for ; Tue, 3 Feb 1998 15:05:07 -0800 (PST) Received: (from fox@localhost) by fuzzy.rsn.hp.com (8.7.1/8.7.1) id RAA01587; Tue, 3 Feb 1998 17:05:05 -0600 (CST) Message-ID: <19980203170505.42962@rsn.hp.com> Date: Tue, 3 Feb 1998 17:05:05 -0600 From: David DeSimone To: mutt-dev@cs.hmc.edu Subject: Re: configure problem Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de> <19980203123843.35685@rsn.hp.com> <19980203131144.57166@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=31gzZEtNLTqOjlF2 X-Mailer: Mutt 0.89i In-Reply-To: <19980203131144.57166@shell9.ba.best.com>; from Brandon Long on Tue, Feb 03, 1998 at 01:11:44PM -0800 --31gzZEtNLTqOjlF2 Content-Type: text/plain; charset=us-ascii Brandon Long wrote: > > The problem isn't with snprintf, but with vsnprintf. Mutt only tests > for snprintf with configure, and then uses vsnprintf in curs_lib.c. > HP-UX has snprintf but not vsnprintf. Hmmm, if that's the case, why doesn't the linker fail looking for a symbol "_vsnprintf"? It dies looking for "_snprintf", which should be locateable.... Weird. -- David DeSimone | "The doctrine of human equality reposes on this: fox@rsn.hp.com | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division | PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44 --31gzZEtNLTqOjlF2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNNeiew0lGhIp2tThAQHFXgMAlLtKxAmMJsBD0AZgQxycrUleXR3EKCXQ KltJdZsHqPuUdOrqIk9WH9mDtV3PjuUU0mTQmrTX0jPnLzVkJXDjYimFqS0zIn4g dBNgi9A1yo1MX9CfQTtEzcdCXSqhh8Br =ozC1 -----END PGP SIGNATURE----- --31gzZEtNLTqOjlF2-- From olsenc@ichips.intel.com Tue Feb 3 15:30:24 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id PAA07746 for ; Tue, 3 Feb 1998 15:30:23 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA00775 for ; Tue, 3 Feb 1998 15:34:04 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id PAA22497 for ; Tue, 3 Feb 1998 15:30:21 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id PAA21392; Tue, 3 Feb 1998 15:30:20 -0800 (PST) Message-ID: <19980203153020.03140@dtthp169.jf.intel.com> Date: Tue, 3 Feb 1998 15:30:20 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.90i] thread hash.2 missing objects Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! I have a feeling that version 2 of this diff is missing some code :) /usr/ccs/bin/ld: Unsatisfied symbols: hash_create (code) hash_find_hash (code) hash_delete_hash (code) hash_destroy (code) hash_string (code) hash_insert (code) -Clint From olsenc@ichips.intel.com Tue Feb 3 16:08:40 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA21147 for ; Tue, 3 Feb 1998 16:08:36 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id QAA08880 for ; Tue, 3 Feb 1998 16:11:23 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id QAA26176 for ; Tue, 3 Feb 1998 16:07:40 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id QAA21536; Tue, 3 Feb 1998 16:07:39 -0800 (PST) Message-ID: <19980203160739.05825@dtthp169.jf.intel.com> Date: Tue, 3 Feb 1998 16:07:39 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.90i] file descriptor leaks? Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! I noticed that in mailx mode when you type CTRL-C to abort Mutt, you're left with a (usually empty) mutt-hostname-yadda in /tmp. -Clint From sec@matrix.42.org Tue Feb 3 16:09:44 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA21436 for ; Tue, 3 Feb 1998 16:09:35 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id BAA21246 (sender ); Wed, 4 Feb 1998 01:09:15 +0100 (CET) Message-ID: <19980204010914.19824@matrix.42.org> Date: Wed, 4 Feb 1998 01:09:14 +0100 From: Stefan `Sec` Zehl To: Mutt Development List Subject: [0.90] my patches Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=sdtB3X0nJg68CQEu X-Mailer: Mutt 0.90i I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, the format of init.h changed from .89.1 to .90 so i had to fix a few patches, You'll find them attached, as usual. And, still as usual, you need that patchlist-patch first, or ignore the one rejection per patch. p=08_a=08_t=08_c=08_h=08_-=08_0=08_.=08_0=08_0=08_.=08_s=08_e=08_c=08_.=08_= p=08_a=08_t=08_c=08_h=08_l=08_i=08_s=08_t=08_.=08_1=08_: This simple patch brings back "patchlist.c" you need to apply b=08be=08ef=08fo=08or=08re=08e any other patch you get from here. p=08_a=08_t=08_c=08_h=08_-=08_0=08_.=08_9=08_0=08_.=08_d=08_s=08_.=08_q=08_= u=08_o=08_t=08_e=08__=08_s=08_i=08_g=08_.=08_1=08_: From: Duncan Sargeant I've rewritten this for 0.79 and fixed the odd bug which produced an unexpected EOF. This patch adds a boolean variable, quote_sig, which controls whether to quote signatures when replying to mail. The default is set, preserving current behaviour. Set noquote_sig to reduce the (rather huge) hassle of manually deleting signatures yourself. p=08_a=08_t=08_c=08_h=08_-=08_0=08_.=08_9=08_0=08_.=08_s=08_e=08_c=08_.=08_= c=08_o=08_n=08_d=08_e=08_n=08_s=08_e=08__=08_p=08_g=08_p=08_.=08_1=08_: From: Stefan `Sec` Zehl Here is the new version of condese_pgp. This patch condenses the output of "pgp" in mutt to the relevant parts. (Parts of this patch have been stolen from alt_pgp from Frank Pilhofer) you can view the whole PGP output again by setting "pgp_paranoid". p=08_a=08_t=08_c=08_h=08_-=08_0=08_.=08_9=08_0=08_.=08_s=08_e=08_c=08_.=08_= p=08_a=08_g=08_e=08_r=08__=08_s=08_t=08_a=08_t=08_u=08_s=08__=08_o=08_n=08_= _=08_t=08_o=08_p=08_.=08_1=08_: This patch adds "set pager_status_on_top" which basically allows you to control the status line in the pager independently of the normal "status_on_top". It also adds a new color object pager_status, which allows you to control the color of the pager_status independently. These, and the rest of my patches can still be fetched from my mutt-page. Any comments welcome. CU, Sec --=20 I didn't say we *can't* do it. In fact we can. We also can calculate digits of sqrt(2) in the background, drive space shuttles, or have an AI algorithm write poems in Swahili while inside the pager. -- daia@stoilow.imar.ro --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.ds.quote_sig.1" --- mutt-0.90i/handler.c.orig Tue Feb 3 10:43:52 1998 +++ mutt-0.90i/handler.c Wed Feb 4 00:34:06 1998 @@ -60,16 +60,34 @@ 41,42,43,44, 45,46,47,48, 49,50,51,-1, -1,-1,-1,-1 }; +#define NumSigLines 4 +static short is_on_sig(char *buf, short *siglines, char *sigsep) +{ + if (*siglines != -1) + { + /* we are on a sig, should we get off it? */ + (*siglines)++; + if (*siglines > NumSigLines && *buf == '\n') + *siglines = -1; + } + else if (!option(OPTQUOTESIG) && (strcmp(sigsep, buf) == 0)) + *siglines = 0; + return (*siglines != -1); +} +#undef NumSigLines + void mutt_decode_xbit (STATE *s, long len, int istext) { int linelen; char buffer[LONG_STRING]; + short siglines = -1; if (istext) { while (len > 0) { - if (fgets (buffer, LONG_STRING, s->fpin) == 0) return; + if (fgets (buffer, LONG_STRING, s->fpin) == 0) + return; linelen = strlen (buffer); len -= linelen; if (linelen >= 2 && buffer[linelen-2] == '\r') @@ -77,7 +95,15 @@ buffer[linelen-2] = '\n'; buffer[linelen-1] = 0; } - if (s->prefix) state_puts (s->prefix, s); + if (s->prefix) + { + if (option(OPTQUOTESIG) || !is_on_sig(buffer, &siglines, "-- \n")) + { + state_puts (s->prefix, s); + state_puts (buffer, s); + } + } + else state_puts (buffer, s); } } @@ -89,6 +115,7 @@ { char *c, buffer[LONG_STRING]; int ch, soft = 0; + short siglines = -1; while (len > 0) { @@ -100,7 +127,15 @@ } c = buffer; len -= strlen (buffer); - if (s->prefix && !soft) state_puts (s->prefix, s); + if (s->prefix && !soft) + { + if (option(OPTQUOTESIG) || !is_on_sig(buffer, &siglines, "--=20\n")) + { + state_puts (s->prefix, s); + } + else + continue; + } soft = 0; while (*c) { --- mutt-0.90i/init.c.orig Tue Feb 3 10:43:52 1998 +++ mutt-0.90i/init.c Wed Feb 4 00:34:06 1998 @@ -1284,6 +1284,7 @@ set_option (OPTMARKERS); set_option (OPTMARKOLD); set_option (OPTPROMPTAFTER); + set_option (OPTQUOTESIG); set_option (OPTRESOLVE); set_option (OPTSAVEEMPTY); set_option (OPTSIGDASHES); --- mutt-0.90i/init.h.orig Tue Feb 3 10:51:28 1998 +++ mutt-0.90i/init.h Wed Feb 4 00:35:21 1998 @@ -156,6 +156,7 @@ { "print_cmd", DT_PATH, R_NONE, S_DECL(PrintCmd) }, { "prompt_after", DT_BOOL, R_NONE, I_DECL(OPTPROMPTAFTER) }, { "quote_regexp", DT_RX, R_PAGER, P_DECL(&QuoteRegexp) }, + { "quote_sig", DT_BOOL, R_NONE, I_DECL(OPTQUOTESIG) }, { "reply_regexp", DT_RX, R_INDEX, P_DECL(&ReplyRegexp) }, { "read_inc", DT_NUM, R_NONE, P_DECL(&ReadInc) }, { "read_only", DT_BOOL, R_NONE, I_DECL(OPTREADONLY) }, --- mutt-0.90i/mutt.h.orig Tue Feb 3 10:43:53 1998 +++ mutt-0.90i/mutt.h Wed Feb 4 00:34:06 1998 @@ -187,6 +187,7 @@ OPTSAVEEMPTY, OPTPAGERSTOP, OPTSIGDASHES, + OPTQUOTESIG, OPTASKBCC, OPTAUTOEDIT, #ifdef _PGPPATH --- mutt-0.90i/patchlist.c.orig Wed Feb 4 00:29:05 1998 +++ mutt-0.90i/patchlist.c Wed Feb 4 00:35:42 1998 @@ -16,6 +16,8 @@ + printf("Feature patch: quote_sig 0.90 by Duncan Sargeant\n"); + /* DO NOT MODIFY AFTER THIS LINE */ --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.sec.condense_pgp.1" --- mutt-0.90i/init.h.orig Tue Feb 3 10:51:28 1998 +++ mutt-0.90i/init.h Wed Feb 4 00:42:21 1998 @@ -132,6 +132,7 @@ { "pgp_replysign", DT_BOOL, R_NONE, I_DECL(OPTPGPREPLYSIGN) }, { "pgp_sign_as", DT_STR, R_NONE, S_DECL(PgpSignAs) }, { "pgp_strict_enc", DT_BOOL, R_NONE, I_DECL(OPTPGPSTRICTENC) }, + { "pgp_paranoid", DT_BOOL, R_NONE, I_DECL(OPTPGPPARANOID) }, { "pgp_pubring", DT_PATH, R_NONE, S_DECL(PgpPubring) }, { "pgp_secring", DT_PATH, R_NONE, S_DECL(PgpSecring) }, { "pgp_timeout", DT_NUM, R_NONE, P_DECL(&PgpTimeout) }, --- mutt-0.90i/mutt.h.orig Tue Feb 3 10:43:53 1998 +++ mutt-0.90i/mutt.h Wed Feb 4 00:41:44 1998 @@ -222,6 +222,7 @@ OPTWRAP, OPTCHECKNEW, OPTFASTREPLY, + OPTPGPPARANOID, OPTWAITKEY, OPTIGNORELISTREPLYTO, OPTSAVEADDRESS, --- mutt-0.90i/patchlist.c.orig Wed Feb 4 00:29:05 1998 +++ mutt-0.90i/patchlist.c Wed Feb 4 00:42:36 1998 @@ -16,6 +16,8 @@ + printf ("Feature patch: condense_pgp 0.90 by Stefan `Sec` Zehl\n"); + /* DO NOT MODIFY AFTER THIS LINE */ --- mutt-0.90i/pgp.c.orig Tue Feb 3 10:53:31 1998 +++ mutt-0.90i/pgp.c Wed Feb 4 00:41:44 1998 @@ -138,6 +138,90 @@ } +/* + * Scan PGP output; return information about state of signature. + * Flush the message (on stdout). + * + * If strat==0, the message is piped to PGP on stdin, the verified + * message is output on stdout, and runtime messages are on stderr. + * If strat==1, the message comes from a file, and the runtime + * messages are on stdout. + */ + +int +mutt_scan_pgp_output (FILE *infile, FILE *outfile, STATE *outstate) +{ + int sigstate=0, pgpwarning=0; + int nl=0; + char buffer[LONG_STRING]; + + while (fgets (buffer, sizeof(buffer), infile) != NULL) { + if (strncmp (buffer, "Good signature", 14) == 0) + if (sigstate!=3) + sigstate=1; + if (strncmp (buffer, "WARNING", 7) == 0 && + strstr (buffer, "not certified") != NULL) + if (sigstate!=3) + sigstate=2; + if (strncmp (buffer, "Bad signature", 13) == 0) + sigstate=3; + if (strncmp (buffer, "\007Key matching", 13) == 0 && + strstr (buffer, "not found") != NULL) + if (sigstate!=3) + sigstate=4; + if (strncmp (buffer, "WARNING", 7) == 0) + pgpwarning|=1; + if (strncmp (buffer, "\007WARNING", 7) == 0) + pgpwarning|=1; + if (strncmp (buffer, "Error", 5) == 0) + pgpwarning|=2; + if (strncmp (buffer, "\007Error", 5) == 0) + pgpwarning|=2; + + if (strncmp(buffer, "File '", 6) == 0 && + strstr (buffer, "has signature, but with no text") != NULL) + continue; + if (strncmp(buffer, "Text is assumed to be in file '", 31) == 0) + continue; + if (strncmp(buffer, "Warning",7) == 0 && + strstr (buffer, "header label \"MessageID:\" ignored") != NULL) + continue; + + if(buffer[0]=='\n'){ + if(nl)continue; + nl=1; + }else{ + nl=0; + } + if (outstate) { + if (strlen(buffer)>2 && buffer[strlen(buffer)-2]=='\007') + buffer[strlen(buffer)-2]=' '; + else if (strlen(buffer)>3 && buffer[strlen(buffer)-3]=='\007') + buffer[strlen(buffer)-3]=' '; + + if (buffer[0] == '\007') { + state_puts(buffer+1, outstate); + } + else { + state_puts(buffer, outstate); + } + } + if (outfile) { + if (buffer[0] == '\007') { + fputs(buffer+1, outfile); + } + else { + fputs(buffer, outfile); + } + } + } + + sigstate |= (pgpwarning<<4); + + return sigstate; +} + + /* Support for the Application/PGP Content Type. */ void application_pgp_handler (BODY *m, STATE *s) @@ -256,21 +340,24 @@ mutt_unlink(tmpfname); if (s->flags & M_DISPLAY) + if(option(OPTPGPPARANOID)) mutt_copy_stream(pgperr, s->fpout); + else + mutt_scan_pgp_output(pgperr,NULL,s); fclose (pgperr); if (s->flags & M_DISPLAY) - state_puts ("\n[-- End of PGP output --]\n\n", s); + state_puts ("\n[-- End of PGP output --", s); } if(s->flags & M_DISPLAY) { if (needpass) - state_puts ("[-- BEGIN PGP MESSAGE --]\n\n", s); + state_puts (" BEGIN PGP MESSAGE --]\n\n", s); else if (pgp_keyblock) - state_puts ("[-- BEGIN PGP PUBLIC KEY BLOCK --]\n", s); + state_puts (" BEGIN PGP PUBLIC KEY BLOCK --]\n", s); else - state_puts ("[-- BEGIN PGP SIGNED MESSAGE --]\n\n", s); + state_puts (" BEGIN PGP SIGNED MESSAGE --]\n\n", s); } /* Use PGP's output if there was no clearsig signature. */ @@ -535,7 +622,10 @@ if((thepid = pgp_invoke_verify (NULL, &pgpout, NULL, -1, -1, fileno(pgperr), tempfile, sigfile)) != -1) { + if(option(OPTPGPPARANOID)) mutt_copy_stream(pgpout, s->fpout); + else + mutt_scan_pgp_output(pgpout,NULL,s); fclose (pgpout); fflush(pgperr); @@ -546,14 +636,14 @@ mutt_wait_filter (thepid); } - state_puts ("[-- End of PGP output --]\n\n", s); + state_puts ("[-- End of PGP output --", s); mutt_unlink (tempfile); mutt_unlink (sigfile); mutt_unlink (pgperrfile); /* Now display the signed body */ - state_puts ("[-- The following data is PGP/MIME signed --]\n\n", s); + state_puts (" The following data is PGP/MIME signed --]\n\n", s); } mutt_body_handler (a, s); @@ -756,8 +846,12 @@ { fflush (pgperr); rewind (pgperr); + if(option(OPTPGPPARANOID)){ mutt_copy_stream (pgperr, s->fpout); - state_puts ("[-- End of PGP output --]\n\n", s); + }else{ + mutt_scan_pgp_output(pgperr,s->fpout,NULL); + } + state_puts ("[-- End of PGP output --", s); } fclose (pgperr); @@ -823,7 +917,7 @@ if ((tattach = pgp_decrypt_part (a, s, fpout)) != NULL) { if (s->flags & M_DISPLAY) - state_puts ("[-- The following data is PGP/MIME encrypted --]\n\n", s); + state_puts (" The following data is PGP/MIME encrypted --]\n\n", s); fpin = s->fpin; s->fpin = fpout; --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.sec.pager_status_on_top.1" --- mutt-0.90i/color.c.orig Tue Feb 3 10:43:48 1998 +++ mutt-0.90i/color.c Wed Feb 4 00:39:44 1998 @@ -75,6 +75,7 @@ { "signature", MT_COLOR_SIGNATURE }, { "indicator", MT_COLOR_INDICATOR }, { "status", MT_COLOR_STATUS }, + { "pager_status", MT_COLOR_PSTATUS }, { "tree", MT_COLOR_TREE }, { "error", MT_COLOR_ERROR }, { "normal", MT_COLOR_NORMAL }, @@ -102,6 +103,7 @@ /* set some defaults */ ColorDefs[MT_COLOR_STATUS] = A_REVERSE; + ColorDefs[MT_COLOR_PSTATUS] = A_REVERSE; ColorDefs[MT_COLOR_INDICATOR] = A_REVERSE; ColorDefs[MT_COLOR_SEARCH] = A_REVERSE; /* special meaning: toggle the relevant attribute */ --- mutt-0.90i/init.h.orig Tue Feb 3 10:51:28 1998 +++ mutt-0.90i/init.h Wed Feb 4 00:40:21 1998 @@ -120,6 +120,7 @@ { "pager_context", DT_NUM, R_NONE, P_DECL(&PagerContext) }, { "pager_format", DT_STR, R_PAGER, S_DECL(PagerFmt) }, { "pager_index_lines",DT_NUM, R_PAGER, P_DECL(&PagerIndexLines) }, + { "pager_status_on_top", DT_BOOL, R_PAGER, I_DECL(OPTPSTATUSONTOP) }, { "pager_stop", DT_BOOL, R_NONE, I_DECL(OPTPAGERSTOP) }, #ifdef _PGPPATH --- mutt-0.90i/mutt.h.orig Tue Feb 3 10:43:53 1998 +++ mutt-0.90i/mutt.h Wed Feb 4 00:39:44 1998 @@ -174,6 +174,7 @@ { OPTPROMPTAFTER, OPTSTATUSONTOP, + OPTPSTATUSONTOP, OPTALLOW8BIT, OPTASCIICHARS, OPTMETOO, --- mutt-0.90i/mutt_curses.h.orig Fri Jan 23 08:08:56 1998 +++ mutt-0.90i/mutt_curses.h Wed Feb 4 00:39:44 1998 @@ -95,6 +95,7 @@ MT_COLOR_SIGNATURE, MT_COLOR_INDICATOR, MT_COLOR_STATUS, + MT_COLOR_PSTATUS, MT_COLOR_TREE, MT_COLOR_NORMAL, MT_COLOR_ERROR, --- mutt-0.90i/pager.c.orig Fri Jan 23 08:08:56 1998 +++ mutt-0.90i/pager.c Wed Feb 4 00:39:44 1998 @@ -1342,7 +1342,7 @@ indicator = indexlen / 3; - if (option (OPTSTATUSONTOP)) + if (option (OPTPSTATUSONTOP)) { indexoffset = 0; statusoffset = hdr ? indexlen : 0; @@ -1365,7 +1365,7 @@ if (option (OPTHELP)) { - SETCOLOR (MT_COLOR_STATUS); + SETCOLOR (MT_COLOR_PSTATUS); mvprintw (helpoffset, 0, "%-*.*s", COLS, COLS, helpstr); SETCOLOR (MT_COLOR_NORMAL); } @@ -1384,7 +1384,7 @@ } SETCOLOR (MT_COLOR_NORMAL); - index->offset = indexoffset + (option (OPTSTATUSONTOP) ? 1 : 0); + index->offset = indexoffset + (option (OPTPSTATUSONTOP) ? 1 : 0); index->pagelen = indexlen - 1; @@ -1449,8 +1449,8 @@ menu_redraw_current (index); /* print out the pager status bar */ - SETCOLOR (MT_COLOR_STATUS); - BKGDSET (MT_COLOR_STATUS); + SETCOLOR (MT_COLOR_PSTATUS); + BKGDSET (MT_COLOR_PSTATUS); CLEARLINE (statusoffset); if (hdr) { @@ -1468,7 +1468,7 @@ if (hdr && PagerIndexLines) { mutt_status_line (buffer, sizeof(buffer), Status); - CLEARLINE (indexoffset + (option(OPTSTATUSONTOP) ? 0 : (indexlen - 1))); + CLEARLINE (indexoffset + (option(OPTPSTATUSONTOP) ? 0 : (indexlen - 1))); printw ("%-*.*s", COLS, COLS, buffer); } BKGDSET (MT_COLOR_NORMAL); --- mutt-0.90i/patchlist.c.orig Wed Feb 4 00:29:05 1998 +++ mutt-0.90i/patchlist.c Wed Feb 4 00:40:35 1998 @@ -16,6 +16,8 @@ + printf("Feature patch: pager_status_on_top 0.90 by Stefan `Sec` Zehl\n"); + /* DO NOT MODIFY AFTER THIS LINE */ --sdtB3X0nJg68CQEu-- From michael@tis.com Tue Feb 3 17:08:55 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA12924 for ; Tue, 3 Feb 1998 17:08:52 -0800 (PST) Received: by relay.la.tis.com; id RAA00121; Tue, 3 Feb 1998 17:19:49 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma000119; Tue, 3 Feb 98 17:19:28 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA25486; Tue, 3 Feb 1998 17:05:36 -0800 (PST) Message-ID: <19980203170536.22504@la.tis.com> Date: Tue, 3 Feb 1998 17:05:36 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] feature: pattern Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Dxnq1zWXvFF0Q93v X-Mailer: Mutt 0.90i --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii This extends the pattern matching code to be able to select by relative date. With it you may select messages older, newer or exactly some offset from the current date. ~d OFFSET select messages older than OFFSET ~d =OFFSET select messages exactly OFFSET old where OFFSET is of the form: Ny N years Nm N months Nw N weeks Nd N days Note that the matching occurs in YOUR timezone, not in the sender's. me --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90i.me.pattern.1 diff -ur mutt-0.90i/date.c mutt-0.90i.pattern/date.c --- mutt-0.90i/date.c Thu Jan 22 23:08:55 1998 +++ mutt-0.90i.pattern/date.c Tue Feb 3 16:05:32 1998 @@ -55,3 +55,32 @@ return (g); } + +void mutt_normalize_time (struct tm *tm) +{ + while (tm->tm_sec < 0) + { + tm->tm_sec += 60; + tm->tm_min--; + } + while (tm->tm_min < 0) + { + tm->tm_min += 60; + tm->tm_hour--; + } + while (tm->tm_hour < 0) + { + tm->tm_hour += 24; + tm->tm_mday--; + } + while (tm->tm_mday < 0) + { + tm->tm_mday += DaysPerMonth[ (tm->tm_mon - 1) % 12]; + tm->tm_mon--; + } + while (tm->tm_mon < 0) + { + tm->tm_mon += 12; + tm->tm_year--; + } +} diff -ur mutt-0.90i/pattern.c mutt-0.90i.pattern/pattern.c --- mutt-0.90i/pattern.c Tue Feb 3 01:43:53 1998 +++ mutt-0.90i.pattern/pattern.c Tue Feb 3 16:59:22 1998 @@ -29,14 +29,15 @@ #include #include + + + #ifdef _PGPPATH #include "pgp.h" #endif - - static const char *eat_regexp (pattern_t *pat, const char *s, char *, size_t); static const char *eat_date (pattern_t *pat, const char *s, char *, size_t); static const char *eat_range (pattern_t *pat, const char *s, char *, size_t); @@ -73,7 +74,6 @@ { 0 } }; - static pattern_t *SearchPattern = NULL; /* current search pattern */ static char LastSearch[STRING] = { 0 }; /* last pattern searched for */ @@ -312,6 +312,34 @@ return (tz); } +/* Ny years + Nm months + Nw weeks + Nd days */ +static const char *get_offset (struct tm *tm, const char *s) +{ + char *ps; + int offset = strtol (s, &ps, 0); + + switch (*ps) + { + case 'y': + tm->tm_year -= offset; + break; + case 'm': + tm->tm_mon -= offset; + break; + case 'w': + tm->tm_mday -= 7 * offset; + break; + case 'd': + tm->tm_mday -= offset; + break; + } + mutt_normalize_time (tm); + return (ps + 1); +} + static const char * eat_date (pattern_t *pat, const char *s, char *err, size_t errlen) { @@ -333,27 +361,65 @@ max.tm_min = 59; max.tm_sec = 59; - if (*s != '-') + if (strchr ("<>=", *s)) { - /* mininum date specified */ - if ((s = getDate (s, &min, err, errlen)) == NULL) - return NULL; - } + /* offset from current time + <3d less than three days ago + >3d more than three days ago + =3d exactly three days ago */ + time_t now = time (NULL); + struct tm *tm = localtime (&now); + int exact = 0; - if (*s && *s == '-') - { - /* max date */ - s++; /* skip the `-' */ - if (*s) - if ((s = getDate (s, &max, err, errlen)) == NULL) - return NULL; + if (*s == '<') + { + memcpy (&min, tm, sizeof (max)); + tm = &min; + } + else + { + memcpy (&max, tm, sizeof (min)); + tm = &max; + + if (*s == '=') + exact++; + } + tm->tm_hour = 23; + tm->tm_min = max.tm_sec = 59; + + s = get_offset (tm, s + 1); + + if (exact) + { + /* start at the beginning of the day in question */ + memcpy (&min, &max, sizeof (max)); + min.tm_hour = min.tm_sec = min.tm_min = 0; + } } else { - /* search for messages on a specific day */ - max.tm_year = min.tm_year; - max.tm_mon = min.tm_mon; - max.tm_mday = min.tm_mday; + if (*s != '-') + { + /* mininum date specified */ + if ((s = getDate (s, &min, err, errlen)) == NULL) + return NULL; + } + + if (*s && *s == '-') + { + /* max date */ + s++; /* skip the `-' */ + if (*s) + if ((s = getDate (s, &max, err, errlen)) == NULL) + return NULL; + } + else + { + /* search for messages on a specific day */ + max.tm_year = min.tm_year; + max.tm_mon = min.tm_mon; + max.tm_mday = min.tm_mday; + } } tz = mutt_local_tz (); diff -ur mutt-0.90i/protos.h mutt-0.90i.pattern/protos.h --- mutt-0.90i/protos.h Tue Feb 3 01:43:53 1998 +++ mutt-0.90i.pattern/protos.h Tue Feb 3 15:31:48 1998 @@ -100,6 +100,7 @@ void mutt_message (const char *, ...); void mutt_message_to_7bit (BODY *, FILE *); void mutt_mktemp (char *); +void mutt_normalize_time (struct tm *); void mutt_parse_adrlist (ADDRESS **, const char *, const char *); void mutt_parse_mime_message (HEADER *); void mutt_pipe_message_to_state (HEADER *, STATE *); --Dxnq1zWXvFF0Q93v-- From eisenbud@allspice.cs.swarthmore.edu Tue Feb 3 17:17:30 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA15834 for ; Tue, 3 Feb 1998 17:17:27 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA13268; Tue, 3 Feb 1998 20:17:14 -0500 (EST) Message-ID: <19980203201714.41169@cs.swarthmore.edu> Date: Tue, 3 Feb 1998 20:17:14 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.90i] feature: thread_hash (EXPERIMENTAL) Mail-Followup-To: Mutt Development List References: <19980202191413.13067@la.tis.com> <19980203030844.41770@xenomorph.dyn.ml.org> <19980203135222.26634@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203135222.26634@la.tis.com>; from Michael Elkins on Tue, Feb 03, 1998 at 01:52:22PM -0800 On Tue, Feb 03, 1998 at 01:52:22PM -0800, Michael Elkins wrote: > On Tue, Feb 03, 1998 at 03:08:44AM -0600, Bill Nottingham wrote: > > More segfaults here. I must just be lucky. > > > > These segfaults all occur at some point after opening one particular > > maildir mailbox, which is attached. FWIW, this mailbox is *NOT* sorted > > correctly when first opened, and you can't even see all its messages. > > Thank you! This really helped me figure out what was going on, and I have > fixed the problem. This turned out to be a problem with the pseudo > threading code. If you have some real threads, such as > > A -> B -> C > > they will all be in the same bin in the hash table since they all have the > same subjects (at least for the example case that caused problems). The new > pseudo threading code will look through all the messages in the bin (because > they have the same subject) to find the best match. However, this means > that message `B' or `C' could be returned as a pseudo thread match for `A', > so I had to add an extra check to not match messages in the same thread. > > I'm not really sure why the old code doesn't have this same problem, because > it used to store all the messages with different subjects in a lookup table. > Consider the case where you have > > A foo > \ > B bar > \ > C foo > > In this case `C' could be a match for `A'. Perhaps we have just never seen > this because it isn't likely that anyone would change the subject back to > the original topic. Hmm, I can at least say that this is even more unlikely than you state, because C's date would have to be earlier than A's for this to happen. And with sort_re on, A would have to be something like Re: foo. But this might well have been a potential bug in the code. > One thing that I am not sure about is whether or not to keep the previous > behavior of only matching messages in which the subject has changed. In the > first case where all messages have the same subject, should psuedo threads > be attached to children of the thread? Or only to the top parent of the > thread? As it currently stands with this patch, you can get things that > look like > > A > +->B > | +*>D > +->C > > Since `B' might be the closest in time to `D'. But in the current code it > would get threaded as > > A > +->B > +*>D > +->C > > Which is more correct? Daniel? I think the latter of these two examples (mutt's behavior without your thread-hash patch) is better, just because we reall have no idea where the message should be attached, and I think it would be significantly more confusing to have subject-threaded messages (and possibly whole reference-threads that descend from them) attached somewhere wrong in the tree than to just have the convention of attaching them to the root of the tree. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From michael@tis.com Tue Feb 3 17:20:49 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA17059 for ; Tue, 3 Feb 1998 17:20:43 -0800 (PST) Received: by relay.la.tis.com; id RAA00289; Tue, 3 Feb 1998 17:31:49 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma000287; Tue, 3 Feb 98 17:31:45 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA25555; Tue, 3 Feb 1998 17:17:52 -0800 (PST) Message-ID: <19980203171752.46716@la.tis.com> Date: Tue, 3 Feb 1998 17:17:52 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] feature: thread_hash #2 (EXPERIMENTAL) Mail-Followup-To: Mutt Development List References: <19980202191413.13067@la.tis.com> <19980203030844.41770@xenomorph.dyn.ml.org> <19980203135222.26634@la.tis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=LQksG6bCIzRHxTLp X-Mailer: Mutt 0.90i In-Reply-To: <19980203135222.26634@la.tis.com>; from Michael Elkins on Tue, Feb 03, 1998 at 01:52:22PM -0800 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Grr, forgot the -N diff option so not all the sources were included in the full #2 patch (the 1->2 patch is still good). Throw away that previous patch and use this one instead... me --LQksG6bCIzRHxTLp Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-0.90.me.thread_hash.2.gz H4sICALB1zQAA3BhdGNoLTAuOTAubWUudGhyZWFkX2hhc2guMgDsPGl32ziSn+VfgbjfdHSQ iiTLp+K8dqedieflerazvf26sxqKhCzGFKkhKTvexP996wBAkJRs5/iwHzqvx6RAoFAo1Ikq TBBOp8J9s0zFfJnnbq+733vy2ruU0zCS3TAuWrv5LJVeMJ552czuseG67uqxjddJLF7IiRAD 0e8dDHcOBvCyv7+30el07gdcGr5/0BscDNXwX34R7ta+sys69PeXXzbE21//dXbY8IIgnSTJ ZTcRXhR6GT7z3PNn8DIJ4wAfaXKdyRTfltPpDTz9JErw918bQv/zk/nci4OMvs4Xkcylek0y flvQyGWajaNwol/nXhjDe+BRd4DXkEGYw6uMc5pyGnkXCDSMqRkWqtrTZA6PC5kHiQLy14bb mAEOEXWYBWkUxgh1BqSSaUZv0QIfvN5LeTP38DfjY6B0bChA4e8CJhrzSfIJW2S8xAeCm2PD wrugKRZeShRaAN1lqkcB2fJFQlMu0jDGtafSvzJ7k079vcFAdYYf/e3BkJsHveEuvGWSNg8f jFIWXsRehC9JmtPAX8PYS2+QpjKz+NFPUimAAmv4jT4HIAMy3QhWiAKRzF8zmD9WBIAbG7/L QPwmfbHVF/2dg14P/gPm3dm/g/fVyDvZvuf0RKfv9HtbyPadJ+2NjmiL58CPaXgxy0XzeQs7 77h74nXozzwZidOuOI4uwzgTT+fyFz/rzuZ+VwbLZziUhuO/81mYweYkF6k3F/A6TaUE4k7z ay+VI3GTLIXvxbBtQZjlaThZ5lKEOVL2SQIES4B4NwYYfFjGwFkin0kBfDDPRDKlH/988178 U8Yy9SLxbjmJQl+8Cn0ZZ7BJMD+2ZDMg3aQAhsNeIDZnChvxIgHoXh4m8UjIEL6n4grYGH4D zdRECqojktRAano5LiQVyQIHtwD7GxGBtJrxXeq7lijF2gOQYZpnlixgiTOADIu+DqNITKRY ZnK6jBwDB0aI30/OX759fy6O3vwhfj86PT16c/7HCEbkswS+yivJ8EJQNyGAh4WmXpzfwHoM mNfHp89fwrijX09enZz/AUsTL07O3xyfnYkXb0/FkXh3dHp+8vz9q6NT8e796bu3Z8ddIc4k IigNlDu2YEpbiRIhcy+Msgo5/gAmyADdKABVciVRhmV4Bch6pBHv32MDyYuS+IIWDyMKGo9E OBVxkjviOg2BwfKkvvsGRsEFjjiJ/a4jdna3xWsvy8TRFWz8c28+ScPgAl5fH4neoA/GQrw/ O6JFPYFVbXR+CmM/WgZSPM1yUiyzZ5XGMKE2q3WTxHS2iY2gykipjpEtYEHNZYyKCSgCopeK duYI7BK3NjqfYVb6MROHojfCX9cz0FWi2c5a+EvAl84hjOl06Gsq82Uai+ZM/AMAQNMtzvjy 6OylaNOcPmgOoFGTZpCRnOtZuE/uTQD6ISjvKEp80czC/5WwQU382mrRFNTFfUaDoSc97Q8a hK9AUAdHaEiw6KWvCEAg2gquQp2Ga8QNqUARyTRnPBSWjiIXmB1HXCVhINqwsZ5eT32eRZ6u WFm1n8JGE720UdWdagma3KYIjsbxMJn7DL4CCPg7Mk2IIrTho2iM5accGm0C/jn7UCMqtEEv GGHTa6ZpxSQgfKfgtZB1qBBMk9Mi3X3kKs8PXxktlPnmiHAR3NEshPjyMzNnyAT25wvRJFJp srTEITC0YuGCbQ2JeBNurXW+ef/qVWmphGog0c164Fq/hk3WrLvePfIy3DuF3oMp86SNxPk3 ovIYjcQFqERQSRG4UgTCA0bN/RmynWKauZxPwFsSrPvCTNMOCPSfZQgmlsah5vM90MrXYODg r2SlO19GeQguKTqVaQi+jtKiYK29uTSgkGHbT4q9a9LMP/8s+OXwsGDiVkt8+SL05up9dUR1 cz9r4AgPiQXtDXwatjf0GemuMkKt36jvwcre5HQgBq1RmZ/Uz1t+qI3S4nO7gpdgNcmN5iNk BFsFh6NCTS54Z9saWJ0tWOm18/lCKQTiixDVuACDJZ6KhVoJqk8Rdjo2d1BnpWC5HxMh/AC+ Cw2oUhcmgr5GFzMVaTw+KhQDVsokaFMY5Ijeet3calWIDANaNlXpj6K/2QAlQUZg13rIs7tc 2tkqD3n2zR7y7EEe8rD/t4P8t4P8t4P8fQ5yVY0oJWrsMGmJwhSv0aBKY92S/sxvFjKQU9XN 0sqF+1mH0Da+JKltAvQTQAljKYyf1FT+AtmtsvekP93tA9ZdQAZWm419FWs+h+xozZH5rmkd obybe7z+0VfEIaNvc8RH3+yTjn6Mize6y7pjI/RYZZzwba1x4o8V48SNJROzdbC9ezDcu+/o csXImnEa7Dg7ogN/+dRyQxRhpToDg8DSagRln1OsWQ8/cbDiyfPT98eiX/x+cfTq7Fj0eMa9 facPFnGw38MnzirE0W+/naJSbKdyEd2M82RUap2DahtPE4iurpcL/VVx0nLyUfogza5uAQJE Y2wesS+cTKfokShVh1+FGqT80eqwRuPeUWb6ucwy70KOw4AweHVydo6gpuAgx77MRoSB6iSK dhQX+Ik2TIJRAMPbQrAGApijdBakOJ4g4G/BxAz0IanCvjYlof/gKTu1KWn8ugnFrTh+81/H r96+Ox7hjpeVJ562gs8P5pm2etjvIXcN+31nT200kHWck1NIe/jy+Oi341MUGZzZbsnBggAq iEueLHgfkLUFflCIs7iFzO6MN4kyHxNMbsQ8uxAoslZv3MS1/cs7jDqgfTVIFRpzb7FAXYZn 4+IqTPMl8ESeMG/ATHFijYP1zL1PamS8xPAK17BIQjx5z9AXwSVbIwCCD/Yxr41RW5lp/wWF YZJ8wqErNcyntcfD+KmqXT5VDng5LbJ1r26pjqtplu29Ldx8fBgxV8sFwRqzQyeab9+dgyf0 /Pj0+AXI+ssWclWHeF4ZlmKHNMf7+Sf3mdp1fYyirdBge5cjBepkNntNtw0VOz6i3hDqSggh OYyBVY+1EDU3T2HhuPf/yLrd7qbD0BdePiN8cbk74KvAcneG1nIRNPWcexfgUkHk+np88vro nZojBI4aTyF09KMkk2O9rzgEwf4kY9hfpMT7s2Map9ZvwJrl6fO6kjH6udJnVBqr6HfHSN2D xLIIMTnC5GVpluUYsyAchiJj1hoaGnI7xJgMLfOmcsyxXZONarslin7QCUm6t7uHKbW9PW2d 8B91iuU1H1oWTaCO4wvQVZVmTHCZZtfEv+EhhKYfD3ExT1ctpYiUac3Q9wFL/6zzdQVLqVW7 z9jTCFq6y2da4X5vC1e4DwqyP6QlNj7iaavqdKtf+NBCj+ygfkjlPMHDF8WipJQouqmIS8Ps uMFFxlfuM2Pu8MxE2O5QlbkUt68ZXv6KTLZuxsJUrptScdzKCYvRtRlF436m65QoemtxiN5J 2OCPWpj7vb1dpw870+/3BviijFcECKLWPixQICtI+ioL50sMTTG2QoFWBv0hktO5TwLXdKgI 9x1iBWasogBQlydxdEMs+Zll414ArmbvCoiKvNwjKCu1RIllWq0RkhQCSzqmBCsbJI8UQZU4 uKLYQ7Up5qD0nrUoHUOM4CKgFSu6jx4KRscWzjouxBu6GRwCIg6KL9DKB07BfAEFxGjoUavZ rladQXusGIErd9HY9PuDgfGsaoqxrv9W6sofaVBpudl1mPsz2/IpFiPUt/Z6zhBQ39rftfwC MQMOUy7VIfQiXGe0dnCrDiusVCMNZaiU2+AFAZ9QaNWojiTqfgTu+myVcjIWUUekZe1UHwNt hXTNVmjY1RAtFVsbxCDF6iNOLmpY5+aprxVPT7WWnLb+QW94MNi9z9lbNbTm7+3tQDw3AHMN T8WT7UYDxcBB+seYL8CjwFS5Up7QRRiB3io8+qPcngx4NFk10hVYt6J0RdZsiSxBcOpk61LK BYDD0FTFazwaYxi3EsN0QbDb+D8a1Wj0kT2YZSCUhankppFBxTibOjLapClQCTLwABMhsZgs w4hWZMsv6sJA+kkg3cy7kjQrub+uDp9Ee0wrIzJzrG2U4YuTV/B96phoCKbnMwnEGvipAPJV MEAQyUkphlNCFkEA8mPgQBklC9lk5chxYSkJRU7L9tAZbIPXst3DJ3ktALVhUnIxJokodYNV PZ09R2ximHgAfvO2zt9gdzA6DW1PADnMBT1S67PbuTP+Iz4c+wmEUHE+RpiiuXAwkAKdxq3k DpCFwRQX6bg+N93SX1TWd+GZenEGEbMLIXOCm4pI9/e+C2sbPZRyBqzpDkj6l2PT2lx85woi GV/kM0R79wdizVABFS9Pwu9HEtwYPw0pAiQCD74D1c8G5dXWurwQa2azhupirT6wLoIKywiW C144ycDekBx3MGbsHD545WEGai/UK/+R8mCB/iqxYId3sIsLgueWFWwJzvc+jh4fQGcKa2rL Eh3Rh4XBW8YrapE+cBvrFlJZBqGJgLIae1WQ1agOB2Ro+r2tPWefqY+0N5RfiyNbGTcMiOl6 FUwViq61E+BO/C7JPHik3TdfKxAnAKKi/T3jcKCWb6xnSFnyNkaqb6kVU6ufQBf55gwCG4ku Lu0Z0vGbkcPBD0MNez4UsZUb9pBd8cLIhf0Ywnawc7sLdoVirx08QVLStQI0kg3oYXEZeQLw rMseTuTiCYtMcfNBoz8iuXMVAwAxT6baRbHIhoTVpIOv1x7YYPAL0Kaj986bh9F4JK/wm7b/ 6qyu4juo7swfbF5Vct19Zs5fMSRpmGIs/A4rgocu9GB+4XGmeWTYGPPoJSY2fWxTj9g0DfOt BHZLfznW0iyqkeTeKwFSZwKl6pFKChQ3g6ZF6BPwWy5xiFI24Kt5yyhHXaM+UbOS+8FgCI4l sMW+fR7ExS5eDBR3KXngwvZce6bqhewrbZkkPgxzTAur7SlOxxUKbfYivQg9qpuuMNlNFDMY yn4nptUDcBvFRGJRsfiYTIoDauCbrob2pAiYH2neDOOxTnL82fsALUAIIm9zsUa6rBEt4lv0 xVpFJU0N4leDEsqQ8j9CV2IsYnIHX76QvDXLrSxpJGSlD7z1jlgoKVOCPUCHERX3YNB3+nsq 4aRnlBwPST83+KgQX1Vdj9mftns6wn4HXMBPKUFCFWOX7lyQGhnnYkEvf/Y/YNDqWutWRkBo FBqrB3V+FGpag8E08pP0RfMU9+cUfy266acyGNBijIMDVFWeg8s62gSOrE10JqOjke596Kbz sUxQ9oxMrx030hS4tUusvhnHTuOrMCyXat2BpEJRGFXwnKSdiiLCLEMVDq9hfOVFwP10DUKg nldlbqaiDdREArEPBOYYPLpKFWB/zrhoAwBqxVRQgEp5f/6cKvlBK3JBCcyzlF0N4ImpfftW SDphoniTXCWENc7Qp6uIbUA3GZp9pxnIyfIC7x04m/XIsNk6AJXGKE2xIMOBWZFSBT7hXB0o Y/4sk5jUy5P0r3iztSarzQcE69La6uvK84hZPfm0NXzYecQ9me0h+IadoXIgNnS6thotkx+i YmWd6+eiNZD3NsunzmKvCbWbU2fWEuuCefzqoJg+PO4vQnaK+dmoInO/fXN+/OZcreJC5sb1 D+NpIprwC2wXr2Eae3MwtMSEDz4sKCbmszxkhDHayzFxQ2mCKrHWcAZv29qjKv25whu6eQVz 3JuZNGPPl5LHblHFRP+gv23VPWw5+1iEsOUM+BCyKLL38WABi+yBAkB1qiibLmOfAqu5dwmG D8VUVQZMwcSyyL4GdEDRJ6nMVqXf8WIaeYpWBh4Mcld2Ha4fzfH+VZrlra4qY4P/MEs6D2Ms PgD82AWlM68ovKRDJR4V8/nVPAEwKMaYTi5OP8GT9Gdi01+mm4wQgM4zGU3pMIy11I9EC+F9 F1qs9rLcy0PfsCQV+Rh6iqZuh/EOi8Z/g2hg7lQdcpnCCMrXLFNzwmoqJejoH8tvHUz9mMIx qrwVJus5Quwy/guQ8GFcceOlcPxgp+eBTMqNJAJEN3QzDNRrM1vCusEAUIhGAQYMgcAjBe2b tRxjf0oeKsJD6gIcoN1Eio9LoOpETrH4j+zYMk0tCoNcJgZSJr2UC74nnn957aWBThha5+S0 y2AIcR8pvskSsAOoA4xFMwDfJLk8wCnRwBeJGyYzH9p/KMyga2VeVSL1o3iKkZz4iEkht+Tu hXq7CM5Ij1ZV4x/ZpRD/YzI2V0hXbi05biqA6nRquagi7Ls3Vcn+OQN9pJ1dZgH2ce9OdOpo TV9CqGQlKQzSjpZreT31ZbhuKJ6VQtb/d7jT41ZYJf5crW1q9KqJlAKXVqt6X6MQwtIlDfL2 3FWqQfuTZcVgCoywbIiP0NFewdqI3/Tn0iF3oRUABKWfeiMrT2hpEu2VIqEZ++bK749sBWQC gC9fwKez6mDO3p6enx63Wi1bsVSTqlQ6xbnUithg7A+LhN0hoVymJWnABDUKta0qzHFhEdZi dOj5VCge0nkI7ZuHrNAuro2oJVArHmZoOoWjlexc0M04r8jLClu71eJYoA3tClKJ73QU3Z6u GgwBrT3cdFixV7qPFooVe+asA2DiroK2invUgCoNWCw0+/A1lZLhMDaU3HH7eo4JqlS1R1lf 65IPPllSmhndkmQRgTmPisoxDC2mWOnO9e+gT8wdHcJdg+RjEQOLij3VpaBUBkt0Y3BMUZvG hkU34xkTBQ9eiisxZgOPUFRc82/k38d4sTzD/BisC6+im9r8RSaXQTJmHw4TfdrxMqDIaOa2 T5YpDZHBNLGLImxZHsMJxKIf9C4hFsIVfd4s2hylZpAe0IiFAbg3Z7Q3iNpF6i3AY8nI7wWn D/0Vqqn3OFgTzwbb24444UaqCyTDlCeY+FMxlsx8bwGWVf5nyV5hjjfTM6YfevHpnMsBcnUx fSzjNMSDT1VJ3Wzh4VJb+bDblIjr72w7u/pEDGycOe27Q2WWCV0oTdxyS2vilYabQm06eFZl hAdWh0ESPl/AXrTwcovZiz7dQeMLaJ7AlIqMAzwhbQJrR0HLquj89+QxuaEKRdK92dgeovHx CtQm+v4UFlNoTxMrRSE4RBWh3HM1BXu5ypR6WLqXUgRNNgcPKU1b6aorXUubmLuu9lQTmZEC zUKsHSWJVZfrFAIgUyhSEw8TxcsFalmW5i7NGhJ+KR84myt0fMqdUcZcJLFUTjIeF5DiY4nN JW7SZJkTpLt8wJBilaBr03e11bQ96ILKZEVEyVQijQ8F8wnb2Dbd9cJ32lqH71fQ+5rbE/pu m4FJAKrXHa0sdXxl+fDFJVos4+XCDzpBrCn6jjbKdXv8YFNc3Jyz617WX9tdWR5nKj2sq7zG urOXVO1nXw9df+Wzdk3PXKIc2Sd3+I2dECALFxgHSfw4V4yrL2tWs0SP6Bx/CjGv0hQ0ujKY VYnQqkQPrYgwbTGyE4KoQFDKnzCwBBagrHAaVGahcBiw3z2+QmkM+wkdnaVYwTWNwjOoOQX1 IZX7xp/VHVROkVAZG+kKXip4WlPkE3M2eFu98liyQ51bPp5WmgulrmUEmaLVZRyF8WVRqlw4 vMmiIsfqZpP2xRYQOtnFfxTNmRIX+EepEG4xeSHj2jO3lXUIaQNlMsjLrmYrzLzGRFGLuo5V BA6m1VDVtPB4PRLfi+vcuhLv89dBssoGlXazsSqu89pkr9rPsvpcYRo/l/QdJl6VyNNFh9JH QoHjlYcoWMuy4SBbY/GWmhnYFVItpXu767cUl4PcU88WKS8XN9p1Tc0yirbE/xedFc5qmD/O jI0ylY/aTVP+MbE4+NTEdfW9trri6gApoFeLY5D1vFWKrRurNhn/VWXpZ5IhXP1I5xgU/yj6 jOtV56qDrTMpZc2XrfrOoC86A7wkMLSqLLgq0J4Y1YzabGIBw0lmGovg4bScXJCP0a+g/y8j NFIzvKdL/OoSyBTzojDgRpMFPXTJiYiJHsg/Q3DT2Z9BFIQKQsCEL6niDqOMbgHFbKTmVE1l xarqq2JW3YmqQr5jfjvTQvZ09ewGKbzgLrSuFg0jStydXjVfcM1L0WrtastUvd3N8WsYvmFY 2JpQn7iUW20pUM1KFGpAWKVXgVSForTESo6/INiKvmgYazJSjHDMAFUOYqHAPjGbRK4VvIfl 1ZvN96oAaLBHlyYG23ulSiW7tN8O6ECGi/plrf+wjROHFaeYNDeZ76aljzmBvQVx1mBLdLb+ r5JrW20bCKK/Iig0JLbATeTmRighGFpoXyS3L3kIjiPFeolMJFOH/nznzGU1q9olfovjy86O ZufM7Ww20bZSvEiUaB0KzlKPGoBz6sH5P97NzeX3eNefxf3IacmvFR3/HPZLoV62CznltzmR 9jrBGXaRYeu1wpgX1e8MSZmfDyCV2n5IYzuFR9yYITjHvb/TczjY0dnFtB8y9wbgM2Nr7939 zKOKKAQXidE1E0F2wz1nrC91Z9INhPaKchlP9Fp4iQInbTKoRPJ7BMvlNozsx5kTiX5tPMJ6 DJ4KROB/GTml7JJCyhESa5fLhvT/+kb+qls17GzbzXrdSA+cP8/bWGy2N9ocSqXskGUZE3jP Li/CMdAVSbzCFi7617ebrciSyoS+sB5wC55Ei+y2FaHCEM0YVog0a9nrHa2nqlKg4Za4z9nm +be7+fxrTqoprBUwUCvPItk1TTG74iRcVRKaoMc6m0QyP0MfQWfYK5BVdEcIJNXTo06LPyIu Q5Z09EvutwsF0uCaKbbtulzWFa6PqDtjSLKSPyt11obpDyDhafAHe76JLFoZj6I6ensIaAqJ Ia74AbgdpHdoIJkR4chLpVEjnbaRKh+CCyhEtkJ2Ai5VNp14xse/EIBj/CVxQJBcKdlGHANJ PE7MEYQ4iPch64fxQAGCNFRYVeMW1fK9IBU31vrRLt0Tbkmi4EIowdEA115TwxwUSzGICoPj 9EZ43x/m0Qj1SDu7OsbyDqs2SHD+bJiOOK35xcfOlXhV7iE70c78t4WTxZ/YoylNZndIEz04 PVMvze9gLhQUoizN28HtIhs8EDp0q5IcvPYm2MM8vnFqnJ4YdZr0xa7mY4KizcP322IucD09 vcS8YHaeBTel38HQx+KVxxZ4u05bPYVrFP9uPvs1y4sZGWjsNtLkE5np5FjIOmRyH3CPToXH io3CI8u8x6Ktn0JKEHwMEzvaFRZ6qsOfpHVVHkPKXzwrwkoTVwAA --LQksG6bCIzRHxTLp-- From michael@tis.com Tue Feb 3 17:45:53 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA25317 for ; Tue, 3 Feb 1998 17:45:46 -0800 (PST) Received: by relay.la.tis.com; id RAA00397; Tue, 3 Feb 1998 17:56:50 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma000393; Tue, 3 Feb 98 17:56:42 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA26205; Tue, 3 Feb 1998 17:42:50 -0800 (PST) Message-ID: <19980203174250.19534@la.tis.com> Date: Tue, 3 Feb 1998 17:42:50 -0800 From: Michael Elkins To: Mutt Masters Subject: [0.90] bugfix: new_addr #2 Mail-Followup-To: Mutt Masters References: <19980203070120.45707@sgpfo14.tinker.af.mil> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=opJtzjQTFsWo+cga X-Mailer: Mutt 0.90i In-Reply-To: <19980203070120.45707@sgpfo14.tinker.af.mil>; from Edward T. King on Tue, Feb 03, 1998 at 07:01:20AM -0600 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 07:01:20AM -0600, Edward T. King wrote: > Reply-To: > Mutt is not prompting for a passphrase when pulling up encrypted mail. I get > the following error messsage: "multipart message has no boundary parameter!" > I have to use a macro to decrypt the displayed message. This is a result of my `new_addr' patch. The following patch should fix the problem. me --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.new_addr.1-2 --- rfc822.c~ Mon Feb 2 18:45:11 1998 +++ rfc822.c Tue Feb 3 17:39:47 1998 @@ -509,7 +509,7 @@ size_t tmplen = sizeof (tmp) - 3; *pc++ = '"'; - for (; value && tmplen; value++) + for (; *value && tmplen; value++) { if (*value == '\\' || *value == '"') { @@ -721,7 +721,7 @@ return top; } -#ifdef 0 +#if 0 void print_addr_list (ADDRESS *list) { while (list) --opJtzjQTFsWo+cga-- From michael@tis.com Tue Feb 3 18:16:27 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id SAA05762 for ; Tue, 3 Feb 1998 18:16:23 -0800 (PST) Received: by relay.la.tis.com; id SAA00762; Tue, 3 Feb 1998 18:27:19 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma000759; Tue, 3 Feb 98 18:26:51 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id SAA26383; Tue, 3 Feb 1998 18:12:59 -0800 (PST) Message-ID: <19980203181259.38703@la.tis.com> Date: Tue, 3 Feb 1998 18:12:59 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] feature: thread_hash #3 (EXPERIMENTAL) Mail-Followup-To: Mutt Development List References: <19980202191413.13067@la.tis.com> <19980203030844.41770@xenomorph.dyn.ml.org> <19980203135222.26634@la.tis.com> <19980203201714.41169@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=a8Wt8u1KmwUX3Y2C X-Mailer: Mutt 0.90i In-Reply-To: <19980203201714.41169@cs.swarthmore.edu>; from Daniel Eisenbud on Tue, Feb 03, 1998 at 08:17:14PM -0500 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 08:17:14PM -0500, Daniel Eisenbud wrote: > I think the latter of these two examples (mutt's behavior without your > thread-hash patch) is better, just because we reall have no idea where > the message should be attached, and I think it would be significantly > more confusing to have subject-threaded messages (and possibly whole > reference-threads that descend from them) attached somewhere wrong in > the tree than to just have the convention of attaching them to the root > of the tree. Ok, thats what I figured, but I wasn't sure. Its easy enough to fix. Just apply the attached one-liner. me --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.thread_hash.2-3" --- thread.c~ Tue Feb 3 13:51:15 1998 +++ thread.c Tue Feb 3 18:10:01 1998 @@ -193,6 +193,7 @@ tmp = ptr->data; if (tmp != cur && /* don't match the same message */ !tmp->fake_thread && /* don't match pseudo threads */ + tmp->subject_changed && /* only match interesting replies */ !is_descendant (tmp, cur) && /* don't match in the same thread */ cur->date_sent >= tmp->date_sent && (!last || (last->date_sent <= tmp->date_sent)) && --a8Wt8u1KmwUX3Y2C-- From dpb@cs.brown.edu Tue Feb 3 19:28:00 1998 Return-Path: dpb@cs.brown.edu Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA00754 for ; Tue, 3 Feb 1998 19:27:56 -0800 (PST) Received: from jones.cs.brown.edu (jones.cs.brown.edu [128.148.38.144]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id WAA08947; Tue, 3 Feb 1998 22:27:21 -0500 (EST) Received: (dpb@localhost) by jones.cs.brown.edu (8.8.5/BrownCS1.0) id WAA04555; Tue, 3 Feb 1998 22:27:21 -0500 (EST) Message-ID: <19980203222721.41225@cs.brown.edu> Date: Tue, 3 Feb 1998 22:27:21 -0500 From: Don Blaheta To: Mutt Development Mailing List Cc: Don Blaheta Subject: [0.89] segfaults Mail-Followup-To: Mutt Development Mailing List , Don Blaheta Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 I've got mutt consistently segfaulting on this one mail... here's a stack trace (sorry, I stripped the binary--I'll recompile it if you need the -g output): =>[1] strlen(0x0, 0x0, 0xefffdbb8, 0x7efefeff, 0x81010100, 0xff00), at 0xef724668 [2] _doprnt(0x63aa8, 0x0, 0x0, 0x0, 0x8, 0x0), at 0xef75a364 [3] snprintf(0xefffdcc8, 0x100, 0x63aa4, 0x1c2db0, 0x0, 0xefffe02f), at 0xef7637a0 [4] _mutt_make_string(0x7f431, 0x2b, 0x25, 0x7e149, 0x4, 0xff), at 0x2e6e4 [5] index_make_entry(0xefffe008, 0x100, 0x1ba8e0, 0x44d, 0x20c4c, 0x0), at 0x20d90 [6] menu_redraw_index(0x1ba8e0, 0x811ac, 0x44d, 0x0, 0x91ad8, 0xcfff8000), at 0x354a4 [7] mutt_pager(0x81000, 0x19b730, 0x4, 0x0, 0x0, 0x1), at 0x3c9fc [8] mutt_display_message(0x19b730, 0x7f800, 0x80c10, 0x1, 0x7f278, 0x82860), at 0x1cc30 [9] mutt_index_menu(0x7f9cc, 0x7b868, 0x7b878, 0xffffffff, 0x813d8, 0x8), at 0x22a68 [10] main(0x3, 0x813d4, 0x0, 0x0, 0x0, 0x0), at 0x3305c It happens whenever I try to display the message, either from the index or the pager. elm has no problems with the message. Unfortunately, if I save the message, and then view it, everything works fine. Even if I copy it out directly with vi, everything is hunky-dorey. This is a gigantic mail file that it's in, but I've saved a copy if anyone cares to look at it. What's more, it seems to be some interaction between this mailfile and my muttrc! Gaaaah! So anyway, I don't have time at the moment to actually go through and figure out what's wrong, but I thought I'd post it in case someone knew what was wrong. -- -=-Don Blaheta-=-=-dpb@cs.brown.edu-=-=--=- Pity the meek, for they shall inherit the earth. -- Don Marquis From blong@shell9.ba.best.com Tue Feb 3 19:51:08 1998 Return-Path: blong@shell9.ba.best.com Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA08637 for ; Tue, 3 Feb 1998 19:51:03 -0800 (PST) Received: (from blong@localhost) by shell9.ba.best.com (8.8.8/8.8.BEST) id TAA23615; Tue, 3 Feb 1998 19:50:52 -0800 (PST) Message-ID: <19980203195052.05554@shell9.ba.best.com> Date: Tue, 3 Feb 1998 19:50:52 -0800 From: Brandon Long To: Mutt Development Mailing List Subject: Re: [0.89] segfaults Reply-To: blong@fiction.net Mail-Followup-To: Mutt Development Mailing List References: <19980203222721.41225@cs.brown.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980203222721.41225@cs.brown.edu>; from Don Blaheta on Tue, Feb 03, 1998 at 10:27:21PM -0500 Organization: Fiction L Networks X-Pgp-Public-Key: X-Uri: On 02/03/98 Don Blaheta uttered the following other thing: > Date: Tue, 3 Feb 1998 22:27:21 -0500 > From: Don Blaheta > To: Mutt Development Mailing List > Cc: Don Blaheta > Subject: [0.89] segfaults > Mail-Followup-To: Mutt Development Mailing List , > Don Blaheta Hmm, looks like something wrong, Don's email address should be full in the Mail-Followup-To: header, right? Brandon -- Brandon Long "Here's a nickel, kid. MD6 Crash Test Dummy Get yourself a better computer." Intel Corporation -"Dilbert" by Scott Adams 6-24-95 I'm too low on the totem pole to speak for Intel. http://www.fiction.net/blong/ From linc@ai2.BPA.Arizona.EDU Tue Feb 3 20:05:13 1998 Return-Path: linc@ai2.BPA.Arizona.EDU Received: from ai2.BPA.Arizona.EDU (AI2.BPA.ARIZONA.EDU [128.196.40.40]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA13831 for ; Tue, 3 Feb 1998 20:05:09 -0800 (PST) Received: by ai2.BPA.Arizona.EDU (1.37.109.24/16.2) id AA081655469; Tue, 3 Feb 1998 21:11:09 -0700 Message-Id: <19980203211109.03253@ai2.BPA.Arizona.EDU> Date: Tue, 3 Feb 1998 21:11:09 -0700 From: Chienting Lin To: MUTT Developers Subject: [0.90] hooks broken? Mail-Followup-To: MUTT Developers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Hello! Since 0.90/0.90i, my exisiting hooks were broken. For example, I have the following hook setup in my muttrc: fcc-save-hook ^utpal(@|$) =ece573 Instead of saving/recording the message to '=ece573', mutt was saving it to '=utpal'. I've tried to use separate fcc-hook and save-hook but it didn't help either. It looks like the problem might have something to do with patch 'pattern_hook.4'. Could somebody help take a look? Many thanks! cheers, Chienting -- Chienting Lin, linc@bpa.arizona.edu McClelland Hall 430W, TEL: 520-621-3927, FAX: 520-621-2433 From ellement@sdd.hp.com Tue Feb 3 22:49:45 1998 Return-Path: ellement@sdd.hp.com Received: from hpsdlo.sdd.hp.com (hpsdlo.sdd.hp.com [15.255.160.64]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id WAA06608 for ; Tue, 3 Feb 1998 22:49:40 -0800 (PST) Received: from epgc352.sdd.hp.com (epgc352.sdd.hp.com [15.64.160.113]) by hpsdlo.sdd.hp.com (8.8.6/8.8.5tis+epg) with ESMTP id WAA10725 for ; Tue, 3 Feb 1998 22:49:35 -0800 (PST) Received: (from ellement@localhost) by epgc352.sdd.hp.com (8.7.6/8.7.3 TIS 5.0/sdd epg) id WAA21236; Tue, 3 Feb 1998 22:49:35 -0800 (PST) Message-ID: <19980203224935.33603@sdd.hp.com> Date: Tue, 3 Feb 1998 22:49:35 -0800 From: David Ellement To: Mutt Development List Subject: Re: [0.89] feature: pattern_hook Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=zYM0uCDKw75PZbzx X-Mailer: Mutt 0.89.1i In-Reply-To: <19980129230323.25189@la.tis.com>; from Michael Elkins on Thu, Jan 29, 1998 at 11:03:23PM -0800 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii On 980129, at 23:03:23, Michael Elkins wrote: > On Thu, Jan 29, 1998 at 09:27:10PM -0800, David Ellement wrote: > > On 980126, at 13:00:57, Michael Elkins wrote: > > > > > > This implements the use of the message/pattern matching in send-hook, > > > save-hook and fcc-hook. This allows much finer grain of control over the > > > hook commands for the user. Existing hooks should work as before. For > > > send-hook the exansion is "~t %s | ~c %s" and for save/fcc-hook it is > > > "~f %c | ~t %s | ~c %s". > > > > I'm having some trouble understanding how to use this feature. > > > > I had been taking advantage of the regular exression matching of the > > previous hooks (which have worked great since the 0.88.11.save_hook > > patch), but the regular expression matching doesn't seem to work with this > > patch (version 3): > > > > save-hook ^(bkung|bats)(@sdd(\\.hp\\.com)?)?$ =syn > > Hmm, I tried something like: > > save-hook ^mutt-(dev|users)@(turing\\.)?cs\\.hmc\\.edu$ +mutt-mail > > and it worked just liked I expected it to > > [...] The parser did not change any, so if it worked before I can > see no obvious reason why it would not after applying this patch. You might > use your debugger to break on mutt_parse_hook() and see what the result of > the mutt_extract_token() is for the pattern, and then also check the output > of mutt_check_simple(). I believe the difference due to the "address" used to match against the pattern. Before this patch, the adress returned by mutt_simple_address was used for the comparison. With this patch, the address returned by rfc822_write_address is used for the comparison. The attached patch substitues mutt_simple_address for rfc822_write_address in mutt_pattern_exec. I still see some strange matches for fcc-hooks, so there must be other matching differences. -- David Ellement --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.89.1i.dme.pattern_simple_address.1" --- pattern.c.orig Tue Feb 3 04:43:36 1998 +++ pattern.c Tue Feb 3 22:34:37 1998 @@ -613,16 +613,16 @@ switch (pat->op) { case M_SENDER: - rfc822_write_address (buf, sizeof (buf), h->env->sender); + mutt_simple_address (buf, sizeof (buf), h->env->sender); break; case M_FROM: - rfc822_write_address (buf, sizeof (buf), h->env->from); + mutt_simple_address (buf, sizeof (buf), h->env->from); break; case M_TO: - rfc822_write_address (buf, sizeof (buf), h->env->to); + mutt_simple_address (buf, sizeof (buf), h->env->to); break; case M_CC: - rfc822_write_address (buf, sizeof (buf), h->env->cc); + mutt_simple_address (buf, sizeof (buf), h->env->cc); break; case M_SUBJECT: if (h->env->subject) --zYM0uCDKw75PZbzx-- From hildeb@stahlw00.stahl.bau.tu-bs.de Wed Feb 4 03:39:01 1998 Return-Path: hildeb@stahlw00.stahl.bau.tu-bs.de Received: from stahlw00.stahl.bau.tu-bs.de (stahlw00.stahl.bau.tu-bs.de [134.169.69.220]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id DAA05378 for ; Wed, 4 Feb 1998 03:38:58 -0800 (PST) Received: (from hildeb@localhost) by stahlw00.stahl.bau.tu-bs.de (8.8.8/8.8.8) id MAA05690; Wed, 4 Feb 1998 12:38:18 +0100 (MET) Message-ID: <19980204123818.13812@stahlw00.stahl.bau.tu-bs.de> Date: Wed, 4 Feb 1998 12:38:18 +0100 From: Ralf Hildebrandt To: mutt-dev@cs.hmc.edu Subject: Re: configure problem Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980203142000.21109@stahlw00.stahl.bau.tu-bs.de> <19980203123843.35685@rsn.hp.com> <19980203131144.57166@shell9.ba.best.com> <19980203170505.42962@rsn.hp.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="Fh2G5kB/856lXr1r" X-Mailer: Mutt 0.90i In-Reply-To: <19980203170505.42962@rsn.hp.com>; from David DeSimone on Tue, Feb 03, 1998 at 05:05:05PM -0600 X-Mailer-Info: http://www.stahl.bau.tu-bs.de/~hildeb --Fh2G5kB/856lXr1r Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Quoting David DeSimone (fox@rsn.hp.com): > > The problem isn't with snprintf, but with vsnprintf. Mutt only tests > > for snprintf with configure, and then uses vsnprintf in curs_lib.c. > > HP-UX has snprintf but not vsnprintf. >=20 > Hmmm, if that's the case, why doesn't the linker fail looking for a > symbol "_vsnprintf"? It dies looking for "_snprintf", which should be > locateable.... Weird. Allow me to explain: I use:=20 %./configure --prefix=3D/users2/local --with-rx --with-slang --enable-pop =2E..snip... checking for strerror... yes checking for snprintf... yes checking for strcasecmp... yes =2E..snip... %make gcc -Wall -pedantic -g -O2 -DSHAREDIR=3D\"/users2/local/share\" -I. -I./rx = -c addrbook.c -o addrbook.o addrbook.c: In function `alias_entry': addrbook.c:47: warning: implicit declaration of function `snprintf' gcc -Wall -pedantic -g -O2 -DSHAREDIR=3D\"/users2/local/share\" -I. -I./rx = -c alias.c -o alias.o alias.c: In function `mutt_create_alias': alias.c:225: warning: implicit declaration of function `snprintf' =2E..snip... lots of implicit declarations follow in each of the file snprintf is used i= n. =2E..snip... gcc -o mutt addrbook.o alias.o attach.o bind.o browser.o buffy.o color.o co= mmands.o complete.o compose.o copy.o curs_lib =2Eo curs_main.o date.o edit.o enter.o flags.o init.o filter.o from.o getdo= main.o handler.o hdrline.o headers.o help.o hoo k.o keymap.o lib.o main.o mbox.o menu.o mh.o mx.o pager.o parse.o pattern.o= postpone.o print.o recvattach.o rfc822.o rfc 1524.o rfc2047.o send.o sendlib.o signal.o sort.o status.o system.o thread.= o pgp.o pgpinvoke.o pgpkey.o pgppubring.o sh a1dgst.o resize.o rx/librx.a pop.o -lslang -lm collect2: ld returned 1 exit status /bin/ld: Unsatisfied symbols: vsnprintf (code) make: *** [mutt] Error 1 --=20 Ralf Hildebrandt, R.Hildebrandt@tu-bs.de (PGP Key @ request ) http://www.stahl.bau.tu-bs.de/~hildeb Institute for Steel Structures @ Technical University of Braunschweig Beethovenstr. 51, 38106 Braunschweig, Germany --Fh2G5kB/856lXr1r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNNhTJEnh/jPvZzKNAQEyHgP/WvZbH6lG7coWL7FGBQIXzIZM0MFNTP4U WEaxNSOE3TYiWLWKi8Jyj597uwoj5IePTHPv5d6YVqJJTnditfxognnGqe8r2eCL xFteNLwFpzLOFWrS974WdOL5z6GF0khgyuiG92/DAU1FNMi7X+YN5EauQI3dvA5S 53sPoQ0i3YI= =iY41 -----END PGP SIGNATURE----- --Fh2G5kB/856lXr1r-- From leitner@germany.sial.com Wed Feb 4 09:03:39 1998 Return-Path: leitner@germany.sial.com Received: from linus.germany.sial.com (gatekeeper.sial.com [199.217.212.1]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id JAA25338 for ; Wed, 4 Feb 1998 09:03:25 -0800 (PST) Received: (from leitner@localhost) by linus.germany.sial.com (8.8.8/8.8.8) id SAA06890; Wed, 4 Feb 1998 18:05:00 +0100 Message-ID: <19980204180500.49303@germany.sial.com> Date: Wed, 4 Feb 1998 18:05:00 +0100 From: Felix von Leitner To: Mutt mailing list Subject: Core dump trying to save the attached mail Reply-To: Felix von Leitner Mail-Followup-To: Mutt mailing list Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=KFztAG8eRSV9hGtP X-Mailer: Mutt 0.89.1i --KFztAG8eRSV9hGtP Content-Type: multipart/mixed; boundary=UlVJffcvxoiEqYs2 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Yes, I know that this mail is badly broken. Mutt should not dump core on my no matter how broken my mails are. Felix --UlVJffcvxoiEqYs2 Content-Type: message/rfc822 Content-Description: Forwarded message from Received: from localhost by linus (fetchmail-4.3.6 POP3) for (single-drop); Wed, 04 Feb 1998 17:58:13 CET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mutt-linus-6881-3 >From leitner Wed Feb 4 17:28:01 1998 Return-Path: Delivered-To: leitner@math.fu-berlin.de Received: (qmail 14479 invoked from network); 4 Feb 1998 16:27:59 -0000 Received: from rudin.math.fu-berlin.de (HELO math.fu-berlin.de) (160.45.40.74) by leibniz.math.fu-berlin.de with SMTP; 4 Feb 1998 16:27:59 -0000 Received: (qmail 14585 invoked by uid 8032); 4 Feb 1998 16:27:56 -0000 Message-ID: <19980204172756.42010@math.fu-berlin.de> Date: Wed, 4 Feb 1998 17:27:56 +0100 From: Sven Guckes To: Felix Subject: [Fefe] Reply-To! Mime-Version: 1.0 X-Mailer: Mutt 0.89i X-Mailer-Info: http://www.math.fu-berlin.de/~guckes/mutt/ Content-Type: application/pgp; format=text; x-action=encryptsign Hint: Reply-To: leitner@math.fu-berlin.de *grummel* Sven === ----- Forwarded message from MAILER-DAEMON@math.fu-berlin.de ----- >From guckes Wed Feb 4 17:24:14 1998 Return-Path: <> Delivered-To: guckes@math.fu-berlin.de Received: (qmail 14362 invoked for bounce); 4 Feb 1998 16:24:09 -0000 Date: 4 Feb 1998 16:24:09 -0000 From: MAILER-DAEMON@math.fu-berlin.de To: guckes@math.fu-berlin.de Subject: [Fefe] failure notice Content-Type: application/pgp; format=text; x-action=encryptsign Hi. This is the qmail-send program at math.fu-berlin.de. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, I couldn't find any host named germany.sial.com. (#5.1.2) --- Below this line is a copy of the message. Return-Path: Received: (qmail 14360 invoked from network); 4 Feb 1998 16:24:07 -0000 Received: from rudin.math.fu-berlin.de (HELO math.fu-berlin.de) (160.45.40.74) by leibniz.math.fu-berlin.de with SMTP; 4 Feb 1998 16:24:07 -0000 Received: (qmail 14560 invoked by uid 8032); 4 Feb 1998 16:24:05 -0000 Message-ID: <19980204172404.01506@math.fu-berlin.de> Date: Wed, 4 Feb 1998 17:24:04 +0100 From: Sven Guckes To: Felix von Leitner Subject: [Fefe] Re: zsh setup and function tar References: <19980204171311.34130@germany.sial.com> Mime-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary=nh7xodEAoBMCZwgA X-Mailer: Mutt 0.89i X-Old-Subject: Re: Will das vielleicht jemand weiterentwickeln oder fixen? In-Reply-To: <19980204171311.34130@germany.sial.com>; from Felix von Leitner on Wed, Feb 04, 1998 at 05:13:11PM +0100 X-Mailer-Info: http://www.math.fu-berlin.de/~guckes/mutt/ --nh7xodEAoBMCZwgA Content-Type: application/pgp-encrypted Version: 1 --nh7xodEAoBMCZwgA Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.3i hIwDH8NrVijL5/UBBACpQkRWDZFQAgOfGZDVjWMCbE9SS2YBYXmEMAwnRdwp1CRG AZa139KPGzcfQKLaX58ihiHre12As7Y476sI9MZJgqGlZ+b+HrjnOha2YcZ6mF6J L1Qz4rZXdi8S7oAClVmNNDiPM9P9C6BkwS7Ro5WZjPNbllp08TVcJ6SUz8tMC4SM A7/W7lhX938JAQP/Yvf0GtKug3veE8vkN8tUAHdgE8s16Z49UMptYAaBmZ3sQYZb 2b6evjNj1uqz2HwbT553iEzcJol659NTxoG/k/F01+xmYVaiTT0zGCVCPIaiBk7K Cu0yECVPgNsvqBRFW3dhHj41JxGVqqpo87ur35gE8ZZ7EaLFriPNb+tVF3KmAAAB tvo/JLLj3V8ZPzcWF/rhHX8vP68BMYO36Ya12m2qIWT6d3VZdg6uDJgIR0gDHnLR rex6UmSZg5yxtqxPevCveZ6mdpLPgunyeC9xFtDapPd2MQgmFMYdXfa/v4DlcvKe jF0fc0tSfmhVuPwGsEx/KFvGQo3d9zJqBUkYtWbmVa8gv61swvP3a4LJg+ryozcf vazhLrugzTCGpbol5Lha6fRe+GWonr9ehJMsHqfZrTotbambr9SRe3SGv4RDN10o V4tIL///VfHajcgnZz6Nge9J+17s0d87PFL83l3M4bcMTn9prnC4EVdPhEKjZ7Qc vwKVy0DmA+Vzg+3ZmvFZ8UK/5LFgWZ5ZF2DLrNg+Z0mCWPRD8/5daLnbRCzi/hSy MfIXboxsT9fLrThSQNTB6GukYW5LdY62JwubCTKZXH2JIyPvQXvsuR4gp9c0++Kq nkbydpBeUC1MkH9Tyv7cPASxnwawLKlZiS8K33Ul4PxUN/FOqEduzi2l2WfEN9u5 7bAUuOivKD6NAKWalFQQ297zVLoj2jeWJcsbxMEWqFl+TtT4Nd9JDHaMWbtWswsE GYSfWwyxOg== =xEcQ -----END PGP MESSAGE----- --nh7xodEAoBMCZwgA-- ----- End forwarded message ----- --UlVJffcvxoiEqYs2-- --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNNifvB/Da1Yoy+f1AQHmhwP/TTxPNejF8oNM7XMK1ktXjRtmI9uRe0DJ rCAo/wTg9M+LRNRctJKrV9qrDVxBvZ2jpspu9NMKjzRlQaY41vBO8B/zfR1pHvIT F8TkGa8c63BdHHVj7JxKaJTMDosMjkAvaD3r56dayr2NYr4qILac3ao8NhSz6B12 4Ih38vpeoa4= =qsoQ -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP-- From reptile@pooh.cs.net.pl Wed Feb 4 09:47:30 1998 Return-Path: reptile@pooh.cs.net.pl Received: from pooh.cs.net.pl (qmailr@pooh.cs.net.pl [195.117.250.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id JAA28835 for ; Wed, 4 Feb 1998 09:47:26 -0800 (PST) Received: (qmail 6228 invoked by uid 501); 4 Feb 1998 17:49:53 -0000 Message-ID: <19980204184946.61290@pdi.net> Date: Wed, 4 Feb 1998 18:49:46 +0100 From: "Robert Richard George 'reptile' Wal" To: mutt-dev@cs.hmc.edu Subject: Re: [0.89] Feature alternative/header Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980128103541.45545@shell9.ba.best.com> <19980203142551.53488@spinnaker.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980203142551.53488@spinnaker.rhein.de>; from Roland Rosenfeld on Tue, Feb 03, 1998 at 02:25:51PM +0100 Organization: Me? Organized? Get real :) X-URL: http://pooh.cs.net.pl (Eternally under construction) X-IRC-Nick: Gadzinka@iRCnET.iRC.nETWORK (Gadzinka -- tiny little reptile) X-Phone: +48(0)42 593453 X-PGP-Fingerprint: 37E1D55F 29793C0C B8D39D01 61FC50CE X-PGP-Key: finger reptile@gryzmak.lodz.pdi.net X-Motto: Fact that you're paranoid doesn't imply that THEY don't follow you. X-Disclaimer: I don't answer mail or news articles below some arbitrary mark. X-Favourites: women, cats, Amiga, Linux, TeX, vim, music, sci-fi, poetry. X-Mount-Entry: mount -t human /dev/reptile /earth/europe/poland/warsaw On 98.02.03 Roland Rosenfeld pressed the following keys: > So I want to have a chance to define text/plain as the most liked > MIME-type. I tried by adding auto_view text/plain, but this results in > a message "auto_view using cat" (or similar) in _every_ message, and > that isn't what I want, too. > > Please switch back to the old behaviour or add a configuration option > to set a priority list, which defines what part should be handled with > priority in multipart/alternative. I second this idea! > BTW: I could remove text/html from auto_view, but this isn't what I > really want, because it would stop the chance to view a text/html part > of a multipart/mixed mail without entering the view-mode. Well, some time ago I started to use Mutt for news, because of it's MIME capabilities. IMHO no newsreader[1] can handle it better. I needed it, because of some brain damaged ppl unable to configure their software so it wouldn't use HTML on usenet. Several days ago I noticed, that the number of such individuals grew substantially. I didn't know what's wrong untill Roland noticed that now mutt chooses to show HTML part in multipart/alternative messages. I want to have the decission about precedence of parts in multipart/alternative, please :) Reptile [1] I don't want to start elephant like Emacs just to read mail and news -- mailto:reptile@pdi.net :) Women are more complicated than PC... :( Look into my headers and you'll see who I am. :) From roessler@sobolev.rhein.de Wed Feb 4 10:55:07 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id KAA05822 for ; Wed, 4 Feb 1998 10:55:05 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.8/8.8.5) with UUCP id TAA29132 for mutt-dev@cs.hmc.edu; Wed, 4 Feb 1998 19:45:22 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id TAA05740 ; Wed, 4 Feb 1998 19:40:42 +0100 Message-ID: <19980204194042.55095@sobolev.rhein.de> Date: Wed, 4 Feb 1998 19:40:42 +0100 From: Thomas Roessler To: "The mutt developpers' list" Subject: [0.90i] make_forward() problem Mail-Followup-To: The mutt developpers' list Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="ftEhullJWpWg/VHq" X-Mailer: Mutt 0.90i --ftEhullJWpWg/VHq Content-Type: multipart/mixed; boundary=KsGdsel6WgEHnImy --KsGdsel6WgEHnImy Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable When setting mime_fwd and trying to forward the attached message, the resulting attachment will look like this: ------------------------------ Mime-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: attachment; filename=3Dmutt-sobolev-5683-4 bla ------------------------------ I.e., all message headers are ignored. After moving the mime headers behind the To header, I get the following: ------------------------------ Message-ID: <199802041620.RAA08197@galera.icm.edu.pl> From: Rafal Wojtczuk Subject: An old ld-linux.so hole To: BUGTRAQ@NETSPACE.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Disposition: attachment; filename=3Dmutt-sobolev-5686-3 bla ------------------------------ Any ideas about where the bug may be? (And any ideas on how to get gdb breakpoints to work on a Linux 2.0.33 Pentium I with the f00f bugfix enabled?) tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=bugmail =46rom newsmaster Wed Feb 4 18:23:34 1998 MIME-Version: 1.0 Content-Type: text/plain; charset=3Dus-ascii Content-Transfer-Encoding: 8bit Message-ID: <199802041620.RAA08197@galera.icm.edu.pl> From: Rafal Wojtczuk Subject: An old ld-linux.so hole To: BUGTRAQ@NETSPACE.ORG Status: RO bla --KsGdsel6WgEHnImy-- --ftEhullJWpWg/VHq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNi2KNImKUTOasbBAQHWiAf/RDqZWZ9uBY46HsYNRTZHyFpGvWmArEop FgRODlU3ahbUYOQvD6OFI+Al9Rkn3CC453gEKbRs9RO7a/lsIP238crvyN+zDbeH mjwM6jaqHFPmIiulyKWW8JcvDL8IpzemdzwqX+XEYKvVL051kb4IiYPEfYVIhn2A 2RBJEgdApMUJTz9MzWl/PjbloGaJhzaJXexcbkg4UvG9XQaSi73RyRJR682yVjaL 8aO6WBPFYy4MuB1Q+BdBPKzBW7FPeMh97rGC960tb8ckF5a5URz5An7/Yu0Yw174 JHmN/NCqZFrbDC1DIyBzwKupakXmEWkIMR76Quxh/ZzAbLNa2Y5Msw== =cnSE -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From olsenc@ichips.intel.com Wed Feb 4 11:46:45 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id LAA10670 for ; Wed, 4 Feb 1998 11:46:43 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id LAA25804 for ; Wed, 4 Feb 1998 11:50:28 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id LAA25926 for ; Wed, 4 Feb 1998 11:46:37 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id LAA09572; Wed, 4 Feb 1998 11:46:37 -0800 (PST) Message-ID: <19980204114637.32580@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 11:46:37 -0800 From: Clint Olsen To: mutt-dev@turing.cs.hmc.edu Subject: [0.90i] core dump forwarding message Mail-Followup-To: mutt-dev@turing.cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! With a long recipient list. Changing it within the editor and returning to the compose menu results in a core. The core is useless. -Clint From mtsirkin@iil.intel.com Wed Feb 4 12:27:28 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA14806 for ; Wed, 4 Feb 1998 12:27:26 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id UAA06159 for ; Wed, 4 Feb 1998 20:27:24 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA11982 (5.65c+/IDA-1.4.4 for ); Wed, 4 Feb 1998 22:27:22 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA08146; Wed, 4 Feb 1998 22:27:22 +0200 Message-Id: <19980204222722.04779@iil.intel.com> Date: Wed, 4 Feb 1998 22:27:22 +0200 From: "Michael S. Tsirkin" To: MUTT Developers Subject: compressed folders patch Reply-To: "Michael S. Tsirkin" Mail-Followup-To: MUTT Developers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 X-Url: http://www.toptown.com/hp/mtsirkin Hello! The compressed folders patch is quite stable now - I sent it to mutt-users and so far no one complained of any bugs. Perhaps we may try to add it in the next devel release? Regards, mst -- This message content is not part of Intel's views or affairs Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; Home:+972-4-8283001; Work:+972-4-8655658; mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth) From sec@matrix.42.org Wed Feb 4 12:42:54 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id MAA16817 for ; Wed, 4 Feb 1998 12:42:38 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id VAA03755 (sender ); Wed, 4 Feb 1998 21:42:20 +0100 (CET) Message-ID: <19980204214219.62101@matrix.42.org> Date: Wed, 4 Feb 1998 21:42:19 +0100 From: Stefan `Sec` Zehl To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.89.1i In-Reply-To: <19980204222722.04779@iil.intel.com>; from Michael S. Tsirkin on Wed, Feb 04, 1998 at 10:27:22PM +0200 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Wed, Feb 04, 1998 at 10:27:22PM +0200, Michael S. Tsirkin wrote: > Hello! > The compressed folders patch is quite stable now -=20 > I sent it to mutt-users and so far no one complained of any bugs. > Perhaps we may try to add it in the next devel release? I hate doing this again, but..... I would not like to see that patch integrated. I think it's just wrong to this. It's too much bloat[t=08tm=08m], and makes the code even more unreadable. And, as a personal nitpick. The new mail detection is broken for me for quite some time now, and IIRC the last change there was the integration of your buffy-size. CU, Sec --=20 Du kannst in allen moeglichen Sprachen CGIs schreiben! Auch in Spanisch? ;-) Wenn du einen Spanisch-Compiler findest ... From olsenc@ichips.intel.com Wed Feb 4 13:39:48 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA24221 for ; Wed, 4 Feb 1998 13:39:47 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id NAA18868 for ; Wed, 4 Feb 1998 13:43:36 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id NAA06862 for ; Wed, 4 Feb 1998 13:39:45 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id NAA10091; Wed, 4 Feb 1998 13:39:45 -0800 (PST) Message-ID: <19980204133944.60630@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 13:39:44 -0800 From: Clint Olsen To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.90i In-Reply-To: <19980204214219.62101@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 09:42:19PM +0100 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 04, Stefan `Sec` Zehl wrote: >=20 > I hate doing this again, but..... >=20 > I would not like to see that patch integrated. I think it's just wrong to > this. It's too much bloat[t=08tm=08m], and makes the code even more > unreadable. And, as a personal nitpick. The new mail detection is broken > for me for quite some time now, and IIRC the last change there was the > integration of your buffy-size. Although I don't like to step on anyone's toes, I would have to agree with you on the compressed folders patch. I do not see the utility (inside Mutt) of being able to read compressed folders. As far as buffy goes, I've never enabled it. It doesn't seem to break new mail detection for me, unless you are referring to the mailboxes command (another feature I don't use). And another is this *hook stuff... This seems to frequently get broken from release to release. I can save and Fcc all on my own, thanks. -Clint (trying to avoid the Emacs of mailers) From michael@tis.com Wed Feb 4 13:45:28 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id NAA24706 for ; Wed, 4 Feb 1998 13:45:26 -0800 (PST) Received: by relay.la.tis.com; id NAA12332; Wed, 4 Feb 1998 13:50:34 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma012328; Wed, 4 Feb 98 13:50:21 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id NAA05223; Wed, 4 Feb 1998 13:36:19 -0800 (PST) Message-ID: <19980204133619.04472@la.tis.com> Date: Wed, 4 Feb 1998 13:36:19 -0800 From: Michael Elkins To: Mutt Development Mailing List Subject: Re: [0.89] segfaults Mail-Followup-To: Mutt Development Mailing List References: <19980203222721.41225@cs.brown.edu> <19980203195052.05554@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980203195052.05554@shell9.ba.best.com>; from Brandon Long on Tue, Feb 03, 1998 at 07:50:52PM -0800 On Tue, Feb 03, 1998 at 07:50:52PM -0800, Brandon Long wrote: > On 02/03/98 Don Blaheta uttered the following other thing: > > Date: Tue, 3 Feb 1998 22:27:21 -0500 > > From: Don Blaheta > > To: Mutt Development Mailing List > > Cc: Don Blaheta > > Subject: [0.89] segfaults > > Mail-Followup-To: Mutt Development Mailing List , > > Don Blaheta > > Hmm, looks like something wrong, Don's email address should be full in > the Mail-Followup-To: header, right? Yes. But this should be the responsibility of sendmail being that it looks like he's using `set nouse_from'. me From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 14:00:28 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA26521 for ; Wed, 4 Feb 1998 14:00:21 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA01476; Wed, 4 Feb 1998 17:00:15 -0500 (EST) Message-ID: <19980204170015.19377@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 17:00:15 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: Buffy problems? Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204214219.62101@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 09:42:19PM +0100 On Wed, Feb 04, 1998 at 09:42:19PM +0100, Stefan `Sec` Zehl wrote: > The new mail detection is broken > for me for quite some time now, and IIRC the last change there was the > integration of your buffy-size. How exactly does it fail? I haven't heard of anyone having problems for a while, but if there's a bug, we should try to fix it. I think that buffy_size adds some slightly messy ifdefs, but it's really not that bad, as a general thing. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From michael@tis.com Wed Feb 4 14:03:32 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA26690 for ; Wed, 4 Feb 1998 14:03:27 -0800 (PST) Received: by relay.la.tis.com; id OAA12965; Wed, 4 Feb 1998 14:14:34 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma012959; Wed, 4 Feb 98 14:14:16 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id OAA06110; Wed, 4 Feb 1998 14:00:13 -0800 (PST) Message-ID: <19980204140013.60254@la.tis.com> Date: Wed, 4 Feb 1998 14:00:13 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=C7zPtVaVf+AK4Oqc X-Mailer: Mutt 0.90.1i In-Reply-To: <19980203224935.33603@sdd.hp.com>; from David Ellement on Tue, Feb 03, 1998 at 10:49:35PM -0800 --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii On Tue, Feb 03, 1998 at 10:49:35PM -0800, David Ellement wrote: > I believe the difference due to the "address" used to match against the > pattern. Before this patch, the adress returned by mutt_simple_address > was used for the comparison. With this patch, the address returned by > rfc822_write_address is used for the comparison. > > The attached patch substitues mutt_simple_address for rfc822_write_address > in mutt_pattern_exec. > > I still see some strange matches for fcc-hooks, so there must be other > matching differences. You found the problem, but the difference you are seeing is probably due to the fact that with your patch it will only match the first address in each list. The following patch makes it match on all addresses in the list, so it should fix your fcc-hooks. me --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.addr_pattern.1" --- pattern.c.orig Wed Feb 4 13:41:23 1998 +++ pattern.c Wed Feb 4 13:55:29 1998 @@ -643,6 +643,19 @@ return 0; } +static int match_adrlist (regex_t *rx, ADDRESS *a) +{ + char buf[STRING]; + + for (; a; a = a->next) + { + mutt_simple_address (buf, sizeof (buf), a); + if (regexec (rx, buf, 0, NULL, 0) == 0) + return 1; + } + return 0; +} + int mutt_pattern_exec (struct pattern_t *pat, CONTEXT *ctx, HEADER *h) { char buf[STRING]; @@ -681,39 +694,21 @@ return (pat->not ^ msg_search (pat->rx, buf, sizeof (buf), 0, h->msgno)); case M_HEADER: return (pat->not ^ msg_search (pat->rx, buf, sizeof (buf), 1, h->msgno)); - default: - buf[0] = 0; - switch (pat->op) - { - case M_SENDER: - rfc822_write_address (buf, sizeof (buf), h->env->sender); - break; - case M_FROM: - rfc822_write_address (buf, sizeof (buf), h->env->from); - break; - case M_TO: - rfc822_write_address (buf, sizeof (buf), h->env->to); - break; - case M_CC: - rfc822_write_address (buf, sizeof (buf), h->env->cc); - break; - case M_SUBJECT: - if (h->env->subject) - strfcpy (buf, h->env->subject, sizeof (buf)); - break; - case M_ID: - if (h->env->message_id) - strfcpy (buf, h->env->message_id, sizeof (buf)); - break; - default: - mutt_error ("error: op type %d not implemented (report this error).", - pat->op); - return (-1); - } - return ((regexec (pat->rx, buf, 0, NULL, 0) == 0) ^ pat->not); + case M_SENDER: + return (pat->not ^ match_adrlist (pat->rx, h->env->sender)); + case M_FROM: + return (pat->not ^ match_adrlist (pat->rx, h->env->from)); + case M_TO: + return (pat->not ^ match_adrlist (pat->rx, h->env->to)); + case M_CC: + return (pat->not ^ match_adrlist (pat->rx, h->env->cc)); + case M_SUBJECT: + return (pat->not ^ (h->env->subject && regexec (pat->rx, h->env->subject, 0, NULL, 0) == 0)); + case M_ID: + return (pat->not ^ (h->env->message_id && regexec (pat->rx, h->env->message_id, 0, NULL, 0) == 0)); } - - /* not reached */ + mutt_error ("error: unknown op %d (report this error).", pat->op); + return (-1); } /* convert a simple search into a real request */ --C7zPtVaVf+AK4Oqc-- From sec@matrix.42.org Wed Feb 4 14:07:46 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA27411 for ; Wed, 4 Feb 1998 14:07:39 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id XAA04621 (sender ); Wed, 4 Feb 1998 23:07:20 +0100 (CET) Message-ID: <19980204230719.24019@matrix.42.org> Date: Wed, 4 Feb 1998 23:07:19 +0100 From: Stefan `Sec` Zehl To: Mutt Development Mailing List Subject: Re: [0.89] segfaults Mail-Followup-To: Mutt Development Mailing List References: <19980203222721.41225@cs.brown.edu> <19980203195052.05554@shell9.ba.best.com> <19980204133619.04472@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980204133619.04472@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 01:36:19PM -0800 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Wed, Feb 04, 1998 at 01:36:19PM -0800, Michael Elkins wrote: > > Hmm, looks like something wrong, Don's email address should be full in > > the Mail-Followup-To: header, right? > Yes. But this should be the responsibility of sendmail being that > it looks like he's using `set nouse_from'. Hm, that's probably correct so far, and then again, sendmail probalby doesn't know about the "Mail-Followup-To" header. so it doesn't know that it should rewite addresses contained in this header. What now ? CU, Sec -- telnet hundehalsband.georg.hunde.sonnenstrasse.muenchen.de Trying 942884947298374923847982472983.2398749874987249247.2398472372349. 3249782374927898324.2987238479874987398634.2987428901171209471.23987432923. 23478987923... Julien Oster zum Thema IPv6 From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 14:08:38 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA27467 for ; Wed, 4 Feb 1998 14:08:23 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA01707; Wed, 4 Feb 1998 17:08:19 -0500 (EST) Message-ID: <19980204170819.10018@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 17:08:19 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.90i In-Reply-To: <19980204214219.62101@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 09:42:19PM +0100 On Wed, Feb 04, 1998 at 09:42:19PM +0100, Stefan `Sec` Zehl wr= ote: > On Wed, Feb 04, 1998 at 10:27:22PM +0200, Michael S. Tsirkin wrote: > > Hello! > > The compressed folders patch is quite stable now -=20 > > I sent it to mutt-users and so far no one complained of any bugs. > > Perhaps we may try to add it in the next devel release? >=20 > I hate doing this again, but..... >=20 > I would not like to see that patch integrated. I think it's just wrong > to this. It's too much bloat[t=08tm=08m], and makes the code even more > unreadable. Have you looked at the patch? I can't speak to how great the stuff in compress.c is, not really having dealt with it, but the changes to the rest of the code are truly minimal. I think there is about one line of changes outside of the #ifdef's, and the #ifdef's are really pretty minimal too. So if this patch gets incorporated, and you don't configure with --enable-compressed, you should see no difference in bloat. And I don't think there's a significant difference in code readability either (again, I haven't read compress.c carefully, and there may or may not be problems there, but that's nicely separated from the rest of mutt.) So I think this patch should go in, because it's really useful for some people, and it doesn't noticeably mess up mutt for the people it's not useful for. -Daniel --=20 Daniel Eisenbud eisenbud@cs.swarthmore.edu From sec@matrix.42.org Wed Feb 4 14:12:13 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA27942 for ; Wed, 4 Feb 1998 14:11:38 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id XAA04748 (sender ); Wed, 4 Feb 1998 23:11:18 +0100 (CET) Message-ID: <19980204231117.48162@matrix.42.org> Date: Wed, 4 Feb 1998 23:11:17 +0100 From: Stefan `Sec` Zehl To: MUTT Developers Subject: Re: Buffy problems? Mail-Followup-To: MUTT Developers X-Current-Backlog: 234 messages References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980204170015.19377@cs.swarthmore.edu>; from Daniel Eisenbud on Wed, Feb 04, 1998 at 05:00:15PM -0500 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Wed, Feb 04, 1998 at 05:00:15PM -0500, Daniel Eisenbud wrote: > On Wed, Feb 04, 1998 at 09:42:19PM +0100, Stefan `Sec` Zehl wrote: > How exactly does it fail? I haven't heard of anyone having problems for > a while, but if there's a bug, we should try to fix it. I think that > buffy_size adds some slightly messy ifdefs, but it's really not that > bad, as a general thing. Hm, i mentioned it a few times. As soon as i save (from within mutt) a message to another mailbox (which is watched for new mail) mutt _instantly_ detects new mail in there. This is obviously wrong (and a quick 'c'hange to will confirm that there is no 'N'ew mail). This worked once (some time ago) and annoys me for some time now. If you could fix this (and at the same time not break anything else :-) I would be very gratefull :-) CU, Sec -- I apologise for the length of this message - Must've booted with the -vvv switch this morning ... From mtsirkin@iil.intel.com Wed Feb 4 14:33:33 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA00528 for ; Wed, 4 Feb 1998 14:33:28 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id WAA11364 for ; Wed, 4 Feb 1998 22:33:24 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA13566 (5.65c+/IDA-1.4.4 for ); Thu, 5 Feb 1998 00:33:22 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA08144; Thu, 5 Feb 1998 00:33:22 +0200 Message-Id: <19980205003322.31874@iil.intel.com> Date: Thu, 5 Feb 1998 00:33:22 +0200 From: "Michael S. Tsirkin" To: MUTT Developers Subject: Re: Buffy problems? Reply-To: "Michael S. Tsirkin" Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980204231117.48162@matrix.42.org>; from "sec@42.org" on Wed, Feb 04, 1998 at 11:11:17PM +0100 X-Url: http://www.toptown.com/hp/mtsirkin Hello! Quoting r. Stefan `Sec` Zehl (sec@42.org) "Re: Buffy problems?": > Hm, i mentioned it a few times. As soon as i save (from within mutt) a > message to another mailbox (which is watched for new mail) mutt > _instantly_ detects new mail in there. This is obviously wrong (and a > quick 'c'hange to will confirm that there is no 'N'ew mail). This worked > once (some time ago) and annoys me for some time now. If you could fix > this (and at the same time not break anything else :-) I would be very > gratefull :-) This problem is not related to buffy_size. Try enabling buffy_size - you won't have this problem :) The problem I think is that when you save to a file the mtime is changed, but atime is not. So mutt thinks there is a new mail there. I am not sure, on my AFS atime just doesn't work. mst -- This message content is not part of Intel's views or affairs Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; Home:+972-4-8283001; Work:+972-4-8655658; mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth) From mtsirkin@iil.intel.com Wed Feb 4 14:37:26 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA01157 for ; Wed, 4 Feb 1998 14:37:24 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id WAA11501 for ; Wed, 4 Feb 1998 22:37:22 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA23630 (5.65c+/IDA-1.4.4 for ); Thu, 5 Feb 1998 00:37:21 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA22792; Thu, 5 Feb 1998 00:37:20 +0200 Message-Id: <19980205003720.54018@iil.intel.com> Date: Thu, 5 Feb 1998 00:37:20 +0200 From: "Michael S. Tsirkin" To: MUTT Developers Subject: Re: compressed folders patch Reply-To: "Michael S. Tsirkin" Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.89 In-Reply-To: <19980204214219.62101@matrix.42.org>; from "sec@42.org" on Wed, Feb 04, 1998 at 09:42:19PM +0100 X-Url: http://www.toptown.com/hp/mtsirkin Hello! Quoting r. Stefan `Sec` Zehl (sec@42.org) "Re: compressed folders patch": > On Wed, Feb 04, 1998 at 10:27:22PM +0200, Michael S. Tsirkin wrote: > > Hello! > > The compressed folders patch is quite stable now -=20 > > I sent it to mutt-users and so far no one complained of any bugs. > > Perhaps we may try to add it in the next devel release? >=20 > I hate doing this again, but..... The last time I got a lot of useful criticism from (the late) Liviu, and I think all of it was taken into account. >=20 > I would not like to see that patch integrated. I think it's just wrong > to this.=20 Good argument. > It's too much bloat[t=08tm=08m],=20 You have to specifically enable it at compile time, and if you don't, no code bloat results. > and makes the code even more > unreadable.=20 Code outside compress.c is hardly changed at all. > And, as a personal nitpick. The new mail detection is broken > for me for quite some time now, and IIRC the last change there was the > integration of your buffy-size. As I said, enable buffy-size and be happy :) >=20 > CU, > Sec > --=20 > Du kannst in allen moeglichen Sprachen CGIs schreiben! > Auch in Spanisch? ;-) > Wenn du einen Spanisch-Compiler findest ... --=20 This message content is not part of Intel's views or affairs=0D Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; =0D Home:+972-4-8283001; Work:+972-4-8655658; =0D mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; =0D > Four things are to be strengthened: Torah,and good deeds,=0D > prayer and one's good manners (Berachoth)=0D From sec@matrix.42.org Wed Feb 4 14:39:44 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA01401 for ; Wed, 4 Feb 1998 14:39:31 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id XAA05043 (sender ); Wed, 4 Feb 1998 23:39:23 +0100 (CET) Message-ID: <19980204233922.57240@matrix.42.org> Date: Wed, 4 Feb 1998 23:39:22 +0100 From: Stefan `Sec` Zehl To: MUTT Developers Subject: Re: Buffy problems? Mail-Followup-To: MUTT Developers X-Current-Backlog: 237 messages References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> <19980205003322.31874@iil.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: Mutt 0.89.1i In-Reply-To: <19980205003322.31874@iil.intel.com>; from Michael S. Tsirkin on Thu, Feb 05, 1998 at 12:33:22AM +0200 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Thu, Feb 05, 1998 at 12:33:22AM +0200, Michael S. Tsirkin wrote: > Try enabling buffy_size - you won't have this problem :) >=20 > The problem I think is that when you save to a file the mtime is changed,= but > atime is not. So mutt thinks there is a new mail there. > I am not sure, on my AFS atime just doesn't work. This is on a local filesystem, it's not even exported via NFS. (because i fear locking and timestamp problems.) It is s=08su=08up=08pp=08po=08os=08se= =08ed=08d to work on an local filesystem. That's the way unix did it for years :) - If I wanted some other (fancy) detection code, i would swich to maildir or IMAP. CU, Sec --=20 telnet hundehalsband.georg.hunde.sonnenstrasse.muenchen.de Trying 942884947298374923847982472983.2398749874987249247.2398472372349. 3249782374927898324.2987238479874987398634.2987428901171209471.23987432923. 23478987923... Julien Oster zum Thema IPv6 From mtsirkin@iil.intel.com Wed Feb 4 14:41:55 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA01907 for ; Wed, 4 Feb 1998 14:41:53 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id WAA11686 for ; Wed, 4 Feb 1998 22:41:51 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA18123 (5.65c+/IDA-1.4.4 for ); Thu, 5 Feb 1998 00:41:49 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA22878; Thu, 5 Feb 1998 00:41:49 +0200 Message-Id: <19980205004149.11261@iil.intel.com> Date: Thu, 5 Feb 1998 00:41:49 +0200 From: "Michael S. Tsirkin" To: MUTT Developers Subject: Re: compressed folders patch Reply-To: "Michael S. Tsirkin" Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204133944.60630@dtthp169.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980204133944.60630@dtthp169.jf.intel.com>; from "olsenc@ichips.intel.com" on Wed, Feb 04, 1998 at 01:39:44PM -0800 X-Url: http://www.toptown.com/hp/mtsirkin Hello! Quoting r. Clint Olsen (olsenc@ichips.intel.com) "Re: compressed folders patch": > Although I don't like to step on anyone's toes, I would have to agree with > you on the compressed folders patch. I do not see the utility (inside > Mutt) of being able to read compressed folders. I would like to hear specific comments why. Note that currently there is no convenient way to do this - if mutt launches urlview, wy not gunzip? Did you look at the patch? Could oyu point out some concrete problems. > > As far as buffy goes, I've never enabled it. It doesn't seem to break new > mail detection for me, unless you are referring to the mailboxes command > (another feature I don't use). Well, obviously he is, and anyway buffy-size is for people with FS which does not have atime attribute working. > > And another is this *hook stuff... This seems to frequently get broken > from release to release. I can save and Fcc all on my own, thanks. > Well, one's most important feature is another's code bloat. > -Clint (trying to avoid the Emacs of mailers) What do you use? pico? :) (I know I know). mst -- This message content is not part of Intel's views or affairs Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; Home:+972-4-8283001; Work:+972-4-8655658; mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth) From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 14:44:33 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA02131 for ; Wed, 4 Feb 1998 14:44:28 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id RAA02408; Wed, 4 Feb 1998 17:44:26 -0500 (EST) Message-ID: <19980204174426.34784@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 17:44:26 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: Re: Buffy problems? Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204231117.48162@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 11:11:17PM +0100 On Wed, Feb 04, 1998 at 11:11:17PM +0100, Stefan `Sec` Zehl wrote: > On Wed, Feb 04, 1998 at 05:00:15PM -0500, Daniel Eisenbud wrote: > > On Wed, Feb 04, 1998 at 09:42:19PM +0100, Stefan `Sec` Zehl wrote: > > How exactly does it fail? I haven't heard of anyone having problems for > > a while, but if there's a bug, we should try to fix it. I think that > > buffy_size adds some slightly messy ifdefs, but it's really not that > > bad, as a general thing. > > Hm, i mentioned it a few times. As soon as i save (from within mutt) a > message to another mailbox (which is watched for new mail) mutt > _instantly_ detects new mail in there. This is obviously wrong (and a > quick 'c'hange to will confirm that there is no 'N'ew mail). This worked > once (some time ago) and annoys me for some time now. If you could fix > this (and at the same time not break anything else :-) I would be very > gratefull :-) That's actually not the fault of buffy_size, AFAIK. And I do know how to fix it, and it really annoys me too, and I just haven't had a chance yet. There are several slightly different options for fixing it, which I might as well ask people what they think of: 1) When saving to another folder, update the access time and modified time to the current time. This is what we used to do, but mx_get_magic resets the access time to what it was, so since we started using that, only the mod time gets updated. The drawback of this solution is that if you have a mailbox that has incoming messages, and you save a message to it, mutt can no longer tell that it has incoming messages. This is what used to happen, and nobody ever complained, but when I suggested changing it back to that a while ago, someone raised a ruckus. 2) We could just leave both the atime and the mtime alone when saving to a mailbox. This somehow feels wrong to me, and might possibly make backup software ignore your updated mailboxes, and things like that, since the mailbox will have been modified, but its attributes won't reflect that. 3a) When we save to a folder that has been modified more recently than it has been accessed, we update the mtime to the current time and the atime to one second before the current time. When the folder has been accessed at the same time or after it was last modified, we update both to the current time. 3b) When the folder has been accessed more recently than modified, we update both times to the current time; when it has been modified more recently than accessed, we leave the atime alone and update the mtime. I prefer solutions 3a and 3b. I guess 3b feels a little bit less like a hack to me, but I don't really think it makes much difference. Comments, please? (And no, I don't think that everybody using buffy_size is a particularly good solution.) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From sec@matrix.42.org Wed Feb 4 14:52:39 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA03107 for ; Wed, 4 Feb 1998 14:52:30 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id XAA05247 (sender ); Wed, 4 Feb 1998 23:52:08 +0100 (CET) Message-ID: <19980204235207.25788@matrix.42.org> Date: Wed, 4 Feb 1998 23:52:07 +0100 From: Stefan `Sec` Zehl To: MUTT Developers Subject: Re: Buffy problems? Mail-Followup-To: MUTT Developers X-Current-Backlog: 235 messages References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> <19980204174426.34784@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980204174426.34784@cs.swarthmore.edu>; from Daniel Eisenbud on Wed, Feb 04, 1998 at 05:44:26PM -0500 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Wed, Feb 04, 1998 at 05:44:26PM -0500, Daniel Eisenbud wrote: > That's actually not the fault of buffy_size, AFAIK. Okay, that might be, i really don't know it, but thats the only change i remember that happened in that 'piece of code' at the time it stopped working. > 3b) When the folder has been accessed more recently than modified, we > update both times to the current time; when it has been modified more > recently than accessed, we leave the atime alone and update the mtime. > > I prefer solutions 3a and 3b. I guess 3b feels a little bit less like a > hack to me, but I don't really think it makes much difference. I personally would prefer 3b. As it looks like DWIM[1] without that 'hackish' attribute that 3a has. On the other hand 2 seems pretty okay to me, too, as the mailbox timestamps will be updated on incoming mail/reading mail also. (and i for my part, dont do 'incremental' backups) CU, Sec -- +----------------------------------+ | Questions Are A Burden | | Answers Are A Prison For Oneself | +----------------------------------+ From michael@tis.com Wed Feb 4 14:53:57 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id OAA03262 for ; Wed, 4 Feb 1998 14:53:55 -0800 (PST) Received: by relay.la.tis.com; id PAA14107; Wed, 4 Feb 1998 15:05:04 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma014104; Wed, 4 Feb 98 15:05:01 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id OAA07027; Wed, 4 Feb 1998 14:50:59 -0800 (PST) Message-ID: <19980204145059.38391@la.tis.com> Date: Wed, 4 Feb 1998 14:50:59 -0800 From: Michael Elkins To: Mutt Development List Subject: [0.90i] bug: can't view-attach on signed messages w/o passphrase Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i If I tried to view-attachments on a PGP/MIME signed-only message, Mutt now asks me for my passphrase. It should not be necessary for signed messages. me From olsenc@ichips.intel.com Wed Feb 4 15:19:20 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id PAA06603 for ; Wed, 4 Feb 1998 15:19:17 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA12142 for ; Wed, 4 Feb 1998 15:23:07 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id PAA18007 for ; Wed, 4 Feb 1998 15:19:16 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id PAA11281; Wed, 4 Feb 1998 15:19:15 -0800 (PST) Message-ID: <19980204151915.02993@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 15:19:15 -0800 From: Clint Olsen To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204133944.60630@dtthp169.jf.intel.com> <19980205004149.11261@iil.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980205004149.11261@iil.intel.com>; from Michael S. Tsirkin on Thu, Feb 05, 1998 at 12:41:49AM +0200 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 05, Michael S. Tsirkin wrote: > > I would like to hear specific comments why. Note that currently there is > no convenient way to do this - if mutt launches urlview, wy not gunzip? > Did you look at the patch? Could oyu point out some concrete problems. I just never have run into a case where I have compressed folders. I think that putting the burden of filesystem management onto Mutt is excessive. It's less of a code bloat thing for me than a matter of principle. If you make in a configure option like you say, you won't hear any gripes from me :) > Well, one's most important feature is another's code bloat. Mutt has been a good compromise since there's compilation options, but I bet Michael will eventually put his foot down when the ifdef's make the code unmanageable. -Clint From michael@tis.com Wed Feb 4 15:19:31 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id PAA06624 for ; Wed, 4 Feb 1998 15:19:26 -0800 (PST) Received: by relay.la.tis.com; id PAA14491; Wed, 4 Feb 1998 15:30:34 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma014487; Wed, 4 Feb 98 15:30:28 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id PAA08504; Wed, 4 Feb 1998 15:16:25 -0800 (PST) Message-ID: <19980204151625.33267@la.tis.com> Date: Wed, 4 Feb 1998 15:16:25 -0800 From: Michael Elkins To: Mutt mailing list Subject: [0.90] bugfix: safe_path Mail-Followup-To: Mutt mailing list References: <19980204180500.49303@germany.sial.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=Dxnq1zWXvFF0Q93v X-Mailer: Mutt 0.90.1i In-Reply-To: <19980204180500.49303@germany.sial.com>; from Felix von Leitner on Wed, Feb 04, 1998 at 06:05:00PM +0100 --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii On Wed, Feb 04, 1998 at 06:05:00PM +0100, Felix von Leitner wrote: > Yes, I know that this mail is badly broken. > Mutt should not dump core on my no matter how broken my mails are. Try the attached patch. me --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.me.safe_path.1" --- lib.c~ Wed Feb 4 13:06:33 1998 +++ lib.c Wed Feb 4 15:15:04 1998 @@ -766,12 +766,14 @@ if (option (OPTSAVEADDRESS)) mutt_simple_address (s, l, a); - else + else if (a && a->mailbox) { strfcpy (s, a->mailbox, l); if ((p = strchr (s, '%'))) *p = 0; } + else + *s = 0; mutt_strlower (s); for (p = s; *p; p++) if (*p == '/' || ISSPACE (*p) || !IsPrint ((unsigned char) *p)) --Dxnq1zWXvFF0Q93v-- From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 16:01:11 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id QAA11164 for ; Wed, 4 Feb 1998 16:00:57 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id TAA03744; Wed, 4 Feb 1998 19:00:13 -0500 (EST) Message-ID: <19980204190013.65187@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 19:00:13 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: [0.90i] bug: can't view-attach on signed messages w/o passphrase Mail-Followup-To: Mutt Development List References: <19980204145059.38391@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204145059.38391@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 02:50:59PM -0800 On Wed, Feb 04, 1998 at 02:50:59PM -0800, Michael Elkins wrote: > If I tried to view-attachments on a PGP/MIME signed-only message, Mutt now > asks me for my passphrase. It should not be necessary for signed messages. Yeah, that happened to me earlier today too. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From olsenc@ichips.intel.com Wed Feb 4 17:10:41 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA19194 for ; Wed, 4 Feb 1998 17:10:40 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id RAA05626 for ; Wed, 4 Feb 1998 17:14:32 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id RAA29231 for ; Wed, 4 Feb 1998 17:10:40 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id RAA17416; Wed, 4 Feb 1998 17:10:39 -0800 (PST) Message-ID: <19980204171039.43489@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 17:10:39 -0800 From: Clint Olsen To: Mutt Development List Subject: Re: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> <19980204140013.60254@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980204140013.60254@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 02:00:13PM -0800 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 04, Michael Elkins wrote: > + mutt_simple_address (buf, sizeof (buf), a); Shouldn't this be mutt_check_simple? -Clint From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 17:14:52 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA19344 for ; Wed, 4 Feb 1998 17:14:49 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA05217; Wed, 4 Feb 1998 20:14:49 -0500 (EST) Message-ID: <19980204201449.36020@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 20:14:49 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: [0.90i] bugfix: buffy_times Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> <19980204174426.34784@cs.swarthmore.edu> <19980204235207.25788@matrix.42.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=y0ulUmNC+osPPQO6 X-Mailer: Mutt 0.90i In-Reply-To: <19980204235207.25788@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 11:52:07PM +0100 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii On Wed, Feb 04, 1998 at 11:52:07PM +0100, Stefan `Sec` Zehl wrote: > On Wed, Feb 04, 1998 at 05:44:26PM -0500, Daniel Eisenbud wrote: > > That's actually not the fault of buffy_size, AFAIK. > > Okay, that might be, i really don't know it, but thats the only change i > remember that happened in that 'piece of code' at the time it stopped > working. > > > 3b) When the folder has been accessed more recently than modified, we > > update both times to the current time; when it has been modified more > > recently than accessed, we leave the atime alone and update the mtime. > > > > I prefer solutions 3a and 3b. I guess 3b feels a little bit less like a > > hack to me, but I don't really think it makes much difference. > > I personally would prefer 3b. As it looks like DWIM[1] without that > 'hackish' attribute that 3a has. On the other hand 2 seems pretty okay > to me, too, as the mailbox timestamps will be updated on incoming > mail/reading mail also. (and i for my part, dont do 'incremental' > backups) 3b it is. Here's the patch. It seems to work. This will make mutt significantly nicer to use for me, as a matter of fact. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90i.de.buffy_times.1" --- mutt-0.90i.orig/protos.h Wed Feb 4 20:04:32 1998 +++ mutt-0.90i/protos.h Wed Feb 4 19:57:22 1998 @@ -143,7 +142,6 @@ int mutt_check_mime_type (const char *); int mutt_check_month (const char *); int mutt_check_overwrite (const char *, const char *, char *, size_t, int); int mutt_complete (char *); -int mutt_confirm_func (const char *); int mutt_copy_bytes (FILE *, FILE *, size_t); int mutt_copy_hdr (FILE *, FILE *, long, long, int); int mutt_copy_header (FILE *, HEADER *, FILE *, int); --- mutt-0.90i.orig/commands.c Wed Feb 4 20:04:32 1998 +++ mutt-0.90i/commands.c Wed Feb 4 20:12:12 1998 @@ -40,6 +40,8 @@ #include #include #include +#include +#include /* The folder the user last saved to. Used by ci_save_message() */ static char LastSaveFolder[_POSIX_PATH_MAX] = ""; @@ -452,13 +454,12 @@ void mutt_display_address (ADDRESS *adr) } /* returns 1 if OK to proceed, 0 to abort */ -int mutt_confirm_func (const char *s) +static int save_confirm_func (const char *s, struct stat *st) { char tmp[_POSIX_PATH_MAX]; - struct stat st; int ret = 1; - if (stat (s, &st) != -1) + if (stat (s, st) != -1) { if (mx_get_magic (s) == -1) { @@ -500,6 +501,13 @@ int mutt_save_message (HEADER *h, int de int chflags = decode ? CH_XMIT | CH_MIME : CH_UPDATE_LEN; char prompt[SHORT_STRING], buf[_POSIX_PATH_MAX]; CONTEXT ctx; + struct stat st; +#ifdef BUFFY_SIZE + BUFFY *tmp = NULL; +#else + struct utimbuf ut; +#endif + *redraw = 0; @@ -555,20 +563,16 @@ int mutt_save_message (HEADER *h, int de mutt_expand_path (buf, sizeof (buf)); /* check to make sure that this file is really the one the user wants */ - if (!mutt_confirm_func (buf)) + if (!save_confirm_func (buf, &st)) { CLEARLINE (LINES-1); return (-1); } mutt_message ("Copying to %s...", buf); - + if (mx_open_mailbox (buf, M_APPEND, &ctx) != NULL) { -#ifdef BUFFY_SIZE - BUFFY *tmp = NULL; -#endif - if (h) { if (decode) @@ -608,8 +612,20 @@ int mutt_save_message (HEADER *h, int de #ifdef BUFFY_SIZE if (tmp && tmp->new == 0) mutt_update_mailbox (tmp); +#else + /* fix up the times so buffy won't get confused */ + if (ctx.magic == M_MBOX || ctx.magic == M_MMDF) + { + if (st.st_mtime > st.st_atime) + { + ut.actime = st.st_atime; + ut.modtime = st.st_mtime; + utime (buf, &ut); + } + else + utime (buf, NULL); + } #endif - mutt_clear_error (); } --y0ulUmNC+osPPQO6-- From ellement@sdd.hp.com Wed Feb 4 17:26:02 1998 Return-Path: ellement@sdd.hp.com Received: from hpsdlo.sdd.hp.com (hpsdlo.sdd.hp.com [15.255.160.64]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA20769 for ; Wed, 4 Feb 1998 17:25:58 -0800 (PST) Received: from epgc352.sdd.hp.com (epgc352.sdd.hp.com [15.64.160.113]) by hpsdlo.sdd.hp.com (8.8.6/8.8.5tis+epg) with ESMTP id RAA03457 for ; Wed, 4 Feb 1998 17:24:26 -0800 (PST) Received: (from ellement@localhost) by epgc352.sdd.hp.com (8.7.6/8.7.3 TIS 5.0/sdd epg) id RAA26890; Wed, 4 Feb 1998 17:24:26 -0800 (PST) Message-ID: <19980204172425.46771@sdd.hp.com> Date: Wed, 4 Feb 1998 17:24:25 -0800 From: David Ellement To: Mutt Development List Subject: Re: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> <19980204140013.60254@la.tis.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=xHFwDpU9dbj6ez1V X-Mailer: Mutt 0.90i In-Reply-To: <19980204140013.60254@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 02:00:13PM -0800 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii On 980204, at 14:00:13, Michael Elkins wrote: > > You found the problem, but the difference you are seeing is probably due to > the fact that with your patch it will only match the first address in each > list. The following patch makes it match on all addresses in the list, so > it should fix your fcc-hooks. Now, on to removing the conflict with the new_addr patch. The attached patch seems to work ... -- David Ellement --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.dme.new_addr_pattern.1" --- pattern.c.orig Wed Feb 4 15:47:47 1998 +++ pattern.c Wed Feb 4 17:13:52 1998 @@ -579,14 +579,9 @@ static int match_adrlist (regex_t *rx, ADDRESS *a) { - char buf[STRING]; - for (; a; a = a->next) - { - mutt_simple_address (buf, sizeof (buf), a); - if (regexec (rx, buf, 0, NULL, 0) == 0) + if (regexec (rx, a->mailbox, 0, NULL, 0) == 0) return 1; - } return 0; } --xHFwDpU9dbj6ez1V-- From michael@tis.com Wed Feb 4 17:34:02 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA22325 for ; Wed, 4 Feb 1998 17:33:59 -0800 (PST) Received: by relay.la.tis.com; id RAA18135; Wed, 4 Feb 1998 17:45:05 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma018125; Wed, 4 Feb 98 17:44:43 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10094; Wed, 4 Feb 1998 17:30:39 -0800 (PST) Message-ID: <19980204173039.43051@la.tis.com> Date: Wed, 4 Feb 1998 17:30:39 -0800 From: Michael Elkins To: Mutt Development List Subject: Looking towards 1.0 Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i Being that we are now at release 0.90, I was sort of thinking about what a 1.0 release would look like. There are a few rough edges that I know still need to be worked out, but I wanted to get a feel from the rest of this group as to what you all think still needs to be done before going to `beta' mode (which would mean that no new features would go in, and we would just fix bugs for a while). What I am looking for is deficiencies that people believe need to be fixed for the 1.0 release. me From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 17:42:23 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA23224 for ; Wed, 4 Feb 1998 17:41:52 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA06016; Wed, 4 Feb 1998 20:41:48 -0500 (EST) Message-ID: <19980204204148.56366@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 20:41:48 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: Re: [0.90i] bugfix: buffy_times Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> <19980204174426.34784@cs.swarthmore.edu> <19980204235207.25788@matrix.42.org> <19980204201449.36020@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204201449.36020@cs.swarthmore.edu>; from Daniel Eisenbud on Wed, Feb 04, 1998 at 08:14:49PM -0500 On Wed, Feb 04, 1998 at 08:14:49PM -0500, Daniel Eisenbud wrote: > On Wed, Feb 04, 1998 at 11:52:07PM +0100, Stefan `Sec` Zehl wrote: > > On Wed, Feb 04, 1998 at 05:44:26PM -0500, Daniel Eisenbud wrote: > > > That's actually not the fault of buffy_size, AFAIK. > > > > Okay, that might be, i really don't know it, but thats the only change i > > remember that happened in that 'piece of code' at the time it stopped > > working. > > > > > 3b) When the folder has been accessed more recently than modified, we > > > update both times to the current time; when it has been modified more > > > recently than accessed, we leave the atime alone and update the mtime. > > > > > > I prefer solutions 3a and 3b. I guess 3b feels a little bit less like a > > > hack to me, but I don't really think it makes much difference. > > > > I personally would prefer 3b. As it looks like DWIM[1] without that > > 'hackish' attribute that 3a has. On the other hand 2 seems pretty okay > > to me, too, as the mailbox timestamps will be updated on incoming > > mail/reading mail also. (and i for my part, dont do 'incremental' > > backups) > > 3b it is. Here's the patch. It seems to work. This will make mutt > significantly nicer to use for me, as a matter of fact. The patch I just sent seems to work when saving to a nonexisting file, and creating a new one, but perhaps only by accident. :) Version two coming in a few minutes. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From michael@tis.com Wed Feb 4 17:46:00 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA23707 for ; Wed, 4 Feb 1998 17:45:57 -0800 (PST) Received: by relay.la.tis.com; id RAA18339; Wed, 4 Feb 1998 17:57:04 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma018329; Wed, 4 Feb 98 17:56:44 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10118; Wed, 4 Feb 1998 17:42:40 -0800 (PST) Message-ID: <19980204174240.57079@la.tis.com> Date: Wed, 4 Feb 1998 17:42:40 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> <19980204140013.60254@la.tis.com> <19980204171039.43489@dtthp169.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i In-Reply-To: <19980204171039.43489@dtthp169.jf.intel.com>; from Clint Olsen on Wed, Feb 04, 1998 at 05:10:39PM -0800 On Wed, Feb 04, 1998 at 05:10:39PM -0800, Clint Olsen wrote: > On Feb 04, Michael Elkins wrote: > > + mutt_simple_address (buf, sizeof (buf), a); > > Shouldn't this be mutt_check_simple? Nope. That piece of code is executed in mutt_pattern_exec(). mutt_check_simple() is only called when parsing limit/search/hook commands before calling mutt_pattern_comp(). me From michael@tis.com Wed Feb 4 17:46:58 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA23761 for ; Wed, 4 Feb 1998 17:46:56 -0800 (PST) Received: by relay.la.tis.com; id RAA18353; Wed, 4 Feb 1998 17:58:04 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma018347; Wed, 4 Feb 98 17:57:38 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10133; Wed, 4 Feb 1998 17:43:34 -0800 (PST) Message-ID: <19980204174333.18626@la.tis.com> Date: Wed, 4 Feb 1998 17:43:33 -0800 From: Michael Elkins To: Mutt Development List Subject: [Announce] Mutt 0.90.1 released (devel-only) Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0F1p//8PRICkK4MW" X-Mailer: Mutt 0.90.1i --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii This is a development-only release of Mutt. It can be found at ftp://ftp.cs.hmc.edu/pub/me/mutt/devel/mutt-0.90.1.tar.gz ftp://ftp.cs.hmc.edu/pub/me/mutt/devel/diff-0.90-0.90.1.gz Note that the `devel' subdirectories are NOT readable, but you can chdir to it and get the files. This is just so that random users poking around the ftp site do not find development versions since they are more likely to contains bugs. Please confine all comments on development releases to the mutt-dev mailing list in order to avoid confusing those only subscribed to the mutt-users mailing list. me --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=Changes Changes since 0.90 -------------------- - [patch-0.90.me.sort.2] $sort_aux is now used for all primary sorting methods - [patch-0.90i.me.pattern.1] extended date matching language (~d) to accept relative dates offset from the current date - [patch-0.90.me.thread_hash.3] modified threading algorithm to use hash tables instead of a linear search - [patch-0.90i.de.difftime.1] remove use of difftime() since it is not portable - [patch-0.89.1i.de-bj.buffy_sanity.1-2] cleanup of the buffy check routine - [patch-0.90.me.addr_pattern.1] fixed some problems with the address matching routines which caused problems for the send-hook and fcc-hook commands - the size of the temp buffer used to expand regexps into patterns in mutt_check_simple() was too short (SHORT_STRING) to handle the patterns for send-hook, save-hook and fcc-hook, so it was increased to LONG_STRING (1024) bytes - [patch-0.90.me.safe_path.1] fixed segfault when trying to save a message with no recipients - [patch-0.89i.de.index-percentage.1] adds `%P' to $status_format to display the percentage of the menu already seen (similar to the way the pager works) - [patch-0.89.1i.bj.pager-redraw-clenaup.1] fixed some redraw problems in the pager with $pager_index_lines set - [patch-0.89.1i.fp.filter.1] screen was not updated when filtering an attachment an the the cte changed --0F1p//8PRICkK4MW-- From steve@gbnet.net Wed Feb 4 17:49:19 1998 Return-Path: steve@gbnet.net Received: from ns.gbnet.net (qmailr@ns.gbnet.net [194.70.126.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id RAA24097 for ; Wed, 4 Feb 1998 17:49:15 -0800 (PST) Received: (qmail 5888 invoked by uid 100); 5 Feb 1998 01:46:15 -0000 Message-ID: <19980205014615.44640@gbnet.net> Date: Thu, 5 Feb 1998 01:46:15 +0000 From: Steve Kennedy To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 Organisation: NetTek Ltd On Wed, Feb 04, 1998 at 05:30:39PM -0800, Michael Elkins wrote: > Being that we are now at release 0.90, I was sort of thinking about what a > 1.0 release would look like. There are a few rough edges that I know still > need to be worked out, but I wanted to get a feel from the rest of this > group as to what you all think still needs to be done before going to > `beta' mode (which would mean that no new features would go in, and we would > just fix bugs for a while). > What I am looking for is deficiencies that people believe need to be fixed > for the 1.0 release. IMAP support, oh and LDAP support ;) LDAP should be relatively straight forward (if somebody does the windowing) as much of the code can be taken from the University of Michigan's ldap-3.3 code (includes a libldap, or using their text based UD program). Steve -- NetTek Ltd tel +44-171 483 1169 fax +44-181 444 6103 Flat 2, 43 Howitt Road, Belsize Park, London NW3 4LU [ IndiNIC info - please email indinic@gbnet.net ] From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 17:53:55 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA24525 for ; Wed, 4 Feb 1998 17:53:48 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA06297; Wed, 4 Feb 1998 20:53:33 -0500 (EST) Message-ID: <19980204205333.13554@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 20:53:33 -0500 From: Daniel Eisenbud To: MUTT Developers Subject: [0.90i] bugfix: buffy_times #2 Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170015.19377@cs.swarthmore.edu> <19980204231117.48162@matrix.42.org> <19980204174426.34784@cs.swarthmore.edu> <19980204235207.25788@matrix.42.org> <19980204201449.36020@cs.swarthmore.edu> <19980204204148.56366@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=CE+1k2dSO48ffgeK X-Mailer: Mutt 0.90i In-Reply-To: <19980204204148.56366@cs.swarthmore.edu>; from Daniel Eisenbud on Wed, Feb 04, 1998 at 08:41:48PM -0500 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii On Wed, Feb 04, 1998 at 08:41:48PM -0500, Daniel Eisenbud wrote: > The patch I just sent seems to work when saving to a nonexisting file, > and creating a new one, but perhaps only by accident. :) Version two > coming in a few minutes. Here's a fixed version. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90i.de.buffy_times.1-2" --- mutt-0.90i.orig/commands.c Wed Feb 4 20:48:16 1998 +++ mutt-0.90i/commands.c Wed Feb 4 20:46:39 1998 @@ -24,6 +24,7 @@ #include "mailbox.h" #include "state.h" #include "copy.h" +#include "mx.h" #ifdef _PGPPATH #include "pgp.h" @@ -31,7 +32,6 @@ #ifdef BUFFY_SIZE #include "buffy.h" -#include "mx.h" #endif #include @@ -474,19 +474,25 @@ static int save_confirm_func (const char ret = 0; } } - else if (errno == ENOENT) + else { - if (option (OPTCONFIRMCREATE)) + st->st_mtime = 0; + st->st_atime = 0; + + if (errno == ENOENT) { - snprintf (tmp, sizeof (tmp), "Create %s?", s); - if (mutt_yesorno (tmp, 1) < 1) - ret = 0; + if (option (OPTCONFIRMCREATE)) + { + snprintf (tmp, sizeof (tmp), "Create %s?", s); + if (mutt_yesorno (tmp, 1) < 1) + ret = 0; + } + } + else + { + mutt_perror (s); + return 0; } - } - else - { - mutt_perror (s); - return 0; } CLEARLINE (LINES-1); --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90i.de.buffy_times.2" diff -durp mutt-0.90i.orig/commands.c mutt-0.90i.new/commands.c --- mutt-0.90i.orig/commands.c Tue Feb 3 04:43:48 1998 +++ mutt-0.90i.new/commands.c Wed Feb 4 20:50:18 1998 @@ -24,6 +24,7 @@ #include "mailbox.h" #include "state.h" #include "copy.h" +#include "mx.h" #ifdef _PGPPATH #include "pgp.h" @@ -31,7 +32,6 @@ #ifdef BUFFY_SIZE #include "buffy.h" -#include "mx.h" #endif #include @@ -40,6 +40,8 @@ #include #include #include +#include +#include /* The folder the user last saved to. Used by ci_save_message() */ static char LastSaveFolder[_POSIX_PATH_MAX] = ""; @@ -452,13 +454,12 @@ void mutt_display_address (ADDRESS *adr) } /* returns 1 if OK to proceed, 0 to abort */ -int mutt_confirm_func (const char *s) +static int save_confirm_func (const char *s, struct stat *st) { char tmp[_POSIX_PATH_MAX]; - struct stat st; int ret = 1; - if (stat (s, &st) != -1) + if (stat (s, st) != -1) { if (mx_get_magic (s) == -1) { @@ -473,19 +474,25 @@ int mutt_confirm_func (const char *s) ret = 0; } } - else if (errno == ENOENT) + else { - if (option (OPTCONFIRMCREATE)) + st->st_mtime = 0; + st->st_atime = 0; + + if (errno == ENOENT) { - snprintf (tmp, sizeof (tmp), "Create %s?", s); - if (mutt_yesorno (tmp, 1) < 1) - ret = 0; + if (option (OPTCONFIRMCREATE)) + { + snprintf (tmp, sizeof (tmp), "Create %s?", s); + if (mutt_yesorno (tmp, 1) < 1) + ret = 0; + } + } + else + { + mutt_perror (s); + return 0; } - } - else - { - mutt_perror (s); - return 0; } CLEARLINE (LINES-1); @@ -500,6 +507,13 @@ int mutt_save_message (HEADER *h, int de int chflags = decode ? CH_XMIT | CH_MIME : CH_UPDATE_LEN; char prompt[SHORT_STRING], buf[_POSIX_PATH_MAX]; CONTEXT ctx; + struct stat st; +#ifdef BUFFY_SIZE + BUFFY *tmp = NULL; +#else + struct utimbuf ut; +#endif + *redraw = 0; @@ -555,20 +569,16 @@ int mutt_save_message (HEADER *h, int de mutt_expand_path (buf, sizeof (buf)); /* check to make sure that this file is really the one the user wants */ - if (!mutt_confirm_func (buf)) + if (!save_confirm_func (buf, &st)) { CLEARLINE (LINES-1); return (-1); } mutt_message ("Copying to %s...", buf); - + if (mx_open_mailbox (buf, M_APPEND, &ctx) != NULL) { -#ifdef BUFFY_SIZE - BUFFY *tmp = NULL; -#endif - if (h) { if (decode) @@ -608,8 +618,20 @@ int mutt_save_message (HEADER *h, int de #ifdef BUFFY_SIZE if (tmp && tmp->new == 0) mutt_update_mailbox (tmp); +#else + /* fix up the times so buffy won't get confused */ + if (ctx.magic == M_MBOX || ctx.magic == M_MMDF) + { + if (st.st_mtime > st.st_atime) + { + ut.actime = st.st_atime; + ut.modtime = st.st_mtime; + utime (buf, &ut); + } + else + utime (buf, NULL); + } #endif - mutt_clear_error (); } diff -durp mutt-0.90i.orig/protos.h mutt-0.90i.new/protos.h --- mutt-0.90i.orig/protos.h Tue Feb 3 04:43:53 1998 +++ mutt-0.90i.new/protos.h Wed Feb 4 20:48:16 1998 @@ -143,7 +143,6 @@ int mutt_check_mime_type (const char *); int mutt_check_month (const char *); int mutt_check_overwrite (const char *, const char *, char *, size_t, int); int mutt_complete (char *); -int mutt_confirm_func (const char *); int mutt_copy_bytes (FILE *, FILE *, size_t); int mutt_copy_hdr (FILE *, FILE *, long, long, int); int mutt_copy_header (FILE *, HEADER *, FILE *, int); --CE+1k2dSO48ffgeK-- From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 17:56:33 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA24694 for ; Wed, 4 Feb 1998 17:56:29 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id UAA06355; Wed, 4 Feb 1998 20:56:26 -0500 (EST) Message-ID: <19980204205626.61815@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 20:56:26 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 On Wed, Feb 04, 1998 at 05:30:39PM -0800, Michael Elkins wrote: > Being that we are now at release 0.90, I was sort of thinking about what a > 1.0 release would look like. There are a few rough edges that I know still > need to be worked out, but I wanted to get a feel from the rest of this > group as to what you all think still needs to be done before going to > `beta' mode (which would mean that no new features would go in, and we would > just fix bugs for a while). > > What I am looking for is deficiencies that people believe need to be fixed > for the 1.0 release. Hmm... I actually think it's pretty ready, with some more testing and bug fixing. What else do you think needs to go in? And could you maybe put back the TODO file, which somehow left the distribution? -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From michael@tis.com Wed Feb 4 18:00:06 1998 Return-Path: michael@tis.com Received: from relay.la.tis.com (firewall-user@relay.la.tis.com [198.51.22.11]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id RAA25175 for ; Wed, 4 Feb 1998 17:59:57 -0800 (PST) Received: by relay.la.tis.com; id SAA18531; Wed, 4 Feb 1998 18:11:04 -0800 (PST) Received: from gila.la.tis.com(192.5.49.200) by relay.la.tis.com via smap (3.2) id xma018526; Wed, 4 Feb 98 18:10:45 -0800 Received: (from michael@localhost) by gila.la.tis.com (8.8.7/8.8.7) id RAA10158; Wed, 4 Feb 1998 17:56:41 -0800 (PST) Message-ID: <19980204175640.19599@la.tis.com> Date: Wed, 4 Feb 1998 17:56:40 -0800 From: Michael Elkins To: Mutt Development List Subject: Re: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> <19980204140013.60254@la.tis.com> <19980204172425.46771@sdd.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i In-Reply-To: <19980204172425.46771@sdd.hp.com>; from David Ellement on Wed, Feb 04, 1998 at 05:24:25PM -0800 On Wed, Feb 04, 1998 at 05:24:25PM -0800, David Ellement wrote: > + if (regexec (rx, a->mailbox, 0, NULL, 0) == 0) That should be if (a->mailbox && regexec (rx, a->mailbox, 0, NULL, 0) == 0) or else you will get a segfault on group addresses (since ->mailbox will be NULL). me From blong@shell9.ba.best.com Wed Feb 4 18:05:18 1998 Return-Path: blong@shell9.ba.best.com Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id SAA25621 for ; Wed, 4 Feb 1998 18:05:15 -0800 (PST) Received: (from blong@localhost) by shell9.ba.best.com (8.8.8/8.8.BEST) id SAA20235; Wed, 4 Feb 1998 18:05:08 -0800 (PST) Message-ID: <19980204180508.27380@shell9.ba.best.com> Date: Wed, 4 Feb 1998 18:05:08 -0800 From: Brandon Long To: Mutt Development List Subject: Re: Looking towards 1.0 Reply-To: blong@fiction.net Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980205014615.44640@gbnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980205014615.44640@gbnet.net>; from Steve Kennedy on Thu, Feb 05, 1998 at 01:46:15AM +0000 Organization: Fiction L Networks X-Pgp-Public-Key: X-Uri: On 02/05/98 Steve Kennedy uttered the following other thing: > On Wed, Feb 04, 1998 at 05:30:39PM -0800, Michael Elkins wrote: > > > Being that we are now at release 0.90, I was sort of thinking about what a > > 1.0 release would look like. There are a few rough edges that I know still > > need to be worked out, but I wanted to get a feel from the rest of this > > group as to what you all think still needs to be done before going to > > `beta' mode (which would mean that no new features would go in, and we would > > just fix bugs for a while). > > What I am looking for is deficiencies that people believe need to be fixed > > for the 1.0 release. > > IMAP support, oh and LDAP support ;) For IMAP support, we probably really need a developer who is using IMAP. > LDAP should be relatively straight forward (if somebody does the windowing) > as much of the code can be taken from the University of Michigan's ldap-3.3 > code (includes a libldap, or using their text based UD program). I'd rather see a generic interface for directory lookups so one could use whatever one has available (ph, ldap, whatever the local wacky variant is). I would imagine it would require a prompt for a search string, and a way of parsing the replies into a menu (one could even argue just for a list of addresses, and if you want a menu, put it in the directory script). Brandon -- Brandon Long "Power Ennobles. Absolute power ennobles absolutely." MD6 Crash Test Dummy -- Harlan Ellison Intel Corporation I'm too low on the totem pole to speak for Intel. http://www.fiction.net/blong/ From blong@shell9.ba.best.com Wed Feb 4 18:16:14 1998 Return-Path: blong@shell9.ba.best.com Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id SAA26687 for ; Wed, 4 Feb 1998 18:16:13 -0800 (PST) Received: (from blong@localhost) by shell9.ba.best.com (8.8.8/8.8.BEST) id SAA22263; Wed, 4 Feb 1998 18:15:27 -0800 (PST) Message-ID: <19980204181526.19858@shell9.ba.best.com> Date: Wed, 4 Feb 1998 18:15:26 -0800 From: Brandon Long To: Mutt Development List Subject: Re: Looking towards 1.0 Reply-To: blong@fiction.net Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 Organization: Fiction L Networks X-Pgp-Public-Key: X-Uri: On 02/04/98 Michael Elkins uttered the following other thing: > Being that we are now at release 0.90, I was sort of thinking about what a > 1.0 release would look like. There are a few rough edges that I know still > need to be worked out, but I wanted to get a feel from the rest of this > group as to what you all think still needs to be done before going to > `beta' mode (which would mean that no new features would go in, and we would > just fix bugs for a while). > > What I am looking for is deficiencies that people believe need to be fixed > for the 1.0 release. My personal todo list: ToDo: - Started: + Done: * Mutt + Delete Attachment - mailcap - how we handle x-unknown (ie, x-unknown/x-X-Sun-Attachment) - setting MM_ env vars when exec'ing mailcap viewers (see metamail (1)) - config list for multipart/alternative order preference - default type for new messages (ie, text/html or text/enriched) - method to send message/digest messages - method for composing multipart messages - next page past end attachment should lead to next attachment - edit charset when sending - have mutt guess new content-type based on new file name + use compose and composecommand entries from mailcap for new attachments - editing of parameters of an attachment? (set when create with composecommand, but how to edit?) - handle reply of attachments (ie, include non-text attachments) -- Brandon Long "There is no single, correct pathway on the web, Fiction Networks or in life. Mistrust anybody who tells you so." -- James Burke, _The Pinball Effect_ blong@fiction.net http://www.fiction.net/blong/ From eisenbud@allspice.cs.swarthmore.edu Wed Feb 4 19:12:46 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA02022 for ; Wed, 4 Feb 1998 19:12:42 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id WAA07866; Wed, 4 Feb 1998 22:12:35 -0500 (EST) Message-ID: <19980204221235.15874@cs.swarthmore.edu> Date: Wed, 4 Feb 1998 22:12:35 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980204205626.61815@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204205626.61815@cs.swarthmore.edu>; from Daniel Eisenbud on Wed, Feb 04, 1998 at 08:56:26PM -0500 On Wed, Feb 04, 1998 at 08:56:26PM -0500, Daniel Eisenbud wrote: > On Wed, Feb 04, 1998 at 05:30:39PM -0800, Michael Elkins wrote: > > Being that we are now at release 0.90, I was sort of thinking about what a > > 1.0 release would look like. There are a few rough edges that I know still > > need to be worked out, but I wanted to get a feel from the rest of this > > group as to what you all think still needs to be done before going to > > `beta' mode (which would mean that no new features would go in, and we would > > just fix bugs for a while). > > > > What I am looking for is deficiencies that people believe need to be fixed > > for the 1.0 release. > > Hmm... I actually think it's pretty ready, with some more testing and > bug fixing. What else do you think needs to go in? And could you maybe > put back the TODO file, which somehow left the distribution? On second thought, there are some threading improvements that I want to do (as I've mentioned before.) And I want to make it possible to highlight just the message number as a cursor (I thought of a much better way to do it than my previous patch) to save screen space and redraw time at the same time. And now that we have the whole hook pattern thing in place, it might be feasible to colorize the index in a fairly simple and easy way, which I may try my hand at. And I want to get Liviu's mh_check patch fixed and installed, because that will make using MH and maildir folders as safe and pleasant as using mbox is now. Speaking of which, mbox_check is a bit buggy. I can't remember exactly what triggers the problem, but I have it written down somewhere, and it's on my list of things to fix. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From ellement@sdd.hp.com Wed Feb 4 19:25:33 1998 Return-Path: ellement@sdd.hp.com Received: from hpsdlo.sdd.hp.com (hpsdlo.sdd.hp.com [15.255.160.64]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id TAA03540 for ; Wed, 4 Feb 1998 19:25:30 -0800 (PST) Received: from epgc352.sdd.hp.com (epgc352.sdd.hp.com [15.64.160.113]) by hpsdlo.sdd.hp.com (8.8.6/8.8.5tis+epg) with ESMTP id TAA26839 for ; Wed, 4 Feb 1998 19:25:27 -0800 (PST) Received: (from ellement@localhost) by epgc352.sdd.hp.com (8.7.6/8.7.3 TIS 5.0/sdd epg) id TAA29113; Wed, 4 Feb 1998 19:25:26 -0800 (PST) Message-ID: <19980204192526.14175@sdd.hp.com> Date: Wed, 4 Feb 1998 19:25:26 -0800 From: David Ellement To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 On 980204, at 17:30:39, Michael Elkins wrote: > > What I am looking for is deficiencies that people believe need to be fixed > for the 1.0 release. deficiencies: no help menu for search pattern wish list: delete(/save/copy) attachments in the attachement menu (for consistancy with the index, save would delete an attachement) order tagged messages for inclusion in reply to current message -- David Ellement From dunc@tibble.omen.com.au Wed Feb 4 19:29:06 1998 Return-Path: dunc@tibble.omen.com.au Received: from tibble.omen.com.au (qmailr@tibble.omen.com.au [203.55.57.65]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id TAA03877 for ; Wed, 4 Feb 1998 19:28:45 -0800 (PST) Received: (qmail 974 invoked by uid 1000); 5 Feb 1998 03:29:20 -0000 Message-ID: <19980205112920.06230@ucc.gu.uwa.edu.au> Date: Thu, 5 Feb 1998 11:29:20 +0800 From: Duncan Sargeant To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 Michael Elkins wrote on Wed February 04, at 17:30 -0800: > Being that we are now at release 0.90, I was sort of thinking about what a > 1.0 release would look like. There are a few rough edges that I know still > need to be worked out, but I wanted to get a feel from the rest of this > group as to what you all think still needs to be done before going to > `beta' mode (which would mean that no new features would go in, and we would > just fix bugs for a while). > > What I am looking for is deficiencies that people believe need to be fixed > for the 1.0 release. I haven't gotten into the mutt-dev thing for quite a while, but here's what I had on an old TODO list. My comments today are after the hyphens. . OS/2 port - argh. Don't use OS/2 too much at home anymore, but I want to get this out the door. maybe. (half done) . mailing API - at some point I had a look and decided it reeked and I wanted to fix it. . buffy cleanup - I think Daniel and Michael Tsirkin have done lots here? . key binding cleanup . attachments cleanup (boggle, don't remember much about them. I'll review) *** . semi-sync - sync without deleting deleted mail. I have it sitting around half done. . being able to attach message/rfc822 from compose menu - this is a biggie. . Print an error if sendmail stuffs up - this one too. . generic mailbox driver - I wanted a more OO approach, thought it was possible before, I'll have to revisit it sometime. . alien folder support - stem out of a generic mailbox driver and be remarkably similar to MT's compressed folders. Hopefully I can get back into mutt sometime soon and work on these. I'd really like to see the last 5 in mutt 1.0 Oh and last and definately not least, I'd really like to see a Tips and Tricks type document go with mutt, or be in the docs. There are heaps out there which we take for granted. OK, very last would be to make that damn manual.sgml more accessible! A man page may not be practical, but how about generating info pages in a make install? ;-) cheers ,dunc -- Duncan Sargeant - dunc@rcpt.to - http://www.ucc.gu.uwa.edu.au/~dunc/ `Local hunters and fishermen begun to report some oddities. Fish without eyes. A two-headed bird. A nine-legged frog, which I actually saw. I decided it was time to get involved.' - C. Beasley Jr., The dirty history of nuclear power. From blong@shell9.ba.best.com Wed Feb 4 20:16:18 1998 Return-Path: blong@shell9.ba.best.com Received: from shell9.ba.best.com (root@shell9.ba.best.com [206.184.139.140]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA10215 for ; Wed, 4 Feb 1998 20:16:16 -0800 (PST) Received: (from blong@localhost) by shell9.ba.best.com (8.8.8/8.8.BEST) id UAA18515; Wed, 4 Feb 1998 20:15:21 -0800 (PST) Message-ID: <19980204201521.63929@shell9.ba.best.com> Date: Wed, 4 Feb 1998 20:15:21 -0800 From: Brandon Long To: Mutt Development List Subject: Re: Looking towards 1.0 Reply-To: blong@fiction.net Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980205112920.06230@ucc.gu.uwa.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: <19980205112920.06230@ucc.gu.uwa.edu.au>; from Duncan Sargeant on Thu, Feb 05, 1998 at 11:29:20AM +0800 Organization: Fiction L Networks X-Pgp-Public-Key: X-Uri: On 02/05/98 Duncan Sargeant uttered the following other thing: > > OK, very last would be to make that damn manual.sgml more accessible! A > man page may not be practical, but how about generating info pages in a > make install? ;-) Um, how are info file more accessible? Brandon -- Brandon Long "They that can give up essential liberty to obtain a little MD6 Crash Test Dummy temporary safety deserve neither liberty nor safety." Intel Corporation -- Benjamin Franklin I'm too low on the totem pole to speak for Intel. http://www.fiction.net/blong/ From mj@aurora.rose.hp.com Wed Feb 4 20:18:50 1998 Return-Path: mj@aurora.rose.hp.com Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA10378 for ; Wed, 4 Feb 1998 20:18:49 -0800 (PST) Received: from aurora.rose.hp.com (mj@aurora.rose.hp.com [15.43.209.80]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id UAA03950 for ; Wed, 4 Feb 1998 20:18:46 -0800 (PST) Received: (from mj@localhost) by aurora.rose.hp.com (8.7.6/8.7.1) id UAA18373; Wed, 4 Feb 1998 20:18:06 -0800 (PST) Message-ID: <19980204201805.05396@aurora.rose.hp.com> Date: Wed, 4 Feb 1998 20:18:05 -0800 From: Mun Johl To: MUTT Developers Subject: Re: compressed folders patch Reply-To: mj@core.rose.hp.com Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980204214219.62101@matrix.42.org>; from Stefan `Sec` Zehl on Wed, Feb 04, 1998 at 09:42:19PM +0100 Company: Hewlett-Packard Company Division: Enterprise Storage Solutions Division Organization: System Interconnect Lab (Roseville, CA) Well, I like it. I have archives of mbox's, which I now gzip and save a bunch of space. With the patch, I can easily open up the mbox and access the mail. Sure, I could do the same with an external script, but since the feature doesn't have to be enabled, I say ship it. On Wed, Feb 04, 1998 at 12:42 PM PST, Stefan `Sec` Zehl wrote: > On Wed, Feb 04, 1998 at 10:27:22PM +0200, Michael S. Tsirkin wrote: > > Hello! > > The compressed folders patch is quite stable now - > > I sent it to mutt-users and so far no one complained of any bugs. > > Perhaps we may try to add it in the next devel release? So, has the patch for 0.90.1 been posted? I never saw the one for 0.90 for some reason either. -- _ _ _ ___ _ ' ) ) ) ( > / // Mun Johl / / / . . ____ __/______/_ // mj@core.rose.hp.com / ' (_(_/_/ / <_ / / (_) / /_; Wed, 4 Feb 1998 20:40:58 -0800 (PST) Received: from infinity.cc.umr.edu (infinity.cc.umr.edu [131.151.37.9]) via ESMTP by hermes.cc.umr.edu (8.8.7/R.4.20) id WAA15899; Wed, 4 Feb 1998 22:40:58 -0600 (CST) Received: from (nneul@localhost) by infinity.cc.umr.edu (8.8.6/M.3.01) id WAA19972; Wed, 4 Feb 1998 22:40:57 -0600 Message-ID: <19980204224057.07875@umr.edu> Date: Wed, 4 Feb 1998 22:40:57 -0600 From: Nathan Neulinger To: Mutt Development List Subject: Re: Looking towards 1.0 References: <19980204173039.43051@la.tis.com> <19980205112920.06230@ucc.gu.uwa.edu.au> <19980204201521.63929@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980204201521.63929@shell9.ba.best.com>; from Brandon Long on Wed, Feb 04, 1998 at 08:15:21PM -0800 On Wed, Feb 04, 1998 at 08:15:21PM -0800, Brandon Long wrote: > On 02/05/98 Duncan Sargeant uttered the following other thing: > > > > OK, very last would be to make that damn manual.sgml more accessible! A > > man page may not be practical, but how about generating info pages in a > > make install? ;-) > > Um, how are info file more accessible? No kidding. I kindof feel about the info browser about the same as I feel about old WordPerfect for dos without the menus. My only way of getting out of that beast was the three-finger-salute. (Never did learn the function keys.) I wouldn't mind if the html version of the manual were included, or at least in a tar'd form on the ftp site. (Not that it matters, I have the sgml tools to generate it from source, but alot of people don't.) -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul@umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 From olsenc@ichips.intel.com Wed Feb 4 20:51:15 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id UAA13523 for ; Wed, 4 Feb 1998 20:51:11 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id UAA02948 for ; Wed, 4 Feb 1998 20:55:03 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id UAA10897 for ; Wed, 4 Feb 1998 20:51:09 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id UAA27860; Wed, 4 Feb 1998 20:51:08 -0800 (PST) Message-ID: <19980204205108.48478@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 20:51:08 -0800 From: Clint Olsen To: Mutt Development List Subject: Re: [0.90] bugfix: addr_pattern Mail-Followup-To: Mutt Development List References: <19980126130057.27937@turing.cs.hmc.edu> <19980129212710.49589@sdd.hp.com> <19980129230323.25189@la.tis.com> <19980203224935.33603@sdd.hp.com> <19980204140013.60254@la.tis.com> <19980204171039.43489@dtthp169.jf.intel.com> <19980204174240.57079@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204174240.57079@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:42:40PM -0800 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 04, Michael Elkins wrote: > > Nope. That piece of code is executed in mutt_pattern_exec(). > mutt_check_simple() is only called when parsing limit/search/hook > commands before calling mutt_pattern_comp(). So, where is this function? I don't have it in my sources. -Clint From olsenc@ichips.intel.com Wed Feb 4 21:18:39 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id VAA16972 for ; Wed, 4 Feb 1998 21:18:38 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id VAA05383 for ; Wed, 4 Feb 1998 21:22:32 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id VAA12271 for ; Wed, 4 Feb 1998 21:18:38 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id VAA28056; Wed, 4 Feb 1998 21:18:37 -0800 (PST) Message-ID: <19980204211837.30144@dtthp169.jf.intel.com> Date: Wed, 4 Feb 1998 21:18:37 -0800 From: Clint Olsen To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204173039.43051@la.tis.com>; from Michael Elkins on Wed, Feb 04, 1998 at 05:30:39PM -0800 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 04, Michael Elkins wrote: > > What I am looking for is deficiencies that people believe need to be > fixed for the 1.0 release. I think Liviu wanted to yet again rewrite the pager. Are there any issues with the pager anyone can think of to warrant such an activity? -Clint From fabrice@math.Princeton.EDU Wed Feb 4 22:50:29 1998 Return-Path: fabrice@math.Princeton.EDU Received: from and.Princeton.EDU (root@and.Princeton.EDU [128.112.16.144]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id WAA28232 for ; Wed, 4 Feb 1998 22:50:27 -0800 (PST) Received: from eurydice.Princeton.EDU (eurydice.Princeton.EDU [128.112.16.153]) by and.Princeton.EDU (8.8.8/8.8.3) with ESMTP id BAA03804 for ; Thu, 5 Feb 1998 01:50:24 -0500 (EST) Received: (fabrice@localhost) by eurydice.Princeton.EDU (950413.SGI.8.6.12/8.6.12) id BAA15745; Thu, 5 Feb 1998 01:50:22 -0500 Message-ID: <19980205015022.56218@math.princeton.edu> Date: Thu, 5 Feb 1998 01:50:22 -0500 From: Fabrice Planchon To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980205112920.06230@ucc.gu.uwa.edu.au> <19980204201521.63929@shell9.ba.best.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="P+T4n/bALQSJXh8B" X-Mailer: Mutt 0.89.1i In-Reply-To: <19980204201521.63929@shell9.ba.best.com>; from Brandon Long on Wed, Feb 04, 1998 at 08:15:21PM -0800 Organization: Princeton University X-http: //www.math.princeton.edu/~fabrice/ --P+T4n/bALQSJXh8B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed Feb 04 1998 at 08:15:21PM -0800, Brandon Long wrote: > > man page may not be practical, but how about generating info pages in a > > make install? ;-) >=20 > Um, how are info file more accessible? info -> HTML ;-) ? it's true, still, that not everybody has the sgml tools. Last time I checked (ok, long ago...), it failed miserabily to install correctly under Irix, so I gave up. Currently I use the manual.txt or the web site, having directly the html version of the info version would be nice. F. --=20 Fabrice Planchon (ph) 609/258-6495 Applied Math Program, 210 Fine Hall (fax) 609/258-1735 --P+T4n/bALQSJXh8B Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3a iQCVAwUBNNlhLtX42EYNMIltAQE50QP/frj9QAKtGnyDG18PVcOOl1VmoM97dyJx pxSPeuVkL4cyW+NVQ/oA4hWxpv6AfwMq2L01rfNXleO85Sn34xYe8QggQHioXJvm KCDlIShDjwNuFy2GMoXONkr8dP0eOgV57KAV/ytk9M693rDhhH0yFiEwzY+3vpqu CjTLZqJ8QOI= =HDOz -----END PGP SIGNATURE----- --P+T4n/bALQSJXh8B-- From roessler@sobolev.rhein.de Wed Feb 4 23:06:22 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id XAA01123 for ; Wed, 4 Feb 1998 23:06:20 -0800 (PST) Received: from sobolev.rhein.de (roessler@sobolev.iam.uni-bonn.de [131.220.223.85]) by riemann.iam.uni-bonn.de (8.8.8/8.8.5) with ESMTP id IAA12658 for ; Thu, 5 Feb 1998 08:06:08 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id IAA20992 ; Thu, 5 Feb 1998 08:05:50 +0100 Message-ID: <19980205080550.20104@sobolev.rhein.de> Date: Thu, 5 Feb 1998 08:05:50 +0100 From: Thomas Roessler To: Mutt Development List Subject: Re: [0.90i] bug: can't view-attach on signed messages w/o passphrase Mail-Followup-To: Mutt Development List References: <19980204145059.38391@la.tis.com> <19980204190013.65187@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.90i In-Reply-To: <19980204190013.65187@cs.swarthmore.edu> On Wed, Feb 04, 1998 at 07:00:13PM -0500, Daniel Eisenbud wrote: > > If I tried to view-attachments on a PGP/MIME signed-only message, Mutt now > > asks me for my passphrase. It should not be necessary for signed messages. > Yeah, that happened to me earlier today too. My pgp_encrflags patch fixes that bug. tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 From roessler@sobolev.rhein.de Wed Feb 4 23:25:11 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id XAA02446 for ; Wed, 4 Feb 1998 23:25:08 -0800 (PST) Received: from sobolev.rhein.de (roessler@sobolev.iam.uni-bonn.de [131.220.223.85]) by riemann.iam.uni-bonn.de (8.8.8/8.8.5) with ESMTP id IAA12915 for ; Thu, 5 Feb 1998 08:25:11 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id IAA23173 ; Thu, 5 Feb 1998 08:25:00 +0100 Message-ID: <19980205082459.48828@sobolev.rhein.de> Date: Thu, 5 Feb 1998 08:24:59 +0100 From: Thomas Roessler To: "The mutt developpers' list" Subject: [Announce] Mutt 0.90.1i released Mail-Followup-To: The mutt developpers' list Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=ReaqsoxgOBHFXBhH X-Mailer: Mutt 0.90.1i --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Please find Mutt 0.90.1i at the following location: ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/mutt-0.90.1i.tar.gz ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/diff-0.90i-0.90.1i.gz ftp://riemann.iam.uni-bonn.de/pub/mutt/devel/duff-0.90.1-0.90.1i.gz Detached PGP signatures are, as usual, available. PGP related changes since 0.90i ------------------------------- - [patch-0.90i.tlr.pgp_attach_keys.1] Fixes a core dump on the compose menu when attaching PGP public keys. - [patch-0.90i.tlr.pgp_encrflags.1] There were several points in the code where a message's pgp flag was evaluated the wrong way (namely, ...->pgp =3D=3D PGPENCRYPT instead of ... & PGPENCR). tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNlpStImKUTOasbBAQH6XQf/dULmVHgeYYJgZsuNk0L17nEKZRnlXktl 9cYW/MFltiwjYGTGXE+Y0RNx+9qMZaqevoLY5aBG/ZJSm7A3rNYy9bGvR+GQGdg+ tyN2jLWlYqKZpDq+EPP4+fVdc6/3VqaAHq2PhQ6wkjG4hHsQ8AM1AxncI/6ycWEb 8ANV7IgzporZ21j5E8xKTEPoA4SQK7AaWETdyOWm4GWAsjovMHxtqCaL7Z3Pu40D NAAmW5zJL5Fne1L/3+3VqYNurmjpo7SlDxy2+M4UBhY1ER9SZTiiulyOnVt3Wcka N9AZ1RqnRmxjxvr3GnjLLkVB4XXAMvJppUxcxwUAaoHOcX0RtvD1BQ== =Bikm -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH-- From roland@spinnaker.rhein.de Wed Feb 4 23:46:40 1998 Return-Path: roland@spinnaker.rhein.de Received: from uran.informatik.uni-bonn.de (uran.informatik.uni-bonn.de [131.220.8.49]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id XAA04246 for ; Wed, 4 Feb 1998 23:46:37 -0800 (PST) Received: (from root@localhost) by uran.informatik.uni-bonn.de (8.8.8-ws3/8.8.8-ws3) id IAA29328 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 08:46:34 +0100 (MET) >Received: from luv.rhein.de (root@localhost) by gatekeeper.rhein.de (8.8.8-ws3/8.8.8-ws3) with BSMTP id IAA19221 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 08:40:16 +0100 (MET) Received: from spinnaker.rhein.de (roland@spinnaker.rhein.de [193.175.27.89]) by luv.rhein.de (8.8.8/8.8.8) with ESMTP id AAA17093; Thu, 5 Feb 1998 00:08:03 +0100 From: Roland Rosenfeld Received: (from roland@localhost) by spinnaker.rhein.de (8.8.8/8.8.8) id AAA01063; Thu, 5 Feb 1998 00:08:00 +0100 Message-ID: <19980205000759.03651@spinnaker.rhein.de> Date: Thu, 5 Feb 1998 00:07:59 +0100 To: Mutt Development List Subject: [0.90i] pattern_hook (was: [0.89] feature: pattern_hook) Mail-Followup-To: Mutt Development List References: <19980129230323.25189@la.tis.com> Mime-Version: 1.0 X-Mailer: Mutt 0.90i In-Reply-To: <19980129230323.25189@la.tis.com> Content-Type: text/plain; charset=us-ascii On Fri, 30 Jan 1998, Michael Elkins wrote: > Hmm, I tried something like: > > save-hook ^mutt-(dev|users)@(turing\\.)?cs\\.hmc\\.edu$ +mutt-mail > > and it worked just liked I expected it to but the above only works, if there is no fullname/comment on the address line. I wondered, why \\.de$ didn't much in most of my replies to German adresses. Then I found out, that "roland@spinnaker.rhein.de" matches on the above RegExp, but "Roland Rosenfeld " doesn't. Temporary I removed the $, which seems to solve the problem, but now \\.de matches many adresses, with aren't located in the TLD de. So how can I match only the mail address without the fullname/comment here? Ciao Roland -- * Internet: roland@spinnaker.rhein.de * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF From pendersa@mcd.alcatel.be Thu Feb 5 00:26:10 1998 Return-Path: pendersa@mcd.alcatel.be Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id AAA07578 for ; Thu, 5 Feb 1998 00:26:08 -0800 (PST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id JAA17178 for ; Thu, 5 Feb 1998 09:24:52 +0100 Received: from btkp04.mcd.bel.alcatel.be(138.203.224.26) by btmplq via smap (V1.3) id sma017138; Thu Feb 5 09:24:39 1998 Received: (from pendersa@localhost) by btkp04.mcd.alcatel.be (8.8.8/8.8.8/HiSpeedCompanyV0.1beta) id JAA07386; Thu, 5 Feb 1998 09:25:10 +0100 (MET) Message-ID: <19980205092510.22392@mcd.alcatel.be> Date: Thu, 5 Feb 1998 09:25:10 +0100 From: Alain Penders To: MUTT Developers Subject: Re: compressed folders patch Reply-To: Alain Penders References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204133944.60630@dtthp169.jf.intel.com> <19980205004149.11261@iil.intel.com> <19980204151915.02993@dtthp169.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980204151915.02993@dtthp169.jf.intel.com>; from Clint Olsen on Wed, Feb 04, 1998 at 03:19:15PM -0800 Organisation: Finale Development, Inc. On Wed, Feb 04, 1998 at 03:19:15PM -0800, Clint Olsen wrote: >On Feb 05, Michael S. Tsirkin wrote: >> >> I would like to hear specific comments why. Note that currently there is >> no convenient way to do this - if mutt launches urlview, wy not gunzip? >> Did you look at the patch? Could oyu point out some concrete problems. > >I just never have run into a case where I have compressed folders. I think >that putting the burden of filesystem management onto Mutt is excessive. >It's less of a code bloat thing for me than a matter of principle. If you >make in a configure option like you say, you won't hear any gripes from >me :) Filesystem management is closely related to applications though. The problem is space.. and you can not solve this problem on the filesystem level, as it doesn't have a clue what files are for... what files can be deleted, what files can be compressed, etc. Alain -- Alain Penders | Visserijstraat 114 | http://www.Finale-Dev.com/ Finale Development, Inc. | B-3590 Diepenbeek | Finale Web Cruiser Alain@Finale-Dev.com | Belgium | MOca Java Virtual Machine DISCLAIMER: The contents of this mail reflect my own opinions, and do NOT in any way represent Finale Development, the ICOA or the TSC. From efraim@desire.argh.org Thu Feb 5 00:57:49 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id AAA11226 for ; Thu, 5 Feb 1998 00:57:39 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0y0N8E-0002XX-00; Thu, 5 Feb 1998 09:58:02 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0y0NBt-00071RC; Thu, 5 Feb 1998 10:01:49 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0y0N5D-000708-00 ; Thu, 5 Feb 1998 09:54:55 +0100 Message-ID: <19980205095455.00714@deadend.argh.org> Date: Thu, 5 Feb 1998 09:54:55 +0100 From: Alexander Koch To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170819.10018@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980204170819.10018@cs.swarthmore.edu>; from "Daniel Eisenbud" on Wed, 04 Feb 1998 17:08:19 -0500 Sender: Alexander Koch On Wed, 4 February 1998 17:08:19 -0500, Daniel Eisenbud wrote: > So I think this patch should go in, because it's > really useful for some people, and it doesn't noticeably mess up mutt > for the people it's not useful for. I second that. I've some archives I don't want to scratch -- though I stillw ant to access them from time to time w/o a wrapper script oder manually unziping them. Alexander -- - Real programmers don't document. Documentation is for simps who can't read the listings of the object deck. Alexander Koch - <>< - aka Efraim - PGP - 0xA78FB1E9 - Wedel - Germany From sec@matrix.42.org Thu Feb 5 01:18:39 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id BAA13118 for ; Thu, 5 Feb 1998 01:18:29 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id KAA12560 (sender ); Thu, 5 Feb 1998 10:18:15 +0100 (CET) Message-ID: <19980205101814.49687@matrix.42.org> Date: Thu, 5 Feb 1998 10:18:14 +0100 From: Stefan `Sec` Zehl To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170819.10018@cs.swarthmore.edu> <19980205095455.00714@deadend.argh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980205095455.00714@deadend.argh.org>; from Alexander Koch on Thu, Feb 05, 1998 at 09:54:55AM +0100 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Thu, Feb 05, 1998 at 09:54:55AM +0100, Alexander Koch wrote: > I second that. I've some archives I don't want to scratch -- though I > stillw ant to access them from time to time w/o a wrapper script oder > manually unziping them. Archives are for looking at them, not for beeing modified. And then you can use a simple "gunzip;call mutt;rm gunzipped" script for looking into it. I dont see this should be added to mutt. Especially as it doesn't give any advatage, because it also decompresses into an temporary file. CU, Sec -- If architects built buildings like programmers build programs, the first woodpecker to come along would destroy civilization. From roessler@sobolev.rhein.de Thu Feb 5 01:43:40 1998 Return-Path: roessler@sobolev.rhein.de Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id BAA15622 for ; Thu, 5 Feb 1998 01:43:36 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.8/8.8.5) with UUCP id KAA15342 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 10:40:50 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id KAA26706 ; Thu, 5 Feb 1998 10:39:00 +0100 Message-ID: <19980205103859.05867@sobolev.rhein.de> Date: Thu, 5 Feb 1998 10:38:59 +0100 From: Thomas Roessler To: "The mutt developpers' list" Subject: bug-fix: [0.90i] make_forward() problem Mail-Followup-To: The mutt developpers' list References: <19980204194042.55095@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=8P1HSweYDcXXzwPJ X-Mailer: Mutt 0.90.1i In-Reply-To: <19980204194042.55095@sobolev.rhein.de> --8P1HSweYDcXXzwPJ Content-Type: multipart/mixed; boundary=GvXjxJ+pjyke8COw --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 04, 1998 at 07:40:42PM +0100, I wrote: > When setting mime_fwd and trying to forward the attached > message, the resulting attachment will look like this: etc. The bug was related to the behaviour of mutt_copy_hdr() [why is this in print.c, not in copy.c?] if CH_MIME is set - the ignore flag wasn't unset, once it was set. Please try the attached patch. On a related topic - the attached patch also fixes a possible problem with long header lines in get_line(). This is yet another dynamic fgets() work-around. Shouldn't we at some point in the future include something like BSD's fgetln(3) with mutt and use that instead of fgets? This could lead to significant simplifications at quite a few places. tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 2048/CE6AC6C1 =B7 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch-0.90.1i.tlr.hdrignore.1" diff -ur /var/tmp/mutt-0.90.1i/print.c mutt-0.90.1i/print.c --- /var/tmp/mutt-0.90.1i/print.c Sat Jan 31 14:12:57 1998 +++ mutt-0.90.1i/print.c Thu Feb 5 10:23:46 1998 @@ -39,7 +39,8 @@ { long old_pos; int ch; - + size_t offset =3D 0; + =20 if (!buf) { *blen =3D HUGE_STRING; @@ -48,11 +49,25 @@ =20 old_pos =3D ftell (fl); =20 - if ((fgets (buf, *blen - 1, fl)) =3D=3D NULL) + do { - buf[0] =3D 0; - return (buf); - } + if(offset =3D=3D *blen - 1) + { + *blen +=3D HUGE_STRING; + safe_realloc((void **) buf, *blen); + } + =20 + if ((fgets (buf + offset, *blen - 1 - offset, fl)) =3D=3D NULL) + { + if(!offset) + buf[0] =3D 0; + =20 + return (buf); + } + =20 + offset +=3D strlen(buf + offset); + =20 + } while(!strchr(buf, '\n')); =20 if (decode) { @@ -175,7 +190,9 @@ strcat (headers[x], buf); } =20 - dprint(2, (debugfile, "Reorder: %s matches %s\n", t->data,=20 + dprint(2, (debugfile, "%s:%d: Reorder: %s matches %s\n", + __FILE__, __LINE__, + t->data, headers[x])); match =3D TRUE; } @@ -212,34 +229,44 @@ } /* end hdr_count */ } /* end CH_REORDER */ =20 - dprint (1, (debugfile, "WEED is %s\n", (flags & CH_WEED) ? "Set" : "Not"= )); + dprint (1, (debugfile, "%s:%d: WEED is %s\n", __FILE__, __LINE__, + (flags & CH_WEED) ? "Set" : "Not")); while (ftell (in) < off_end) { if ((buf =3D get_line (in, buf, &blen, (flags & CH_DECODE))) =3D=3D NU= LL || buf[0] =3D=3D 0) break; =20 + dprint (1, (debugfile, "%s:%d: Ignore =3D %d\n", __FILE__, __LINE__, i= gnore)); + dprint (1, (debugfile, "%s:%d: Read %s\n", __FILE__, __LINE__, + buf)); + =20 if (!from && strncmp ("From ", buf, 5) =3D=3D 0) { + dprint(1, (debugfile, "%s:%d: Skipping From_\n", __FILE__, __LINE__)= ); if ((flags & CH_FROM) =3D=3D 0) continue; from =3D 1; } else if (buf[0] =3D=3D '\n' || (buf[0] =3D=3D '\r' && buf[1] =3D=3D '\= n')) + { + dprint(1, (debugfile, "%s:%d: End of header\n", __FILE__, __LINE__)); break; /* end of header */ - - if (flags & CH_WEED) + } + =20 + if (buf[0] =3D=3D ' ' || buf[0] =3D=3D '\t') { - if (buf[0] =3D=3D ' ' || buf[0] =3D=3D '\t') - { - if (ignore) - continue; - } - else if (mutt_matches_ignore (buf, Ignore) && - !mutt_matches_ignore (buf, UnIgnore)) - ignore =3D 1; - else - ignore =3D 0; + if (ignore) + continue; + } + else + ignore =3D 0; + =20 + if (flags & CH_WEED && mutt_matches_ignore (buf, Ignore) && + !mutt_matches_ignore (buf, UnIgnore)) + { + dprint (1, (debugfile, "%s:%d: Ignoring.\n", __FILE__, __LINE__)); + ignore =3D 1; } =20 if (!ignore) @@ -280,6 +307,9 @@ } if (match) { + dprint(1, (debugfile, "%s:%d: Ignoring %s.\n", + __FILE__, __LINE__, t->data)); + =20 ignore =3D 1; continue; } @@ -295,6 +325,9 @@ } } =20 + dprint(1, (debugfile, "%s:%d: Printing: %s\n", + __FILE__, __LINE__, buf)); + =20 if (fputs (buf, out) =3D=3D EOF) { if (buf) --GvXjxJ+pjyke8COw-- --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBNNmIsdImKUTOasbBAQG0Qgf6AnyYqxLuKKS1gbEp4iBmt6RUaQvw46Tx iNEkqa+Y+USYhmlkvucut0oFGeaOvGjjAebRfMnuy6SCYXZQIUO/JTbAQwYOZiIT 5BXm//3JmliCVMOrWiA38mchx3feKAbpk9Mw4quRCVIba8bYVuboAsrbTVLfyFRY JMMAo3jeZ3784CXAlpA8+wlqBfeV1N/Hp6rvOIRwY1MsErCk51IuXoEFLUUR3kC2 zKYg5epnmdObMzWqfVZdpJ9Jxn4NmMbN7jmL284Umv2nKi0WEx0Uxi4LqiUcFb/l 89uR6yv86rAnC9mHWlh/wqgU2d4gxopO7xNgL9i5q+1PEpExFee2Mg== =48hl -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From news@spinnaker.rhein.de Thu Feb 5 01:56:09 1998 Return-Path: news@spinnaker.rhein.de Received: from uran.informatik.uni-bonn.de (uran.informatik.uni-bonn.de [131.220.8.49]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id BAA16657 for ; Thu, 5 Feb 1998 01:56:06 -0800 (PST) Received: (from root@localhost) by uran.informatik.uni-bonn.de (8.8.8-ws3/8.8.8-ws3) id KAA04671 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 10:55:50 +0100 (MET) >Received: from luv.rhein.de (root@localhost) by gatekeeper.rhein.de (8.8.8-ws3/8.8.8-ws3) with BSMTP id KAA20415 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 10:51:49 +0100 (MET) Received: (from news@localhost) by luv.rhein.de (8.8.8/8.8.8) id KAA22337 for mutt-dev@cs.hmc.edu; Thu, 5 Feb 1998 10:23:27 +0100 To: mutt-dev@cs.hmc.edu From: Roland Rosenfeld Newsgroups: mailinglist.mutt-dev Subject: Re: compressed folders patch Date: 5 Feb 1998 09:23:26 GMT Organization: private site, Widdig, Germany Lines: 39 Message-ID: <6bc0ee$ll9$1@luv.rhein.de> References: <19980204151915.02993@dtthp169.jf.intel.com> NNTP-Posting-Host: spinnaker.rhein.de User-Agent: tin/pre-1.4-980202 (UNIX) (Linux/2.0.33 (i586)) Xref: luv mailinglist.mutt-dev:5549 Content-Type: text Clint Olsen wrote: >> I would like to hear specific comments why. Note that currently there is >> no convenient way to do this - if mutt launches urlview, wy not gunzip? >> Did you look at the patch? Could oyu point out some concrete problems. > I just never have run into a case where I have compressed folders. I never used Fcc, is this an argument to remove all Fcc code? Many people always work on monochrome terminal, is this an argument to removed the color code? > I think that putting the burden of filesystem management onto Mutt > is excessive. That's right, but do you see a way to realize compressed folders an any other way? (No, I don't want to install a patched libc only for using compressed mailfolders). > It's less of a code bloat thing for me than a matter of principle. Oh yeah, that's a very good argument ;-) > If you make in a configure option like you say, you won't hear any > gripes from me :) So why do I hear you? The configure option is in as long as I use this patch. The default for this configure option is "disabled". So the normal user will get a completly unchanged binary, when simply installing this patch. Most code is encapsulated in compress.c and all changes in the other files are guarded by #ifdefs. Tschoeeee Roland -- * Internet: roland@spinnaker.rhein.de * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF From pendersa@mcd.alcatel.be Thu Feb 5 02:03:36 1998 Return-Path: pendersa@mcd.alcatel.be Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id CAA17413 for ; Thu, 5 Feb 1998 02:03:34 -0800 (PST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id LAA28902 for ; Thu, 5 Feb 1998 11:02:19 +0100 Received: from btkp04.mcd.bel.alcatel.be(138.203.224.26) by btmplq via smap (V1.3) id sma028888; Thu Feb 5 11:02:12 1998 Received: (from pendersa@localhost) by btkp04.mcd.alcatel.be (8.8.8/8.8.8/HiSpeedCompanyV0.1beta) id LAA07572; Thu, 5 Feb 1998 11:02:45 +0100 (MET) Message-ID: <19980205110244.28823@mcd.alcatel.be> Date: Thu, 5 Feb 1998 11:02:44 +0100 From: Alain Penders To: MUTT Developers Subject: Re: compressed folders patch Reply-To: Alain Penders References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170819.10018@cs.swarthmore.edu> <19980205095455.00714@deadend.argh.org> <19980205101814.49687@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980205101814.49687@matrix.42.org>; from Stefan `Sec` Zehl on Thu, Feb 05, 1998 at 10:18:14AM +0100 Organisation: Finale Development, Inc. On Thu, Feb 05, 1998 at 10:18:14AM +0100, Stefan `Sec` Zehl wrote: >Archives are for looking at them, not for beeing modified. And then you >can use a simple "gunzip;call mutt;rm gunzipped" script for looking into >it. I dont see this should be added to mutt. Especially as it doesn't >give any advatage, because it also decompresses into an temporary file. Isn't that the same as saying "I drive on the left side of the road, so everyone has to drive on the left side of the road" ? If I had to manage all my mail in uncompressed mailboxes, I'd never stay under my disk quota. Alain -- Alain Penders | Visserijstraat 114 | http://www.Finale-Dev.com/ Finale Development, Inc. | B-3590 Diepenbeek | Finale Web Cruiser Alain@Finale-Dev.com | Belgium | MOca Java Virtual Machine DISCLAIMER: The contents of this mail reflect my own opinions, and do NOT in any way represent Finale Development, the ICOA or the TSC. From sec@matrix.42.org Thu Feb 5 02:14:53 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA18125 for ; Thu, 5 Feb 1998 02:14:48 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id LAA13105 (sender ); Thu, 5 Feb 1998 11:14:35 +0100 (CET) Message-ID: <19980205111433.01633@matrix.42.org> Date: Thu, 5 Feb 1998 11:14:33 +0100 From: Stefan `Sec` Zehl To: Alain Penders , MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: Alain Penders , MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204133944.60630@dtthp169.jf.intel.com> <19980205004149.11261@iil.intel.com> <19980204151915.02993@dtthp169.jf.intel.com> <19980205092510.22392@mcd.alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <19980205092510.22392@mcd.alcatel.be>; from Alain Penders on Thu, Feb 05, 1998 at 09:25:10AM +0100 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Thu, Feb 05, 1998 at 09:25:10AM +0100, Alain Penders wrote: > Filesystem management is closely related to applications though. The > problem is space.. You can't really use this patch when you're _really_ short on space, as it takes even more space for openening the mailboxes. And for other cases a simple wrapper works as good (IMHO). > and you can not solve this problem on the filesystem > level, as it doesn't have a clue what files are for... what files can > be deleted, what files can be compressed, etc. That is plain wrong. an simple 'gzip' can be implemented on filesystem level (see MS-DOG). It's not that we use any more intelligent compression schemes which utilize our 'knowledge' that these are Mailbox files. CU, Sec P.S.: I just wanted to add the url of that article describing to save space by shortening all well-known headers to single-character ones, but i can't find the url now. Does anyone have it? - This was meant as an example of 'using' the knowledge that dthe file is an MBOX. - You could surely implement some more elaborate schemes. But as long as we resort to 'gzip' it shouldnt be in mutt (imho) :-) -- stop reading here From sec@matrix.42.org Thu Feb 5 02:16:00 1998 Return-Path: sec@matrix.42.org Received: from matrix.42.org (sec@matrix.42.org [192.68.213.129]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA18156 for ; Thu, 5 Feb 1998 02:15:56 -0800 (PST) Received: (from sec@localhost) by matrix.42.org (8.8.8/8.8.6) id LAA13133 (sender ); Thu, 5 Feb 1998 11:15:51 +0100 (CET) Message-ID: <19980205111550.60474@matrix.42.org> Date: Thu, 5 Feb 1998 11:15:50 +0100 From: Stefan `Sec` Zehl To: Roland Rosenfeld , mutt-dev@cs.hmc.edu Subject: Re: compressed folders patch Mail-Followup-To: Roland Rosenfeld , mutt-dev@cs.hmc.edu References: <19980204151915.02993@dtthp169.jf.intel.com> <6bc0ee$ll9$1@luv.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <6bc0ee$ll9$1@luv.rhein.de>; from Roland Rosenfeld on Thu, Feb 05, 1998 at 09:23:26AM +0000 I-love-doing-this: really X-Visit-My-Mutt-Page: http://sec.42.org/mutt/ On Thu, Feb 05, 1998 at 09:23:26AM +0000, Roland Rosenfeld wrote: > Most code is encapsulated in compress.c and all > changes in the other files are guarded by #ifdefs. Yep. And #ifdefs is that whats going to make code unmaintainable in the long run. CU, Sec -- So viel ist in so kurzer Zeit zu tun. From efraim@desire.argh.org Thu Feb 5 02:31:33 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id CAA19206 for ; Thu, 5 Feb 1998 02:31:29 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0y0Ob8-0006ig-00; Thu, 5 Feb 1998 11:31:58 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0y0Oen-00071RC; Thu, 5 Feb 1998 11:35:45 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0y0NhP-0007Le-00 ; Thu, 5 Feb 1998 10:34:23 +0100 Message-ID: <19980205103423.07362@deadend.argh.org> Date: Thu, 5 Feb 1998 10:34:23 +0100 From: Alexander Koch To: MUTT Developers Subject: Re: compressed folders patch Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204170819.10018@cs.swarthmore.edu> <19980205095455.00714@deadend.argh.org> <19980205101814.49687@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980205101814.49687@matrix.42.org>; from "Stefan `Sec` Zehl" on Thu, 05 Feb 1998 10:18:14 +0100 Sender: Alexander Koch On Thu, 5 February 1998 10:18:14 +0100, Stefan `Sec` Zehl wrote: > I dont see this should be added to mutt. You'll have to enable it as a compile time option, so only those weirdos crazy enough to use it will experience it. You don't have to use it a single second. It's just my own laziness, I'm afraid. Alexander -- Was ist ein Boomerang, der nicht fliegt? Ein Treffer. (Und kein Stock!) [tm Efraim] Alexander Koch - <>< - aka Efraim - PGP - 0xA78FB1E9 - Wedel - Germany From efraim@desire.argh.org Thu Feb 5 02:40:03 1998 Return-Path: efraim@desire.argh.org Received: from mail.provi.de (mail.provi.de [193.98.9.7]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id CAA19827 for ; Thu, 5 Feb 1998 02:40:00 -0800 (PST) Received: from news.hamburg.pop.de (claimed popnews.hamburg.pop.de, is IP 193.98.9.248) by mail.provi.de with smtp (Exim 1.80 #2) id 0y0OjN-0007Pm-00; Thu, 5 Feb 1998 11:40:29 +0100 Received: from desire.argh.org by popnews.hamburg.pop.de with bsmtp (Smail3.2.0.95 #6) id m0y0On1-00071RC; Thu, 5 Feb 1998 11:44:15 +0100 (MET) Received: from efraim by desire.argh.org with local (Exim 1.82 #1) id 0y0OgV-00002a-00 ; Thu, 5 Feb 1998 11:37:31 +0100 Message-ID: <19980205113731.37233@deadend.argh.org> Date: Thu, 5 Feb 1998 11:37:31 +0100 From: Alexander Koch To: mutt-dev@cs.hmc.edu Subject: Re: compressed folders patch Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980204151915.02993@dtthp169.jf.intel.com> <6bc0ee$ll9$1@luv.rhein.de> <19980205111550.60474@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i In-Reply-To: <19980205111550.60474@matrix.42.org>; from "Stefan `Sec` Zehl" on Thu, 05 Feb 1998 11:15:50 +0100 Sender: Alexander Koch On Thu, 5 February 1998 11:15:50 +0100, Stefan `Sec` Zehl wrote: > On Thu, Feb 05, 1998 at 09:23:26AM +0000, Roland Rosenfeld wrote: > > Most code is encapsulated in compress.c and all > > changes in the other files are guarded by #ifdefs. > Yep. And #ifdefs is that whats going to make code unmaintainable in the > long run. You've got a serious problem with that patch, it seems. ,-) Alexander -- "That's the way you respond to every situation: if it doesn't work, hit it!" B'elanna Torres (human) to B'elanna Torres (klingon) Alexander Koch - <>< - aka Efraim - PGP - 0xA78FB1E9 - Wedel - Germany From lillqvis@cc.helsinki.fi Thu Feb 5 02:50:16 1998 Return-Path: lillqvis@cc.helsinki.fi Received: from kontti.Helsinki.FI (lillqvis@kontti.helsinki.fi [128.214.205.13]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id CAA20470 for ; Thu, 5 Feb 1998 02:50:12 -0800 (PST) Received: (from lillqvis@localhost) by kontti.Helsinki.FI (8.8.8-spammers-bug-off/8.8.0) id MAA12964; Thu, 5 Feb 1998 12:49:46 +0200 (EET) Message-ID: <19980205124946.28152@kontti.Helsinki.FI> Date: Thu, 5 Feb 1998 12:49:46 +0200 From: Holger Lillqvist To: Mutt Development List Subject: Re: Looking towards 1.0 References: <19980204173039.43051@la.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19980204173039.43051@la.tis.com> Quoting Michael Elkins (me@cs.hmc.edu): > Being that we are now at release 0.90, I was sort of thinking about what a > 1.0 release would look like. Quoting Kim DeVaughn (kimdv@best.com): > It would also be nice if the browser supported "tagging" (at least when > invoked from the compose menu), so that multiple files could be selected > for attachment in a single operation. I too think that support for attachment of tagged files would be a useful feature. Holger From hildeb@stahlw00.stahl.bau.tu-bs.de Thu Feb 5 03:35:38 1998 Return-Path: hildeb@stahlw00.stahl.bau.tu-bs.de Received: from stahlw00.stahl.bau.tu-bs.de (stahlw00.stahl.bau.tu-bs.de [134.169.69.220]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id DAA23224 for ; Thu, 5 Feb 1998 03:35:36 -0800 (PST) Received: (from hildeb@localhost) by stahlw00.stahl.bau.tu-bs.de (8.8.8/8.8.8) id MAA19581; Thu, 5 Feb 1998 12:35:33 +0100 (MET) Message-ID: <19980205123532.41076@stahlw00.stahl.bau.tu-bs.de> Date: Thu, 5 Feb 1998 12:35:32 +0100 From: Ralf Hildebrandt To: mutt-dev@cs.hmc.edu Subject: Minor flaw (0.89-0.90.1) Make clean Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=mP3DRpeJDSE+ciuQ X-Mailer: Mutt 0.90.1i X-Mailer-Info: http://www.stahl.bau.tu-bs.de/~hildeb --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi! In 0.89-0.90i "make clean" doesn't call a "make clean" in rx. =20 --=20 Ralf Hildebrandt, R.Hildebrandt@tu-bs.de (PGP Key @ request ) http://www.stahl.bau.tu-bs.de/~hildeb Institute for Steel Structures @ Technical University of Braunschweig Beethovenstr. 51, 38106 Braunschweig, Germany --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNNmj/knh/jPvZzKNAQGpaQP/QIhtFCiQCXtp8BDPi4LX/ADCJocp95RJ CttwoFcjZw9WNdXC/InGKahw0gIAy6mDOXw5l8W3+KSsTNjOjibiLHryR33ODPoZ p7QXgxPryWu2UHkwgpuZvCyYJoFrx8udoi3IIwS/pNgfmX2DCXLYYzYA6KzNdMTX Os1cpo/v3fo= =fpz6 -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From josh@jg.webmaster.com Thu Feb 5 04:13:19 1998 Return-Path: josh@jg.webmaster.com Received: from jg.webmaster.com (newport-2-4.quick.net [207.212.160.220]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id EAA25689 for ; Thu, 5 Feb 1998 04:13:11 -0800 (PST) Received: (from josh@localhost) by jg.webmaster.com (8.8.8/8.8.7) id EAA10403; Thu, 5 Feb 1998 04:12:31 -0800 (PST) Message-ID: <19980205041230.13512@jg.webmaster.com> Date: Thu, 5 Feb 1998 04:12:30 -0800 From: Josh Gilliam To: Stefan `Sec` Zehl Cc: mutt-dev@cs.hmc.edu Subject: [0.90.1] restore_url References: <19980119124316.18250@cs.swarthmore.edu> <19980119164216.06779@shell3.ba.best.com> <19980120121555.60343@matrix.42.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/2994txjAzEdQwm5" X-Mailer: Mutt 0.90.1 (restore_url) In-Reply-To: <19980120121555.60343@matrix.42.org> X-IRC: soil X-Operating-System: FreeBSD 3.0-CURRENT i386 --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mutt009676 sec@42.org (Stefan `Sec` Zehl) wrote: > > The attached patch will restore the url function to > > 0.88.14i. Feel free to #ifdef it to make a compile-time > > option if you want ... > > I didn't have time to install urlview properly, yet. So it > would be very convinient to have that menu back. > > However, I understand the reasoning behind "me"'s wish to > remove that code, so I'll be putting this patch on my > patch-page if it's not re-included. Attached patch restores url menu to 0.90.1. -- Josh Gilliam josh@quick.net 5333 E LOS ARBOLES AVE ORANGE CA 92869-4216 USA --/2994txjAzEdQwm5 Content-Type: text/plain; charset=us-ascii Content-Description: patch-0.90.1.jg.restore_url.1 Content-Disposition: attachment; filename="patch-0.90.1.jg.restore_url.1" diff -ur mutt-0.90.1.dist/Makefile.in mutt-0.90.1/Makefile.in --- mutt-0.90.1.dist/Makefile.in Wed Feb 4 17:11:41 1998 +++ mutt-0.90.1/Makefile.in Thu Feb 5 00:58:06 1998 @@ -43,7 +43,7 @@ mbox.o menu.o mh.o mx.o pager.o parse.o pattern.o \ postpone.o print.o recvattach.o rfc822.o \ rfc1524.o rfc2047.o send.o sendlib.o signal.o sort.o \ - status.o system.o thread.o @LIBOBJS@ + status.o system.o thread.o url.o @LIBOBJS@ CLEANFILES=mutt *.o *~ *.rej *.orig # kill these files when making new export distributions diff -ur mutt-0.90.1.dist/OPS mutt-0.90.1/OPS --- mutt-0.90.1.dist/OPS Wed Feb 4 17:11:41 1998 +++ mutt-0.90.1/OPS Thu Feb 5 00:58:06 1998 @@ -3,6 +3,7 @@ OP_ATTACH_VIEW_TEXT "view attachment as text" OP_BOTTOM_PAGE "move to the bottom of the page" OP_BOUNCE_MESSAGE "remail a message to another user" +OP_BROWSE_URL "run a web browser on a URL in a message" OP_BROWSER_NEW_FILE "select a new file in this directory" OP_CHANGE_DIRECTORY "change directories" OP_CHECK_NEW "check mailboxes for new mail" diff -ur mutt-0.90.1.dist/bind.c mutt-0.90.1/bind.c --- mutt-0.90.1.dist/bind.c Wed Feb 4 17:11:45 1998 +++ mutt-0.90.1/bind.c Thu Feb 5 00:58:07 1998 @@ -25,6 +25,7 @@ static struct mapping_t Menus[] = { { "alias", MENU_ALIAS }, + { "url", MENU_URL }, { "attach", MENU_ATTACH }, { "browser", MENU_FOLDER }, { "compose", MENU_COMPOSE }, @@ -118,6 +119,9 @@ break; case MENU_ATTACH: bindings = OpAttach; + break; + case MENU_URL: + bindings = OpUrl; break; case MENU_EDITOR: bindings = OpEditor; diff -ur mutt-0.90.1.dist/curs_main.c mutt-0.90.1/curs_main.c --- mutt-0.90.1.dist/curs_main.c Wed Feb 4 17:11:47 1998 +++ mutt-0.90.1/curs_main.c Thu Feb 5 00:58:07 1998 @@ -1130,6 +1130,12 @@ ci_bounce_message (tag ? NULL : CURHDR, &menu->redraw); break; + case OP_BROWSE_URL: + CHECK_MSGCOUNT; + mutt_browse_url (CURHDR); + menu->redraw = REDRAW_FULL; + break; + case OP_CREATE_ALIAS: mutt_create_alias (Context && Context->vcount ? CURHDR->env : NULL); diff -ur mutt-0.90.1.dist/functions.h mutt-0.90.1/functions.h --- mutt-0.90.1.dist/functions.h Wed Feb 4 17:11:47 1998 +++ mutt-0.90.1/functions.h Thu Feb 5 00:58:07 1998 @@ -61,6 +61,7 @@ struct binding_t OpMain[] = { { "create-alias", OP_CREATE_ALIAS, "a" }, { "bounce-message", OP_BOUNCE_MESSAGE, "b" }, + { "browse-url", OP_BROWSE_URL, "\002" }, { "change-folder", OP_MAIN_CHANGE_FOLDER, "c" }, { "change-folder-readonly", OP_MAIN_CHANGE_FOLDER_READONLY, "\033c" }, { "copy-message", OP_COPY_MESSAGE, "C" }, @@ -134,6 +135,7 @@ struct binding_t OpPager[] = { { "create-alias", OP_CREATE_ALIAS, "a" }, { "bounce-message", OP_BOUNCE_MESSAGE, "b" }, + { "browse-url", OP_BROWSE_URL, "\002" }, { "change-folder", OP_MAIN_CHANGE_FOLDER, "c" }, { "change-folder-readonly", OP_MAIN_CHANGE_FOLDER_READONLY, "\033c" }, { "copy-message", OP_COPY_MESSAGE, "C" }, @@ -300,6 +302,11 @@ { "history-up", OP_EDITOR_HISTORY_UP, NULL }, { "history-down", OP_EDITOR_HISTORY_DOWN, NULL }, { NULL, 0, NULL } +}; + +struct binding_t OpUrl[] = { + { "quit", OP_PAGER_EXIT, "i" }, + { NULL, 0, NULL } }; struct binding_t OpAlias[] = { diff -ur mutt-0.90.1.dist/globals.h mutt-0.90.1/globals.h --- mutt-0.90.1.dist/globals.h Wed Feb 4 17:11:48 1998 +++ mutt-0.90.1/globals.h Thu Feb 5 00:58:07 1998 @@ -73,6 +73,7 @@ WHERE char Tochars[8]; /* " +TCF" */ WHERE char Username[SHORT_STRING]; WHERE char Visual[_POSIX_PATH_MAX]; +WHERE char WebBrowser[_POSIX_PATH_MAX] INITVAL({0}); WHERE LIST *AutoViewList INITVAL(0); WHERE LIST *HeaderOrderList INITVAL(0); diff -ur mutt-0.90.1.dist/help.c mutt-0.90.1/help.c --- mutt-0.90.1.dist/help.c Wed Feb 4 17:11:48 1998 +++ mutt-0.90.1/help.c Thu Feb 5 00:58:07 1998 @@ -49,6 +49,9 @@ case MENU_ATTACH: map = OpAttach; break; + case MENU_URL: + map = OpUrl; + break; case MENU_POST: map = OpPost; break; @@ -201,6 +204,10 @@ case MENU_ALIAS: funcs = OpAlias; desc = "alias"; + break; + case MENU_URL: + funcs = OpUrl; + desc = "url"; break; case MENU_POST: funcs = OpPost; diff -ur mutt-0.90.1.dist/init.c mutt-0.90.1/init.c --- mutt-0.90.1.dist/init.c Wed Feb 4 17:11:49 1998 +++ mutt-0.90.1/init.c Thu Feb 5 00:58:08 1998 @@ -796,10 +796,11 @@ rx = (regex_t *) safe_malloc (sizeof (regex_t)); if (!ptr->pattern || strcmp (ptr->pattern, tmp) != 0) { - /* $alternates and $local_site are case-insensitive, + /* $url_regexp, $alternates and $local_site are case-insensitive, * $mask is case-sensitive */ - if (strcmp (MuttVars[idx].option, "alternates") == 0 || + if (strcmp (MuttVars[idx].option, "url_regexp") == 0 || + strcmp (MuttVars[idx].option, "alternates") == 0 || strcmp (MuttVars[idx].option, "local_site") == 0) flags |= REG_ICASE; else if (strcmp (MuttVars[idx].option, "mask") != 0) @@ -1371,6 +1372,10 @@ QuoteRegexp.rx = safe_malloc (sizeof (regex_t)); REGCOMP (QuoteRegexp.rx, QuoteRegexp.pattern, mutt_which_case (QuoteRegexp.pattern)); + + UrlRegexp.pattern = safe_strdup ("((ftp|http)://|mailto:)[^ \t\r\n\">]*[^., \"\r\t\n>]"); + UrlRegexp.rx = safe_malloc (sizeof (regex_t)); + REGCOMP (UrlRegexp.rx, UrlRegexp.pattern, REG_ICASE); Mask.pattern = safe_strdup ("^(\\.\\.$|[^.])"); Mask.rx = safe_malloc (sizeof (regex_t)); diff -ur mutt-0.90.1.dist/init.h mutt-0.90.1/init.h --- mutt-0.90.1.dist/init.h Wed Feb 4 17:11:49 1998 +++ mutt-0.90.1/init.h Thu Feb 5 02:36:27 1998 @@ -176,12 +176,14 @@ { "timeout", DT_NUM, R_NONE, P_DECL(&Timeout) }, { "tmpdir", DT_PATH, R_NONE, S_DECL(Tempdir) }, { "to_chars", DT_STR, R_BOTH, S_DECL(Tochars) }, + { "url_regexp", DT_RX, R_NONE, P_DECL(&UrlRegexp) }, { "use_8bitmime", DT_BOOL, R_NONE, I_DECL(OPTUSE8BITMIME) }, { "use_domain", DT_BOOL, R_NONE, I_DECL(OPTUSEDOMAIN) }, { "use_from", DT_BOOL, R_NONE, I_DECL(OPTUSEFROM) }, { "use_mailcap", DT_QUAD, R_NONE, I_DECL(OPT_USEMAILCAP) }, { "visual", DT_PATH, R_NONE, S_DECL(Visual) }, { "wait_key", DT_BOOL, R_NONE, I_DECL(OPTWAITKEY) }, + { "web_browser", DT_PATH, R_NONE, S_DECL(WebBrowser) }, { "write_inc", DT_NUM, R_NONE, P_DECL(&WriteInc) }, { NULL } }; diff -ur mutt-0.90.1.dist/keymap.c mutt-0.90.1/keymap.c --- mutt-0.90.1.dist/keymap.c Wed Feb 4 17:11:49 1998 +++ mutt-0.90.1/keymap.c Thu Feb 5 00:58:08 1998 @@ -343,6 +343,7 @@ create_bindings (OpAlias, MENU_ALIAS); create_bindings (OpAttach, MENU_ATTACH); + create_bindings (OpUrl, MENU_URL); create_bindings (OpBrowser, MENU_FOLDER); create_bindings (OpCompose, MENU_COMPOSE); create_bindings (OpMain, MENU_MAIN); diff -ur mutt-0.90.1.dist/keymap.h mutt-0.90.1/keymap.h --- mutt-0.90.1.dist/keymap.h Wed Feb 4 17:11:49 1998 +++ mutt-0.90.1/keymap.h Thu Feb 5 00:58:08 1998 @@ -48,6 +48,7 @@ enum { MENU_ALIAS, + MENU_URL, MENU_ATTACH, MENU_COMPOSE, MENU_EDITOR, @@ -78,6 +79,7 @@ extern struct binding_t OpPost[]; extern struct binding_t OpMain[]; extern struct binding_t OpAttach[]; +extern struct binding_t OpUrl[]; extern struct binding_t OpPager[]; extern struct binding_t OpCompose[]; extern struct binding_t OpBrowser[]; diff -ur mutt-0.90.1.dist/mutt_regex.h mutt-0.90.1/mutt_regex.h --- mutt-0.90.1.dist/mutt_regex.h Wed Feb 4 17:11:43 1998 +++ mutt-0.90.1/mutt_regex.h Thu Feb 5 00:58:08 1998 @@ -50,5 +50,6 @@ WHERE REGEXP Mask; WHERE REGEXP QuoteRegexp; WHERE REGEXP ReplyRegexp; +WHERE REGEXP UrlRegexp; #endif /* MUTT_REGEX_H */ diff -ur mutt-0.90.1.dist/pager.c mutt-0.90.1/pager.c --- mutt-0.90.1.dist/pager.c Wed Feb 4 17:11:50 1998 +++ mutt-0.90.1/pager.c Thu Feb 5 00:58:08 1998 @@ -1805,6 +1805,16 @@ ci_bounce_message (hdr, &redraw); break; + case OP_BROWSE_URL: + CHECK_MODE; + if (mutt_browse_url (hdr) == OP_PAGER_EXIT) + { + rc = -1; + ch = -1; + } + redraw = REDRAW_FULL; + break; + case OP_CREATE_ALIAS: CHECK_MODE; mutt_create_alias (hdr->env); diff -ur mutt-0.90.1.dist/protos.h mutt-0.90.1/protos.h --- mutt-0.90.1.dist/protos.h Wed Feb 4 17:11:43 1998 +++ mutt-0.90.1/protos.h Thu Feb 5 00:58:08 1998 @@ -128,6 +128,7 @@ void mutt_update_tree (ATTACHPTR **, short); void mutt_view_attachments (HEADER *); +int mutt_browse_url (HEADER *); int mutt_addr_is_user (ADDRESS *); int mutt_alias_complete (char *, size_t); int mutt_alloc_color (int fg, int bg); --/2994txjAzEdQwm5-- From pendersa@mcd.alcatel.be Thu Feb 5 04:21:32 1998 Return-Path: pendersa@mcd.alcatel.be Received: from btmplq.god.bel.alcatel.be (gatekeeper.alcatel.be [138.203.244.2]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id EAA26059 for ; Thu, 5 Feb 1998 04:21:28 -0800 (PST) Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id NAA14860 for ; Thu, 5 Feb 1998 13:20:11 +0100 Received: from btkp04.bsg.bel.alcatel.be(138.203.224.26) by btmplq via smap (V1.3) id sma014836; Thu Feb 5 13:20:00 1998 Received: (from pendersa@localhost) by btkp04.mcd.alcatel.be (8.8.8/8.8.8/HiSpeedCompanyV0.1beta) id NAA07698; Thu, 5 Feb 1998 13:20:31 +0100 (MET) Message-ID: <19980205132030.37939@mcd.alcatel.be> Date: Thu, 5 Feb 1998 13:20:30 +0100 From: Alain Penders To: MUTT Developers Subject: Re: compressed folders patch Reply-To: Alain Penders References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204133944.60630@dtthp169.jf.intel.com> <19980205004149.11261@iil.intel.com> <19980204151915.02993@dtthp169.jf.intel.com> <19980205092510.22392@mcd.alcatel.be> <19980205111433.01633@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85 In-Reply-To: <19980205111433.01633@matrix.42.org>; from Stefan `Sec` Zehl on Thu, Feb 05, 1998 at 11:14:33AM +0100 Organisation: Finale Development, Inc. On Thu, Feb 05, 1998 at 11:14:33AM +0100, Stefan `Sec` Zehl wrote: >You can't really use this patch when you're _really_ short on space, as >it takes even more space for openening the mailboxes. And for other >cases a simple wrapper works as good (IMHO). That is a problem if you only have a few mailboxes. If you get so little mail that you can handle it in less then 4 mailboxes, then you obviously aren't a person that needs compression. Eg. suppose you have 4 mailboxes, each 1MB in size, and with a compression ratio of 2:1... then the 4 compressed boxes use 2MB disk space... at the moment that you're editing one they use 3MB. Still less than the 4MB they'd need if you didn't compress them at all. I have about 30 mailboxes... 4 for my main job, 5 general ones for my company, one for each business partner, and another 10 or to save "goodies" from the mailinglists that I monitor. This is like a databank for me, and being able to access it quickly and flexible are very important. >> and you can not solve this problem on the filesystem >> level, as it doesn't have a clue what files are for... what files can >> be deleted, what files can be compressed, etc. > >That is plain wrong. an simple 'gzip' can be implemented on filesystem >level (see MS-DOG). It's not that we use any more intelligent compression >schemes which utilize our 'knowledge' that these are Mailbox files. MSDOS is a dead simple filingsystem, on which crap like this will work and be more or less acceptable. I've implemented a similar system for AmigaOS, which is more complex, and found that it's definitely a pain in the ass if you try to compress everything. On unix you might be able to pull it off if you have sufficient memory for caching, sufficient CPU power and a very decent algorythm which can filter out certain files. If you want to write this, be my guest. I'll stick to applications doing it themselves. Alain -- Alain Penders | Visserijstraat 114 | http://www.Finale-Dev.com/ Finale Development, Inc. | B-3590 Diepenbeek | Finale Web Cruiser Alain@Finale-Dev.com | Belgium | MOca Java Virtual Machine DISCLAIMER: The contents of this mail reflect my own opinions, and do NOT in any way represent Finale Development, the ICOA or the TSC. From eisenbud@allspice.cs.swarthmore.edu Thu Feb 5 05:51:40 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id FAA01953 for ; Thu, 5 Feb 1998 05:51:39 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id IAA15975; Thu, 5 Feb 1998 08:51:39 -0500 (EST) Message-ID: <19980205085139.64266@cs.swarthmore.edu> Date: Thu, 5 Feb 1998 08:51:39 -0500 From: Daniel Eisenbud To: mutt-dev@cs.hmc.edu Subject: Re: compressed folders patch Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980204151915.02993@dtthp169.jf.intel.com> <6bc0ee$ll9$1@luv.rhein.de> <19980205111550.60474@matrix.42.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980205111550.60474@matrix.42.org>; from Stefan `Sec` Zehl on Thu, Feb 05, 1998 at 11:15:50AM +0100 On Thu, Feb 05, 1998 at 11:15:50AM +0100, Stefan `Sec` Zehl wrote: > On Thu, Feb 05, 1998 at 09:23:26AM +0000, Roland Rosenfeld wrote: > > Most code is encapsulated in compress.c and all > > changes in the other files are guarded by #ifdefs. > > Yep. And #ifdefs is that whats going to make code unmaintainable in the > long run. If you look at the #ifdefs for the compressed folder stuff, it really doesn't go very far toward making the code unmaintainable. There are about four or five small ifdefs outside of compress.c. I think this is not something that's suddenly going to turn mutt from a friendly puppy into a rabid werewolf. :) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From eisenbud@allspice.cs.swarthmore.edu Thu Feb 5 05:56:41 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id FAA02289 for ; Thu, 5 Feb 1998 05:56:39 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id IAA16053; Thu, 5 Feb 1998 08:56:36 -0500 (EST) Message-ID: <19980205085636.63945@cs.swarthmore.edu> Date: Thu, 5 Feb 1998 08:56:36 -0500 From: Daniel Eisenbud To: mutt-dev@cs.hmc.edu Subject: Re: [0.90.1] restore_url Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980119124316.18250@cs.swarthmore.edu> <19980119164216.06779@shell3.ba.best.com> <19980120121555.60343@matrix.42.org> <19980205041230.13512@jg.webmaster.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980205041230.13512@jg.webmaster.com>; from Josh Gilliam on Thu, Feb 05, 1998 at 04:12:30AM -0800 On Thu, Feb 05, 1998 at 04:12:30AM -0800, Josh Gilliam wrote: > sec@42.org (Stefan `Sec` Zehl) wrote: > > > > The attached patch will restore the url function to > > > 0.88.14i. Feel free to #ifdef it to make a compile-time > > > option if you want ... > > > > I didn't have time to install urlview properly, yet. So it > > would be very convinient to have that menu back. > > > > However, I understand the reasoning behind "me"'s wish to > > remove that code, so I'll be putting this patch on my > > patch-page if it's not re-included. > > Attached patch restores url menu to 0.90.1. Your patch leaves out url.c. Try running diff -urN instead of diff -ur. (BTW, my favorite diff flags at the moment are "-durp": the -d makes diff make sure the diff is as small as possible, and the -p makes it print C function names as a comment at the top of each hunk of the diff. Or in this case, "-durpN".) -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From Vincent.Lefevre@ens-lyon.fr Thu Feb 5 07:59:18 1998 Return-Path: Vincent.Lefevre@ens-lyon.fr Received: from cri.ens-lyon.fr (cri.ens-lyon.fr [140.77.1.32]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id HAA10817 for ; Thu, 5 Feb 1998 07:59:14 -0800 (PST) Received: from zelfde.ens-lyon.fr (zelfde [140.77.11.124]) by cri.ens-lyon.fr (8.8.5/8.8.1) with ESMTP id QAA16166; Thu, 5 Feb 1998 16:58:56 +0100 (MET) Received: (from vlefevre@localhost) by zelfde.ens-lyon.fr (8.8.5/8.8.0) id QAA09662; Thu, 5 Feb 1998 16:58:55 +0100 (MET) Message-ID: <19980205165855.19774@ens-lyon.fr> Date: Thu, 5 Feb 1998 16:58:55 +0100 From: Vincent Lefevre To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980204211837.30144@dtthp169.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980204211837.30144@dtthp169.jf.intel.com>; from "Clint Olsen" on Wed, Feb 04, 1998 at 21:18:37 X-Mailer-Info: http://www.ens-lyon.fr/~vlefevre/mutt_eng.html On Wed, Feb 04, 1998 at 21:18:37 -0800, Clint Olsen wrote: > I think Liviu wanted to yet again rewrite the pager. Are there any issues > with the pager anyone can think of to warrant such an activity? One could have a browse-url in the pager (a la lynx). -- Vincent Lefevre | Acorn Risc PC, StrongARM @ 202MHz WWW: http://www.ens-lyon.fr/~vlefevre/ | 20+2MB RAM, Eagle M2, TV + Teletext PhD st. in Computer Science, 2nd year | Apple CD-300, SyQuest 270MB (SCSI) ----------------------------------------------------------------------------- From hensley@merit.edu Thu Feb 5 08:07:39 1998 Return-Path: hensley@merit.edu Received: from merit.edu (merit.edu [198.108.1.42]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA11605 for ; Thu, 5 Feb 1998 08:07:38 -0800 (PST) Received: from puttytat.merit.net (hensley@puttytat.merit.net [198.108.60.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA08345 for ; Thu, 5 Feb 1998 11:07:12 -0500 (EST) Message-ID: <19980205110711.58162@merit.net> Date: Thu, 5 Feb 1998 11:07:11 -0500 From: John Hensley To: mutt-dev@cs.hmc.edu Subject: Re: compressed folders patch Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980204201805.05396@aurora.rose.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <19980204201805.05396@aurora.rose.hp.com>; from Mun Johl on Wed, Feb 04, 1998 at 08:18:05PM -0800 I'd like to register a vote in favor of the compressed folders functionality. Folder management is a legitimate function of a mailer, and as others have pointed out, if you don't want it, it's reasonably discrete and configure'able, so you don't have to deal with it. You could also argue that you should encrypt your messages outside the mailer. Integrating PGP simplifies a cumbersome process. So does the compressed folders patch. And if you have both, it's not a huge leap to implement a pet idea of mine: PGP-encrypted folders, which would save disk *and* simplify secure storage of mail. Just to toss another wish into the mix. -- The men who are not interested in philosophy need it most urgently; they are most helplessly in its power. -- Ayn Rand From mtsirkin@iil.intel.com Thu Feb 5 08:11:16 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA11725 for ; Thu, 5 Feb 1998 08:11:14 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id QAA03980 for ; Thu, 5 Feb 1998 16:11:12 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA11901 (5.65c+/IDA-1.4.4 for ); Thu, 5 Feb 1998 18:11:10 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA19882; Thu, 5 Feb 1998 18:11:09 +0200 Message-Id: <19980205181109.48720@iil.intel.com> Date: Thu, 5 Feb 1998 18:11:09 +0200 From: "Michael S. Tsirkin" To: MUTT Developers Subject: Re: compressed folders patch Reply-To: "Michael S. Tsirkin" Mail-Followup-To: MUTT Developers References: <19980204222722.04779@iil.intel.com> <19980204214219.62101@matrix.42.org> <19980205003720.54018@iil.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980205003720.54018@iil.intel.com>; from "mtsirkin@iil.intel.com" on Thu, Feb 05, 1998 at 12:37:20AM +0200 X-Url: http://www.toptown.com/hp/mtsirkin Hello! Quoting r. Michael S. Tsirkin (mtsirkin@iil.intel.com) "Re: compressed folders patch": > Hello! > Quoting r. Stefan `Sec` Zehl (sec@42.org) "Re: compressed folders patch": > > On Wed, Feb 04, 1998 at 10:27:22PM +0200, Michael S. Tsirkin wrote: > > > Hello! > > > The compressed folders patch is quite stable now - > > > I sent it to mutt-users and so far no one complained of any bugs. > > > Perhaps we may try to add it in the next devel release? > > What are the gods saying :) ME? What do you think? mst -- This message content is not part of Intel's views or affairs Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; Home:+972-4-8283001; Work:+972-4-8655658; mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth) From eisenbud@allspice.cs.swarthmore.edu Thu Feb 5 08:17:51 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA12575 for ; Thu, 5 Feb 1998 08:17:48 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id LAA20498; Thu, 5 Feb 1998 11:17:47 -0500 (EST) Message-ID: <19980205111747.62411@cs.swarthmore.edu> Date: Thu, 5 Feb 1998 11:17:47 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: [0.90.1i] buffy cleanup Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=6TrnltStXW4iwmi0 X-Mailer: Mutt 0.90i --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii This patch gets rid of duplicated code in mutt_force_buffy_check() by adding an integer argument to mutt_buffy_check, which, if set, will force a check right then. It addresses all the nits that Michael Tsirkin and I have pointed out about the buffy code there, namely an extra call to time(), sharing information between functions with a global, and duplication of code. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu --6TrnltStXW4iwmi0 Content-Type: application/x-gunzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-0.90.1i.de.buffy-cleanup.1.gz" H4sICELl2TQCA3BhdGNoLTAuOTAuMWkuZGUuYnVmZnktY2xlYW51cC4xAN1YbVPbSAz+TH6F SqdtTGxqx+ElycGUkjBwB7QD4dper+Mx9oZ4mtgee1OSa/vfT9q1YzuxIeW+HTNgvKvVaqVH j7R2veEQNHcahTCZcq7p22192/Be30bBfcyibacwvH07HQ7nmjNmtj8NM6GapmkV6zdOIg9+ t31omqA3O/p+Z2cHjHZ7v9ZoNNZSvjEYTeGE3QLgQr2zs99pJRrevAGtaeyqe9CQDxyIuc09 BzyfA5vZE89nlutFzOFBNIf6xc1gcNG/vIGtGtBPxPg08qGuGUqXRn7WoKaBMMsS5ljOiDlf oY7TjbJxndbRSm8I9bobwgEEIfNxS6i7igIHB3B5c36ukMh3afBuUxgsHuUGT2xvfBvMWFw0 ON3m2ZnvBCh4p5QcosT6NYz3PW6RIQzq4qHChPlTMU02m3qLbJaPzOZvgefKtSRNS6OpwyGJ HCok3TSlHfKAXKN3s5GJPcMRsZt2yHwezcfM76ZnFHYqdBqA2A8jdA+Oco+P0TbxQGkVNi8W rvr8wv2yqZaFTh7/P+vRFYkRNo6ZDKfwPh566ISIrdDmIxXO7Zj3vEiF2PuHBUM5TCvdqkyj PR7JMylSkmVyIp8hlGO7HbO5Xo6trqcM2+u0jHyG6TLDdBl8QqrwTmhHcQGsTuDHHJyRHcFW rNbgucuGiGe4HhwNrOPT/vEfiJHb7Rjxwr0Jg0OQb7Z4+/EDAzMJtUOf3Y/R6xFDaLjw8mUi 5QgpTKi8iqpZoVLBBHlOyTiE11vw9ubk5JN1ffZXH7ZeU54vDjIMIocVMoaQrdQaC4kCEGhU LEH1AgRCM2yh8QIgSRoQtNGabuLEfdUwyYv43C24sWp31NQ7u4It5BKpVziW4PTZev/u+uyj 9f5ocGpdHH38srItRoKzmUW7I/TJFxYH3pXshr6Yhi4lu/AZgnRsi7jR6dA1KPKWrBkIj0qh umAxQS+0F6oY4hqGyxL2QR/zEYsY2PjrB5DBgpz9IHHp0sjlrRrJIuEfCjQHLWfYb9n/wZQr MsUTjWLmOJj6nNTQVOFAwl2ZzIKYxNBlwL3hPBmT7Gfuqli9GqbZVo3murFLWTnbh+hDFBj0 Hh95MQT+eC7dHhOgAIEv/AbMdkaF42ExYcNtMBWIGcbWFV7VyuEpLdC+J6H+lThpK3HSinFK BOq5QOWDoqxERauIirYYrfAjYe1nTavB0iF9GZ7Uz2X592CepEcoqROEsRwElBSBZaVgRTYr CBRJIjKEUOrHLpBtIAcTjpvxJAtkW2Duiz7G3NuXLCtqa7YzkqukVaV44PwmspaLNWwW2r5r kROQclVYcoRM5Pje44izMleIs1fP60p2YMeOGeidJFdauigWZru5xjEStOExFq4A+RPjuV79 rb/qSgBBBUqoLyOMS933dgz3UeDfISQjFs99h9LMvxPQbuT0FDQYa6tIbLvFwvS1K99+LnoA 0QKgp0V0Rc2XxN9qiri2jP21HeIIUjo8wHT/X7rl4U5o9HjDMqrqhEYb11j86LZhGoBXDcPE ZugXOqHRcifUKnRC5p7aohRVTYrkh9P+VR/iURDxIlefXZ4N/jw6h7pJjJ/kqoyUh0mZMG6x XUpck4OHLNGZdKIHbklMdjWPtzDVznamUUzK/Ydbz5zYqtNzk09uQSt0kPPbndZurg1tyza0 rS8nEjoVex15BUnKgsQf4leiuVBcPZ8qID4kbeLk2GVRBmV8dZK2ANc4i3qVlL50DKfLiBOe HSw0JE3J48v05XVJTsmbUsTcyL6HHwdw1e9dHX2wqJ++ue5mjOEGhepYKCx7Owb5TT4e89tG uieGJWKL1ggnxAoKWmSxKKISR0Vko7p6NzZKSYVU5U+1ONQJNhM0GzNuBSH3Auyd3r0fXPeP ro5Pzy4xoc56YnlCNFXAfhzTVXBOUPhUCikBsdHRjU4zxyA7uyIY8pE2krhOXirs6M5RE0LY wpdv+baC4jwc28i5L+HCEmywiHNSDar6GrwV6UpK9aLkVpb0pNzI2CHJ3JNtm5eLPhGwJxgt cml7U0SEzTwug1sVlDAKeBA/zO2pzGpg0plVkmmt9y2pTIGk9529LDiGKb7MyEe+y7ddN7K8 2JrGDHF/1Otd9a+vYYvOnsmMPTu2kFLCMaPPKDKK8jOAxZdEx4GDomPKInGZvFPF7O1dUc6f W1/Z3OKBRfc5z5+yYtGgDHzgDtB94AJb2Kiks85PO7ZvuXjtcHH7t+96n5ZOjrb4d8wibEL9 tH/U61/RweUmVYCgW+o0fjhPU5lVQKQzTwZEmQKZrUYzB4jWjtpGQIjHgjqRvSy53hrT140k 1LhBGm3BoyLPJJHZY0mt38Xf/Ieo4YRnX4rwRVFh88WLF7G7qUIYsaE3Eyy79PVqEmaLqHlW Qeip+PT15NXyg9cGtXNkAn33qmIPujA8IiIIRtiSOiUpLhtZ71j7FzFPGWGPFgAA --6TrnltStXW4iwmi0-- From Vincent.Lefevre@ens-lyon.fr Thu Feb 5 08:30:23 1998 Return-Path: Vincent.Lefevre@ens-lyon.fr Received: from cri.ens-lyon.fr (cri.ens-lyon.fr [140.77.1.32]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA13644 for ; Thu, 5 Feb 1998 08:30:13 -0800 (PST) Received: from zelfde.ens-lyon.fr (zelfde [140.77.11.124]) by cri.ens-lyon.fr (8.8.5/8.8.1) with ESMTP id RAA17887; Thu, 5 Feb 1998 17:30:04 +0100 (MET) Received: (from vlefevre@localhost) by zelfde.ens-lyon.fr (8.8.5/8.8.0) id RAA10608; Thu, 5 Feb 1998 17:30:03 +0100 (MET) Message-ID: <19980205173003.26569@ens-lyon.fr> Date: Thu, 5 Feb 1998 17:30:03 +0100 From: Vincent Lefevre To: mutt-dev@cs.hmc.edu Subject: [0.90.1] bug: "From " line no longer included in a piped message Mail-Followup-To: mutt-dev@cs.hmc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1 X-Mailer-Info: http://www.ens-lyon.fr/~vlefevre/mutt_eng.html With Mutt 0.90.1, when I pipe a message (or several messages), the "From " line is no longer included. This bug was introduced in Mutt 0.88.x. -- Vincent Lefevre | Acorn Risc PC, StrongARM @ 202MHz WWW: http://www.ens-lyon.fr/~vlefevre/ | 20+2MB RAM, Eagle M2, TV + Teletext PhD st. in Computer Science, 2nd year | Apple CD-300, SyQuest 270MB (SCSI) ----------------------------------------------------------------------------- From olsenc@ichips.intel.com Thu Feb 5 08:45:19 1998 Return-Path: olsenc@ichips.intel.com Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA15088 for ; Thu, 5 Feb 1998 08:45:17 -0800 (PST) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id IAA07207 for ; Thu, 5 Feb 1998 08:49:13 -0800 (PST) Received: from dtthp169 (olsenc@dtthp169.jf.intel.com [134.134.102.22]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA08303 for ; Thu, 5 Feb 1998 08:45:16 -0800 (PST) Received: by dtthp169 (8.8.8/WW2.1) id IAA11945; Thu, 5 Feb 1998 08:45:13 -0800 (PST) Message-ID: <19980205084512.52152@dtthp169.jf.intel.com> Date: Thu, 5 Feb 1998 08:45:13 -0800 From: Clint Olsen To: mutt-dev@cs.hmc.edu Subject: Re: compressed folders patch Mail-Followup-To: mutt-dev@cs.hmc.edu References: <19980204151915.02993@dtthp169.jf.intel.com> <6bc0ee$ll9$1@luv.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <6bc0ee$ll9$1@luv.rhein.de>; from Roland Rosenfeld on Thu, Feb 05, 1998 at 09:23:26AM +0000 Organization: Intel Corporation, Hillsboro, OR X-Disclaimer: Mutt Bites! On Feb 05, Roland Rosenfeld wrote: > > I never used Fcc, is this an argument to remove all Fcc code? Many > people always work on monochrome terminal, is this an argument to > removed the color code? Fcc is commonly associated with reading mail. I don't use Fcc either, but I don't see any issue with it. Since when is reading compressed folders a necessity? In a day when disk space is so cheap and plentiful, I don't see why so many are using compressed folders. How big are your folders such that you need to compress them? > That's right, but do you see a way to realize compressed folders an any > other way? (No, I don't want to install a patched libc only for using > compressed mailfolders). Why not? It *is* another way. > So why do I hear you? Because at some point too many features with #ifdefs will make spaghetti out of Mutt. Yes, I know the issue of bloat has been addressed. Maintainability is another. -Clint From eisenbud@allspice.cs.swarthmore.edu Thu Feb 5 08:48:17 1998 Return-Path: eisenbud@allspice.cs.swarthmore.edu Received: from allspice.cs.swarthmore.edu (allspice.cs.swarthmore.edu [130.58.68.10]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA15396 for ; Thu, 5 Feb 1998 08:48:15 -0800 (PST) Received: (from eisenbud@localhost) by allspice.cs.swarthmore.edu (8.8.8/8.8.8) id LAA22242; Thu, 5 Feb 1998 11:48:14 -0500 (EST) Message-ID: <19980205114814.50186@cs.swarthmore.edu> Date: Thu, 5 Feb 1998 11:48:14 -0500 From: Daniel Eisenbud To: Mutt Development List Subject: Re: Looking towards 1.0 Mail-Followup-To: Mutt Development List References: <19980204173039.43051@la.tis.com> <19980204211837.30144@dtthp169.jf.intel.com> <19980205165855.19774@ens-lyon.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90i In-Reply-To: <19980205165855.19774@ens-lyon.fr>; from Vincent Lefevre on Thu, Feb 05, 1998 at 04:58:55PM +0100 On Thu, Feb 05, 1998 at 04:58:55PM +0100, Vincent Lefevre wrote: > On Wed, Feb 04, 1998 at 21:18:37 -0800, Clint Olsen wrote: > > I think Liviu wanted to yet again rewrite the pager. Are there any issues > > with the pager anyone can think of to warrant such an activity? > > One could have a browse-url in the pager (a la lynx). You know, I just thought of a very simple way to do this, which might require only very small code changes (I don't know, I haven't dug in and figured out the code just yet.) We could just use the find command (either make a new keybinding, or just use a macro) with the appropriate URL, and have a command that executes the url browser on the currently found text. I don't know how feasible this is, but if it would take just a few lines of code, it would satisfy a long-standing wish, and provide a less bloated way to put back some sort of url functionality. -Daniel -- Daniel Eisenbud eisenbud@cs.swarthmore.edu From sitaram@cse.iitb.ernet.in Thu Feb 5 08:49:36 1998 Return-Path: sitaram@cse.iitb.ernet.in Received: from mailhost.iitb.ac.in (mailhost.iitb.ac.in [202.54.44.115]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id IAA15444 for ; Thu, 5 Feb 1998 08:49:31 -0800 (PST) Received: (qmail 19546 invoked from network); 5 Feb 1998 16:54:57 -0000 Received: from kailash.cse.iitb.ernet.in (sitaram@144.16.111.2) by mailhost.iitb.ac.in with SMTP; 5 Feb 1998 16:54:57 -0000 Received: from mohini (mohini [144.16.111.193]) by kailash.cse.iitb.ernet.in (8.8.5/8.8.5) id WAA24510; Thu, 5 Feb 1998 22:21:40 +0530 (IST) Message-ID: <19980205221632.47720@mohini.cse.iitb.ernet.in> Date: Thu, 5 Feb 1998 22:16:32 +0530 From: Sitaram Iyer To: Mutt Development List Subject: segfault due to LONG_STRING not being LONG enough Reply-To: sitaram@cse.iitb.ernet.in Mail-Followup-To: Mutt Development List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.1i the defn of LONG_STRING in mutt.h is only 1024. This length string is used to store the list of mailboxes, and I had a longer list. mutt segfaulted. Either the LONG_STRING size should be increased, or mutt_parse_mailboxes (buffy.c) should use HUGE_STRING or something. - Sitaram. -- Thanx. ,----------------------------------------------------------------. | If architects built buildings like programmers build programs, | | the first woodpecker to come along would destroy civilization. | `----------. ,---------' | Sitaram Iyer | | http://www.cse.iitb.ernet.in/~sitaram | `------------------------------------------' From mtsirkin@iil.intel.com Thu Feb 5 08:53:02 1998 Return-Path: mtsirkin@iil.intel.com Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by turing.cs.hmc.edu (8.8.5/8.8.4) with ESMTP id IAA15644 for ; Thu, 5 Feb 1998 08:53:00 -0800 (PST) Received: from iil.intel.com (iil-1.iil.intel.com [143.185.96.171]) by melete.ch.intel.com (8.8.6/8.8.5) with SMTP id QAA05406 for ; Thu, 5 Feb 1998 16:52:58 GMT Received: from ilx347.iil.intel.com by iil.intel.com with SMTP id AA14788 (5.65c+/IDA-1.4.4 for ); Thu, 5 Feb 1998 18:52:57 +0200 Received: by ilx347.iil.intel.com (AIX 4.1/UCB 5.64/IDC-RS6000-AIX-3.2) id AA38446; Thu, 5 Feb 1998 18:52:56 +0200 Message-Id: <19980205185256.28049@iil.intel.com> Date: Thu, 5 Feb 1998 18:52:56 +0200 From: "Michael S. Tsirkin" To: Mutt Development List Subject: Re: [0.90.1i] buffy cleanup Reply-To: "Michael S. Tsirkin" Mail-Followup-To: Mutt Development List References: <19980205111747.62411@cs.swarthmore.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <19980205111747.62411@cs.swarthmore.edu>; from "eisenbud@cs.swarthmore.edu" on Thu, Feb 05, 1998 at 11:17:47AM -0500 X-Url: http://www.toptown.com/hp/mtsirkin Hello! Quoting r. Daniel Eisenbud (eisenbud@cs.swarthmore.edu) "[0.90.1i] buffy cleanup": > This patch gets rid of duplicated code in mutt_force_buffy_check() by > adding an integer argument to mutt_buffy_check, which, if set, will > force a check right then. It addresses all the nits that Michael > Tsirkin and I have pointed out about the buffy code there, namely an > extra call to time(), sharing information between functions with a > global, and duplication of code. I think this is the correct approach. mst -- This message content is not part of Intel's views or affairs Michael S. Tsirkin,32000, Technion, Canada dorms 44/3/3,Haifa,Israel; Home:+972-4-8283001; Work:+972-4-8655658; mailto:mtsirkin@usa.net; http://www.toptown.com/hp/mtsirkin/; > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth) From Andrew.Large@Eng.Sun.COM Thu Feb 5 09:00:13 1998 Return-Path: Andrew.Large@Eng.Sun.COM Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by turing.cs.hmc.edu (8.8.5/8.8.4) with SMTP id JAA16363 for ; Thu, 5 Feb 1998 09:00:06 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25479 for ; Thu, 5 Feb 1998 08:59:22 -0800 Received: from kea.eng.sun.com (kea.Eng.Sun.COM [129.146.114.224]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA14760 for ; Thu, 5 Feb 1998 08:58:36 -0800 Received: from lobo.eng.sun.com by kea.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA24917; Thu, 5 Feb 1998 08:58:34 -0800 Received: by lobo.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16039; Thu, 5 Feb 1998 08:58:34 -0800 Message-ID: <19980205085834.00962@eng.sun.com> Date: Thu, 5 Feb 1998 08:58:34 -0800 From: "Andrew R. Large" To: Mutt Developers Subject: [0.90.1i] bug: manual nit (fcc-send-hook -> fcc-save-hook) Reply-To: alarge@techie.com Mail-Followup-To: Mutt Developers Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=8t9RHnE3ZwKMSgU+ X-Mailer: Mutt 0.90.1i Organization: Sun Microsystems, Inc. --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii (Didn't see this one come across) -- -=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=- Andrew Large | Sun Microsystems, Inc. andrew.large@eng.sun.com | 901 San Antonio Road (650) 786-6503 [office] | MS MPK18-209 (650) 786-4101 [fax] | Palo Alto, CA 94303-4900 -=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=- --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-0.90.1i.arl.fcc-save.1" --- mutt-0.90.1i/doc/manual.sgml.orig Thu Feb 5 08:39:19 1998 +++ mutt-0.90.1i/doc/manual.sgml Thu Feb 5 08:39:35 1998 @@ -983,12 +983,12 @@ Example: command. +name="fcc-save-hook"> command. Specify default save filename and default Fcc: mailbox at once