Moving notmucch between machines

2019-08-13 Thread Bart Bunting
Hi everyone,

Sorry if this question has an obvious answer but I couldn't find it.

I am migrating from OSX to Linux and want to move my mail over.

I am unsure of the best way to approach the problem.

Is it possible to somehow export and re import tags or can I simply move the
maildir and notmuch indexes over and expect things to work?

I have previously tried and some how offlineimap got itself in a tangle
and redownloaded all messages.  This is nontrivial as I have about 50g
of mail and indexes.

Any suggestions would be appreciated.


Kind regards
Bart
-- 

Bart Bunting - URSYS
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: converting attachments to text

2017-01-09 Thread Bart Bunting
Hi Brian,
Thanks so much for this, it has done exactly what I was after!


Kind regards

Bart

Brian Sniffen <b...@evenmere.org> writes:

> Sure!  Here's what I use for docx, and I think it could be adapted to
> pdf with pdftotext or whatever you're already using there.  You need a
> small shell script that reads from STDIN, writes to a file, and calls
> pandoc or pdftotext or whatever, like ~/bin/antiwordx:
>
> #!/bin/sh
>
> tmpfile=$(mktemp /tmp/antiwordx.XX.docx)
> trap 'rm -f -- "$tmpfile"' INT TERM HUP EXIT
> cat > "$tmpfile"
> pandoc --normalize -r docx -w markdown "$tmpfile"
>
> You need a small handler function to call it from Elisp---see attached
> file `inline-docx.el`, which assumed you have both the old `antiword`
> for old-style .doc files and pandoc for new-style `docx`.
>
> I apologize for the roughness of the code; it should probably use
> customizable paths for pandoc and such.
>
> -Brian
>
>
> (defun mm-inline-msword (handle)  
> 
>   (let (text) 
> 
> (with-temp-buffer 
> 
>   (mm-insert-part handle) 
> 
>   (call-process-region (point-min) (point-max) "antiword" t t nil "-")
> 
>   (setq text (buffer-string)))
> 
> (mm-insert-inline handle text)))  
> 
>   
> 
> (defun mm-inline-docx (handle)
>   "pandoc --normalize -r docx -w markdown %s"
>   (let (text) 
> 
> (with-temp-buffer 
> 
>   (mm-insert-part handle) 
> 
>   (let ((coding-system-for-read 'utf-8))
>   (call-process-region (point-min) (point-max) "/Users/bts/bin/antiwordx" 
> t t nil))
>   (setq text (buffer-string)))
> 
> (mm-insert-inline handle text)))  
> 
>
> (setq my-inline-mime-tests
>  '(("text/rtf" mm-inline-rtf
> (lambda
>   (handle)
>   (let
>   ((name
> (mail-content-type-get
>  (mm-handle-disposition handle)
>  'filename)))
> (and name
>  (equal ".rtf"
> (substring name -4 nil))
>("application/x-msword" mm-inline-docx
> (lambda
>   (handle)
>   (let
>   ((name
> (mail-content-type-get
>  (mm-handle-disposition handle)
>  'filename)))
> (and name
>  (equal ".docx"
> (substring name -5 nil))
>("application/x-msword" mm-inline-msword
> (lambda
>   (handle)
>   (let
>   ((name
> (mail-content-type-get
>  (mm-handle-disposition handle)
>  'filename)))
> (and name
>  (equal ".doc"
> (substring name -4 nil))
>
> ("application/vnd.openxmlformats-officedocument.wordprocessingml.document" 
> mm-inline-docx identity)
>("application/octet-stream" mm-inline-docx
> (lambda
>   (handle)
>   (let
>   ((name
> (mail-content-type-get
>  (mm-handle-disposition handle)
>  'filename)))
> (and name
>  (equal ".docx"
> (substring name -5 nil))
>("application/octet-stream" mm-inline-msword
> (lambda
>   (handle)
>   (let
>   ((name
>     (mail-content-type-get
>  (mm-handle-disposition handle)
>  'filename)))
> (and name
>  (equal ".doc"
> (substring name -4 nil))
>("application/msword" mm-inline-msword identity)))
>
> (mapcar (lambda (x) (add-to-list 'mm-inlined-types (car x)))
> my-inline-mime-tests)
>
> (mapcar (la

converting attachments to text

2017-01-02 Thread Bart Bunting

Hi,

Just looking for some pointers.

I have to deal with quite a few emails with attachments in either pdf or
word format.

I'm on a mac so can use applescript or something pdftotext or similar to
convert them to text.

I'm blind so use emacspeak as my primary interface.  Having an easy way
to convert the notmuch attachments to text other than saving to a file
and processing them would greatly speed up my workflow.

Is there something in existance already to do this sort of thing?

I have a little rudimentary lisp skill so can hack something up if
someone can give me some pointers on a direction to head in.

Any advice appreciated.

Kind regards

Bart

Kind regards
Bart
-- 

Bart Bunting - URSYS
PH: 02 87452811
Mbl: 0409560005
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Converting attachments to text or html

2016-06-17 Thread Bart Bunting

Hi everyone,

I often receive email with word or pdf attachments.

I'm blind and use emacspeak on a mac.  Whilst it is possible to save the
attachment, use unoconv or similar to convert to text or html the
process is tedious as it means leaving notmuch and executing several commands.

Is there any functionality in notmuch where I can have it preprocess
attachments of a given mime type or filename regexp or similar pass to
an external command and display the resulting text.

I'd be happy if either the entire part was replaced with the text or an
additional part added or anything at all really that made it unnecessary
to leave notmuch to view the content of the attachment.

Does anyone have suggestions?

Kind regards
Bart
-- 

Bart Bunting - URSYS
PH: 02 87452811
Mbl: 0409560005
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Question re undo

2015-11-20 Thread Bart Bunting
Hi there,

I've accidentally removed a bunch of tags in error and was dreaming
there may be a way to fix it :).

Is there any way to restore tags as they were at a certain point in
time?

Even if not now after i've done it, is there anything that could have been
done at the time to fix the error?

Kind regards
Bart
-- 

Bart Bunting - URSYS
PH: 02 87452811
Mbl: 0409560005
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


muchsync and osx compile failure

2015-11-08 Thread Bart Bunting

Hi,

Not sure if it is appropriate to post to this list with muchsync
questions but if not could someone let me know...

I'm trying to compile muchsync from git on OSX, I noted that the
announcement said it should compile cleanly.

I get the following when trying to compile:
make
g++ -DPACKAGE_NAME=\"muchsync\" -DPACKAGE_TARNAME=\"muchsync\" 
-DPACKAGE_VERSION=\"2\" -DPACKAGE_STRING=\"muchsync\ 2\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"muchsync\" 
-DVERSION=\"2\" -DHAVE_OPENAT=1 -DHAVE_FDOPENDIR=1 -DST_MTIM=st_mtimespec -I.   
 -I/usr/local/Cellar/xapian/1.2.19/include   -g -O2 -std=c++11 -Wall  -pthread 
-MT infinibuf.o -MD -MP -MF .deps/infinibuf.Tpo -c -o infinibuf.o infinibuf.cc
mv -f .deps/infinibuf.Tpo .deps/infinibuf.Po
g++ -DPACKAGE_NAME=\"muchsync\" -DPACKAGE_TARNAME=\"muchsync\" 
-DPACKAGE_VERSION=\"2\" -DPACKAGE_STRING=\"muchsync\ 2\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"muchsync\" 
-DVERSION=\"2\" -DHAVE_OPENAT=1 -DHAVE_FDOPENDIR=1 -DST_MTIM=st_mtimespec -I.   
 -I/usr/local/Cellar/xapian/1.2.19/include   -g -O2 -std=c++11 -Wall  -pthread 
-MT misc.o -MD -MP -MF .deps/misc.Tpo -c -o misc.o misc.cc
In file included from misc.cc:11:
./misc.h:10:10: fatal error: 'openssl/sha.h' file not found
#include 
> ^
1 error generated.
make: *** [misc.o] Error 1

And if it is of use here is the configure:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of g++... gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking whether C++ compiler accepts ... yes
checking whether C++ compiler accepts -pthread... yes
checking for openat... yes
checking for fdopendir... yes
checking for pkg-config... /usr/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for sqlite3... yes
checking for libcrypto... yes
checking for xapian-config... /usr/local/bin/xapian-config
checking For st_mtim in struct stat... no
checking For st_mtimespec in struct stat... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands


Thanks for any help.
Kind regards
Bart
-- 

Bart Bunting - URSYS
PH: 02 87452811
Mbl: 0409560005
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Build failure on OSX

2013-12-09 Thread Bart Bunting

Good morning,

I am still having issues building notmuch from source on OSX.

I'm unfortunately not sure if it is something specific to my setup or
not.

I am running latest git version of notmuch, osx 10.9.

Xapian and talloc are from homebrew.

If I manually edit the makefile to remove -lintl everything builds ok.
I'm not sure what the intl library is or does so not sure if something
else is subtly broken.

Can anyone else confirm the issue?  


make V=1
g++ command-line-arguments.o debugger.o gmime-filter-reply.o hooks.o notmuch.o 
notmuch-compact.o notmuch-config.o notmuch-count.o notmuch-dump.o 
notmuch-insert.o notmuch-new.o notmuch-reply.o notmuch-restore.o 
notmuch-search.o notmuch-setup.o notmuch-show.o notmuch-tag.o notmuch-time.o 
sprinter-json.o sprinter-sexp.o sprinter-text.o query-string.o mime-node.o 
crypto.o tag-util.o lib/libnotmuch.a util/libutil.a 
parse-time-string/libparse-time-string.a   -L/usr/local/Cellar/gmime/2.6.19/lib 
-L/usr/local/Cellar/glib/2.38.2/lib -lgmime-2.6 -lgio-2.0 -lgobject-2.0 
-lglib-2.0 -lintl  -L/usr/local/Cellar/talloc/2.0.8/lib -ltalloc  
-L/usr/local/Cellar/xapian/1.2.15/lib -lxapian -lz -o notmuch
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [notmuch] Error 1


Kind regards

Bart


Build failure on OSX

2013-12-08 Thread Bart Bunting

Good morning,

I am still having issues building notmuch from source on OSX.

I'm unfortunately not sure if it is something specific to my setup or
not.

I am running latest git version of notmuch, osx 10.9.

Xapian and talloc are from homebrew.

If I manually edit the makefile to remove -lintl everything builds ok.
I'm not sure what the intl library is or does so not sure if something
else is subtly broken.

Can anyone else confirm the issue?  


make V=1
g++ command-line-arguments.o debugger.o gmime-filter-reply.o hooks.o notmuch.o 
notmuch-compact.o notmuch-config.o notmuch-count.o notmuch-dump.o 
notmuch-insert.o notmuch-new.o notmuch-reply.o notmuch-restore.o 
notmuch-search.o notmuch-setup.o notmuch-show.o notmuch-tag.o notmuch-time.o 
sprinter-json.o sprinter-sexp.o sprinter-text.o query-string.o mime-node.o 
crypto.o tag-util.o lib/libnotmuch.a util/libutil.a 
parse-time-string/libparse-time-string.a   -L/usr/local/Cellar/gmime/2.6.19/lib 
-L/usr/local/Cellar/glib/2.38.2/lib -lgmime-2.6 -lgio-2.0 -lgobject-2.0 
-lglib-2.0 -lintl  -L/usr/local/Cellar/talloc/2.0.8/lib -ltalloc  
-L/usr/local/Cellar/xapian/1.2.15/lib -lxapian -lz -o notmuch
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [notmuch] Error 1


Kind regards

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


Links in email messages

2013-07-22 Thread Bart Bunting
That sounds exactly like what I was hoping for.


Kind regards
Bart

Mark Walters  writes:

> Hi
>
> I think C-c RET works to follow the link. At least that seems to do the
> same as clicking it.
>
> I agree that just RET would be nice, but also would like the links to be
> treated as buttons so next-button (ie TAB) would stop at them. What do
> other people think?
>
> (I have a preliminary implementation that does this)
>
> Best wishes
>
> Mark
>
>
>
>
> Bart Bunting  writes:
>
>> Adam,
>>
>> Thanks for the tip.  That is obvious now you point it out.
>>
>> I too would welcome an implementation that allowed hitting enter to
>> follow a link.  Hitting another key though is not too arduous.
>>
>> Guyzmo, no problems regarding your interpretation of my question.  I
>> should have been more specific with regards to emacs.
>>
>>  
>>
>> Kind regards
>>
>> Bart
>>
>> Adam Wolfe Gordon <awg+notmuch at xvx.ca> writes:
>>
>>> Hi Bart,
>>>
>>> On Sun, Jul 14, 2013 at 11:34 PM, Bart Bunting  wrote:
>>>> I am having trouble activating links in emails.  I guess what I
>>>> intuitively expect to happen is that if i hit enter on a link that it
>>>> opens up using browse-url-at-point or similar.
>>>>
>>>> All that appears to happen is that the message I'm viewing collapses.
>>>>
>>>> I would also if possible like urls to be active in text messages as
>>>> well.
>>>>
>>>> Is there an easy solution to this that I'm missing?
>>>
>>> First off, if anyone would like to implement this feature, I would
>>> definitely appreciate it. I don't have a great solution, but there are
>>> two workarounds I've used for this:
>>>
>>> 1. I used to use a terminal that automatically made links clickable
>>> (with a modifier key). This worked well until I got tired of other
>>> bugs in that terminal. (Note that this only applies if, like me, you
>>> run emacs -nw).
>>>
>>> 2. These days I add a key to the notmuch-show keymap mapped to
>>> browse-url-at-point, with the following:
>>>
>>> (define-key notmuch-show-mode-map "U" 'browse-url-at-point)
>>>
>>> So when there's a URL I want to see, I go to it and hit U. It's not as
>>> convenient/obvious as enter, but it works well enough. I assume this
>>> works in non-terminal emacs as well.
>>>
>>> -- Adam
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
Bart


Links in email messages

2013-07-16 Thread Bart Bunting
Adam,

Thanks for the tip.  That is obvious now you point it out.

I too would welcome an implementation that allowed hitting enter to
follow a link.  Hitting another key though is not too arduous.

Guyzmo, no problems regarding your interpretation of my question.  I
should have been more specific with regards to emacs.



Kind regards

Bart

Adam Wolfe Gordon <awg+notmuch at xvx.ca> writes:

> Hi Bart,
>
> On Sun, Jul 14, 2013 at 11:34 PM, Bart Bunting  wrote:
>> I am having trouble activating links in emails.  I guess what I
>> intuitively expect to happen is that if i hit enter on a link that it
>> opens up using browse-url-at-point or similar.
>>
>> All that appears to happen is that the message I'm viewing collapses.
>>
>> I would also if possible like urls to be active in text messages as
>> well.
>>
>> Is there an easy solution to this that I'm missing?
>
> First off, if anyone would like to implement this feature, I would
> definitely appreciate it. I don't have a great solution, but there are
> two workarounds I've used for this:
>
> 1. I used to use a terminal that automatically made links clickable
> (with a modifier key). This worked well until I got tired of other
> bugs in that terminal. (Note that this only applies if, like me, you
> run emacs -nw).
>
> 2. These days I add a key to the notmuch-show keymap mapped to
> browse-url-at-point, with the following:
>
> (define-key notmuch-show-mode-map "U" 'browse-url-at-point)
>
> So when there's a URL I want to see, I go to it and hit U. It's not as
> convenient/obvious as enter, but it works well enough. I assume this
> works in non-terminal emacs as well.
>
> -- Adam


Errors after upgrade to 0.14

2012-08-23 Thread Bart Bunting
Ok perhaps this is more helpfull?

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  notmuch-search-show-result("tags")
  byte-code("\304\305\"\203\306
!\307=\203\310\202Q\303\202Q\304\311\"\203D\312
!\304\313\"\2030\310\202@\304\314\"\203<\315\202@\316!\210)\202Q\304\317\"\203Q\320
 !\210\310\304\207" [notmuch-search-process-state notmuch-search-json-parser 
done result memql (begin) notmuch-json-begin-compound retry t (result) 
notmuch-json-read (retry) (end) end notmuch-search-show-result (end) 
notmuch-json-eof] 3)
  notmuch-search-process-filter(# ", \"tags\": []},\nA 
Xapian exception occurred performing query: The revision being read has been 
discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a59\n{\"thread\": 
\"0001fd19\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a57\n{\"thread\": 
\"00020a59\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a57\n{\"thread\": 
\"00020a57\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": ")
  recursive-edit()
  debug(error (error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  error("A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked")
  notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:00022288")
  apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
"thread:00022288"))
  notmuch-tag("thread:00022288" ("-inbox"))
  notmuch-search-tag-region(202 202 ("-inbox"))
  notmuch-search-tag(("-inbox"))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)
  recursive-edit()
  debug(error (error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")


Kind regards

Bart


Errors after upgrade to 0.14

2012-08-23 Thread Bart Bunting
Austin,

I agree, it appears to be the normal locking issue.
That poses a problem but one I'm used to.

I was doing an archive when I hit the other error as well.

I just got a debug traceback when entering the inbox from the hello
screen.  Unfortunately it locked up my entire emacs and had to kill the
process.

I'll keep trying until I get something more helpfull.

Cheers
Bart




Austin Clements  writes:

> This looks like a different error from the one in your original email.
> Was the original error also triggered by hitting 'a'?
>
> This error is definitely from simultaneous access to the database and
> is expected.  But this has been a problem since the dawn of notmuch
> and shouldn't have started just with 0.14 (unless we did something to
> make it worse?).  I do have some experimental patches that fix the
> database locking issues if it's turning out to be a serious problem
> for you, but the fix introduces its own issues.
>
> Quoth Bart Bunting on Aug 23 at 11:21 am:
>> Hi Austin,
>> 
>> I applied the patch and this error was from after that.
>> 
>> The way it was triggered was by hitting 'a' to archive a message in the
>> search view.
>> 
>> From what I can tell it's just the xapian error and there is nothing
>> about json.  Hope it means more to you.
>> 
>> Debugger entered--Lisp error: (error "A Xapian exception occurred opening 
>> database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: 
>> already locked")
>>   ad-Orig-signal(error ("A Xapian exception occurred opening database: 
>> Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
>> locked"))
>>   signal(error ("A Xapian exception occurred opening database: Unable to get 
>> write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
>>   ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
>> write lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   apply(ad-Orig-error "A Xapian exception occurred opening database: Unable 
>> to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   error("A Xapian exception occurred opening database: Unable to get write 
>> lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:000225c8")
>>   apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
>> "thread:000225c8"))
>>   notmuch-tag("thread:000225c8" ("-inbox"))
>>   notmuch-search-tag-region(800 800 ("-inbox"))
>>   notmuch-search-tag(("-inbox"))
>>   ad-Orig-notmuch-search-archive-thread()
>>   notmuch-search-archive-thread()
>>   call-interactively(notmuch-search-archive-thread nil nil)
>> 
>> 
>> Kind regards
>> 
>> Austin Clements  writes:
>> 
>> > Quoth myself on Aug 22 at  8:41 pm:
>> >> Quoth Bart Bunting on Aug 23 at  9:36 am:
>> >> > Good morning,
>> >> > 
>> >> > After upgrading to notmuch 014 I am seeing the following messages appear
>> >> > in the messages buffer.
>> >> > 
>> >> > error in process filter: byte-code: Wrong type argument: 
>> >> > number-or-marker-p, nil
>> >> > error in process filter: Wrong type argument: number-or-marker-p, nil
>> >> > 
>> >> > I am also getting a repeating message in the minibuffer (I think) which
>> >> > says something like "json read tail error".  Sorry that I am not more
>> >> > specific as I use emacspeak and this message appears to repeat many
>> >> > times interupting speech so I am not 100% sure of what it exactly says.
>> >> 
>> >> This is probably "json-readtable-error", which is, unfortunately,
>> >> about the most generic error the JSON parser can give.
>> >> 
>> >> > My gut feeling is that it is happening when notmuch is updating the
>> >> > database or something.
>> >> > 
>> >> > Is this expected behaviour?  It is particularly annoying for me as it
>> >> > sends the speech synth crazy and crashes it for a period of about 30
>> >> > seconds.
>> >> > 
>> >> > If it is expected then I will try and find a way to prevent emacspeak
>> >> > from trying to read it.
>> >> 
>> >> This is definitely not expected behavior.  Does this happen wh

Errors after upgrade to 0.14

2012-08-23 Thread Bart Bunting
Hi Austin,

I applied the patch and this error was from after that.

The way it was triggered was by hitting 'a' to archive a message in the
search view.

>From what I can tell it's just the xapian error and there is nothing
about json.  Hope it means more to you.

Debugger entered--Lisp error: (error "A Xapian exception occurred opening 
database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
locked")
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  error("A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked")
  notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:000225c8")
  apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
"thread:000225c8"))
  notmuch-tag("thread:000225c8" ("-inbox"))
  notmuch-search-tag-region(800 800 ("-inbox"))
  notmuch-search-tag(("-inbox"))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)


Kind regards

Austin Clements  writes:

> Quoth myself on Aug 22 at  8:41 pm:
>> Quoth Bart Bunting on Aug 23 at  9:36 am:
>> > Good morning,
>> > 
>> > After upgrading to notmuch 014 I am seeing the following messages appear
>> > in the messages buffer.
>> > 
>> > error in process filter: byte-code: Wrong type argument: 
>> > number-or-marker-p, nil
>> > error in process filter: Wrong type argument: number-or-marker-p, nil
>> > 
>> > I am also getting a repeating message in the minibuffer (I think) which
>> > says something like "json read tail error".  Sorry that I am not more
>> > specific as I use emacspeak and this message appears to repeat many
>> > times interupting speech so I am not 100% sure of what it exactly says.
>> 
>> This is probably "json-readtable-error", which is, unfortunately,
>> about the most generic error the JSON parser can give.
>> 
>> > My gut feeling is that it is happening when notmuch is updating the
>> > database or something.
>> > 
>> > Is this expected behaviour?  It is particularly annoying for me as it
>> > sends the speech synth crazy and crashes it for a period of about 30
>> > seconds.
>> > 
>> > If it is expected then I will try and find a way to prevent emacspeak
>> > from trying to read it.
>> 
>> This is definitely not expected behavior.  Does this happen when
>> you're searching for messages or when you're viewing a thread?  Can
>> you give any more details on what you're doing when you get this
>> error?
>> 
>> Try doing M-x toggle-debug-on-error and then triggering the error.
>> Hopefully Emacs will give you a buffer with a backtrace that will give
>> us a better idea of where this is happening.
>
> Actually, I might know what's going on here.  Based on your suspicion
> about notmuch updating the database and assuming that this happens in
> the search buffer, I think the parser error recovery code is leaving
> the parser in a slightly invalid state, which causes the next
> invocation to think it can consume more data when there is no more
> data to consume.  I would expect that to give at most one readtable
> error, but maybe there's something I'm overlooking.
>
> Could you try the following one line patch?
>
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index 900235b..a09c0f6 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -375,7 +375,7 @@ resynchronize after an error by moving point."
>  
>(if (eq (notmuch-json-next jp) 'value)
>;; We're already at a value
> -  nil
> +  (if (eobp) 'retry nil)
>  ;; Drive the state toward 'expect-value
>  (skip-chars-forward " \t\r\n")
>  (or (when (eobp) 'retry)
>
Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:   +61 2 8745 2811
Mbl:  0409 560 005


Errors after upgrade to 0.14

2012-08-23 Thread Bart Bunting
Good morning,

After upgrading to notmuch 014 I am seeing the following messages appear
in the messages buffer.

error in process filter: byte-code: Wrong type argument: number-or-marker-p, nil
error in process filter: Wrong type argument: number-or-marker-p, nil

I am also getting a repeating message in the minibuffer (I think) which
says something like "json read tail error".  Sorry that I am not more
specific as I use emacspeak and this message appears to repeat many
times interupting speech so I am not 100% sure of what it exactly says.

My gut feeling is that it is happening when notmuch is updating the
database or something.

Is this expected behaviour?  It is particularly annoying for me as it
sends the speech synth crazy and crashes it for a period of about 30
seconds.

If it is expected then I will try and find a way to prevent emacspeak
from trying to read it.



Kind regards

Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:   +61 2 8745 2811
Mbl:  0409 560 005


Re: Errors after upgrade to 0.14

2012-08-22 Thread Bart Bunting
Hi Austin,

I applied the patch and this error was from after that.

The way it was triggered was by hitting 'a' to archive a message in the
search view.

From what I can tell it's just the xapian error and there is nothing
about json.  Hope it means more to you.

Debugger entered--Lisp error: (error A Xapian exception occurred opening 
database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
locked)
  ad-Orig-signal(error (A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  signal(error (A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  ad-Orig-error(A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked)
  apply(ad-Orig-error A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked)
  error(A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked)
  notmuch-call-notmuch-process(tag -inbox -- thread:000225c8)
  apply(notmuch-call-notmuch-process tag (-inbox -- 
thread:000225c8))
  notmuch-tag(thread:000225c8 (-inbox))
  notmuch-search-tag-region(800 800 (-inbox))
  notmuch-search-tag((-inbox))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)


Kind regards

Austin Clements amdra...@mit.edu writes:

 Quoth myself on Aug 22 at  8:41 pm:
 Quoth Bart Bunting on Aug 23 at  9:36 am:
  Good morning,
  
  After upgrading to notmuch 014 I am seeing the following messages appear
  in the messages buffer.
  
  error in process filter: byte-code: Wrong type argument: 
  number-or-marker-p, nil
  error in process filter: Wrong type argument: number-or-marker-p, nil
  
  I am also getting a repeating message in the minibuffer (I think) which
  says something like json read tail error.  Sorry that I am not more
  specific as I use emacspeak and this message appears to repeat many
  times interupting speech so I am not 100% sure of what it exactly says.
 
 This is probably json-readtable-error, which is, unfortunately,
 about the most generic error the JSON parser can give.
 
  My gut feeling is that it is happening when notmuch is updating the
  database or something.
  
  Is this expected behaviour?  It is particularly annoying for me as it
  sends the speech synth crazy and crashes it for a period of about 30
  seconds.
  
  If it is expected then I will try and find a way to prevent emacspeak
  from trying to read it.
 
 This is definitely not expected behavior.  Does this happen when
 you're searching for messages or when you're viewing a thread?  Can
 you give any more details on what you're doing when you get this
 error?
 
 Try doing M-x toggle-debug-on-error and then triggering the error.
 Hopefully Emacs will give you a buffer with a backtrace that will give
 us a better idea of where this is happening.

 Actually, I might know what's going on here.  Based on your suspicion
 about notmuch updating the database and assuming that this happens in
 the search buffer, I think the parser error recovery code is leaving
 the parser in a slightly invalid state, which causes the next
 invocation to think it can consume more data when there is no more
 data to consume.  I would expect that to give at most one readtable
 error, but maybe there's something I'm overlooking.

 Could you try the following one line patch?

 diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
 index 900235b..a09c0f6 100644
 --- a/emacs/notmuch-lib.el
 +++ b/emacs/notmuch-lib.el
 @@ -375,7 +375,7 @@ resynchronize after an error by moving point.
  
(if (eq (notmuch-json-next jp) 'value)
;; We're already at a value
 -  nil
 +  (if (eobp) 'retry nil)
  ;; Drive the state toward 'expect-value
  (skip-chars-forward  \t\r\n)
  (or (when (eobp) 'retry)

Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:   +61 2 8745 2811
Mbl:  0409 560 005
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Errors after upgrade to 0.14

2012-08-22 Thread Bart Bunting
Austin,

I agree, it appears to be the normal locking issue.
That poses a problem but one I'm used to.

I was doing an archive when I hit the other error as well.

I just got a debug traceback when entering the inbox from the hello
screen.  Unfortunately it locked up my entire emacs and had to kill the
process.

I'll keep trying until I get something more helpfull.

Cheers
Bart




Austin Clements amdra...@mit.edu writes:

 This looks like a different error from the one in your original email.
 Was the original error also triggered by hitting 'a'?

 This error is definitely from simultaneous access to the database and
 is expected.  But this has been a problem since the dawn of notmuch
 and shouldn't have started just with 0.14 (unless we did something to
 make it worse?).  I do have some experimental patches that fix the
 database locking issues if it's turning out to be a serious problem
 for you, but the fix introduces its own issues.

 Quoth Bart Bunting on Aug 23 at 11:21 am:
 Hi Austin,
 
 I applied the patch and this error was from after that.
 
 The way it was triggered was by hitting 'a' to archive a message in the
 search view.
 
 From what I can tell it's just the xapian error and there is nothing
 about json.  Hope it means more to you.
 
 Debugger entered--Lisp error: (error A Xapian exception occurred opening 
 database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: 
 already locked)
   ad-Orig-signal(error (A Xapian exception occurred opening database: 
 Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
 locked))
   signal(error (A Xapian exception occurred opening database: Unable to get 
 write lock on /Users/bart/mail/.notmuch/xapian: already locked))
   ad-Orig-error(A Xapian exception occurred opening database: Unable to get 
 write lock on /Users/bart/mail/.notmuch/xapian: already locked)
   apply(ad-Orig-error A Xapian exception occurred opening database: Unable 
 to get write lock on /Users/bart/mail/.notmuch/xapian: already locked)
   error(A Xapian exception occurred opening database: Unable to get write 
 lock on /Users/bart/mail/.notmuch/xapian: already locked)
   notmuch-call-notmuch-process(tag -inbox -- thread:000225c8)
   apply(notmuch-call-notmuch-process tag (-inbox -- 
 thread:000225c8))
   notmuch-tag(thread:000225c8 (-inbox))
   notmuch-search-tag-region(800 800 (-inbox))
   notmuch-search-tag((-inbox))
   ad-Orig-notmuch-search-archive-thread()
   notmuch-search-archive-thread()
   call-interactively(notmuch-search-archive-thread nil nil)
 
 
 Kind regards
 
 Austin Clements amdra...@mit.edu writes:
 
  Quoth myself on Aug 22 at  8:41 pm:
  Quoth Bart Bunting on Aug 23 at  9:36 am:
   Good morning,
   
   After upgrading to notmuch 014 I am seeing the following messages appear
   in the messages buffer.
   
   error in process filter: byte-code: Wrong type argument: 
   number-or-marker-p, nil
   error in process filter: Wrong type argument: number-or-marker-p, nil
   
   I am also getting a repeating message in the minibuffer (I think) which
   says something like json read tail error.  Sorry that I am not more
   specific as I use emacspeak and this message appears to repeat many
   times interupting speech so I am not 100% sure of what it exactly says.
  
  This is probably json-readtable-error, which is, unfortunately,
  about the most generic error the JSON parser can give.
  
   My gut feeling is that it is happening when notmuch is updating the
   database or something.
   
   Is this expected behaviour?  It is particularly annoying for me as it
   sends the speech synth crazy and crashes it for a period of about 30
   seconds.
   
   If it is expected then I will try and find a way to prevent emacspeak
   from trying to read it.
  
  This is definitely not expected behavior.  Does this happen when
  you're searching for messages or when you're viewing a thread?  Can
  you give any more details on what you're doing when you get this
  error?
  
  Try doing M-x toggle-debug-on-error and then triggering the error.
  Hopefully Emacs will give you a buffer with a backtrace that will give
  us a better idea of where this is happening.
 
  Actually, I might know what's going on here.  Based on your suspicion
  about notmuch updating the database and assuming that this happens in
  the search buffer, I think the parser error recovery code is leaving
  the parser in a slightly invalid state, which causes the next
  invocation to think it can consume more data when there is no more
  data to consume.  I would expect that to give at most one readtable
  error, but maybe there's something I'm overlooking.
 
  Could you try the following one line patch?
 
  diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
  index 900235b..a09c0f6 100644
  --- a/emacs/notmuch-lib.el
  +++ b/emacs/notmuch-lib.el
  @@ -375,7 +375,7 @@ resynchronize after an error by moving point.
   
 (if (eq (notmuch-json-next jp) 'value

Re: Errors after upgrade to 0.14

2012-08-22 Thread Bart Bunting
Ok perhaps this is more helpfull?

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  notmuch-search-show-result(tags)
  byte-code(\304\305\\203\306
!\307=\203\310\202Q\303\202Q\304\311\\203D\312
!\304\313\\2030\310\202@\304\314\\203\315\202@\316!\210)\202Q\304\317\\203Q\320
 !\210\310\304\207 [notmuch-search-process-state notmuch-search-json-parser 
done result memql (begin) notmuch-json-begin-compound retry t (result) 
notmuch-json-read (retry) (end) end notmuch-search-show-result (end) 
notmuch-json-eof] 3)
  notmuch-search-process-filter(#process notmuch-search , \tags\: []},\nA 
Xapian exception occurred performing query: The revision being read has been 
discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a59\n{\thread\: 
\0001fd19\, \timestamp\: 0, \date_relative\: \1970-01-01\, 
\matched\: 0, \total\: 0, \authors\: \\, \subject\: \\, \tags\: 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a57\n{\thread\: 
\00020a59\, \timestamp\: 0, \date_relative\: \1970-01-01\, 
\matched\: 0, \total\: 0, \authors\: \\, \subject\: \\, \tags\: 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery 
 string was: thread:00020a57\n{\thread\: \00020a57\, 
\timestamp\: 0, \date_relative\: \1970-01-01\, \matched\: 0, \total\: 
0, \authors\: )
  recursive-edit()
  debug(error (error A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  ad-Orig-signal(error (A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  signal(error (A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  ad-Orig-error(A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked)
  apply(ad-Orig-error A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked)
  error(A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked)
  notmuch-call-notmuch-process(tag -inbox -- thread:00022288)
  apply(notmuch-call-notmuch-process tag (-inbox -- 
thread:00022288))
  notmuch-tag(thread:00022288 (-inbox))
  notmuch-search-tag-region(202 202 (-inbox))
  notmuch-search-tag((-inbox))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)
  recursive-edit()
  debug(error (error A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  ad-Orig-signal(error (A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  signal(error (A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked))
  ad-Orig-error(A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked)
  apply(ad-Orig-error A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked)


Kind regards

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


Any tips on emacs and different signatures per address

2012-06-06 Thread Bart Bunting
Good morning,

I am hoping this isn't off topic.

I have several different email addresses that notmuch handles mail for.
I am trying to understand how I can have multiple different signatures
based on the account from which I am sending the email.

One possibility looks like somehow using message-mode to do this but I
can't quite figure it out.

The other thing I would like in an ideal world is to change the bcc
address to a different address again based on the from address of the
email I am sending.

Sorry if this is trivial.

Any pointers or snippits of config would be greatly appreciated.

Kind regards

Bart



Any tips on emacs and different signatures per address

2012-06-05 Thread Bart Bunting
Good morning,

I am hoping this isn't off topic.

I have several different email addresses that notmuch handles mail for.
I am trying to understand how I can have multiple different signatures
based on the account from which I am sending the email.

One possibility looks like somehow using message-mode to do this but I
can't quite figure it out.

The other thing I would like in an ideal world is to change the bcc
address to a different address again based on the from address of the
email I am sending.

Sorry if this is trivial.

Any pointers or snippits of config would be greatly appreciated.

Kind regards

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


ANNOUNCE: nottoomuch-addresses.pl

2011-12-06 Thread Bart Bunting
Hi Tomi,

I made the changes for case insensitivity and I much prefer that.

Perhaps it could be an option if you like it the other way around.

Kind regards

Bart


ANNOUNCE: nottoomuch-addresses.pl

2011-12-06 Thread Bart Bunting
Hi,

I agree with Jamie on this one.

The case sensitivity appears to get in the way of searching.  I also
think that enabling the regular expressionsearching is a good idea.

All in all though this is great.

The only other idea I have, which is only half formed, is that it would
be nice to prioritize emails that are more important than others.

I'm not sure exactly how this would work but something like:
- Addresses I have actualy sent email to rather than jjust received from
get a high priority in the result.
- Addresses that have sent me email directly rather than just to a list
get next priority.
- All other emails after that.

Also some sort of weighting within the groups to do with frequency of
emails sent or something.


Does that make sense?  Would it be hard to implement?


Cheers

Bart

> On Mon, 05 Dec 2011 14:35:03 +0200, Tomi Ollila  wrote:
> > Yes, the search is deliberately case sensitive.
> 
> I haven't had a chance to play around with this but I will say that it
> makes more sense to me that this kind of search should deliberately be
> case *in*sensitive.  Case sensitivity seems fairly detrimental here,
> actually, considering there is no consistency in case in names or email
> addresses.
> 
> jamie.


ANNOUNCE: nottoomuch-addresses.pl

2011-12-05 Thread Bart Bunting
Hi Tomi,

Another observation.  Not sure if this is a bug or a design decision:
I have the address:
"Zac Hamed" 
a serch like:
./nottoomuch-addresses.pl  zham

shows it up as expected.

However if I search on the name part like:
./nottoomuch-addresses.pl  zac

It doesn't find the match.

Is this expected behaviour?

Kind regards

Bart




 On Mon, 05 Dec 2011 13:51:16 +0200, Tomi Ollila  
wrote:
> Hi
> 
> Thanks to Bart's findings those things are now fixed in
> version 1.1 of nottoomuch-addresses.pl 
> 
> Get it:
> 
> (wget) http://www.iki.fi/too/nottoomuch/nottoomuch-addresses.pl 
> 
> Sha1 digest is now 4ed74ef9eaabb73804e55caa2c29682e643d2b78
> 
> Installation instructions & some other info now available at:
> 
> http://www.iki.fi/too/nottoomuch/nottoomuch-addresses/
> 
> 
> Tomi


Re: ANNOUNCE: nottoomuch-addresses.pl

2011-12-05 Thread Bart Bunting
Hi Tomi,

Another observation.  Not sure if this is a bug or a design decision:
I have the address:
Zac Hamed zha...@xx.xxx.au
a serch like:
./nottoomuch-addresses.pl  zham

shows it up as expected.

However if I search on the name part like:
./nottoomuch-addresses.pl  zac

It doesn't find the match.

Is this expected behaviour?

Kind regards

Bart




 On Mon, 05 Dec 2011 13:51:16 +0200, Tomi Ollila tomi.oll...@nixu.com wrote:
 Hi
 
 Thanks to Bart's findings those things are now fixed in
 version 1.1 of nottoomuch-addresses.pl 
 
 Get it:
 
 (wget) http://www.iki.fi/too/nottoomuch/nottoomuch-addresses.pl 
 
 Sha1 digest is now 4ed74ef9eaabb73804e55caa2c29682e643d2b78
 
 Installation instructions  some other info now available at:
 
 http://www.iki.fi/too/nottoomuch/nottoomuch-addresses/
 
 
 Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: ANNOUNCE: nottoomuch-addresses.pl

2011-12-05 Thread Bart Bunting
Hi,

I agree with Jamie on this one.

The case sensitivity appears to get in the way of searching.  I also
think that enabling the regular expressionsearching is a good idea.

All in all though this is great.

The only other idea I have, which is only half formed, is that it would
be nice to prioritize emails that are more important than others.

I'm not sure exactly how this would work but something like:
- Addresses I have actualy sent email to rather than jjust received from
get a high priority in the result.
- Addresses that have sent me email directly rather than just to a list
get next priority.
- All other emails after that.

Also some sort of weighting within the groups to do with frequency of
emails sent or something.


Does that make sense?  Would it be hard to implement?


Cheers

Bart
  
 On Mon, 05 Dec 2011 14:35:03 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
  Yes, the search is deliberately case sensitive.
 
 I haven't had a chance to play around with this but I will say that it
 makes more sense to me that this kind of search should deliberately be
 case *in*sensitive.  Case sensitivity seems fairly detrimental here,
 actually, considering there is no consistency in case in names or email
 addresses.
 
 jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: ANNOUNCE: nottoomuch-addresses.pl

2011-12-05 Thread Bart Bunting
Hi Tomi,

I made the changes for case insensitivity and I much prefer that.

Perhaps it could be an option if you like it the other way around.

Kind regards

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


ANNOUNCE: nottoomuch-addresses.pl

2011-12-02 Thread Bart Bunting
Hi Tomi,

I have had a quick try of setting up nottoomuch-addresses addresses.

Here are a couple of issues I have hit and I think it's still not quite
 right.

I attach the shell output from emacs below.

- firstly it appears that if the term is set to DUMB then the script
assumes it's being called from emacs and exits if there is no search
string.  This is problematic for me as I run all my stuff including the
--update command from a shell.  
- The instructions don't tell you to create the .config/nottoomuch
directory.  Perhaps you could check for it's existance and create if
required?
- Even when I got this far I had an odd result when running the script
as shown below.  First time I got a strange error.  Second run it added
900 or so addresses.  Subsiquent runs added no more addresses.  I find
this strange as I have over 180k emails.

Anyway great work.  Heading in a cool direction.  Hope this somewhat
rambling report helps.

Bart

bart at bit:~$
bart at bit:~$shasum ~/bin/nottoomuch-addresses.pl 
125f3917b3f2dc68bdf30af04ab623d53321e50c  
/Users/bart/bin/nottoomuch-addresses.pl
bart at bit:~$chmod 755 ~/bin/nottoomuch-addresses.pl 
bart at bit:~$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart at bit:~$cd
bart at bit:~$cd .config
bash: cd: .config: No such file or directory
bart at bit:~$
bart at bit:~$mkdir .config
bart at bit:~$nottoomuch --update
bash: nottoomuch: command not found
bart at bit:~$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart at bit:~$
bart at bit:~$cd
bart at bit:~$cd .config
bart at bit:~/.config$mkdir nottoomuch
bart at bit:~/.config$
bart at bit:~/.config$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart at bit:~/.config$cd nottoomuch/
bart at bit:~/.config/nottoomuch$touch addresses
bart at bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
bart at bit:~/.config/nottoomuch$ls
addresses
bart at bit:~/.config/nottoomuch$ls -s addresses 
0 addresses
bart at bit:~/.config/nottoomuch$echo $TERM
dumb
bart at bit:~/.config/nottoomuch$export TERM=emacs
bart at bit:~/.config/nottoomuch$ls -s addresses 
0 addresses
bart at bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since -604800.
Unrecognized option: -604800..
Added 0 addresses in 0 seconds. Total number of addresses: 0.
bart at bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since 1322159542.
Added 993 addresses in 4 seconds. Total number of addresses: 993.
bart at bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since 1322159560.
Added 0 addresses in 1 seconds. Total number of addresses: 993.
bart at bit:~/.config/nottoomuch$ On Thu, 01 Dec 2011 17:36:24 +0200, Tomi 
Ollila  wrote:


Having trouble displaying some html emails

2011-12-01 Thread Bart Bunting
Thanks tomi, 

I missed your reply.

This works  beautifully!

Thanks

Bart

On Tue, 15 Nov 2011 09:51:26 +0200, Tomi Ollila  wrote:
> On Tue, 15 Nov 2011 10:37:42 +1100, Bart Bunting  
> wrote:
> > Hi everyone,
> > 
> > I am having an issue with html emails displaying correctly.
> > 
> > For some reason the first time I view a html email it displays
> > correctly.  All subsequent attempts to view html emails result in the
> > following error:
> > 
> > mm-shr: Wrong type argument: bufferp, "*Summary*"
> > 
> > 
> > The message opens but the parts are hidden like this:
> > 
> > [ multipart/mixed ]
> > [ text/html ]
> > 
> > 
> > I'm not exactly sure what is going on here or what the best way to debug
> > is?
> > 
> > Any one have any ideas or suggestions?
> 
> You could try
> 
> (setq mm-text-html-renderer 'w3m)
> 
> or
> 
> (setq mm-text-html-renderer 'w3m-standalone)
> 
> 
> For w3m-standalone you need w3m binary to be installed
> and with w3m you also need some w3m.el elisp packages
> (which may or may not be installed along emacs)
> (or something)
> 
> > 
> > Kind regards
> > 
> > Bart
> 
> Tomi


Re: ANNOUNCE: nottoomuch-addresses.pl

2011-12-01 Thread Bart Bunting
Hi Tomi,

I have had a quick try of setting up nottoomuch-addresses addresses.

Here are a couple of issues I have hit and I think it's still not quite
 right.

I attach the shell output from emacs below.

- firstly it appears that if the term is set to DUMB then the script
assumes it's being called from emacs and exits if there is no search
string.  This is problematic for me as I run all my stuff including the
--update command from a shell.  
- The instructions don't tell you to create the .config/nottoomuch
directory.  Perhaps you could check for it's existance and create if
required?
- Even when I got this far I had an odd result when running the script
as shown below.  First time I got a strange error.  Second run it added
900 or so addresses.  Subsiquent runs added no more addresses.  I find
this strange as I have over 180k emails.

Anyway great work.  Heading in a cool direction.  Hope this somewhat
rambling report helps.

Bart

bart@bit:~$
bart@bit:~$shasum ~/bin/nottoomuch-addresses.pl 
125f3917b3f2dc68bdf30af04ab623d53321e50c  
/Users/bart/bin/nottoomuch-addresses.pl
bart@bit:~$chmod 755 ~/bin/nottoomuch-addresses.pl 
bart@bit:~$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart@bit:~$cd
bart@bit:~$cd .config
bash: cd: .config: No such file or directory
bart@bit:~$
bart@bit:~$mkdir .config
bart@bit:~$nottoomuch --update
bash: nottoomuch: command not found
bart@bit:~$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart@bit:~$
bart@bit:~$cd
bart@bit:~$cd .config
bart@bit:~/.config$mkdir nottoomuch
bart@bit:~/.config$
bart@bit:~/.config$~/bin/nottoomuch-addresses.pl  --update
Cannot open database, maybe not created yet.
run /Users/bart/bin/nottoomuch-addresses.pl --update from command line first.
bart@bit:~/.config$cd nottoomuch/
bart@bit:~/.config/nottoomuch$touch addresses
bart@bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
bart@bit:~/.config/nottoomuch$ls
addresses
bart@bit:~/.config/nottoomuch$ls -s addresses 
0 addresses
bart@bit:~/.config/nottoomuch$echo $TERM
dumb
bart@bit:~/.config/nottoomuch$export TERM=emacs
bart@bit:~/.config/nottoomuch$ls -s addresses 
0 addresses
bart@bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since -604800.
Unrecognized option: -604800..
Added 0 addresses in 0 seconds. Total number of addresses: 0.
bart@bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since 1322159542.
Added 993 addresses in 4 seconds. Total number of addresses: 993.
bart@bit:~/.config/nottoomuch$~/bin/nottoomuch-addresses.pl  --update
Updating '/Users/bart/.config/nottoomuch/addresses', since 1322159560.
Added 0 addresses in 1 seconds. Total number of addresses: 993.
bart@bit:~/.config/nottoomuch$ On Thu, 01 Dec 2011 17:36:24 +0200, Tomi Ollila 
tomi.oll...@iki.fi wrote:
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Having trouble displaying some html emails

2011-11-30 Thread Bart Bunting
Thanks tomi, 

I missed your reply.

This works  beautifully!

Thanks

Bart
 
On Tue, 15 Nov 2011 09:51:26 +0200, Tomi Ollila tomi.oll...@iki.fi wrote:
 On Tue, 15 Nov 2011 10:37:42 +1100, Bart Bunting b...@bunting.net.au wrote:
  Hi everyone,
  
  I am having an issue with html emails displaying correctly.
  
  For some reason the first time I view a html email it displays
  correctly.  All subsequent attempts to view html emails result in the
  following error:
  
  mm-shr: Wrong type argument: bufferp, *Summary*
  
  
  The message opens but the parts are hidden like this:
  
  [ multipart/mixed ]
  [ text/html ]
  
  
  I'm not exactly sure what is going on here or what the best way to debug
  is?
  
  Any one have any ideas or suggestions?
 
 You could try
 
 (setq mm-text-html-renderer 'w3m)
 
 or
 
 (setq mm-text-html-renderer 'w3m-standalone)
 
 
 For w3m-standalone you need w3m binary to be installed
 and with w3m you also need some w3m.el elisp packages
 (which may or may not be installed along emacs)
 (or something)
 
  
  Kind regards
  
  Bart
 
 Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Having trouble displaying some html emails

2011-11-15 Thread Bart Bunting
Hi everyone,

I am having an issue with html emails displaying correctly.

For some reason the first time I view a html email it displays
correctly.  All subsequent attempts to view html emails result in the
following error:

mm-shr: Wrong type argument: bufferp, "*Summary*"


The message opens but the parts are hidden like this:

[ multipart/mixed ]
[ text/html ]


I'm not exactly sure what is going on here or what the best way to debug
is?

Any one have any ideas or suggestions?

Kind regards

Bart





Having trouble displaying some html emails

2011-11-14 Thread Bart Bunting
Hi everyone,

I am having an issue with html emails displaying correctly.

For some reason the first time I view a html email it displays
correctly.  All subsequent attempts to view html emails result in the
following error:

mm-shr: Wrong type argument: bufferp, *Summary*


The message opens but the parts are hidden like this:

[ multipart/mixed ]
[ text/html ]


I'm not exactly sure what is going on here or what the best way to debug
is?

Any one have any ideas or suggestions?

Kind regards

Bart


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


Notmuch on os x?

2011-03-22 Thread Bart Bunting
Hi all,

Has anyone compiled notmuch for the mac?

If so how?  I'm new to the mac and can find xapian but not the other
libraries notmuch requires.

TIA

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


Notmuch on os x?

2011-03-18 Thread Bart Bunting
Hi all,

Has anyone compiled notmuch for the mac?

If so how?  I'm new to the mac and can find xapian but not the other
libraries notmuch requires.

TIA

Bart


Notmuch with multiple imap accounts?

2010-12-07 Thread Bart Bunting
Hi Everyone,

I have recently had to split my mail in to two imap accounts.

Up until now I have been using notmuch with no issues with one account
and offlineimap.

All my email is under ~/MAIL.

I can configure offlineimap with two accounts each in a different
directory.  However I am not sure how I can configure notmuch to work in
this way?  If anyone has any tips or pointers that would be greatly
appreciated.  I presume what I need to do is to move my two maildirs
under a common directory and tell notmuch to index that?  Or is there a
way to have notmuch look at multiple maildirs?

Cheers

Bart


[notmuch] notmuch.el and searching within citations

2010-01-09 Thread Bart Bunting
Hi all,



I am having a little bit of trouble with notmuch.el, I'm not sure if I'm
just not understanding how it works or if there is an actual issue.



The problem is that if I search for a word, lets say grandfather using 's'
from the notmuch buffer a list of messages is returned correctly that
contain the word.

Next I hit enter on the thread I want to read.

Then I use 'c-s' to search forward through the buffer for the word
'grandfather'.  

Provided that the word is in a non citation part of the buffer all works as
expected.

If however the word 'grandfather' appears in a citation then an incremental
search through the buffer won't find it.

If the citation is expanded then things work as expected.



I don't think this is very logical behavior as it stands, having to expand
each citation to be able to search in it appears to sort of defeat the
search.



Ideally I would like to be able to search forward and if the word was in a
citation to have it automagicaly expand for me.  

Alternatively Just having point land on the citation would be enough to let
me know there was something inside I may want to read.



What do others think?



Regards



Bart



-- next part --
An HTML attachment was scrubbed...
URL: