[feature][search view] don't-list tag list

[pazz]

[feature][search view] don't-list tag list

[pazz]

I think what you want here is not a global blacklist but a blacklist local to you inbox.
The problem, actually the coolness lies in you inbox not being any special than any other search.
So, you might consider translating the inbox tagstring to something shorter for space.

[tag translate]  # we should really change this to tag-translate methinks
inbox = IN

The problem with this is that it's global: for example if you search for tag:unread it is actually good to know if a thread
is already tagged inbox. You could actually translate inbox to the empty string. Then it never gets displayed at all,
But the current implementation of the taglist buffer can't handle empty strings. This might however be easy to fix,
This buffer needs some love anyway (it should display the translated and the original string).

I see that the send+reply tagging is somewhat redundant. notmuch new actually adds these tag. maybe it has
a config option to disable one of them?

[0x64746b]

The problem, actually the coolness lies in you inbox not being any special than any other search.

I totally agree with you

The problem with this is that it's global [...]
Then it never gets displayed at all

Nah, that's not whut I want. See your example. Or issue #27 where I would want those tags to be displayed if non-defining.

I see that the send+reply tagging is somewhat redundant. notmuch new actually adds these tag.

Actually, in my case, I'm the one who added the sent tag. I don't think notmuch has a default send tag. There is no maildir flag for that, is there? 'L' at least shows no such tag.
So notmuch probably won't be able to fix that ;)

[pazz]

Ah ok, yes, sent is a custom tag. However, the taglist buffer should display a sent-tag if there are messages so labelled.
my example?
cf the non-defining thing: Here, both 'sent' and 'repliied' would not be shared by all messages in the thread and therefore be
displayed as defining right? You might consider shortening (by display translation) the replied tag or simply remove it
in your sort script.

Removing/not displaying the inbox tag in the "inbox search" is problematic. At least I don't see how to do it without
hardcoding a inbox searchstring and testing it every time in the Threadline display widgets..

[0x64746b]

sent is a custom tag

yes

the taglist buffer should display a sent-tag if there are messages so labelled

yes. but i don't want them in my search results ('sent' is just an example, of course)

my example?

for example if you search for tag:unread it is actually good to know if a thread is already tagged inbox.

cf the non-defining thing: Here, both 'sent' and 'repliied' would not be shared by all messages in the thread and therefore be displayed as defining right?

They would be displayed since they are non-defining to the thread

You might consider shortening (by display translation) the replied tag or simply remove it
in your sort script.

I don't think that's what I want: If I have 'replied' to a mail in a thread, there will be a 'sent' mail in that thread as well (namely the reply). So the replied tag will always appear together with the sent tag in a thread. However, they belong to different mails! 'replied' to the mail I replied to (yours), while 'sent' marks my reply (mine).

Removing/not displaying the inbox tag in the "inbox search" is problematic. At least I don't see how to do it without
hardcoding a inbox searchstring and testing it every time in the Threadline display widgets..

I had a rather cheeky idea about that. One might decide to not display tags that have been searched for (so if the search term contains a is:inbox, don't display the inbox tag). One might argue, that when searching for mails with tag 't', the returned threads will obviously contain mails with that tag. Don't know if that would be easily implemented. Didn't think about corner cases yet

[0x64746b]

One might decide to not display tags that have been searched for

Thought about it again. First I thought the algo was quite sleek, but now I'm not sure if it isn't too much so. Potentially too much going on too implicitely. Might rather confuse the user.

I'd like to keep this discussion for potential later reference, but I think I'll suspend my thoughts on this issue for now and just go and find myself some nice catchy utf-8 symbols for those ever appearing tags (and maybe even color them ;P ;D)

[pazz]

cf the non-defining thing: Here, both 'sent' and 'repliied' would not be shared by all messages in the thread and therefore be displayed as defining right?

They would be displayed since they are non-defining to the thread

right, that's what i meant.

You might consider shortening (by display translation) the replied tag or simply remove it
in your sort script.

I don't think that's what I want: If I have 'replied' to a mail in a thread, there will be a 'sent' mail in that thread as well (namely the reply). So the
replied tag will always appear together with the sent tag in a thread. However, they belong to different mails! 'replied' to the mail I replied to
(yours), while 'sent' marks my reply (mine).

That makes sense. Although the Tree layout of the Thread view makes it obvious that one is the reply to the other.

Removing/not displaying the inbox tag in the "inbox search" is problematic. At least I don't see how to do it without
hardcoding a inbox searchstring and testing it every time in the Threadline display widgets..

I had a rather cheeky idea about that. One might decide to not display tags that have been searched for (so if the search term contains a is:inbox, don't
display the inbox tag). One might argue, that when searching for mails with tag 't', the returned threads will obviously contain mails with that tag. Don't
know if that would be easily implemented. Didn't think about corner cases yet

The problem is that notmuchs query syntax allows arbitrary boolean combinations of its atomic statements.
What do you do it the query is "not not tag:inbox"? simply leave that tag out because it occured as a substring in the
query?
This does simplify your display, agreed. but at least as default behaviour this might be confising. Maybe make this
optional..
Also, what do you do with all the saved space? :)

[0x64746b]

That makes sense. Although the Tree layout of the Thread view makes it obvious that one is the reply to the other.

yes. but i'm a fanatic. I want my mails tagged properly!!! screamjump* ;)

The problem is that notmuchs query syntax allows arbitrary boolean combinations of its atomic statements.

Well, if notmuch can parse it, so can alot. Alot is better than you at everything! ;P Seriously, though:

What do you do it the query is "not not tag:inbox"? simply leave that tag out because it occured as a substring in the query?

yes, in this case that would seem acceptable. More problematic would be OR expressions, where it'd be rather interesting to see what tag matched.

but at least as default behaviour this might be confising. Maybe make this optional

actually, I'm not that convinced anymore :/

Also, what do you do with all the saved space? :)

Weeell, display more of the subject, more of the preview, or, actually, I would like to see more sender addresses. Or just a more detailed timestamp. Anywayz, I'd find something to garble my screen with ;)