David Bremner <david@tethera.net> writes:
> This seems reasonable enough. Two questions
>
> 1) can you make a test (probably something in T465 can serve as 
> a mode

(As you might've noticed from me going dark...)

My work on this has completely stalled out for two reasons. First 
and foremost and primarily, I could not figure out the test 
language or how to write tests. Bashing my li'l pea-brain against 
that T465 file for two days without understanding how it works or 
what it does, let alone how to replicate it for my own patch.

Second and least but also a more show-stopping reason... I'm no 
longer sure this is the right approach.

My use case when I wrote it is that I'm with people who write 
super long threads, and, for the most part, I used Delta Chat and 
I only needed to pop into Emacs occasionally and the long threads 
would stall, sometimes even crash notmuch and this was a fix for 
that. But now that I use Emacs and Notmuch much more often and 
much more primarily, I've found it to be still not be perfect 
even with the patch.

With my patch, I run my normal daily (notmuch-search "tag:inbox 
and tag:personal" notmuch-search-oldest-first), and it shows me 
the threads and I can enter them and if they are super duper 
short (I think I set the cutoff at ten emails), it shows me the 
full thread in traditional notmuch fashion but if they are long, 
what I used to get before my patch was a crash but what I get now 
is a second tree view... with only the new emails in it.

If there's only one email, this is really annoying because it's 
one extra step to click through (or RET through rather since I 
use keyboard but you know what I mean). I'm like "ugh this extra 
step for just one email, I could've gotten this email in my inbox 
directly instead of this weird virtual folder being in my inbox".

And if it's ten new short emails from that person, it's even MORE 
annoying since I have to click through (RET through) each one of 
them separately.


Conclusion: what I want instead is notmuch-show mode *but only 
for the new emails*. I realize that notmuch will crash if I 
notmuch show a thread with thousands of emails like most of my 
threads are.

So this would solve both situations. There's only one or two new 
email in the kilothread? Great, notmuch-show will show me them 
*directly* instead of that extra unnecessary step. There are ten 
new emails? Great, I can scroll through them instead of opening 
them one by one.

There's a hundred new emails? That'd be one situation where 
neither approach is good. Opening a hundred messages one my one 
does not sound fun but neither, I know from experience, is a 
crashed notmuch (or rather it's the entire Emacs that will stall 
and crash).

What I'm kind of realizing I really want is an entire new 
approach to showing the emails in my inbox. All in one long 
*unnested* buffer, maybe with redundant headers removed (i.e. if 
someone changes the subject or adds a CC to the thread? Show 
that. Otherwise be more minimal).

Basically a view that looks more like a social media app's time 
line of posts instead of little packages or envelopes that I have 
to open individually. Notmuch was innovative making it so that 
the *thread* was the package rather the individual *message* 
being individually wrapped, but I'm realizing want the entire 
*search results* to be the package all unwrapped at once in one 
cozy long buffer. So... Basically the OPPOSITE of what my patch 
does!

Reason I want it flat is that even with 
notmuch-show-indent-messages-width to zero it still indents them 
invisibly which leads to the crashes. And also my screen is super 
narrow. Also epa-mail-decrypt doesn't work when there are leading 
spaces (hitting V for a raw view is a workaround).

So, the silver lining to me not being able to figure out the test 
language is that it's given me lots of time to dogfood the patch 
and I don't like it anymore!

Short term (now, this is all just daydreaming at this stage), 
I'll replace it with a notmuch-show that uses query-context to 
limit it to posts that matched the search (i.e. only show new 
posts) and to reduce crashes that way instead.

Long term, ideally we'd want a notmuch-show (or a new alternative 
to notmuch-show if we want to keep the other version too) that 
doesn't crash, that isn't limited to one single thread id, and 
that is more minimal i.e. better at hiding redundant metadata 
across separate messages.

That's not so say that I figured out the test language, I still 
haven't. And that's my bad and my shortcoming. But next step for 
me is the "short term" solution above; tear out my patches and 
replace it with adding a query-context to notmuch-show. Andd if I 
manage to do that (I mean who knows) I'll submit a new patch and 
then maybe I'll ask for help with the test stuff because it's 
beyond my ken! I remember spending two full and one half trying 
to figure out how to write that dang test with zero progress! 
Hacker card revoked
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org