From: Austin Clements <amdragon@mit.edu>
To: Daniel Schoepe <daniel.schoepe@googlemail.com>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH] emacs: User-defined sections in notmuch-hello
Date: Fri, 10 Jun 2011 01:42:07 -0400 [thread overview]
Message-ID: <BANLkTinKCLg1epsGvfxtyy-_G2Hm=gjUMQ@mail.gmail.com> (raw)
In-Reply-To: <87tyc7hvtz.fsf@gilead.invalid>
This looks really interesting.
I haven't examined the code very closely, but I have some high level comments.
It seems that the code is simultaneously trying to do something very
general, but also hard-coding a lot of behaviors, and I think the
code's complexity suffers for it. What would this look like if the
*entire* hello screen were replaced by a configurable list of
sections? What I'm imagining could be as simple as a list of
section-generating functions plus a collection of standard functions
for generating standard sections (probably known to customize to make
it easy for non-elispers to control).
For more-configurable sections, there could be a mechanism for passing
arguments, but this quickly enters the land of hair-raising defcustoms
and confusing flexibility. I think it would be much simpler and more
user-friendly to require the functions in this list to take no
arguments (at least, none that are user-configurable). Flexible
sections could be implemented then as a low-level function that takes
arguments and one or more no-argument high-level functions that call
the low-level section generator either with fixed arguments, or with
the values of other customize variables. This would keep things
simple and fairly flexible for non-elispers, without sacrificing
complete flexibility if you're willing to write a few lines of elisp.
Maybe you also want to configure the title of each section. But, IMO,
this is also confusing flexibility. In fact, with the no-argument
section generators, it would make a lot of sense to simply put the
section name in the function's plist.
This wouldn't fit well with the current logic to compute the
cross-section widest tag, but personally I've always found that
behavior extremely confusing (not to mention buggy) and wouldn't miss
it at all.
The use of the term "title" for pretty-printed tags is confusing. To
me, "title" means the section title. For example, I couldn't figure
out what "Return widest title string in SECTION." meant until I read
the code (*flashback* "a section only has one title, what the heck is
the widest one?")
This patch should probably be split into a few patches, as it seems to
also introduce new functionality for some of the sections (and does
little things like moving notmuch-remove-if-not).
On Fri, Jun 3, 2011 at 9:46 AM, Daniel Schoepe
<daniel.schoepe@googlemail.com> wrote:
> On Fri, 27 May 2011 20:52:01 +0200, Daniel Schoepe <daniel.schoepe@googlemail.com> wrote:
>> I'll also work on some tests for this functionality, (if no one
>> has big, structural complaints about the code).
>
> I rebased my patch against the current master and wrote some tests.
prev parent reply other threads:[~2011-06-10 5:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-27 18:52 [PATCH] emacs: User-defined sections in notmuch-hello Daniel Schoepe
2011-05-27 21:41 ` Daniel Schoepe
2011-05-27 21:51 ` Daniel Schoepe
2011-06-03 13:46 ` Daniel Schoepe
2011-06-10 5:42 ` Austin Clements [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTinKCLg1epsGvfxtyy-_G2Hm=gjUMQ@mail.gmail.com' \
--to=amdragon@mit.edu \
--cc=daniel.schoepe@googlemail.com \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).