From 0decb489fc7a047eb57e5e392a411397eb9e795f Mon Sep 17 00:00:00 2001 From: Franz Fellner Date: Mon, 13 Oct 2014 10:43:24 +0200 Subject: [PATCH] Re: VIM: search_refresh limits message count to 2 * window.height --- e3/be52415d7fe65a7b86a97a45cd92b9dafe0863 | 107 ++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 e3/be52415d7fe65a7b86a97a45cd92b9dafe0863 diff --git a/e3/be52415d7fe65a7b86a97a45cd92b9dafe0863 b/e3/be52415d7fe65a7b86a97a45cd92b9dafe0863 new file mode 100644 index 000000000..80668c770 --- /dev/null +++ b/e3/be52415d7fe65a7b86a97a45cd92b9dafe0863 @@ -0,0 +1,107 @@ +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 ;) -- 2.26.2