tweaks for handling parts in reply

2011-06-09 Thread Austin Clements
It's too bad this requires lots of special-casing.  I dug into mutt,
hoping to find some simpler way to choose what to reply to, but all I
found was a far more complicated collection of heuristics (see
mutt_body_handler if you're interested).

Should reply *ever* include a "Non-text part" message?  It certainly
doesn't help the receiver of the reply and presumably the sender will
either notice that a part is missing if they care about it, or
probably miss the Non-text part message anyway if they don't.

On Wed, Jun 8, 2011 at 3:30 PM, Jameson Graef Rollins
 wrote:
> This is a small set of tweaks to remove unneccessary "Non-text part:"
> lines in reply, for parts that really don't need to be mentioned.
>
> This patch set is not really related to the series that it is being
> sent in reply to, but it has been worked on top of the message/rfc822
> rework of the multipart test, so it's being sent in reply to that
> message.
>
> jamie.
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>


[PATCH] Add dir-locals style variables for C++, Elisp, and shell code.

2011-06-09 Thread Austin Clements
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
 .dir-locals.el |   24 
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index cbdb1f9..aea630b 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -1,7 +1,23 @@
 ; emacs local configuration settings for notmuch source
 ; surmised by dkg on 2010-11-23 13:43:18-0500
+; amended by amdragon on 2011-06-06

-((c-mode . ((indent-tabs-mode . t)
-(tab-width . 8)
-(c-basic-offset . 4)
-(c-file-style . "linux"
+((c-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . "linux"))
+ (c++-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . "linux"))
+ (emacs-lisp-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8))
+ (shell-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (sh-basic-offset . 4)
+  (sh-indentation . 4))
+ )
-- 
1.7.5.1



[PATCH] Add dir-locals style variables for C++, Elisp, and shell code.

2011-06-09 Thread Austin Clements
Also, slightly reformat dir-locals.el so that the settings align and
to make it friendlier for future additions.
---
 .dir-locals.el |   24 
 1 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index cbdb1f9..aea630b 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -1,7 +1,23 @@
 ; emacs local configuration settings for notmuch source
 ; surmised by dkg on 2010-11-23 13:43:18-0500
+; amended by amdragon on 2011-06-06
 
-((c-mode . ((indent-tabs-mode . t)
-(tab-width . 8)
-(c-basic-offset . 4)
-(c-file-style . linux
+((c-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . linux))
+ (c++-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (c-basic-offset . 4)
+  (c-file-style . linux))
+ (emacs-lisp-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8))
+ (shell-mode
+  (indent-tabs-mode . t)
+  (tab-width . 8)
+  (sh-basic-offset . 4)
+  (sh-indentation . 4))
+ )
-- 
1.7.5.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: User-defined sections in notmuch-hello

2011-06-09 Thread Austin Clements
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.scho...@googlemail.com wrote:
 On Fri, 27 May 2011 20:52:01 +0200, Daniel Schoepe 
 daniel.scho...@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch