Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
0x64746b opened this issue Aug 19, 2011 · 7 comments
Closed

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

0x64746b opened this issue Aug 19, 2011 · 7 comments
Milestone

Comments

@0x64746b
Copy link
Collaborator

Request

I'd like to be able to specify a set of tags that I don't want to appear in that list that shows all the tags that appear with any mail in the thread.

Justification

I apply a 'sent' tag to the mails in the 'sent' maildir directory. That feels pretty intuitive to me and makes for easy searching for the mails oneself sent. If searching for the inbox tag, though, the sent tag always appears in combination with the replied tag - which makes displaying it rather a waste of screen estate.
Additionally, I might spend considerable time in the view of the safed search for the inbox tag (yes, in my inbox; I'm sorry -.-). It might be superfluous to display the inbox tag in that search in every line.

@pazz
Copy link
Owner

pazz commented Aug 19, 2011

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
Copy link
Collaborator Author

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
Copy link
Owner

pazz commented Aug 19, 2011

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Owner

pazz commented Aug 19, 2011

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
Copy link
Collaborator Author

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants