Undo tag operation?
On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins wrote: > Being also to share tags alone would be super cool. I have no idea what this means, but I do know that tag sharing would be super cool, and I think time stamping tag operations could help facilitate it. jamie.
[PATCH] test: run emacs inside tmux if screen is not available
On Wed, 20 Jul 2011 20:12:55 +0200, Thomas Jost wrote: > On Wed, 20 Jul 2011 10:28:38 -0700, Jameson Graef Rollins finestructure.net> wrote: > Non-text part: multipart/signed > > On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin > gmail.com> wrote: > > > On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost > > schnouki.net> wrote: > > > > Before this change, the test suite reported many failed tests on > > > > machines where > > > > screen is not installed (which is the case of many *BSD systems). This > > > > patch > > > > makes the test suite try to use tmux, another terminal multiplexer, if > > > > screen is > > > > not available. > > > > > > This is a nice improvement. But I think we should make it even better :) > > > There are more terminal emulators besides screen and tmux (dtach comes > > > to mind). We need a more general mechanism for trying them. There > > > should be a list of commands for running terminal emulators in the order > > > of preference (I think that is dtach, tmux, screen), and we should try > > > each one in a loop (this would also avoid repeating the long emacs > > > command). > > > > Hi, guys. I suppose you can go down this route if you want, but I worry > > that it just adds a lot of extra code to the test suite that will > > ultimately make it less robust. What's wrong with just depending on > > screen for the tests? I'm sure screen is available on every operating > > system that we currently support. > > > > It makes me wary that we would be starting a precedent for making a > > bunch of conditionals for all of the possible alternative tools we use > > in the test suite. Maybe that's an overblown concern, though. > > > > jamie. > > You're right, just depending on screen would be enough (the package is > just 864 kB on Arch Linux...), and supporting alternative tools > would make the test suite more complicated and less robust. But the > dependency on screen should be more *explicit*: if it's not available, > the test suite should skip all the emacs tests and display a message > about screen. > > Apparently test-lib.sh includes some things about prerequisites. I'll > try to use these to implement the explicit dependency on screen. > Full ack. The only reason I did not implement it in the original patch is because there is an existing patch series [1] that adds proper prerequisites for gdb, emacs and gpg. So instead of reimplementing the same thing, I decided to wait until that series is merged and add screen prerequisite later. Regards, Dmitry [1] id:"1307016220-17509-1-git-send-email-pieter at praet.org" > Regards, > > -- > Thomas/Schnouki Non-text part: application/pgp-signature
Undo tag operation?
Le 20 Jul 2011 09:48, Jameson Graef Rollins a ?crit: > On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza wrote: > > I just inadvertently removed the "todo" tag from all my "todo"-tagged > > emails (about 60 of them going back several months, so I doubt I can > > find them all again in my email haystack). So I have a few questions: > > Hey, Alex. This won't help you now, and doesn't really answer your > questions either, but you should periodically back up your tags with the > "dump" command. If you had a dumpfile backup of the tags you could > restore with "restore". hth (for the future). I wonder if it may be possible to create a journal of all the operations on tags: a file where all the changes are registered, with a timestamp. Two benefits: - going through the history to undo mistakes - being able to build a diff of two journals in order to synchronize db on multiple hosts A drawback may be to slow down the changes on tags, since we add one more write each time a tag is added or removed. Olivier
[PATCH] test: run emacs inside tmux if screen is not available
On Wed, 20 Jul 2011 10:28:38 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/signed > On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin gmail.com> wrote: > > On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost > > wrote: > > > Before this change, the test suite reported many failed tests on machines > > > where > > > screen is not installed (which is the case of many *BSD systems). This > > > patch > > > makes the test suite try to use tmux, another terminal multiplexer, if > > > screen is > > > not available. > > > > This is a nice improvement. But I think we should make it even better :) > > There are more terminal emulators besides screen and tmux (dtach comes > > to mind). We need a more general mechanism for trying them. There > > should be a list of commands for running terminal emulators in the order > > of preference (I think that is dtach, tmux, screen), and we should try > > each one in a loop (this would also avoid repeating the long emacs > > command). > > Hi, guys. I suppose you can go down this route if you want, but I worry > that it just adds a lot of extra code to the test suite that will > ultimately make it less robust. What's wrong with just depending on > screen for the tests? I'm sure screen is available on every operating > system that we currently support. > > It makes me wary that we would be starting a precedent for making a > bunch of conditionals for all of the possible alternative tools we use > in the test suite. Maybe that's an overblown concern, though. > > jamie. You're right, just depending on screen would be enough (the package is just 864 kB on Arch Linux...), and supporting alternative tools would make the test suite more complicated and less robust. But the dependency on screen should be more *explicit*: if it's not available, the test suite should skip all the emacs tests and display a message about screen. Apparently test-lib.sh includes some things about prerequisites. I'll try to use these to implement the explicit dependency on screen. Regards, -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110720/8472a0ef/attachment.pgp>
[PATCH] test: run emacs inside tmux if screen is not available
Hi Thomas.
On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost
wrote:
> Before this change, the test suite reported many failed tests on machines
> where
> screen is not installed (which is the case of many *BSD systems). This patch
> makes the test suite try to use tmux, another terminal multiplexer, if screen
> is
> not available.
This is a nice improvement. But I think we should make it even better :)
There are more terminal emulators besides screen and tmux (dtach comes
to mind). We need a more general mechanism for trying them. There
should be a list of commands for running terminal emulators in the order
of preference (I think that is dtach, tmux, screen), and we should try
each one in a loop (this would also avoid repeating the long emacs
command).
Regards,
Dmitry
> ---
> test/test-lib.sh | 13 +++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 0608e42..5851b3d 100755
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -860,12 +860,21 @@ EOF
> test_emacs () {
> if [ -z "$EMACS_SERVER" ]; then
> EMACS_SERVER="notmuch-test-suite-$$"
> - # start a detached screen session with an emacs server
> + # start a detached screen or tmux session with an emacs server
> screen -S "$EMACS_SERVER" -d -m "$TMP_DIRECTORY/run_emacs" \
> --no-window-system \
> --eval "(setq server-name \"$EMACS_SERVER\")" \
> --eval '(server-start)' \
> - --eval "(orphan-watchdog $$)" || return
> + --eval "(orphan-watchdog $$)"
> + if [ "$?" != 0 ]
> + then
> + tmux -f /dev/null -L "$EMACS_SERVER" new-session -d
> "$TMP_DIRECTORY/run_emacs \
> + --no-window-system \
> + --eval \"(setq server-name
> \\\"$EMACS_SERVER\\\")\" \
> + --eval '(server-start)' \
> + --eval \"(orphan-watchdog $$)\"" || return
> + fi
> +
> # wait until the emacs server is up
> until test_emacs '()' 2>/dev/null; do
> sleep 1
> --
> 1.7.6
>
[PATCH 2/2] add edit function to resume postponed emails
On Sat, 16 Jul 2011 15:31:31 -0400, Austin Clements wrote: > I think this could be simplified a lot and many of the known issues > addressed if this were narrowed to *only* resuming from drafts. > message-mode draft files aren't MIME messages (or, at least, they're > never multipart, and message-mode has its own special annotations over > basic RFC 822), so rather than treating the draft as a MIME message > and trying to transform it back into a message-mode-compatible draft > (which, in full generality, would be somewhere between hard and > impossible), what about just dumping the raw contents of the draft > file into a buffer and pointing message-mode at it? If the draft file > is available, you could even open it directly (this wouldn't work for > remote usage, but remote drafts introduce many other problems, too). I think this is a great idea. Unfortunately, I had a lot of trouble making message-mode digest an existing buffer. For example, if you take any existing buffer and call (message-mode) on it, you will notice it will clear the buffer completely. I guess I would need to look at how (notmuch-mua-edit-mail) does it but it was the blocker i had when i tried to figure this out.. Any suggestions? A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110720/2869dfb6/attachment.pgp>
Undo tag operation?
Dear notmuch folks, I just inadvertently removed the "todo" tag from all my "todo"-tagged emails (about 60 of them going back several months, so I doubt I can find them all again in my email haystack). So I have a few questions: 1. Is there currently an easy way to undo this? 2. Is there currently a complicated, maybe-won't-work way to undo this? I have not touched the emacs instance, nor the notmuch database, since the incident, if that helps. 3. If the answers to both 1 and 2 are "no" (which is what I expect), should notmuch itself (or the emacs frontend) have an undo possibility? Best, Alex -- Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- http://aghitza.org
Undo tag operation?
On Wed, 20 Jul 2011 09:48:53 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza wrote: > > I just inadvertently removed the "todo" tag from all my "todo"-tagged > > emails (about 60 of them going back several months, so I doubt I can > > find them all again in my email haystack). So I have a few questions: > > Hey, Alex. This won't help you now, and doesn't really answer your > questions either, but you should periodically back up your tags with the > "dump" command. If you had a dumpfile backup of the tags you could > restore with "restore". hth (for the future). I generally run my notmuch commands through notmuch-retry. See http://notmuch.198994.n3.nabble.com/PATCH-Add-shell-script-notmuch-retry-td417192.html That could be easily amended to log tag commands. You could then restore from your most recent dump and replay all the tag commands since that dump, minus the offending command. Not a perfect solution, but it would work. Maybe I'll build it if I encounter some free time.
[PATCH 2/2] add edit function to resume postponed emails
On Wed, 20 Jul 2011 17:36:43 -0400, Antoine Beaupr?
wrote:
> I think this is a great idea. Unfortunately, I had a lot of trouble
> making message-mode digest an existing buffer. For example, if you take
> any existing buffer and call (message-mode) on it, you will notice it
> will clear the buffer completely.
Hey, Antoine. Is this really true? It seems to work for me. For
instance, if I view a received message raw ('V') I can then "C-x
message-mode" on that buffer and it creates a partially filled, although
not properly formatted, message.
jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110720/d51b28f9/attachment.pgp>
[PATCH] libnotmuch: only build symbols list after the modules are built
If the notmuch.sym target does not explicitly depend on $(libnotmuch_modules), gen-version-script.sh may be run before all the .o files are created. This can be observed when doing a parallel build on a machine with many cores: $ make -j ... sh lib/gen-version-script.sh lib/notmuch.h lib/filenames.o lib/string-list.o lib/libsha1.o lib/message-file.o lib/messages.o lib/sha1.o lib/tags.o lib/xutil.o lib/database.o lib/directory.o lib/index.o lib/message.o lib/query.o lib/thread.o > notmuch.sym nm: 'lib/libsha1.o': No such file nm: 'lib/message-file.o': No such file nm: 'lib/database.o': No such file nm: 'lib/directory.o': No such file nm: 'lib/index.o': No such file nm: 'lib/message.o': No such file nm: 'lib/query.o': No such file nm: 'lib/thread.o': No such file ... --- lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 9210f0e..fbc2f6a 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -74,7 +74,7 @@ $(dir)/libnotmuch.a: $(libnotmuch_modules) $(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ -notmuch.sym: lib/notmuch.h +notmuch.sym: lib/notmuch.h $(libnotmuch_modules) sh lib/gen-version-script.sh $< $(libnotmuch_modules) > $@ $(dir)/$(SONAME): $(dir)/$(LIBNAME) -- 1.7.6
Undo tag operation?
On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander wrote: > I wonder if it may be possible to create a journal of all the operations > on tags: a file where all the changes are registered, with a timestamp. > > Two benefits: > - going through the history to undo mistakes > - being able to build a diff of two journals in order to synchronize db on > multiple >hosts I'm having trouble finding the thread right now, but wasn't there just recently a discussion about just this (i.e. time-stamping tag operations)? Unless there is a big performance hit, I'm starting to think this sounds like a good idea. Being also to share tags alone would be super cool. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110720/cf09f157/attachment.pgp>
[PATCH] test: run emacs inside tmux if screen is not available
Before this change, the test suite reported many failed tests on machines where
screen is not installed (which is the case of many *BSD systems). This patch
makes the test suite try to use tmux, another terminal multiplexer, if screen is
not available.
---
test/test-lib.sh | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 0608e42..5851b3d 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -860,12 +860,21 @@ EOF
test_emacs () {
if [ -z "$EMACS_SERVER" ]; then
EMACS_SERVER="notmuch-test-suite-$$"
- # start a detached screen session with an emacs server
+ # start a detached screen or tmux session with an emacs server
screen -S "$EMACS_SERVER" -d -m "$TMP_DIRECTORY/run_emacs" \
--no-window-system \
--eval "(setq server-name \"$EMACS_SERVER\")" \
--eval '(server-start)' \
- --eval "(orphan-watchdog $$)" || return
+ --eval "(orphan-watchdog $$)"
+ if [ "$?" != 0 ]
+ then
+ tmux -f /dev/null -L "$EMACS_SERVER" new-session -d
"$TMP_DIRECTORY/run_emacs \
+ --no-window-system \
+ --eval \"(setq server-name
\\\"$EMACS_SERVER\\\")\" \
+ --eval '(server-start)' \
+ --eval \"(orphan-watchdog $$)\"" || return
+ fi
+
# wait until the emacs server is up
until test_emacs '()' 2>/dev/null; do
sleep 1
--
1.7.6
[PATCH] libnotmuch: only build symbols list after the modules are built
On Wed, 20 Jul 2011 14:38:18 +0200, Thomas Jost wrote: > If the notmuch.sym target does not explicitly depend on $(libnotmuch_modules), > gen-version-script.sh may be run before all the .o files are created. This can > be observed when doing a parallel build on a machine with many cores: > $ make -j > ... > sh lib/gen-version-script.sh lib/notmuch.h lib/filenames.o lib/string-list.o > lib/libsha1.o lib/message-file.o lib/messages.o lib/sha1.o lib/tags.o > lib/xutil.o lib/database.o lib/directory.o lib/index.o lib/message.o Hi Thomas; Your patch looks sensible. If you could shorten up the commit message a bit, probably by putting the make output after '---' and adjusting the rest of the text, I'll be happy to push it. d
[PATCH] test: run emacs inside tmux if screen is not available
On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin wrote: > On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost > wrote: > > Before this change, the test suite reported many failed tests on machines > > where > > screen is not installed (which is the case of many *BSD systems). This patch > > makes the test suite try to use tmux, another terminal multiplexer, if > > screen is > > not available. > > This is a nice improvement. But I think we should make it even better :) > There are more terminal emulators besides screen and tmux (dtach comes > to mind). We need a more general mechanism for trying them. There > should be a list of commands for running terminal emulators in the order > of preference (I think that is dtach, tmux, screen), and we should try > each one in a loop (this would also avoid repeating the long emacs > command). Hi, guys. I suppose you can go down this route if you want, but I worry that it just adds a lot of extra code to the test suite that will ultimately make it less robust. What's wrong with just depending on screen for the tests? I'm sure screen is available on every operating system that we currently support. It makes me wary that we would be starting a precedent for making a bunch of conditionals for all of the possible alternative tools we use in the test suite. Maybe that's an overblown concern, though. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110720/a74ac13d/attachment-0001.pgp>
Undo tag operation?
On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza wrote: > I just inadvertently removed the "todo" tag from all my "todo"-tagged > emails (about 60 of them going back several months, so I doubt I can > find them all again in my email haystack). So I have a few questions: Hey, Alex. This won't help you now, and doesn't really answer your questions either, but you should periodically back up your tags with the "dump" command. If you had a dumpfile backup of the tags you could restore with "restore". hth (for the future). jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110720/fec33075/attachment.pgp>
[PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'
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
[PATCH] test: run emacs inside tmux if screen is not available
Before this change, the test suite reported many failed tests on machines where
screen is not installed (which is the case of many *BSD systems). This patch
makes the test suite try to use tmux, another terminal multiplexer, if screen is
not available.
---
test/test-lib.sh | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 0608e42..5851b3d 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -860,12 +860,21 @@ EOF
test_emacs () {
if [ -z $EMACS_SERVER ]; then
EMACS_SERVER=notmuch-test-suite-$$
- # start a detached screen session with an emacs server
+ # start a detached screen or tmux session with an emacs server
screen -S $EMACS_SERVER -d -m $TMP_DIRECTORY/run_emacs \
--no-window-system \
--eval (setq server-name \$EMACS_SERVER\) \
--eval '(server-start)' \
- --eval (orphan-watchdog $$) || return
+ --eval (orphan-watchdog $$)
+ if [ $? != 0 ]
+ then
+ tmux -f /dev/null -L $EMACS_SERVER new-session -d
$TMP_DIRECTORY/run_emacs \
+ --no-window-system \
+ --eval \(setq server-name
\\\$EMACS_SERVER\\\)\ \
+ --eval '(server-start)' \
+ --eval \(orphan-watchdog $$)\ || return
+ fi
+
# wait until the emacs server is up
until test_emacs '()' 2/dev/null; do
sleep 1
--
1.7.6
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: run emacs inside tmux if screen is not available
Hi Thomas.
On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost schno...@schnouki.net wrote:
Before this change, the test suite reported many failed tests on machines
where
screen is not installed (which is the case of many *BSD systems). This patch
makes the test suite try to use tmux, another terminal multiplexer, if screen
is
not available.
This is a nice improvement. But I think we should make it even better :)
There are more terminal emulators besides screen and tmux (dtach comes
to mind). We need a more general mechanism for trying them. There
should be a list of commands for running terminal emulators in the order
of preference (I think that is dtach, tmux, screen), and we should try
each one in a loop (this would also avoid repeating the long emacs
command).
Regards,
Dmitry
---
test/test-lib.sh | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 0608e42..5851b3d 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -860,12 +860,21 @@ EOF
test_emacs () {
if [ -z $EMACS_SERVER ]; then
EMACS_SERVER=notmuch-test-suite-$$
- # start a detached screen session with an emacs server
+ # start a detached screen or tmux session with an emacs server
screen -S $EMACS_SERVER -d -m $TMP_DIRECTORY/run_emacs \
--no-window-system \
--eval (setq server-name \$EMACS_SERVER\) \
--eval '(server-start)' \
- --eval (orphan-watchdog $$) || return
+ --eval (orphan-watchdog $$)
+ if [ $? != 0 ]
+ then
+ tmux -f /dev/null -L $EMACS_SERVER new-session -d
$TMP_DIRECTORY/run_emacs \
+ --no-window-system \
+ --eval \(setq server-name
\\\$EMACS_SERVER\\\)\ \
+ --eval '(server-start)' \
+ --eval \(orphan-watchdog $$)\ || return
+ fi
+
# wait until the emacs server is up
until test_emacs '()' 2/dev/null; do
sleep 1
--
1.7.6
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Undo tag operation?
Dear notmuch folks, I just inadvertently removed the todo tag from all my todo-tagged emails (about 60 of them going back several months, so I doubt I can find them all again in my email haystack). So I have a few questions: 1. Is there currently an easy way to undo this? 2. Is there currently a complicated, maybe-won't-work way to undo this? I have not touched the emacs instance, nor the notmuch database, since the incident, if that helps. 3. If the answers to both 1 and 2 are no (which is what I expect), should notmuch itself (or the emacs frontend) have an undo possibility? Best, Alex -- Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne -- http://aghitza.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza aghi...@gmail.com wrote: I just inadvertently removed the todo tag from all my todo-tagged emails (about 60 of them going back several months, so I doubt I can find them all again in my email haystack). So I have a few questions: Hey, Alex. This won't help you now, and doesn't really answer your questions either, but you should periodically back up your tags with the dump command. If you had a dumpfile backup of the tags you could restore with restore. hth (for the future). jamie. pgpxi7ghRuMwm.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] libnotmuch: only build symbols list after the modules are built
On Wed, 20 Jul 2011 14:38:18 +0200, Thomas Jost schno...@schnouki.net wrote: If the notmuch.sym target does not explicitly depend on $(libnotmuch_modules), gen-version-script.sh may be run before all the .o files are created. This can be observed when doing a parallel build on a machine with many cores: $ make -j ... sh lib/gen-version-script.sh lib/notmuch.h lib/filenames.o lib/string-list.o lib/libsha1.o lib/message-file.o lib/messages.o lib/sha1.o lib/tags.o lib/xutil.o lib/database.o lib/directory.o lib/index.o lib/message.o Hi Thomas; Your patch looks sensible. If you could shorten up the commit message a bit, probably by putting the make output after '---' and adjusting the rest of the text, I'll be happy to push it. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: run emacs inside tmux if screen is not available
On Wed, 20 Jul 2011 10:28:38 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Non-text part: multipart/signed On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost schno...@schnouki.net wrote: Before this change, the test suite reported many failed tests on machines where screen is not installed (which is the case of many *BSD systems). This patch makes the test suite try to use tmux, another terminal multiplexer, if screen is not available. This is a nice improvement. But I think we should make it even better :) There are more terminal emulators besides screen and tmux (dtach comes to mind). We need a more general mechanism for trying them. There should be a list of commands for running terminal emulators in the order of preference (I think that is dtach, tmux, screen), and we should try each one in a loop (this would also avoid repeating the long emacs command). Hi, guys. I suppose you can go down this route if you want, but I worry that it just adds a lot of extra code to the test suite that will ultimately make it less robust. What's wrong with just depending on screen for the tests? I'm sure screen is available on every operating system that we currently support. It makes me wary that we would be starting a precedent for making a bunch of conditionals for all of the possible alternative tools we use in the test suite. Maybe that's an overblown concern, though. jamie. You're right, just depending on screen would be enough (the package is just 864 kB on Arch Linux...), and supporting alternative tools would make the test suite more complicated and less robust. But the dependency on screen should be more *explicit*: if it's not available, the test suite should skip all the emacs tests and display a message about screen. Apparently test-lib.sh includes some things about prerequisites. I'll try to use these to implement the explicit dependency on screen. Regards, -- Thomas/Schnouki pgpVj7WlrZLJN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: run emacs inside tmux if screen is not available
On Wed, 20 Jul 2011 20:12:55 +0200, Thomas Jost schno...@schnouki.net wrote: On Wed, 20 Jul 2011 10:28:38 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Non-text part: multipart/signed On Wed, 20 Jul 2011 17:37:35 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: On Wed, 20 Jul 2011 14:36:36 +0200, Thomas Jost schno...@schnouki.net wrote: Before this change, the test suite reported many failed tests on machines where screen is not installed (which is the case of many *BSD systems). This patch makes the test suite try to use tmux, another terminal multiplexer, if screen is not available. This is a nice improvement. But I think we should make it even better :) There are more terminal emulators besides screen and tmux (dtach comes to mind). We need a more general mechanism for trying them. There should be a list of commands for running terminal emulators in the order of preference (I think that is dtach, tmux, screen), and we should try each one in a loop (this would also avoid repeating the long emacs command). Hi, guys. I suppose you can go down this route if you want, but I worry that it just adds a lot of extra code to the test suite that will ultimately make it less robust. What's wrong with just depending on screen for the tests? I'm sure screen is available on every operating system that we currently support. It makes me wary that we would be starting a precedent for making a bunch of conditionals for all of the possible alternative tools we use in the test suite. Maybe that's an overblown concern, though. jamie. You're right, just depending on screen would be enough (the package is just 864 kB on Arch Linux...), and supporting alternative tools would make the test suite more complicated and less robust. But the dependency on screen should be more *explicit*: if it's not available, the test suite should skip all the emacs tests and display a message about screen. Apparently test-lib.sh includes some things about prerequisites. I'll try to use these to implement the explicit dependency on screen. Full ack. The only reason I did not implement it in the original patch is because there is an existing patch series [1] that adds proper prerequisites for gdb, emacs and gpg. So instead of reimplementing the same thing, I decided to wait until that series is merged and add screen prerequisite later. Regards, Dmitry [1] id:1307016220-17509-1-git-send-email-pie...@praet.org Regards, -- Thomas/Schnouki Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
On Wed, 20 Jul 2011 09:48:53 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza aghi...@gmail.com wrote: I just inadvertently removed the todo tag from all my todo-tagged emails (about 60 of them going back several months, so I doubt I can find them all again in my email haystack). So I have a few questions: Hey, Alex. This won't help you now, and doesn't really answer your questions either, but you should periodically back up your tags with the dump command. If you had a dumpfile backup of the tags you could restore with restore. hth (for the future). I generally run my notmuch commands through notmuch-retry. See http://notmuch.198994.n3.nabble.com/PATCH-Add-shell-script-notmuch-retry-td417192.html That could be easily amended to log tag commands. You could then restore from your most recent dump and replay all the tag commands since that dump, minus the offending command. Not a perfect solution, but it would work. Maybe I'll build it if I encounter some free time. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
Le 20 Jul 2011 09:48, Jameson Graef Rollins a écrit: On Wed, 20 Jul 2011 16:17:37 +0200, Alex Ghitza aghi...@gmail.com wrote: I just inadvertently removed the todo tag from all my todo-tagged emails (about 60 of them going back several months, so I doubt I can find them all again in my email haystack). So I have a few questions: Hey, Alex. This won't help you now, and doesn't really answer your questions either, but you should periodically back up your tags with the dump command. If you had a dumpfile backup of the tags you could restore with restore. hth (for the future). I wonder if it may be possible to create a journal of all the operations on tags: a file where all the changes are registered, with a timestamp. Two benefits: - going through the history to undo mistakes - being able to build a diff of two journals in order to synchronize db on multiple hosts A drawback may be to slow down the changes on tags, since we add one more write each time a tag is added or removed. Olivier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
JSON parsing performance (was Re: [PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter')
Quoth myself on Jul 13 at 2:57 pm: Quoth Pieter Praet on Jul 13 at 4:16 pm: Jamie Zawinski once said/wrote [1]: 'Some people, when confronted with a problem, think I know, I'll use regular expressions. Now they have two problems.' With this in mind, I set out to get rid of this whole regex mess altogether, by populating the search buffer using Notmuch's JSON output instead of doing brittle text matching tricks. Looking for some documentation, I stumbled upon a long-forgotten gem [2]. David's already done pretty much all of the work for us! Yes, similar thoughts were running through my head as I futzed with the formatting for this. My concern with moving to JSON for search buffers is that parsing it is about *30 times slower* than the current regexp-based approach (0.6 seconds versus 0.02 seconds for a mere 1413 result search buffer). I think JSON makes a lot of sense for show buffers because there's generally less data and it has a lot of complicated structure. Search results, on the other hand, have a very simple, regular, and constrained structure, so JSON doesn't buy us nearly as much. JSON is hard to parse because, like the text search output, it's designed for human consumption (of course, unlike the text search output, it's also designed for computer consumption). There's something to be said for the debuggability and generality of this and JSON is very good for exchanging small objects, but it's a remarkably inefficient way to exchange large amounts of data between two programs. I guess what I'm getting at, though it pains me to say it, is perhaps search needs a fast, computer-readable interchange format. The structure of the data is so simple and constrained that this could be altogether trivial. Or maybe I need a faster computer. Or maybe I need to un-lame my benchmark. TL;DR: We should use JSON for search results, but possibly not the json.el shipped with Emacs. I realized that my text benchmark didn't capture the cost of extracting the match strings. re-search-forward records matches as buffer positions, which don't get realized into strings until you call match-string. Hence, match-string is quite expensive. Also, Emacs' json.el is slow, so I perked it up. My modified json.el is ~3X faster, particularly for string-heavy output like notmuch's. Though now I'm well into the realm of eq is faster than = and M-x disassemble, so unless I missed something big, this is as fast as it gets. While I was still thinking about new IPC formats, I realized that the text format and the Emacs UI are already tightly coupled, so why not go all the way and use S-expressions for IPC? I now think JSON is fast enough to use, but S-expressions still have a certain appeal. They share most of the benefits of JSON; structure and extensibility in particular. Further, while the content of some ad-hoc format could easily diverge from both the text and JSON formats, S-expressions could exactly parallel the JSON content (with a little more abstraction, they could even share the same format code). For kicks, I included an S-expression benchmark. It beats out the text parser by a factor of two and the optimized JSON parser by a factor of three. Here are the results for my 1,413 result search buffer and timeworn computer Time Normalized --format=text 0.148s 1.00x --format=json 0.598s 4.04x custom json.el 0.209s 1.41x + string keys 0.195s 1.32x S-expressions 0.066s 0.45x I don't have time right now, but next week I might be able to look through and update dme's JSON-based search code. The benchmark and modified json.el are attached. The benchmark is written so you can open it and eval-buffer, then C-x C-e the various calls in the comments. You can either make-text/make-json, or run notmuch manually, pipe the results into files text and json, and open them in Emacs. Please excuse the modified json.el code; it's gone through zero cleanup. (defmacro time-it (repeat rest body) (declare (indent 1)) (when (not (numberp repeat)) (push repeat body) (setq repeat 1)) (let ((start-time (gensym)) (i (gensym))) `(let ((,start-time (get-internal-run-time))) (dotimes (,i ,repeat) ,@body) (/ (float-time (time-subtract (get-internal-run-time) ,start-time)) ,repeat ;; Text (defun make-text () (with-current-buffer (get-buffer-create text) (erase-buffer) (call-process notmuch nil t nil search --format=text -- tag:x/notmuch))) (defun time-text () (with-current-buffer text (time-it 10 (goto-char (point-min)) (while (re-search-forward ^\\(thread:[0-9A-Fa-f]*\\) \\([^][]*\\) \\(\\[[0-9/]*\\]\\) \\([^;]*\\); \\(.*\\) (\\([^()]*\\))$ nil t) (let* ((thread-id (match-string 1)) (date (match-string 2)) (count (match-string 3)) (authors (match-string 4)) (subject
Re: [PATCH 2/2] add edit function to resume postponed emails
On Sat, 16 Jul 2011 15:31:31 -0400, Austin Clements amdra...@mit.edu wrote: I think this could be simplified a lot and many of the known issues addressed if this were narrowed to *only* resuming from drafts. message-mode draft files aren't MIME messages (or, at least, they're never multipart, and message-mode has its own special annotations over basic RFC 822), so rather than treating the draft as a MIME message and trying to transform it back into a message-mode-compatible draft (which, in full generality, would be somewhere between hard and impossible), what about just dumping the raw contents of the draft file into a buffer and pointing message-mode at it? If the draft file is available, you could even open it directly (this wouldn't work for remote usage, but remote drafts introduce many other problems, too). I think this is a great idea. Unfortunately, I had a lot of trouble making message-mode digest an existing buffer. For example, if you take any existing buffer and call (message-mode) on it, you will notice it will clear the buffer completely. I guess I would need to look at how (notmuch-mua-edit-mail) does it but it was the blocker i had when i tried to figure this out.. Any suggestions? A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm pgp2pNs2TFrvJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander olivier.schwan...@chadok.info wrote: I wonder if it may be possible to create a journal of all the operations on tags: a file where all the changes are registered, with a timestamp. Two benefits: - going through the history to undo mistakes - being able to build a diff of two journals in order to synchronize db on multiple hosts I'm having trouble finding the thread right now, but wasn't there just recently a discussion about just this (i.e. time-stamping tag operations)? Unless there is a big performance hit, I'm starting to think this sounds like a good idea. Being also to share tags alone would be super cool. jamie. pgpv84STsAxay.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] add edit function to resume postponed emails
On Wed, 20 Jul 2011 17:36:43 -0400, Antoine Beaupré anar...@koumbit.org wrote:
I think this is a great idea. Unfortunately, I had a lot of trouble
making message-mode digest an existing buffer. For example, if you take
any existing buffer and call (message-mode) on it, you will notice it
will clear the buffer completely.
Hey, Antoine. Is this really true? It seems to work for me. For
instance, if I view a received message raw ('V') I can then C-x
message-mode on that buffer and it creates a partially filled, although
not properly formatted, message.
jamie.
pgp76syaqAt9B.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] libnotmuch: only build symbols list after the modules are built
If the notmuch.sym target does not explicitly depend on $(libnotmuch_modules), gen-version-script.sh may be run before all the .o files are created, for example when doing a parallel build on a machine with many cores. --- Hi David, Here's an updated version of the patch with a shorter commit message. For the record, the build log I sent earlier was obtained on my work PC, which has two 8-core CPUs. No problem on my laptop with its dual-core CPU though :) Regards, Thomas lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 9210f0e..fbc2f6a 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -74,7 +74,7 @@ $(dir)/libnotmuch.a: $(libnotmuch_modules) $(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) $(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@ -notmuch.sym: lib/notmuch.h +notmuch.sym: lib/notmuch.h $(libnotmuch_modules) sh lib/gen-version-script.sh $ $(libnotmuch_modules) $@ $(dir)/$(SONAME): $(dir)/$(LIBNAME) -- 1.7.6 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] libnotmuch: only build symbols list after the modules are built
On Thu, 21 Jul 2011 01:31:37 +0200, Thomas Jost schno...@schnouki.net wrote: Here's an updated version of the patch with a shorter commit message. For the record, the build log I sent earlier was obtained on my work PC, which has two 8-core CPUs. No problem on my laptop with its dual-core CPU though :) Thanks, pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: On Wed, 20 Jul 2011 22:02:47 +0200, Olivier Schwander olivier.schwan...@chadok.info wrote: I wonder if it may be possible to create a journal of all the operations on tags: a file where all the changes are registered, with a timestamp. Two benefits: - going through the history to undo mistakes - being able to build a diff of two journals in order to synchronize db on multiple hosts I'm having trouble finding the thread right now, but wasn't there just recently a discussion about just this (i.e. time-stamping tag operations)? Unless there is a big performance hit, I'm starting to think this sounds like a good idea. Being also to share tags alone would be super cool. I think the discussion was on IRC, not the mailing list. It would be very cool :) Cheers, mwh ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Undo tag operation?
On Wed, 20 Jul 2011 14:37:50 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Being also to share tags alone would be super cool. I have no idea what this means, but I do know that tag sharing would be super cool, and I think time stamping tag operations could help facilitate it. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
