Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id E3545429E25 for ; Tue, 10 Jan 2012 08:05:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttbvYZ12pWj2 for ; Tue, 10 Jan 2012 08:05:00 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by olra.theworths.org (Postfix) with ESMTP id 612F7431FB6 for ; Tue, 10 Jan 2012 08:05:00 -0800 (PST) X-AuditID: 12074425-b7f4a6d0000008e0-ad-4f0c61abf56f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 3B.3B.02272.BA16C0F4; Tue, 10 Jan 2012 11:04:59 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q0AG4sg5000391; Tue, 10 Jan 2012 11:04:54 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0AG4rkx005292 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 10 Jan 2012 11:04:53 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RkeC6-0001w6-K8; Tue, 10 Jan 2012 11:05:02 -0500 Date: Tue, 10 Jan 2012 11:05:02 -0500 From: Austin Clements To: David Edmondson Subject: Re: [PATCH] emacs: Improve `notmuch-hello' display on ttys. Message-ID: <20120110160502.GN20796@mit.edu> References: <1326190528-3548-1-git-send-email-dme@dme.org> <20120110153650.GM20796@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrLs6kcffYN87K4t9d7YwWVy/OZPZ gclj1/O/TB7PVt1iDmCK4rJJSc3JLEst0rdL4Mo4fm4iS8Emrop37b8ZGxhncHQxcnJICJhI nD40jR3CFpO4cG89WxcjF4eQwD5Gie87ZkA5GxglFqxZywThnGSSOHjmDDuEs4RR4knPE2aQ fhYBVYnlP04xgdhsAhoS2/YvZwSxRQQUJf5/WwG2g1lAWuLb72awGmEBF4lHB06wgti8AjoS F7Z8YYQY2s8o8fLAI3aIhKDEyZlPWCCatSRu/HsJ1MwBNmj5P7AfOAVsJO6d28cGYosKqEhM ObmNbQKj0Cwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMj KLTZXVR3ME44pHSIUYCDUYmH96QGt78Qa2JZcWXuIUZJDiYlUd6LCTz+QnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4Wa2BcrwpiZVVqUX5MClpDhYlcV5NrXd+QgLpiSWp2ampBalFMFkZDg4l Cd6nIEMFi1LTUyvSMnNKENJMHJwgw3mAhtslggwvLkjMLc5Mh8ifYtTluN449xyjEEtefl6q lDivLEiRAEhRRmke3BxYSnrFKA70ljDv8VCgKh5gOoOb9ApoCRPQElFRbpAlJYkIKakGxpU3 18xVnJl0tc7aotp7yuGF3Q+4bfaETp7ac1yiaO7HOcGuaiXch14dqTboqLzh9Tw0u0Lc6IDG gx1VXwVenOKepnzVtqViXZiH1xT5NSZap59qVJ9e1/DtNMM6Zz3ZQ41L0ncl8vWw2D+MeXZE adqJuJzDd7IEEkqOH97x498F/ijFZtezjUosxRmJhlrMRcWJAJo4+T0kAwAA Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:05:01 -0000 Quoth David Edmondson on Jan 10 at 3:47 pm: > On Tue, 10 Jan 2012 10:36:50 -0500, Austin Clements wrote: > > LGTM, though would it be easier to put this in the else clause of the > > if after the setq count? > > Agreed. I got confused thinking about it due to the empty elements in > the matrix, but perhaps that doesn't matter. I'll continue to think, but > would rather not delay fixing the bug. Fair enough. > > Is it possible for a tag in the last column to be just long enough to > > make the line still wrap? Somehow my current tag set doesn't trigger > > this bug, so I can't test this case (and I admit I can't follow > > notmuch-hello-insert-tags well enough to reason this out). > > With a sufficiently narrow window it's always possible to generate wrap, > of course. I couldn't make it happen for any window width that seemed > reasonable. I should have specified more than one column. Clearly if you're down to one column it's always possible to wrap, but if you have more than one, does the code always reduce the number of columns in preference to allowing a particularly long tag name to wrap a line? Based on your testing, it sounds like it handles this correctly. (Even if it didn't, this shouldn't block this patch; it's related, but not the same issue.)