David Bremner <[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
