David Bremner <[email protected]> writes:
1) can you make a test (probably something in T465 can serve as
a model
What does T465 refer to?
2) Should this be bound by default, or is the function in the
next patch always the one users will want?
The latter since it prevents crashes. I've been dogfooding this
since I made it. It's been so great since I have huge threads
that used to overload Emacs and that's finally no longer a
problem.
"Big" is hardcoded to ten messages or lower, if we want to
introduce a variable for that instead, that might be great.
Yes, I think a defcustom is called for.
Right. Even if we find the perfect number and set that as the
default, it's just good Emacs practice to make it a defcustom.
Some of that explanation can maybe go in the docstring of the
newly defined customize variable
I'll try!
emacs wants to indent this line differently, so please follow
its lead here.
Wilco!
One option is to replace the default notmuch-search-show-thread
binding
Yes, that's what I've done locally. An even stronger step in that
direction would be to make this the new
notmuch-search-show-thread.
and just set the threshhold very high so that most users will
not notice the change.
But if the treshhold is too big it won't prevent any crashes,
overloads, or uncomfortably unergonomic thread view. It needs to
be within a useful range. Maybe 35, 40 or so. I've been sticking
with the "< 11" threshold I sent in the patch.
There is a slight performance penalty from add notmuch count;
I'm not sure if this is noticable.
Right. Since my machine is very fast I've not noticed any
slowdown at all. It's instant. A drawback of working on a fast
machine, I don't know what's too slow for more retro-minded
users. But even though my machine is fast it still couldn't
handle the big threads.
_______________________________________________
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]
