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 54BDF431FAF for ; Mon, 13 Oct 2014 01:43:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 vsTxygJx40nf for ; Mon, 13 Oct 2014 01:43:17 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 8CC7B431FAE for ; Mon, 13 Oct 2014 01:43:17 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so6322351lab.33 for ; Mon, 13 Oct 2014 01:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:message-id:from:to:subject:in-reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding; bh=c4JI7xXwWJf+uiplxropyl/6+O+d3eBXrsP2GbhhIJ8=; b=lWESPXxiz0zMOcYDVlzSY2KnIbhm8+ufs7UClTmlH1hwGObG7SmY+FmVPB9jdpZklW 29nIXHPnmEn1cGd2z7ViuKMeTC7v4PBp/g9SjB8wmOB2hGTzeAvMdso2/hda5V0uBB67 H6/QUzYH6V1PT1VEbOLQQFBJjrkPwyr5nhX9cnG5/O+EyQhrUYwajATmthkjtQI3C906 a+//umJv9mogQ94lPD/txdMjVXHoykKzpJFn311Hf4NZMkVOELZTau3mwvg3PkgnBoeS 77vCj+kfYBXVxcicLKrCp/g9HOrh8mH76oyVgxkYA8sjfobDLdorJfbxbIphyMJlKLfM Bbrg== X-Received: by 10.112.150.106 with SMTP id uh10mr22347534lbb.11.1413189795615; Mon, 13 Oct 2014 01:43:15 -0700 (PDT) Received: from localhost (p5B00D37C.dip0.t-ipconnect.de. [91.0.211.124]) by mx.google.com with ESMTPSA id al5sm4377604lbc.6.2014.10.13.01.43.13 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 13 Oct 2014 01:43:14 -0700 (PDT) Date: Mon, 13 Oct 2014 10:43:24 +0200 Message-ID: <20141013104324.GF23373@TP_L520.localdomain> From: Franz Fellner To: notmuch@notmuchmail.org Subject: Re: VIM: search_refresh limits message count to 2 * window.height In-Reply-To: <20141010175623.GB7504@TP_L520.localdomain> References: <20141010175623.GB7504@TP_L520.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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: Mon, 13 Oct 2014 08:43:23 -0000 The issue is that VIM::Buffer.render yield's itself BEFORE it clears itself. Two quick solutions: 1) Simply manually fixup the mess in StagedRender::initialize after @b.render {do_next } by adding @last_render = @b.count 2) First clear the VIM:Buffer before yielding. This exposes one issue in Vims buffer handling: A newly created buffer has count==0, But after the first line got added you cannot get count==0 again, so a refresh currently ends up with an empty line at the beginning. It is possible to get the empty line at the end by implementing VIM::Buffer.<<() as append(count()-1, arg) Of course one has to add one line now directly after creating a new buffer. Solution 1) would be a simple oneliner but IMHO looks a little bit hacky ;) Solution 2) at first looks ugly because of the empty line at the end/beginning. But it also adds the opportunity to print additional information, like description of the columns (date, thread participants, subject, ...) at the beginning, or something like "end of search list", "end of thread" at the end of the buffers. Please tell me which one you like most and I can send a patch. Regards Franz On Fri, 10 Oct 2014 17:56:23 +0200, Franz Fellner wrote: > The reason is that StagedRender.is_ready depends on last_render, which > get's set to VIM::Buffer.count() in StagedRender::do_next. > I do not (yet) know what exactly happens, but after the first call to > search refresh last_render never get's less than 2*2*window.height. > That means once you do search_refresh StagedRender never will be ready - > is_ready returns false, so s:show_cursor_moved never will advance the > StagedRender. > > I am trying to understand the code, but it's a hard time for me ;)