On Tue, 03 Jan 2012 13:45:14 -0800, Jameson Graef Rollins
wrote:
> Unfortunately, auto encrypting of replies to encrypted emails is not yet
> implemented. It is desperately needed, though, obviously. So this is a
> good excuse to start a discussion about how we could achieve this.
>
On Thu, 12 Jan 2012 20:05:14 +0100, Gregor Zattler wrote:
> But how about not only replying encrypted but encrypting every
> email if possible? "Possible" could mean different things,
> though:
This is already easy to do in emacs, and doesn't require any special
notmuch support:
(add-hook 'mess
On Fri, 13 Jan 2012 05:05:35 -0400, David Bremner wrote:
> I thought about this a bit more, and I agree that at least the release
> candidates (basically anything tagged on branch release) ought to be
> merged back to master. Since any series of bugfix patches seems to be
> cause for a new release
On Thu, 12 Jan 2012 18:12:16 +0100, Pieter Praet wrote:
> To allow for expansion whilst keeping everything tidy and organized,
> move all defcustom/defface variables to the following subgroups,
> defined in notmuch-lib.el:
Baring the issue that the Davids brought up about the sub group
descriptio
I like all of Austin's description suggestions.
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Fri, 13 Jan 2012 18:07:01 -0500, Austin Clements wrote:
> This addresses Jani's comments and improves some of the text and code
> comments.
This is a really nice feature addition, Austin. And it works like a
charm. ++1.
A couple of small comments to follow.
jamie.
pgp6BJym8ezVU.pgp
Descr
It looks like something in this patch is causing the following build
warning:
CXX -O2 lib/query.o
lib/query.cc:26:8: warning: ‘_notmuch_query’ declared with greater visibility
than the type of its field
‘_notmuch_query::exclude_terms’ [-Wattributes]
However, I can't quite figure out what's causi
This patch looks fine. Philosophical UI discussion to follow:
On Fri, 13 Jan 2012 18:07:04 -0500, Austin Clements wrote:
> +if (notmuch_config_get_auto_exclude_tags (config, &tmp) == NULL) {
> + const char *tags[] = { "deleted", "spam" };
> + notmuch_config_set_auto_exclude_tags (con
On Mon, 16 Jan 2012 08:39:30 +, David Edmondson wrote:
> Is there a mechanistic way to determine the correct behaviour in this
> respect? I suspect that it's exactly the kind of thing that Carl wanted
> to be included in 'notmuch' itself, so that other UIs can benefit.
Agreed. I think it's g
On Sun, 15 Jan 2012 12:16:36 +, Mark Walters
wrote:
> Define a keymap for attachment buttons to allow multiple actions.
> Define 3 possible actions:
> save attachment: exactly as currently,
> view attachment: uses mailcap entry,
> view attachment with user chosen program
Great im
On Mon, 16 Jan 2012 22:06:15 +0400, Dmitry Kurochkin
wrote:
> Since this patches got in, I have yet to send a single email to the
> address(es) I intend to :( I am really used to the bindings and this
> change is a pain. From IRC discussion, it seems like I am not alone
> here.
Yeah, this has b
On Mon, 16 Jan 2012 09:12:38 +, David Edmondson wrote:
> I don't think that anything should be excluded from the search results
> by default, at least not as a default behaviour of the 'notmuch'
> binary.
>
> Having "deleted" and "spam" as default settings in the configuration
> file might be
On Sat, 14 Jan 2012 19:17:32 -0500, Austin Clements wrote:
> This fixes the symbol visibility warning Jamie pointed out.
LGTM. I'm using this now and it works like a charm.
jamie.
pgpYAMEajXyca.pgp
Description: PGP signature
___
notmuch mailing list
On Mon, 16 Jan 2012 21:38:30 +, Mark Walters
wrote:
> Define a keymap for attachment buttons to allow multiple actions.
Thanks, Mark. This new patch works great. I'm still not quite sure why
it wasn't working for me before, but this patch works great.
+1
We'll need to add a ":group notmu
On Mon, 16 Jan 2012 15:18:18 -0700, Jeremy Nickurak
wrote:
> 1) If no exclude options are in the config file, none should be used.
> 2) On notmuch setup, "deleted" and "spam" should be added to .notmuch-config
That's correct.
jamie.
pgpte3TFLdDYd.pgp
Description: PGP signature
___
On Mon, 16 Jan 2012 23:32:00 -0500, Austin Clements wrote:
> Cleanup is the type of pain that should only be suffered once, so I'd
> be much happier with this if there was an accompanying git hook that
> prevented more mis-formatted code from slipping in.
Agreed. However, if we're really going t
On Tue, 17 Jan 2012 07:48:27 -, Mark Foxwell
wrote:
> Not sure if you're aware of this?
Yes, we are aware. There are actually two fresh patches to the list to
address this, though:
id:"1326758199-18058-1-git-send-email-schno...@schnouki.net"
id:"1326767208-25174-1-git-send-email-ape...@ig
I have reworked the show-mode message/thread archiving improvements from
two now-obsolete patch sets:
id:"1325975294-646-1-git-send-email-jroll...@finestructure.net"
id:"1325986015-22510-1-git-send-email-jroll...@finestructure.net"
All the "delete" stuff has been removed from this series, and I j
This provides a smoother message processing flow by reducing the
number of key presses needed for these common operations.
---
emacs/notmuch-show.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 6b2e6e9..21eadbe 100644
This adds two new message archiving functions that parallel the thread
archiving functions: notmuch-show-archive-message{,-then-next}. The
former also takes a prefix argument to unarchive the message (ie. put
back in inbox).
---
emacs/notmuch-show.el | 17 +
1 files changed, 17
This changes the default key bindings for the 'a' key in notmuch-show
mode. Instead of archiving the entire thread, it now just archives
the current message, and then advance to the next open message
(archive-message-then-next). 'A' is now bound to the previous
archive-thread-then-next function.
Brake up notmuch-show-archive-thread-internal into two new functions:
notmuch-show-tag-thread-internal: applies a tag to all messages in
thread. If option remove flag is t, tags will be removed instead of
added.
notmuch-show-next-thread: moves to the next thread in the search
result. If given a
This will allow for keybindings that achieve a smoother message
processing flow by reducing the number of key presses needed for most
common operations.
---
emacs/notmuch-show.el | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmu
This function is now just for archiving the current thread. A new
function is created to archive-then-next. The 'a' key binding is
updated accordingly.
This will allow people to bind to the simple thread archiving function
without the extra navigation. The archive-thread function now also
takes
+1.
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
This removes an inaccuracy in the thread archiving function, and adds
a clarification to the message archiving function.
---
Late catch on some documentation inaccuracies. Apologies.
emacs/notmuch-show.el | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/emacs/no
Use this standard function, to keep thread navigation in one place.
---
emacs/notmuch.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index ef4dcc7..e4bca51 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -617,7 +617,7 @@ thr
Now that Austin's excellent tag exclusion patch set [0] has been pushed,
the question remains if we want to support any delete-handling key
bindings in emacs.
Based on the show-mode improvements I recently sent [1], the following
patch set implements thread and message delete keys.
This is the la
No functional change here. The help message previously referred to
the "delete" tag, but "deleted" is now preferred, so hopefully this
will reduce any potential confusion.
---
emacs/notmuch.el |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/not
This mimics the archiving keys ('a' and 'A').
---
emacs/notmuch-show.el |2 ++
emacs/notmuch.el |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 141241d..f0259d5 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notm
---
emacs/notmuch-show.el | 46 ++
emacs/notmuch.el |8
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index c1d721e..141241d 100644
--- a/emacs/notmuch-show.el
+++ b/emac
On Tue, 17 Jan 2012 15:10:40 -0500, Aaron Ecay wrote:
> This should be a docstring instead of a comment. (This applies equally
> to the old version)
We're not currently in the habit of adding doc strings for
non-interactive programs. Do we need to go down that route?
jamie.
pgpxWGCN6f8xU
On Tue, 17 Jan 2012 15:13:47 -0500, Aaron Ecay wrote:
> If this function uses the prefix arg, its interactive call should be
> “(interactive "P")”. This applies equally to the -thread variant in
> patch 2/6, but I made the comment here because that diff doesn’t show
> the function contiguously.
On Wed, 18 Jan 2012 08:12:27 +, David Edmondson wrote:
> No need for brackets around `r'. Please put initialised local variables
> before uninitialised.
Yeah, that's another comment of Aron's that I forgot to fix this time
around. Sorry about that.
> > (while (and (setq r (notmuch-show
On Wed, 18 Jan 2012 08:38:23 +, David Edmondson wrote:
> Something must create the initial configuration file if none exists. I'd
> be okay with that code adding 'deleted' and 'spam' to the excluded list.
>
> This would mean that an existing user would see no change without taking
> some actio
On Wed, 18 Jan 2012 10:45:06 -0400, David Bremner wrote:
> The advantage of this rather than just writing lots of little lambdas is
> that it combines adding and deleting, and it could be done via
> customize.
Is all of this really easier than just adding the following to your
.emacs?:
(define-k
On Wed, 18 Jan 2012 09:52:52 +, David Edmondson wrote:
> I agree that as long as no keys are pre-bound it will make little
> difference. That just transfers the discussion to the thread about
> adding the bindings, which seems silly.
I think that's ok. The tag exclusion is in, which is great
On Wed, 18 Jan 2012 08:56:26 +, David Edmondson wrote:
> I'm used to the cursor going to the bottom of the thread to let me know
> that I reached the end, then I hit 'space' and move on to the next
> thread. Will that behaviour be retained with this patch? (Well,
> including your other patch w
On Wed, 18 Jan 2012 15:03:52 -0400, David Bremner wrote:
> My main motivation here is (as you can probably see from the example)
> dealing with patches, and in that setting, tagging the whole thread is
> is almost never what you want.
The example I sent was about tagging individual message, not t
On Wed, 18 Jan 2012 15:56:45 -0500, Austin Clements wrote:
> Since "auto_exclude_tags" is long and its description is multi-line,
> start the description on the next line and indent it consistently.
lgtm.
pgpMNovZHNU66.pgp
Description: PGP signature
_
On Wed, 18 Jan 2012 20:04:44 -0400, David Bremner wrote:
> If we're going to go the way of providing a toolkit/api for uses to make
> their own bindings, then I think that we should make the effort to
> provide a proper info document with the distribution, rather than
> relying on the wiki. Of co
On Thu, 19 Jan 2012 09:34:07 +, David Edmondson wrote:
> The `mm-inlinable-p' function works better if it has access to the
> data of the relevant part, so load that content before calling it.
>
> Don't load the content for parts that the user has indicated no desire
> to inline.
So I'm a li
On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements wrote:
> Shouldn't we only be doing this for parts with inline (or not
> attachment) content-disposition? That's cheap to check. Or do we
> actually want things like image attachments to get inlined, despite
> their disposition?
This is a good
On Fri, 20 Jan 2012 09:43:31 +, David Edmondson wrote:
> The buttons inserted for encrypted parts are slightly different now -
> previously the logic was that if a part was encrypted it would have
> the signature status inserted only if the encryption status was
> specified. Now the signature
On Fri, 20 Jan 2012 17:00:27 -0500, Austin Clements wrote:
> Later runs of "notmuch new" won't scan these files again and won't
> print warnings.
Nice. +1. LGTM.
jamie.
pgp5iKg7NwEt5.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@n
On Sat, 21 Jan 2012 22:16:08 +0100, Peter Feigl wrote:
> The output routines have been rewritten so that logical structure
> (objects with key/value pairs, arrays, strings and numbers) are
> written instead of ad-hoc printfs. This allows for easier adaptation
> of other output formats, as only the
On Sun, 22 Jan 2012 00:21:37 +0100, "Peter Feigl" wrote:
> What kind of documentation should I include?
Update the man page to describe the new format and command line options.
> The test suite should work fine, *if* it compares EXPECTED and OUTPUT
> not character-by-character, but rather by pre
On Fri, 20 Jan 2012 09:43:31 +, David Edmondson wrote:
> Instead, allow the caller to specify some parameters for the
> button. Rework `notmuch-show-insert-part-multipart/signed' and
> `notmuch-show-insert-part-multipart/encrypted' accordingly, moving
> most of the code into a common
> `notmuc
On Wed, 18 Jan 2012 15:28:24 -0500, Austin Clements wrote:
> This adds support for self-recursive message formatters, while
> maintaining backwards compatibility with old style formatters. After
> this, each format can be converted to the new style individually and,
> once they're all converted,
On Sun, 22 Jan 2012 23:14:13 +0100, Xavier Maillard wrote:
>
> On Thu, 19 Jan 2012 20:19:03 +0100, Pieter Praet wrote:
> > If the 'search.exclude_tags' option is missing from the config file,
> > its value is automatically set to "deleted;spam;". Taking PoLS/DWIM
> > into account, this should p
On Mon, 23 Jan 2012 06:05:27 +0100, Pieter Praet wrote:
> You definitely have a point, but then again, who are we to assume that
> the terms "deleted" and "spam" have the *exact* same meaning for
> everyone? (also see id:"8739bbo0br@praet.org")
Hrm. I'm not sure I buy this. Words already h
On Mon, 23 Jan 2012 07:22:25 +, Jani Nikula wrote:
> There really should be a definitive list of tags that are special to
> lib/cli/emacs (like "inbox", "unread", "deleted", ...), or are
> recommended for specific purposes (like "new" as an intermediate tag
> before more sophisticated tagging)
v2 of this series to follow, based on some good feedback from David and
Aaron.
Reminder:
> The last patch changes the default keybind for the 'a' key to archive
> just the current message, and not the entire thread. In my opinion this
> is a *much* more sensible binding for this key. I actually
This adds two new message archiving functions that parallel the thread
archiving functions: notmuch-show-archive-message{,-then-next}. The
former also takes a prefix argument to unarchive the message (ie. put
back in inbox).
---
emacs/notmuch-show.el | 17 +
1 files changed, 17
Brake up notmuch-show-archive-thread-internal into two new functions:
notmuch-show-tag-thread-internal: applies a tag to all messages in
thread. If option remove flag is t, tags will be removed instead of
added.
notmuch-show-next-thread: moves to the next thread in the search
result. If given a
This provides a smoother message processing flow by reducing the
number of key presses needed for these common operations.
---
emacs/notmuch-show.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index fe7ec6a..8c71d03 100644
This will allow for keybindings that achieve a smoother message
processing flow by reducing the number of key presses needed for most
common operations.
---
emacs/notmuch-show.el | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/no
This function is now just for archiving the current thread. A new
function is created to archive-then-next. The 'a' key binding is
updated accordingly.
This will allow people to bind to the simple thread archiving function
without the extra navigation. The archive-thread function now also
takes
This changes the default key bindings for the 'a' key in notmuch-show
mode. Instead of archiving the entire thread, it now just archives
the current message, and then advance to the next open message
(archive-message-then-next). 'A' is now bound to the previous
archive-thread-then-next function.
On Mon, 23 Jan 2012 08:24:44 +, Jani Nikula wrote:
> The lib *does* assign special meaning to the tags it syncs to maildir
> flags: draft, flagged, passed, replied, unread. (deleted used to be part
> of the list.) The cli does have to request the syncing, but the mapping
> is in the lib (flag2
On Mon, 23 Jan 2012 08:16:03 +, David Edmondson wrote:
> There was no problem with the logic. The code in the two functions was
> almost identical, so I'd like to make any future changes in just one
> place.
>
> You didn't actually answer my question - is the logic in the new
> function correc
On Mon, 23 Jan 2012 11:02:04 +, David Edmondson wrote:
> On Mon, 23 Jan 2012 00:34:23 -0800, Jameson Graef Rollins
> wrote:
> > -(defun notmuch-show-next-open-message ()
> > +(defun notmuch-show-next-open-message (&optional pop-at-end)
> >"Show the n
On Mon, 23 Jan 2012 17:55:14 +, David Edmondson wrote:
> On that basis, I hope no-one will complain if I fix them as a 'drive by'
> during another change...
Hrm. I don't think that follows. Unless the patch is already touching
that code, I would really prefer we continue to enforce that unr
On Tue, 24 Jan 2012 12:53:38 +, David Edmondson wrote:
> Instead, allow the caller to specify some parameters for the
> button. Rework `notmuch-show-insert-part-multipart/signed' and
> `notmuch-show-insert-part-multipart/encrypted' accordingly.
Hi, David. I was thinking about this, and it se
On Tue, 24 Jan 2012 19:25:19 +, David Edmondson wrote:
> On Tue, 24 Jan 2012 10:46:57 -0800, Jameson Graef Rollins
> wrote:
> > Is there a reason it's really necessary to make this change? Can't
> > callers just ignore the returned button if they don't care
This function is now just for archiving the current thread. A new
function is created to archive-then-next. The 'a' key binding is
updated accordingly.
This will allow people to bind to the simple thread archiving function
without the extra navigation. The archive-thread function now also
takes
We should always use the dedicated search mode navigation functions,
in case navigation mechanics change down the line.
---
emacs/notmuch-show.el |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e6a5b31..a0045fc 100644
-
This changes the default key bindings for the 'a' key in notmuch-show
mode. Instead of archiving the entire thread, it now just archives
the current message, and then advance to the next open message
(archive-message-then-next). 'A' is now bound to the previous
archive-thread-then-next function.
This will allow for keybindings that achieve a smoother message
processing flow by reducing the number of key presses needed for most
common operations.
---
emacs/notmuch-show.el | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/emacs/notmuch-show.
---
emacs/notmuch-show.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 4de552d..a4f83ee 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1399,7 +1399,7 @@ buffer."
(goto-char (point-max))
Final v3 rework of this patch series:
* reworked pop-at-end patch to be much simpler (which also happens to
get around other issues with this patch that dme had)
* added pop-at-end function to both show-next-...message functions
* fixed call to search-next-thread in show-next-thread function
* a
Brake up notmuch-show-archive-thread-internal into two new functions:
notmuch-show-tag-thread-internal: applies a tag to all messages in
thread. If option remove flag is t, tags will be removed instead of
added.
notmuch-show-next-thread: moves to the next thread in the search
result. If given a
This adds two new message archiving functions that parallel the thread
archiving functions: notmuch-show-archive-message{,-then-next}. The
former also takes a prefix argument to unarchive the message (ie. put
back in inbox).
---
emacs/notmuch-show.el | 17 +
1 files changed, 17
This provides a smoother message processing flow by reducing the
number of key presses needed for these common operations.
---
emacs/notmuch-show.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 8837402..b309b5b 100644
On Tue, 24 Jan 2012 16:34:32 -0500, micah anderson wrote:
> David replied to it because it was sent to him, but the list email
> hasn't come through yet (I want this functionality, so I'm dying to see
> the patch!)
Hey, Micah. There an outstanding patch series that add a new JSON reply
format, a
On Wed, 25 Jan 2012 06:23:01 +, David Edmondson wrote:
> Can you explain the logic that will apply to determine whether or not a
> reply is encrypted?
My plan was to modify notmuch-reply.c to include a flag in the JSON
output if the message being replied to was encrypted. The emacs reply
fun
On Wed, 25 Jan 2012 17:21:26 +0200, Tomi Ollila wrote:
> -type GMimeObject mime_node_t
> +type GMimeObject GMimeCryptoContext GMimeCipherContext
> +type mime_node_t notmuch_message_t
This must be a mistake. Presumably this hasn't been properly rebased
against the latest master, which includes Au
On Wed, 25 Jan 2012 10:20:26 +, David Edmondson wrote:
> Isn't it still necessary to ensure that you have encryption keys
> appropriate to the recipient?
I want to ensure that all replies to encrypted to be encrypted. I would
rather have the reply fail outright than fall back to unencrypted.
On Wed, 25 Jan 2012 20:24:19 +0200, Tomi Ollila wrote:
> On Wed, 25 Jan 2012 08:41:52 -0800, Jameson Graef Rollins
> wrote:
> > On Wed, 25 Jan 2012 17:21:26 +0200, Tomi Ollila wrote:
> > > -type GMimeObject mime_node_t
> > > +type GMimeObject GMimeCryptoContext
On Wed, 25 Jan 2012 10:29:30 -0800, Jameson Graef Rollins
wrote:
> On Wed, 25 Jan 2012 20:24:19 +0200, Tomi Ollila wrote:
> > On Wed, 25 Jan 2012 08:41:52 -0800, Jameson Graef Rollins
> > wrote:
> > > On Wed, 25 Jan 2012 17:21:26 +0200, Tomi Ollila
> > >
On Wed, 25 Jan 2012 20:19:03 -0500, Austin Clements wrote:
> One very common cause of this is someone using "reply" to get an
> initial set of recipients, but then replacing the entire message and
> subject (presumably without realizing that the mail is still tracking
> what it was a reply to). T
On Thu, 26 Jan 2012 02:47:57 -0500, Daniel Kahn Gillmor
wrote:
> those of you who run debian might be interested in the gmime2.6
> packaging which i cobbled together for debian from the existing gmime2.4
> packaging:
>
> http://bugs.debian.org/657426
>
> Those of you developing notmuch with th
This adds a test for proposed rfc6068 "mailto:"; URI handling. The
proposed function would be called 'notmuch-mua-mailto'. The test
provides an example mailto: string that should test some subset of the
rfc6068 specification: http://tools.ietf.org/html/rfc6068
---
test/emacs | 29 +
The new function 'notmuch-mua-mailto' provides an interactive handler
for rfc6068 "mailto:"; URIs. It attempts to implement the rfc6068
specification: http://tools.ietf.org/html/rfc6068
More decoding of the mailto string needs to be done, as is evident by
the fact that the mailto test remains bro
On Wed, 25 Jan 2012 10:18:46 +, David Edmondson wrote:
> The crypto toggle previously worked using an argument to
> `notmuch-show' and various other functions and relied on killing and
> re-creating the notmuch-show-mode buffer. Various other
> pseudo-buffer-local variables were present based
On Mon, 30 Jan 2012 15:43:10 +, David Edmondson wrote:
> On Sun, 29 Jan 2012 11:33:44 -0800, Jameson Graef Rollins
> wrote:
> > The new function 'notmuch-mua-mailto' provides an interactive handler
> > for rfc6068 "mailto:"; URIs. It attempts to i
On Mon, 30 Jan 2012 11:26:32 +, David Edmondson wrote:
> The simplest approach is to have `notmuch-show-process-crypto' inherit
> the value of `notmuch-crypto-process-mime' when any `notmuch-show-mode'
> buffers are first created. Currently that happens in only one place
> (`notmuch-show'), wh
On Mon, 30 Jan 2012 16:30:59 +, David Edmondson wrote:
> v3:
> - Add a toggle for line truncation (>).
> - Retain the state of a show buffer across a call to refresh (which
>includes the various toggles here).
>
> David Edmondson (5):
> emacs: Rework crypto switch toggle.
> emacs: A
On Mon, 30 Jan 2012 16:52:20 +, David Edmondson wrote:
> The blank line doesn't really change position, but is now considered
> to be part of the body rather than part of the headers. This means
> that it is visible when the body is visible rather than when the
> headers are visible.
This def
On Tue, 31 Jan 2012 01:18:55 +, Mark Walters
wrote:
> One of the mails has an in-reply-to header which looks like
>
> In-reply-to: Message from Carsten Dominik of
> "Tue, 15 Mar 2011 12:18:51 BST."
> <17242340-a14f-495a-b144-20c96d52b...@gmail.com>
!!
__
On Tue, 31 Jan 2012 11:40:00 +, Mark Walters
wrote:
> The reason I went for verbose do-not-exclude was to try and avoid the
> double negative ambiguity: does no-exclude mean do-not-exclude or
> do-note-return-excluded-messages. Possibly I am worrying needlessly, and
> obviously I am quite hap
On Tue, 31 Jan 2012 08:09:08 +, David Edmondson wrote:
> On Mon, 30 Jan 2012 09:47:34 -0800, Jameson Graef Rollins
> wrote:
> > One thing I've noticed, which isn't actually part of this patch, is that
> > the long-line truncation doesn't respect the indenta
On Wed, 1 Feb 2012 11:19:54 +0400, Dmitry Kurochkin
wrote:
> The down side of this approach is that diff argument order depends on
> test_expect_equal_file() argument order. So sometimes we get diff
> from expected to actual results, and sometimes the other way around.
> But the files are alway
On Wed, 01 Feb 2012 14:37:53 +0400, Dmitry Kurochkin
wrote:
> On Wed, 01 Feb 2012 12:18:08 +0200, Tomi Ollila wrote:
> >
> > There are at least these options here
> >
> > 1) go through all ~100 places where test_expect_equal_file is used
> >and fix the call order: quick look tells that the
On Wed, 1 Feb 2012 11:19:54 +0400, Dmitry Kurochkin
wrote:
> Before the change, test_expect_equal_file() function treated the first
> argument as "actual output file" and the second argument as "expected
> output file". When the test fails, the files are copied for later
> inspection. The firs
On Tue, 24 Jan 2012 20:08:14 +, Clint Adams wrote:
> I just received an email in RTL script and it was rendered incorrectly
> in the emacs interface. Does anyone know what to do about this?
More info please. What is "RTL script"? Is that "right to left"? If
so, yikes. I can't even imagin
On Thu, 02 Feb 2012 19:26:53 +0200, Jani Nikula wrote:
> Do you have all those email addresses in the user.other_email
> configuration option in your ~/.notmuch-config? It should do the trick,
> though I can see that it might get a bit tedious if you use plenty of
> email addresses like above.
Ye
Hey, Dmitry. I'm so sorry I sent my last email on your original patch
before I saw this new series. I do now like your original proposal
better, since it shows the diff based the names the caller provides,
which I now agree is probably the clearest and most robust solution.
The second patch in th
On Fri, 03 Feb 2012 18:04:05 +0400, Dmitry Kurochkin
wrote:
> Actually, we can do both: check file name for consistent diff order
> (from expected to actual) and use file names that the caller provides.
>
> What do you think?
I'm not sure it's worth it, but I suppose that's fine.
jamie.
pgpD
Sorry to be so late on this, but I'm not a big fan of this new feature.
I would prefer to always see the subject (or any other field for that
matter) as is.
As a principle I would prefer there not be text replacements unless it's
very clear that text has been replaced. Buttons work because it's c
1 - 100 of 1816 matches
Mail list logo
