[PATCH v3 1/2] emacs: User-defined sections in notmuch-hello

[Michal Sojka]

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 at 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 at 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