esented, and store it in the index as a property.
>this could be combined with the suggestions above.
+1 for heuristics.
> what do you think? what ideas are missing from the branstorm above? I'd
> love to hear from people with multilingual mailboxes about how we might
> be able
all the things PGP using `gmime-3`?
Yes, they use GPGME instead of a custom wrapper:
https://mail.gnome.org/archives/gmime-devel-list/2017-April/msg2.html
BTW, I created a merge-request to have GMime 3 in Nixpkgs:
https://github.com/NixOS/nixpkgs/pull/28796
Servilio
--
Servil
Hi David,
I like the idea of aligning the headers, but won't padding with spaces
from the left break code that expects at the beginning of the line?
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo
This commit adds an extra button at the end of the search entries that
allows deleting that individual search from the history. A short
confirmation (?y? or ?n?) is made before taking action.
---
emacs/notmuch-hello.el | 25 +++--
1 file changed, 23 insertions(+), 2
The button to clear the recent searches in notmuch-hello is easy to
press accidentally while moving around the, clearing potentially
useful searches with no way of recovering them.
---
emacs/notmuch-hello.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Hi,
Two patches that enhance the notmuch-hello search history UI. Though
minor changes, I find them very helpful.
This second iteration includes the modifications suggested by Jani and
Tomi.
Servilio Afre Puentes (2):
emacs: hello: ask confirmation for clearing recent searches
emacs: hello
Jani Nikula writes:
> On Fri, 03 May 2013, Servilio Afre Puentes wrote:
>> Two patches that enhance the notmuch-hello search history UI. Though
>> minor I find them very helpful.
>
> Both seem to work as advertised; I did not look at the code much. A
> minor bikeshed
Jani Nikula j...@nikula.org writes:
On Fri, 03 May 2013, Servilio Afre Puentes servi...@gmail.com wrote:
Two patches that enhance the notmuch-hello search history UI. Though
minor I find them very helpful.
Both seem to work as advertised; I did not look at the code much. A
minor bikeshed
This commit adds an extra button at the end of the search entries that
allows deleting that individual search from the history. A short
confirmation (?y? or ?n?) is made before taking action.
---
emacs/notmuch-hello.el | 26 --
1 file changed, 24 insertions(+), 2
The button to clear the recent searches in notmuch-hello is easy to
press accidentally while moving around the, clearing potentially
useful searches with no way of recovering them.
---
emacs/notmuch-hello.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
Hi,
Two patches that enhance the notmuch-hello search history UI. Though
minor I find them very helpful.
Servilio Afre Puentes (2):
emacs: hello: ask confirmation for clearing recent searches
emacs: hello: allow deleting individual searches in the history
emacs/notmuch-hello.el | 31
Hi,
Two patches that enhance the notmuch-hello search history UI. Though
minor I find them very helpful.
Servilio Afre Puentes (2):
emacs: hello: ask confirmation for clearing recent searches
emacs: hello: allow deleting individual searches in the history
emacs/notmuch-hello.el | 31
The button to clear the recent searches in notmuch-hello is easy to
press accidentally while moving around the, clearing potentially
useful searches with no way of recovering them.
---
emacs/notmuch-hello.el | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
This commit adds an extra button at the end of the search entries that
allows deleting that individual search from the history. A short
confirmation («y» or «n») is made before taking action.
---
emacs/notmuch-hello.el | 26 --
1 file changed, 24 insertions(+), 2
, as the longer they go, the more hidden text there will be
And because of this, though you might already have a proper method for
measuring it, the results are different. I thought about this because
my searches have only ~180 threads, yet I could notice the difference.
Servilio
, as the longer they go, the more hidden text there will be
And because of this, though you might already have a proper method for
measuring it, the results are different. I thought about this because
my searches have only ~180 threads, yet I could notice the difference.
Servilio
I join the petition, I have been using for a couple of days and the
difference is noticeable.
Servilio
join the petition, I have been using for a couple of days and the
difference is noticeable.
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
What about encoding in notmuch the elements composing the line, print
the elements with a separator that would be encoded if it appears in
an element, then do the reverse in emacs. One such encoding might be
URL-encoding.
Servilio
What about encoding in notmuch the elements composing the line, print
the elements with a separator that would be encoded if it appears in
an element, then do the reverse in emacs. One such encoding might be
URL-encoding.
Servilio
___
notmuch mailing
On 3 July 2011 08:44, David Bremner wrote:
> On Sun, 3 Jul 2011 03:14:03 -0400, servilio wrote:
>>
>> I think there is no need for tags on master, "make dist" should only
>> be run on the "release" branch, right?
>
> It isn't just about make
.7
>
> This is all a bit hypothetical at this point of course, since there has
> never been a bug-fix release.
But there shouldn't be any issue, any changes done in "release" should
be merged back to master as I see it.
Servilio
On 2 July 2011 13:30, David Bremner wrote:
> On Sat, 2 Jul 2011 11:59:04 -0400, servilio wrote:
>> What about having Carl do the merging of features into a develop
>> branch[1], then the release manager prepares a release in a release
>> branch, merging back and tagging int
On 2 July 2011 13:30, David Bremner da...@tethera.net wrote:
On Sat, 2 Jul 2011 11:59:04 -0400, servilio servi...@gmail.com wrote:
What about having Carl do the merging of features into a develop
branch[1], then the release manager prepares a release in a release
branch, merging back
rge back to master, tag).
This workflow would keep a nice useful history while allowing even
more independence between the feature merging and release process,
what do you think?
Servilio
[1] Or next, or whatever other name is better understood by the community.
between the feature merging and release process,
what do you think?
Servilio
[1] Or next, or whatever other name is better understood by the community.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
te notmuch_database_upgrade[2] to fill in the new data for the
documents missing it
- include an upgradedb command that wraps notmuch_database_upgrade[2]
- have notmuch search prints a warning about running a DB version less
than the runtime and suggests running upgradedb
Regards,
Servilio
[1] http://git.notm
in the new data for the
documents missing it
- include an upgradedb command that wraps notmuch_database_upgrade[2]
- have notmuch search prints a warning about running a DB version less
than the runtime and suggests running upgradedb
Regards,
Servilio
[1] http://git.notmuchmail.org/git/notmuch/blob
view, this change makes me a bit uncomfortable since it apparently
> merges two cases together, and makes an error (no Subject)
> indistinguishable from an odd situation (Subject of empty string).
> Or am I missing something here?
I see the the same issue.
Servilio
, this change makes me a bit uncomfortable since it apparently
merges two cases together, and makes an error (no Subject)
indistinguishable from an odd situation (Subject of empty string).
Or am I missing something here?
I see the the same issue.
Servilio
would be to add the feature to notmuch
new of taking the initial tags from a custom header (e.g.:
X-Notmuchmail-Agent-Initial-Tags), and use
message-ignored-mail-headers[1] to filter this header out the sent
message.
Servilio
[1] http://www.gnu.org/software/emacs/manual/html_mono/message.html#Mail
2011/3/14 Kristoffer Ström kristof...@rymdkoloni.se:
Have you looked at 'ido-completing-read that comes with ido-mode?
[...]
It allows for fuzzy matching on any part of the name.
Yes, that's what I use, yes with flex matching.
Regards,
Servilio
2011/3/14 Kristoffer Str?m :
> Have you looked at 'ido-completing-read that comes with ido-mode?
[...]
> It allows for fuzzy matching on any part of the name.
Yes, that's what I use, yes with flex matching.
Regards,
Servilio
at:
git://git.latertulia.org/servilio/notmuch.git
In the branch complete-name-and-address-v2. There is a web interface
if you prefer to see the changes, just use "http" as the protocol in
your web browser.
The first few changes in the branch are fixes and small enhancements I
found whi
Seeding the autocompletion with the first match makes it harder to see
what the other matches are, as all the extra characters would need to
be deleted before being able to see the matches.
---
emacs/notmuch-address.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Thus avoid disrupting usage of regular expressions functions
elsewhere.
---
emacs/notmuch-address.el |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 52e320d..2960da9 100644
--- a/emacs/notmuch-address.el
+++
There is no need to move the cursor to the position if you can
retrieve its value directly.
---
emacs/notmuch-address.el |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 1a7c577..52e320d 100644
---
at:
git://git.latertulia.org/servilio/notmuch.git
In the branch complete-name-and-address-v2. There is a web interface
if you prefer to see the changes, just use http as the protocol in
your web browser.
The first few changes in the branch are fixes and small enhancements I
found while working
There is no need to move the cursor to the position if you can
retrieve its value directly.
---
emacs/notmuch-address.el |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 1a7c577..52e320d 100644
---
Thus avoid disrupting usage of regular expressions functions
elsewhere.
---
emacs/notmuch-address.el |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 52e320d..2960da9 100644
--- a/emacs/notmuch-address.el
+++
Hi Michal,
On 20 November 2010 16:15, Michal Sojka wrote:
> On Sat, 20 Nov 2010, servilio wrote:
>> This implementation uses GNU readline for the prompt and command
>> history, with the default file completion enabled. GLib is used to
>> split the read line into an argument
(including development files such as
headers)"
echo " http://talloc.samba.org/;
fi
+if [ $have_readline -eq 0 ]; then
+ echo " The readline library (including development files such as
headers)"
+ echo " http://tiswww.case.edu/php/
/notmuch.c
@@ -18,8 +18,17 @@
*
* Authors: Carl Worth cwo...@cworth.org
* Keith Packard kei...@keithp.com
+ * Servilio Afre Puentes servi...@gmail.com
*/
+#include stdio.h
+
+#include string.h
+
+#include glib.h
+#include readline/readline.h
+#include readline/history.h
Hi Michal,
On 20 November 2010 16:15, Michal Sojka sojk...@fel.cvut.cz wrote:
On Sat, 20 Nov 2010, servilio wrote:
This implementation uses GNU readline for the prompt and command
history, with the default file completion enabled. GLib is used to
split the read line into an arguments list
confusing the issue.
And "xargs -L1 ..." will solve the issue in a nicer way. So the above would be:
notmuch search --output=files tag:deleted | xargs -L1 rm
Servilio
.
And xargs -L1 ... will solve the issue in a nicer way. So the above would be:
notmuch search --output=files tag:deleted | xargs -L1 rm
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
> running notmuch cat id: which will always give the correct
> content.
Wouldn't it be more efficient to query notmuch for the filename using
the message ID we store in the DB? When network usage is implemented,
tramp can give us transparent remote file access in emacs.
Regards,
Servilio
id:message-id which will always give the correct
content.
Wouldn't it be more efficient to query notmuch for the filename using
the message ID we store in the DB? When network usage is implemented,
tramp can give us transparent remote file access in emacs.
Regards,
Servilio
ailable (for
me a sign of more faith in free software than the Github people).
An alternative would be to have a list of git branches in the wiki,
with description, clone URL, etc.
Servilio
is available (for
me a sign of more faith in free software than the Github people).
An alternative would be to have a list of git branches in the wiki,
with description, clone URL, etc.
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http
is reached, the next release will
emerge.
+1 and maintaining a list of these repos in the wiki ;)
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
e/etc tracking system
that is 100% notmuch-based and message driven (PR for the feature, we
have to think forward!).
IMHO this will allow for totally awesome workflows.
And we should name it "notmuch issues" or "notmuch bugs".
Servilio
[1] I like pull request because they are e
that is 100% notmuch-based and message driven (PR for the feature, we
have to think forward!).
IMHO this will allow for totally awesome workflows.
And we should name it notmuch issues or notmuch bugs.
Servilio
[1] I like pull request because they are easier to manage: you don't
need to resend
On 23 April 2010 13:13, Dirk Hohndel wrote:
> On Fri, 23 Apr 2010 12:54:21 +0100, David Edmondson wrote:
>> Add `notmuch-show-headers-visible' which, when set `t', causes headers
>> to be shown by default.
>
> Excellent - Carl, can you pull this into 0.3, please?
+1
Servilio
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On 22 April 2010 08:30, David Edmondson wrote:
> On Thu, 22 Apr 2010 04:58:16 -0400, Servilio Afre Puentes gmail.com> wrote:
>> On 21 April 2010 17:03, Carl Worth wrote:
>> > On Mon, 19 Apr 2010 09:27:39 +0100, David Edmondson wrote:
>> [...]
>> > Mean
hint somewhere to make it
> easier to find. Perhaps a keybinding to get to the customization
> buffer.)
The help screen is a very good place to place a link to the
customization screen.
Servilio
On 22 April 2010 08:30, David Edmondson d...@dme.org wrote:
On Thu, 22 Apr 2010 04:58:16 -0400, Servilio Afre Puentes
servi...@gmail.com wrote:
On 21 April 2010 17:03, Carl Worth cwo...@cworth.org wrote:
On Mon, 19 Apr 2010 09:27:39 +0100, David Edmondson d...@dme.org wrote
ests that
> python-notmuch might not be a crazy name.
And looks like the one recommended by the Debian Python Policy:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
Servilio
On 21 April 2010 20:10, Carl Worth wrote:
> On Sun, 18 Apr 2010 23:55:50 -0400, Servilio Afre Puentes gmail.com> wrote:
>> As the user has already defined aliases for certain searches in
>> notmuch-folders, search buffer names that use these aliases will
>> be easier t
On 21 April 2010 20:10, Carl Worth cwo...@cworth.org wrote:
On Sun, 18 Apr 2010 23:55:50 -0400, Servilio Afre Puentes
servi...@gmail.com wrote:
As the user has already defined aliases for certain searches in
notmuch-folders, search buffer names that use these aliases will
be easier
-notmuch might not be a crazy name.
And looks like the one recommended by the Debian Python Policy:
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
This patch has been obsoleted by the one sent in message:
x2hb22065d01004182055vc111d42az357076f93b6cb72a at mail.gmail.com
Servilio
This patch obsoletes the one sent in message:
r2sb22065d01004150516jf099f3dcw180a7db0dc972...@mail.gmail.com
8--
As the user has already defined aliases for certain searches in
notmuch-folders, search buffer names that use these aliases will
be easier to identify.
---
emacs/notmuch.el |
On 15 April 2010 21:46, Carl Worth wrote:
[...]
> We'll probably need to arrange for notmuch to accept search
> specifications on stdin or so.
Or a daemon mode with a pipe or DBus interface.
Servilio
---
emacs/notmuch.el | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index be09f42..17e0e86 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -696,6 +696,15 @@ characters as well as `_.+-'.
(apply
---
emacs/notmuch.el | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index be09f42..17e0e86 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -696,6 +696,15 @@ characters as well as `_.+-'.
(apply
On 14 April 2010 05:53, Sebastian Spaeth wrote:
> On 2010-04-14, Michal Sojka wrote:
>> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
>> > The current hardcoded behaviour will not take you to the next unread
>> > thread when the sort order is set to newer-first fro
On 14 April 2010 05:53, Sebastian Spaeth sebast...@sspaeth.de wrote:
On 2010-04-14, Michal Sojka wrote:
On Tue, 13 Apr 2010, Servilio Afre Puentes wrote:
The current hardcoded behaviour will not take you to the next unread
thread when the sort order is set to newer-first from the default
Signed-off-by: Servilio Afre Puentes
---
emacs/notmuch.el | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..4d4971f 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -264,7 +264,7 @@ For a mouse binding
The current hardcoded behaviour will not take you to the next unread
thread when the sort order is set to newer-first from the default of
older-first.
Signed-off-by: Servilio Afre Puentes
---
emacs/notmuch.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/emacs
The current hardcoded behaviour will not take you to the next unread
thread when the sort order is set to newer-first from the default of
older-first.
Signed-off-by: Servilio Afre Puentes servi...@gmail.com
---
emacs/notmuch.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff
Signed-off-by: Servilio Afre Puentes servi...@gmail.com
---
emacs/notmuch.el | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..4d4971f 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -264,7 +264,7
ty data you have in your cache.
>>
>> libeatmydata also gets rid of msync(), O_SYNC etc as well.
>
> Which is why so many of us have started to use BTRFS...
How stable is it now? What kernel version and distro are you using?
Servilio
of msync(), O_SYNC etc as well.
Which is why so many of us have started to use BTRFS...
How stable is it now? What kernel version and distro are you using?
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo
Signed-off-by: Servilio Afre Puentes
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 3798d60..8eb4754 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -383,7 +383,7 @@ notmuch_reply_format_default(void
Signed-off-by: Servilio Afre Puentes servi...@gmail.com
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 3798d60..8eb4754 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -383,7 +383,7
On 4 February 2010 00:05, martin f krafft wrote:
> also sprach Servilio Afre Puentes [2010.02.04.1714
> +1300]:
>> In the second link, the links with the text "commitdiff" provide
>> it, and you have the Atom and RSS feeds at the bottom.
>
> As I see it, the f
ither of these two give you diffs. This is what
> a post-receive hook offers.
In the second link, the links with the text "commitdiff" provide it,
and you have the Atom and RSS feeds at the bottom.
Servilio
of these two give you diffs. This is what
a post-receive hook offers.
In the second link, the links with the text commitdiff provide it,
and you have the Atom and RSS feeds at the bottom.
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http
This allows the use non-word characters (e.g.: "/") as the folder name
in the notmuch-folders variable.
---
notmuch.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 97914f2..bdb0200 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1467,7
This allows the use non-word characters (e.g.: /) as the folder name
in the notmuch-folders variable.
---
notmuch.el |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/notmuch.el b/notmuch.el
index 97914f2..bdb0200 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1467,7
lly set tags from procmail too),
> write the message to the message store, and update the database.
Such an MDA wouldn't need to use "notmuch new", and thus won't be
affected by this
> This would allow us to get rid of 'notmuch new' altogether, at least
> conceptually. We'd still need it if mail is being delivered
> independently, e.g. with offlineimap.
Then we'd still need it, why not make it better?
Regards,
Servilio
, at least
conceptually. We'd still need it if mail is being delivered
independently, e.g. with offlineimap.
Then we'd still need it, why not make it better?
Regards,
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
would have been written as a set of hooks
into Gnus for customizing views this would have been more evident
(though I haven't neither used or looked at the vim front-end code),
or maybe I am missing the point entirely and the long-term goal of the
authors is to have a full-fledged MUA.
Regards,
Servilio
messages neither all the code).
I am also very glad of something like this having been created and
look forward to help enhance it and use it more extensively (right now
I am trying to get the Gnus bit in place).
Regards,
Servilio
___
notmuch mailing
86 matches
Mail list logo