bug report: Emacs notmuch-mode fails attachments with spaces
David Edmondson writes:
> On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote:
>> Tomi Ollila writes:
>>
>>> On Mon, Feb 09 2015, Nils Dagsson Moskopp >> dieweltistgarnichtso.net> wrote:
>>>
>>>> Dear notmuch developers,
>>>>
>>>>
>>>> I use notmuch-mode for GNU Emacs for managing my email.
>>>>
>>>> I think I have found a bug in notmuch-mode: If I do â.-vâ on the line
>>>> â[
>>>> 2015 _ Richtlinien.pdf: application/pdf ]â, then notmuch will open three
>>>> windows of zathura (the PDF viewer I use).
>>>>
>>>> It seems to me that someone here either forgot quoting or decided to
>>>> split filenames on spaces. I suggest that â2015 _ Richtlinien.pdf:
>>>> application/pdfâ should be quoted in notmuch-show-view-part.
>>>>
>>>> Note that saving attachment (â.-sâ, notmuch-show-save-part) generally
>>>> works even if the attachment file names have spaces. In case it matters,
>>>> I normally use the rc(1) shell in Debian <http://tobold.org/article/rc>.
>>>
>>> This code handles the saving and displaying in question (quick look hop i
>>> am right :)
>>>
>>>2282 (defun notmuch-show-save-part ()
>>>2283 "Save the MIME part containing point to a file."
>>>2284 (interactive)
>>>2285 (notmuch-show-apply-to-current-part-handle #'mm-save-part))
>>>2286
>>>2287 (defun notmuch-show-view-part ()
>>>2288 "View the MIME part containing point in an external viewer."
>>>2289 (interactive)
>>>2290 ;; Set mm-inlined-types to nil to force an external viewer
>>>2291 (let ((mm-inlined-types nil))
>>>2292 (notmuch-show-apply-to-current-part-handle #'mm-display-part)))
>>>
>>> SO, there is 2 options:
>>>
>>> 1) mm executes save part correctly but not display part
>>
>> It seems I cannot investigate this with my knowledge, as âM-x
>> find-function RET mm-display-partâ gives âCan't find library
>> /usr/share/emacs/23.4/lisp/gnus/mm-decode.elâ. Any ideas?
>>
>>> 2) there is (shell) wrapper program executing zathura which cannot handle
>>>arguments with spaces (there is plenty of examples of this!)
>>>
>>>
>>> You could try to check how th external processes are executed by executing:
>>>
>>> strace -f -e trace=process emacs -f notmuch
>>>
>>> (emacs on X is preferable in this case ;)
>>
>> Thank you for that suggestion. It seems that there does happen both some
>> (wrong) escaping and splitting at spaces. I can see the following trace:
>>
>> --- snib ---
>> execve("/usr/bin/zathura", ["/usr/bin/zathura", "/tmp/emm.23178ut2/2015\\",
>> "_\\", "Richtlinien.pdf"] [/* 51 vars */]) = 0
>> --- snab ---
>>
>> Somewhat unusually, it is preceeded by an invocation of the shell:
>>
>> --- sneb ---
>> execve("/usr/bin/rc", ["/usr/bin/rc", "-c", "/usr/bin/zathura
>> /tmp/emm.23178u"...], [/* 51 vars */]
>
> It would be useful to see the rest of this string ^^. Can you persuade
> strace to show more please?
I have no idea how. Do you?
--
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20150531/d0502569/attachment.sig>
Re: bug report: Emacs notmuch-mode fails attachments with spaces
David Edmondson d...@dme.org writes: On Tue, Feb 10 2015, Nils Dagsson Moskopp wrote: Tomi Ollila tomi.oll...@iki.fi writes: On Mon, Feb 09 2015, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Dear notmuch developers, I use notmuch-mode for GNU Emacs for managing my email. I think I have found a bug in notmuch-mode: If I do “.-v” on the line “[ 2015 _ Richtlinien.pdf: application/pdf ]”, then notmuch will open three windows of zathura (the PDF viewer I use). It seems to me that someone here either forgot quoting or decided to split filenames on spaces. I suggest that “2015 _ Richtlinien.pdf: application/pdf” should be quoted in notmuch-show-view-part. Note that saving attachment (“.-s”, notmuch-show-save-part) generally works even if the attachment file names have spaces. In case it matters, I normally use the rc(1) shell in Debian http://tobold.org/article/rc. This code handles the saving and displaying in question (quick look hop i am right :) 2282 (defun notmuch-show-save-part () 2283 Save the MIME part containing point to a file. 2284 (interactive) 2285 (notmuch-show-apply-to-current-part-handle #'mm-save-part)) 2286 2287 (defun notmuch-show-view-part () 2288 View the MIME part containing point in an external viewer. 2289 (interactive) 2290 ;; Set mm-inlined-types to nil to force an external viewer 2291 (let ((mm-inlined-types nil)) 2292 (notmuch-show-apply-to-current-part-handle #'mm-display-part))) SO, there is 2 options: 1) mm executes save part correctly but not display part It seems I cannot investigate this with my knowledge, as “M-x find-function RET mm-display-part” gives “Can't find library /usr/share/emacs/23.4/lisp/gnus/mm-decode.el”. Any ideas? 2) there is (shell) wrapper program executing zathura which cannot handle arguments with spaces (there is plenty of examples of this!) You could try to check how th external processes are executed by executing: strace -f -e trace=process emacs -f notmuch (emacs on X is preferable in this case ;) Thank you for that suggestion. It seems that there does happen both some (wrong) escaping and splitting at spaces. I can see the following trace: --- snib --- execve(/usr/bin/zathura, [/usr/bin/zathura, /tmp/emm.23178ut2/2015\\, _\\, Richtlinien.pdf] [/* 51 vars */]) = 0 --- snab --- Somewhat unusually, it is preceeded by an invocation of the shell: --- sneb --- execve(/usr/bin/rc, [/usr/bin/rc, -c, /usr/bin/zathura /tmp/emm.23178u...], [/* 51 vars */] unfinished ... It would be useful to see the rest of this string ^^. Can you persuade strace to show more please? I have no idea how. Do you? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgpEd8q6mkhHA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
bug report: Emacs notmuch-mode fails attachments with spaces
David Bremner writes: > Tomi Ollila writes: > >> SO, there is 2 options: >> >> 1) mm executes save part correctly but not display part >> >> 2) there is (shell) wrapper program executing zathura which cannot handle >>arguments with spaces (there is plenty of examples of this!) >> > > For what it's worth, emacs-24.4 / notmuch-0.19+48 / Debian / zsh and > mupdf as a previewer, it ". v" worked ok on the examples I tried with > spaces in the file name of a pdf attachment. It does not work here with Emacs 23.4.1 / notmuch-0.18.2-1 / Debian and Dash. I am installing the emacs24 package now and will report back then. -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net> -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 212 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150210/cc2eb915/attachment.pgp>
bug report: Emacs notmuch-mode fails attachments with spaces
Tomi Ollila writes:
> On Mon, Feb 09 2015, Nils Dagsson Moskopp
> wrote:
>
>> Dear notmuch developers,
>>
>>
>> I use notmuch-mode for GNU Emacs for managing my email.
>>
>> I think I have found a bug in notmuch-mode: If I do ?.-v? on the line ?[
>> 2015 _ Richtlinien.pdf: application/pdf ]?, then notmuch will open three
>> windows of zathura (the PDF viewer I use).
>>
>> It seems to me that someone here either forgot quoting or decided to
>> split filenames on spaces. I suggest that ?2015 _ Richtlinien.pdf:
>> application/pdf? should be quoted in notmuch-show-view-part.
>>
>> Note that saving attachment (?.-s?, notmuch-show-save-part) generally
>> works even if the attachment file names have spaces. In case it matters,
>> I normally use the rc(1) shell in Debian <http://tobold.org/article/rc>.
>
> This code handles the saving and displaying in question (quick look hop i
> am right :)
>
>2282 (defun notmuch-show-save-part ()
>2283 "Save the MIME part containing point to a file."
>2284 (interactive)
>2285 (notmuch-show-apply-to-current-part-handle #'mm-save-part))
>2286
>2287 (defun notmuch-show-view-part ()
>2288 "View the MIME part containing point in an external viewer."
>2289 (interactive)
>2290 ;; Set mm-inlined-types to nil to force an external viewer
>2291 (let ((mm-inlined-types nil))
>2292 (notmuch-show-apply-to-current-part-handle #'mm-display-part)))
>
> SO, there is 2 options:
>
> 1) mm executes save part correctly but not display part
It seems I cannot investigate this with my knowledge, as ?M-x
find-function RET mm-display-part? gives ?Can't find library
/usr/share/emacs/23.4/lisp/gnus/mm-decode.el?. Any ideas?
> 2) there is (shell) wrapper program executing zathura which cannot handle
>arguments with spaces (there is plenty of examples of this!)
>
>
> You could try to check how th external processes are executed by executing:
>
> strace -f -e trace=process emacs -f notmuch
>
> (emacs on X is preferable in this case ;)
Thank you for that suggestion. It seems that there does happen both some
(wrong) escaping and splitting at spaces. I can see the following trace:
--- snib ---
execve("/usr/bin/zathura", ["/usr/bin/zathura", "/tmp/emm.23178ut2/2015\\",
"_\\", "Richtlinien.pdf"] [/* 51 vars */]) = 0
--- snab ---
Somewhat unusually, it is preceeded by an invocation of the shell:
--- sneb ---
execve("/usr/bin/rc", ["/usr/bin/rc", "-c", "/usr/bin/zathura
/tmp/emm.23178u"...], [/* 51 vars */]
--- snob ---
It seems to me that all of the following are true in this case:
1. Emacs executes the user's default shell to start zathura.
2. For this, Emacs escapes the filename.
3. Emacs applies the wrong escaping to the filename. Note that single
quotes are interoperable between shells, while backslashes are not.
4. The rc(1) shell splits on spaces, as it knows no backslash escaping.
5. The shell executes zathura with three arguments, all bogus filenames.
I cannot pinpoint where all this is happening, but I would suggest to
just execve() zathura with a single unescaped filename as its argument.
Greetings,
--
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20150210/c00a321d/attachment.pgp>
Re: bug report: Emacs notmuch-mode fails attachments with spaces
David Bremner da...@tethera.net writes: Tomi Ollila tomi.oll...@iki.fi writes: SO, there is 2 options: 1) mm executes save part correctly but not display part 2) there is (shell) wrapper program executing zathura which cannot handle arguments with spaces (there is plenty of examples of this!) For what it's worth, emacs-24.4 / notmuch-0.19+48 / Debian / zsh and mupdf as a previewer, it . v worked ok on the examples I tried with spaces in the file name of a pdf attachment. It does not work here with Emacs 23.4.1 / notmuch-0.18.2-1 / Debian and Dash. I am installing the emacs24 package now and will report back then. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgpCp8GXm30Ka.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug report: Emacs notmuch-mode fails attachments with spaces
Tomi Ollila tomi.oll...@iki.fi writes: On Mon, Feb 09 2015, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Dear notmuch developers, I use notmuch-mode for GNU Emacs for managing my email. I think I have found a bug in notmuch-mode: If I do “.-v” on the line “[ 2015 _ Richtlinien.pdf: application/pdf ]”, then notmuch will open three windows of zathura (the PDF viewer I use). It seems to me that someone here either forgot quoting or decided to split filenames on spaces. I suggest that “2015 _ Richtlinien.pdf: application/pdf” should be quoted in notmuch-show-view-part. Note that saving attachment (“.-s”, notmuch-show-save-part) generally works even if the attachment file names have spaces. In case it matters, I normally use the rc(1) shell in Debian http://tobold.org/article/rc. This code handles the saving and displaying in question (quick look hop i am right :) 2282 (defun notmuch-show-save-part () 2283 Save the MIME part containing point to a file. 2284 (interactive) 2285 (notmuch-show-apply-to-current-part-handle #'mm-save-part)) 2286 2287 (defun notmuch-show-view-part () 2288 View the MIME part containing point in an external viewer. 2289 (interactive) 2290 ;; Set mm-inlined-types to nil to force an external viewer 2291 (let ((mm-inlined-types nil)) 2292 (notmuch-show-apply-to-current-part-handle #'mm-display-part))) SO, there is 2 options: 1) mm executes save part correctly but not display part It seems I cannot investigate this with my knowledge, as “M-x find-function RET mm-display-part” gives “Can't find library /usr/share/emacs/23.4/lisp/gnus/mm-decode.el”. Any ideas? 2) there is (shell) wrapper program executing zathura which cannot handle arguments with spaces (there is plenty of examples of this!) You could try to check how th external processes are executed by executing: strace -f -e trace=process emacs -f notmuch (emacs on X is preferable in this case ;) Thank you for that suggestion. It seems that there does happen both some (wrong) escaping and splitting at spaces. I can see the following trace: --- snib --- execve(/usr/bin/zathura, [/usr/bin/zathura, /tmp/emm.23178ut2/2015\\, _\\, Richtlinien.pdf] [/* 51 vars */]) = 0 --- snab --- Somewhat unusually, it is preceeded by an invocation of the shell: --- sneb --- execve(/usr/bin/rc, [/usr/bin/rc, -c, /usr/bin/zathura /tmp/emm.23178u...], [/* 51 vars */] unfinished ... --- snob --- It seems to me that all of the following are true in this case: 1. Emacs executes the user's default shell to start zathura. 2. For this, Emacs escapes the filename. 3. Emacs applies the wrong escaping to the filename. Note that single quotes are interoperable between shells, while backslashes are not. 4. The rc(1) shell splits on spaces, as it knows no backslash escaping. 5. The shell executes zathura with three arguments, all bogus filenames. I cannot pinpoint where all this is happening, but I would suggest to just execve() zathura with a single unescaped filename as its argument. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgpAiXLuycWkM.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
bug report: Emacs notmuch-mode fails attachments with spaces
Dear notmuch developers, I use notmuch-mode for GNU Emacs for managing my email. I think I have found a bug in notmuch-mode: If I do ?.-v? on the line ?[ 2015 _ Richtlinien.pdf: application/pdf ]?, then notmuch will open three windows of zathura (the PDF viewer I use). It seems to me that someone here either forgot quoting or decided to split filenames on spaces. I suggest that ?2015 _ Richtlinien.pdf: application/pdf? should be quoted in notmuch-show-view-part. Note that saving attachment (?.-s?, notmuch-show-save-part) generally works even if the attachment file names have spaces. In case it matters, I normally use the rc(1) shell in Debian <http://tobold.org/article/rc>. Greetings, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net> -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 212 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150209/9483621c/attachment.pgp>
bug report: Emacs notmuch-mode fails attachments with spaces
Dear notmuch developers, I use notmuch-mode for GNU Emacs for managing my email. I think I have found a bug in notmuch-mode: If I do “.-v” on the line “[ 2015 _ Richtlinien.pdf: application/pdf ]”, then notmuch will open three windows of zathura (the PDF viewer I use). It seems to me that someone here either forgot quoting or decided to split filenames on spaces. I suggest that “2015 _ Richtlinien.pdf: application/pdf” should be quoted in notmuch-show-view-part. Note that saving attachment (“.-s”, notmuch-show-save-part) generally works even if the attachment file names have spaces. In case it matters, I normally use the rc(1) shell in Debian http://tobold.org/article/rc. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgpXUC3UTPjXL.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-hello buffer slow doe to slow query
Hello, If notmuch-hello includes a saved search with a slow query, switching to a notmuch-hello buffer is very slow due to notmuch-mode updating counts for search results. mjw1009 suggested "(setq notmuch-hello-auto-refresh nil)", which stops the counting and works around the problem. Fundamentally, the problem is a slow query. On my laptop (Thinkpad T60), many things are pretty much instant, even though I have a HDD, no SSD: > ; time notmuch count 'tag:inbox and tag:list' > 25452 > 0.02user 0.00system 0:00.03elapsed 72%CPU (0avgtext+0avgdata 3852maxresident)k > 0inputs+0outputs (0major+1135minor)pagefaults 0swaps However, from-queries take their time: > ; time notmuch count 'not tag:replied and to:nils at dieweltistgarnichtso.net' > 5328 > 0.10user 0.15system 0:14.14elapsed 1%CPU (0avgtext+0avgdata 3472maxresident)k > 157544inputs+0outputs (0major+1039minor)pagefaults 0swaps mjw1009 can reproduce if the from-query contains an "@" and thinks the problem may be "something deeper down in notmuch (actually probably in xapian)". Greetings, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net> -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 212 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140411/1b60ff05/attachment.pgp>
notmuch-hello buffer slow doe to slow query
Hello, If notmuch-hello includes a saved search with a slow query, switching to a notmuch-hello buffer is very slow due to notmuch-mode updating counts for search results. mjw1009 suggested (setq notmuch-hello-auto-refresh nil), which stops the counting and works around the problem. Fundamentally, the problem is a slow query. On my laptop (Thinkpad T60), many things are pretty much instant, even though I have a HDD, no SSD: ; time notmuch count 'tag:inbox and tag:list' 25452 0.02user 0.00system 0:00.03elapsed 72%CPU (0avgtext+0avgdata 3852maxresident)k 0inputs+0outputs (0major+1135minor)pagefaults 0swaps However, from-queries take their time: ; time notmuch count 'not tag:replied and to:n...@dieweltistgarnichtso.net' 5328 0.10user 0.15system 0:14.14elapsed 1%CPU (0avgtext+0avgdata 3472maxresident)k 157544inputs+0outputs (0major+1039minor)pagefaults 0swaps mjw1009 can reproduce if the from-query contains an @ and thinks the problem may be something deeper down in notmuch (actually probably in xapian). Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgpxCpPcJjxH7.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
