From: Franz Fellner <alpine.art.de@gmail.com>
To: notmuch@notmuchmail.org
Subject: Re: VIM: search_refresh limits message count to 2 * window.height
Date: Mon, 13 Oct 2014 10:43:24 +0200 [thread overview]
Message-ID: <20141013104324.GF23373@TP_L520.localdomain> (raw)
In-Reply-To: <20141010175623.GB7504@TP_L520.localdomain>
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 <alpine.art.de@gmail.com> 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 ;)
prev parent reply other threads:[~2014-10-13 8:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-10 15:56 VIM: search_refresh limits message count to 2 * window.height Franz Fellner
2014-10-13 8:43 ` Franz Fellner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141013104324.GF23373@TP_L520.localdomain \
--to=alpine.art.de@gmail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).