On Wed, 06 Jul 2011, Daniel Schoepe wrote: Non-text part: multipart/signed > On Wed, 06 Jul 2011 13:34:13 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote: > > So my proposal is to forget about different queries for filters and > > counts and having here only the following options: filter, hide-tags and > > hide-if-empty. > > > > Then, the documentation would be simple: "This section displays buttons > > for all tags of messages matching a FILTER. Optionally, some of these > > tags may be hidden." > > > > Is there a use case, which is not covered by this? > > I'm not sure, I can imagine someone wanting to have an overview of all > his tags, whether there are, e.g., unread messages or not. This wouldn't work for me. My all-tags section covers almost entire screen and finding non-zero entries there is not very convenient. I find much more useful to have a section saying: "Hey, you have unread messages only for these three tags". Moreover, it wouldn't help me to see non-zero number of unread messages and when I click the button I would see all the messages, not only the unread ones. It simply seems very confusing to me. > If we decide to keep this functionality, it should be inverted though, > i.e. one has to explicitly specify :show-empty-searches to get them. > > About the counts: I introduced this because Austin Clements says he > finds it useful in his comment here: > > id:"BANLkTi=729DWai4q57iBSfz1wDhBXsmndQ@mail.gmail.com" I agree that it is useful to see unread counts, but it is not useful to see all messages when I click the button. > > > + :type > > > + (let ((opts > > > + '((:title (string :tag "Title for this section")) > > > + (:make-query (string :tag "Filter for each tag")) > > > + (:make-count (string :tag "Different query to generate counts")) > > > + (:hide-tags (repeat :tag "Tags that will be hidden" string)) > > > > I can imagine, that :hide-tags could also be a (list of) regexp(es). > > > > > + (:initially-hidden (boolean :tag "Hide this on startup?")) > > > > This is IMHO not needed here, as you always has to enable this section > > manually. > > A user might still want to have the section collapsed when starting the > notmuch UI and only have it shown when he needs it. (I use that for a > section that displays unread counts for each tag). You are right. I use emacs --daemon so I actually initialize notmuch UI only when emacs crashes or when I run out of battery power ;-) > > > +;; only defined to avoid compilation warnings about free variables > > > +(defvar notmuch-hello-target nil) > > > > Add the documentation as discussed above. Additionally, it seems that > > having only the label in this variable is not enough, since the same > > label can appear in multiple sections. Perhaps, we need both the title > > of the section and the label here. > > What do you mean by label? "Custom function"? If yes, that element will > have the actual function name in the input element next to it anyway. If I understand this variable correctly, it stores the label (text) of the button you have your point at. This allows you to stay at the same button after reloading of notmuch-hello even if the layout changes, right? Then having the same named button in multiple sections results in moving the first (or last) occurrence of this button when notmuch-hello is reloaded. > > > Perhaps you want to end this (and also all other) section with an empty > > line so that the order of sections doesn't matter. I use sections in > > this order: header, inbox, saved-searches and there is no space between > > header and inbox and two spaces between inbox and saved-searches. > > My thinking was to have no section end with a newline and insert a > newline between each section when building the notmuch-hello buffer, to > prevent forgotten trailing newlines when defining a new section. This sounds reasonable. > > I might be useful to include here a link to the customization of this > > page. Maybe, it would be useful to have notmuch-hello subgroup in > > customization interface and link to this group. But creation of the > > subgroup should be definitely in a separate patch. > > Yes definitely. Pieter Praet recently sent a patch reorganizing the > customization options into subgroups, so I'll change it once that patch > has been applied. Good. -Michal