* org-element-at-point fails in programming-modes
@ 2014-08-20 12:00 Thorsten Jolitz
2014-08-20 12:12 ` Thorsten Jolitz
2014-08-20 12:40 ` Nicolas Richard
0 siblings, 2 replies; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-20 12:00 UTC (permalink / raw)
To: emacs-orgmode
Hi List,
with point at the beginning of each of the following blocks,
`org-element-at-point' does recognize the correct type when buffer is in
org-mode and other text-modes, but not so in programming modes, e.g. the
*scratch* buffer (lisp-interaction-mode). Then only the src-block is
recognized correctly, all the others are parsed as paragraphs.
* ORG SCRATCH
#+BEGIN_QUOTE
hallo world
#+END_QUOTE
#+BEGIN_COMMENT
hallo world
#+END_COMMENT
#+BEGIN_EXAMPLE
hallo world
#+END_EXAMPLE
#+BEGIN_SRC emacs-lisp
hallo world
#+END_SRC
Although Org functions are of course made only for working in org-mode
and its a bit hard to see at first sight how this could be useful, I
wonder if the regexps could be made a bit more general to make
`org-element-at-point' work in programming modes too (most likely this
behaviour is caused by references to character-classes that differ in
text-modes and programming-modes)?
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:00 org-element-at-point fails in programming-modes Thorsten Jolitz
@ 2014-08-20 12:12 ` Thorsten Jolitz
2014-08-20 12:17 ` Nick Dokos
` (2 more replies)
2014-08-20 12:40 ` Nicolas Richard
1 sibling, 3 replies; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-20 12:12 UTC (permalink / raw)
To: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
As a side-remark, I did send these blocks with emptly lines between them,
and when I look at my post in gmane the format looks alright, however
when I open it in gnus the empty lines are gone and it looks like this:
> * ORG SCRATCH
>
> #+BEGIN_QUOTE
> hallo world
> #+END_QUOTE
> #+BEGIN_COMMENT
> hallo world
> #+END_COMMENT
> #+BEGIN_EXAMPLE
> hallo world
> #+END_EXAMPLE
> #+BEGIN_SRC emacs-lisp
> hallo world
> #+END_SRC
Am I the only one seeing this? Bug in gnus/message mode?
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-20 12:12 ` Thorsten Jolitz
@ 2014-08-20 12:17 ` Nick Dokos
2014-08-20 12:39 ` Sebastien Vauban
2014-08-20 12:41 ` Nicolas Richard
2014-08-21 20:03 ` Rasmus
2 siblings, 1 reply; 27+ messages in thread
From: Nick Dokos @ 2014-08-20 12:17 UTC (permalink / raw)
To: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
> As a side-remark, I did send these blocks with emptly lines between them,
> and when I look at my post in gmane the format looks alright, however
> when I open it in gnus the empty lines are gone and it looks like this:
>
>> * ORG SCRATCH
>>
>> #+BEGIN_QUOTE
>> hallo world
>> #+END_QUOTE
>> #+BEGIN_COMMENT
>> hallo world
>> #+END_COMMENT
>> #+BEGIN_EXAMPLE
>> hallo world
>> #+END_EXAMPLE
>> #+BEGIN_SRC emacs-lisp
>> hallo world
>> #+END_SRC
>
> Am I the only one seeing this? Bug in gnus/message mode?
I see empty lines between the blocks in gnus.
--
Nick
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:17 ` Nick Dokos
@ 2014-08-20 12:39 ` Sebastien Vauban
2014-08-20 14:28 ` Nick Dokos
0 siblings, 1 reply; 27+ messages in thread
From: Sebastien Vauban @ 2014-08-20 12:39 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Nick Dokos wrote:
> Thorsten Jolitz <tjolitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Thorsten Jolitz <tjolitz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this:
>>
>>> * ORG SCRATCH
>>>
>>> #+BEGIN_QUOTE
>>> hallo world
>>> #+END_QUOTE
>>> #+BEGIN_COMMENT
>>> hallo world
>>> #+END_COMMENT
>>> #+BEGIN_EXAMPLE
>>> hallo world
>>> #+END_EXAMPLE
>>> #+BEGIN_SRC emacs-lisp
>>> hallo world
>>> #+END_SRC
>>
>> Am I the only one seeing this? Bug in gnus/message mode?
>
> I see empty lines between the blocks in gnus.
I don't see the empty lines, like Thorsten.
While, if you look at the raw message (C-u g, in Gnus), I see well that
you had separated the blocks.
If Nick does not see the problem, that must be a bug in our configs?
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:39 ` Sebastien Vauban
@ 2014-08-20 14:28 ` Nick Dokos
2014-08-22 4:02 ` Nick Dokos
0 siblings, 1 reply; 27+ messages in thread
From: Nick Dokos @ 2014-08-20 14:28 UTC (permalink / raw)
To: emacs-orgmode
Sebastien Vauban <sva-news@mygooglest.com>
writes:
> Nick Dokos wrote:
>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>
>>> As a side-remark, I did send these blocks with emptly lines between them,
>>> and when I look at my post in gmane the format looks alright, however
>>> when I open it in gnus the empty lines are gone and it looks like this:
>>>
>>>> * ORG SCRATCH
>>>>
>>>> #+BEGIN_QUOTE
>>>> hallo world
>>>> #+END_QUOTE
>>>> #+BEGIN_COMMENT
>>>> hallo world
>>>> #+END_COMMENT
>>>> #+BEGIN_EXAMPLE
>>>> hallo world
>>>> #+END_EXAMPLE
>>>> #+BEGIN_SRC emacs-lisp
>>>> hallo world
>>>> #+END_SRC
>>>
>>> Am I the only one seeing this? Bug in gnus/message mode?
>>
>> I see empty lines between the blocks in gnus.
>
> I don't see the empty lines, like Thorsten.
>
... and on a different machine, I don't see them either.
Now I have to figure out what's different between them.
Nick
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 14:28 ` Nick Dokos
@ 2014-08-22 4:02 ` Nick Dokos
2014-08-22 5:22 ` Nicolas Richard
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Nick Dokos @ 2014-08-22 4:02 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> Sebastien Vauban <sva-news@mygooglest.com>
> writes:
>
>> Nick Dokos wrote:
>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>
>>>> As a side-remark, I did send these blocks with emptly lines between them,
>>>> and when I look at my post in gmane the format looks alright, however
>>>> when I open it in gnus the empty lines are gone and it looks like this:
>>>>
>>>>> * ORG SCRATCH
>>>>>
>>>>> #+BEGIN_QUOTE
>>>>> hallo world
>>>>> #+END_QUOTE
>>>>> #+BEGIN_COMMENT
>>>>> hallo world
>>>>> #+END_COMMENT
>>>>> #+BEGIN_EXAMPLE
>>>>> hallo world
>>>>> #+END_EXAMPLE
>>>>> #+BEGIN_SRC emacs-lisp
>>>>> hallo world
>>>>> #+END_SRC
>>>>
>>>> Am I the only one seeing this? Bug in gnus/message mode?
>>>
>>> I see empty lines between the blocks in gnus.
>>
>> I don't see the empty lines, like Thorsten.
>>
>
> ... and on a different machine, I don't see them either.
> Now I have to figure out what's different between them.
>
One machine is running Gnus v. 5.13: that one smooshes the code
blocks together.
The other is running Ma Gnus v. 0.12: that one leaves empty
lines between blocks.
--
Nick
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-22 4:02 ` Nick Dokos
@ 2014-08-22 5:22 ` Nicolas Richard
2014-08-22 13:23 ` Nick Dokos
2014-08-22 10:28 ` Thorsten Jolitz
2014-08-22 17:07 ` Rasmus
2 siblings, 1 reply; 27+ messages in thread
From: Nicolas Richard @ 2014-08-22 5:22 UTC (permalink / raw)
To: Nick Dokos; +Cc: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> One machine is running Gnus v. 5.13: that one smooshes the code
> blocks together.
>
> The other is running Ma Gnus v. 0.12: that one leaves empty
> lines between blocks.
Do they both fontify blocks ?
--
Nico.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-22 4:02 ` Nick Dokos
2014-08-22 5:22 ` Nicolas Richard
@ 2014-08-22 10:28 ` Thorsten Jolitz
2014-08-22 13:46 ` Nick Dokos
2014-08-22 13:53 ` Nicolas Richard
2014-08-22 17:07 ` Rasmus
2 siblings, 2 replies; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-22 10:28 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Sebastien Vauban <sva-news@mygooglest.com>
>> writes:
>>
>>> Nick Dokos wrote:
>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>>
>>>>> As a side-remark, I did send these blocks with emptly lines
>>>>> between them,
>>>>> and when I look at my post in gmane the format looks alright, however
>>>>> when I open it in gnus the empty lines are gone and it looks like
>>>>> this:
>>>>>
>>>>>> * ORG SCRATCH
>>>>>>
>>>>>> #+BEGIN_QUOTE
>>>>>> hallo world
>>>>>> #+END_QUOTE
>>>>>> #+BEGIN_COMMENT
>>>>>> hallo world
>>>>>> #+END_COMMENT
>>>>>> #+BEGIN_EXAMPLE
>>>>>> hallo world
>>>>>> #+END_EXAMPLE
>>>>>> #+BEGIN_SRC emacs-lisp
>>>>>> hallo world
>>>>>> #+END_SRC
>>>>>
>>>>> Am I the only one seeing this? Bug in gnus/message mode?
>>>>
>>>> I see empty lines between the blocks in gnus.
>>>
>>> I don't see the empty lines, like Thorsten.
>>>
>>
>> ... and on a different machine, I don't see them either.
>> Now I have to figure out what's different between them.
>>
>
> One machine is running Gnus v. 5.13: that one smooshes the code
> blocks together.
>
> The other is running Ma Gnus v. 0.12: that one leaves empty
> lines between blocks.
Maybe they switched to the new parser between versions, that parses a
src-block with :post-blank's, but does not take them into account when
interpreting?
,----[ C-h f mm-display-inline-fontify RET ]
| mm-display-inline-fontify is a compiled Lisp function in `mm-view.el'.
|
| (mm-display-inline-fontify HANDLE &optional MODE)
|
| Insert HANDLE inline fontifying with MODE.
| If MODE is not set, try to find mode automatically.
`----
is responsable here, and if we would find the place where 'handle' is
parsed (I couldn't in reasonable time) we would probably know what is
the problem ('handle' is the src-block in this case, 'mode' is 'org').
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-22 10:28 ` Thorsten Jolitz
@ 2014-08-22 13:46 ` Nick Dokos
2014-08-22 13:53 ` Nicolas Richard
1 sibling, 0 replies; 27+ messages in thread
From: Nick Dokos @ 2014-08-22 13:46 UTC (permalink / raw)
To: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>> Sebastien Vauban <sva-news@mygooglest.com>
>>> writes:
>>>
>>>> Nick Dokos wrote:
>>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>>>
>>>>>> ...
>>>>>> Am I the only one seeing this? Bug in gnus/message mode?
>>>>>
>>>>> I see empty lines between the blocks in gnus.
>>>>
>>>> I don't see the empty lines, like Thorsten.
>>>>
>>>
>>> ... and on a different machine, I don't see them either.
>>> Now I have to figure out what's different between them.
>>>
>>
>> One machine is running Gnus v. 5.13: that one smooshes the code
>> blocks together.
>>
>> The other is running Ma Gnus v. 0.12: that one leaves empty
>> lines between blocks.
>
> Maybe they switched to the new parser between versions, that parses a
> src-block with :post-blank's, but does not take them into account when
> interpreting?
>
No clue.
> ,----[ C-h f mm-display-inline-fontify RET ]
> | mm-display-inline-fontify is a compiled Lisp function in `mm-view.el'.
> |
> | (mm-display-inline-fontify HANDLE &optional MODE)
> |
> | Insert HANDLE inline fontifying with MODE.
> | If MODE is not set, try to find mode automatically.
> `----
>
> is responsable here, and if we would find the place where 'handle' is
> parsed (I couldn't in reasonable time) we would probably know what is
> the problem ('handle' is the src-block in this case, 'mode' is 'org').
The stack trace on Ma Gnus v. 0.12 (and probably on 5.13 as well) looks like this:
mm-display-inline-fontify((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil) org-mode)
mm-display-org-inline((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil))
mm-display-inline((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil))
mm-display-part((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil) t)
byte-code("..." [ignored type gnus-summary-buffer buffer gnus-inhibit-images handle string-match throw nil buffer-live-p get-buffer "\\`image/" mm-inline-override-p 4 "inline" mm-attachment-override-p mm-automatic-display-p mm-inlinable-p mm-inlined-p mm-automatic-external-display-p t split-string "/" "text" rassq "message" insert-char 10 2 0 1 gnus-unbuttonized-mime-type-p gnus-insert-mime-button (set-buffer gnus-summary-buffer) ((error)) derived-mode-p gnus-article-mode mm-display-part mm-display-inline gnus-article-insert-newline "\n" -1 put-text-property gnus-undeletable gnus-treat-article "application/pgp-signature" not-attachment display text gnus-article-mime-handle-alist ...] 6)
gnus-mime-display-single((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil))
gnus-mime-display-part((#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil))
mapcar(gnus-mime-display-part ((#<buffer *mm-uu*> ("text/plain" (charset . gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 3806 in *Article gmane.emacs.orgmode*> #<marker at 4171 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-161616> ("text/x-org") nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 4172 in *Article gmane.emacs.orgmode*> #<marker at 4210 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-44672> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-414536> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-4102> ("text/plain" (charset . gnu
s-decoded)) nil nil nil nil nil nil)))
gnus-mime-display-mixed(((#<buffer *mm-uu*> ("text/plain" (charset . gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 3806 in *Article gmane.emacs.orgmode*> #<marker at 4171 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-161616> ("text/x-org") nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 4172 in *Article gmane.emacs.orgmode*> #<marker at 4210 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-44672> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-414536> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-4102> ("text/plain" (charset . gnus-deco
ded)) nil nil nil nil nil nil)))
gnus-mime-display-part(("multipart/mixed" (#<buffer *mm-uu*> ("text/plain" (charset . gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 3806 in *Article gmane.emacs.orgmode*> #<marker at 4171 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-161616> ("text/x-org") nil (lambda nil (let ((inhibit-read-only t)) (delete-region #<marker (moves after insertion) at 4172 in *Article gmane.emacs.orgmode*> #<marker at 4210 in *Article gmane.emacs.orgmode*>))) nil nil nil nil) (#<buffer *mm-uu*-975097> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-44672> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-414536> ("text/x-org") nil nil nil nil nil nil) (#<buffer *mm-uu*-4102> ("text/plain" (ch
arset . gnus-decoded)) nil nil nil nil nil nil)))
gnus-display-mime()
gnus-article-prepare-display()
gnus-article-prepare(89997 nil)
gnus-summary-display-article(89997)
gnus-summary-next-page(nil)
funcall-interactively(gnus-summary-next-page nil)
call-interactively(gnus-summary-next-page nil nil)
command-execute(gnus-summary-next-page)
The mm-display-inline-fontify call inserts "#+begin_foo...\n#+end_foo\n"
and (I won't swear to this but I think it's right) somebody on the way
*up* the stack adds an extra newline (maybe gnus-mime-display-single - the
others seem too generic and/or too simple to do it).
--
Nick
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-22 10:28 ` Thorsten Jolitz
2014-08-22 13:46 ` Nick Dokos
@ 2014-08-22 13:53 ` Nicolas Richard
2014-08-22 14:20 ` Nicolas Richard
` (2 more replies)
1 sibling, 3 replies; 27+ messages in thread
From: Nicolas Richard @ 2014-08-22 13:53 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Maybe they switched to the new parser between versions, that parses a
> src-block with :post-blank's, but does not take them into account when
> interpreting?
I tried an experiment : (defun org-mode (&rest _) t) and refresh. The
newlines didn't come back (but fontification obviously disappeared). So
I guess it isn't org-mode's fault.
I would like to blame (mm-uu-dissect) but I didn't look into it. I'll
take the opportunity to test if it'll also eat multiple blank lines (I
think it will) :
#+BEGIN_QUOTE
hallo world
#+END_QUOTE
#+BEGIN_COMMENT
hallo world
#+END_COMMENT
#+BEGIN_EXAMPLE
hallo world
#+END_EXAMPLE
#+BEGIN_SRC emacs-lisp
hallo world
#+END_SRC
(There should be 1, then 2, then 3 blanks lines between the successives
blocks above.)
--
Nico.
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-22 13:53 ` Nicolas Richard
@ 2014-08-22 14:20 ` Nicolas Richard
2014-08-22 14:26 ` Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes) Thorsten Jolitz
2014-08-22 14:46 ` org-element-at-point fails in programming-modes Nick Dokos
2 siblings, 0 replies; 27+ messages in thread
From: Nicolas Richard @ 2014-08-22 14:20 UTC (permalink / raw)
To: Nicolas Richard; +Cc: emacs-orgmode, Thorsten Jolitz
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> I would like to blame (mm-uu-dissect) but I didn't look into it.
I now blame (mm-uu-dissect). The following patch fixes it, but that part
of the code must be there for a reason... and I don't know what it is.
Modified lisp/gnus/mm-uu.el
diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
index 423324a..2200caa 100644
--- a/lisp/gnus/mm-uu.el
+++ b/lisp/gnus/mm-uu.el
@@ -668,10 +668,7 @@ value of `mm-uu-text-plain-type'."
(setq end-point (point)))))
(or (not (setq func (mm-uu-function-2 entry)))
(funcall func)))
- (if (and (> start-point text-start)
- (progn
- (goto-char text-start)
- (re-search-forward "." start-point t)))
+ (if (> start-point text-start)
(push
(mm-make-handle (mm-uu-copy-to-buffer text-start start-point)
mm-uu-text-plain-type)
--
Nico.
^ permalink raw reply related [flat|nested] 27+ messages in thread
* Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes)
2014-08-22 13:53 ` Nicolas Richard
2014-08-22 14:20 ` Nicolas Richard
@ 2014-08-22 14:26 ` Thorsten Jolitz
2014-08-22 14:46 ` org-element-at-point fails in programming-modes Nick Dokos
2 siblings, 0 replies; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-22 14:26 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>> Maybe they switched to the new parser between versions, that parses a
>> src-block with :post-blank's, but does not take them into account when
>> interpreting?
>
> I tried an experiment : (defun org-mode (&rest _) t) and refresh. The
> newlines didn't come back (but fontification obviously disappeared). So
> I guess it isn't org-mode's fault.
>
> I would like to blame (mm-uu-dissect) but I didn't look into it. I'll
> take the opportunity to test if it'll also eat multiple blank lines (I
> think it will) :
>
> #+BEGIN_QUOTE
> hallo world
> #+END_QUOTE
> #+BEGIN_COMMENT
> hallo world
> #+END_COMMENT
> #+BEGIN_EXAMPLE
> hallo world
> #+END_EXAMPLE
> #+BEGIN_SRC emacs-lisp
> hallo world
> #+END_SRC
>
> (There should be 1, then 2, then 3 blanks lines between the successives
> blocks above.)
I don't see any blank lines between the blocks.
This is how a string that is fontified in mm-view.el looks like, no
matter if there are trailing blank lines:
,----
| "#+BEGIN_SRC emacs-lisp\n (- 2 2)\n#+END_SRC\n"
`----
i.e. thats the value of HANDLE in this function:
,----
| (mm-display-inline-fontify HANDLE &optional MODE)
`----
So either they missed the additional final "\n"'s for all but the last
block when parsing, or they forgot to handle them when inserting the
fontified string again.
PS
I renamed this thread because the original topic, which is still more
important for me (!), is not discussed anymore.
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-22 13:53 ` Nicolas Richard
2014-08-22 14:20 ` Nicolas Richard
2014-08-22 14:26 ` Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes) Thorsten Jolitz
@ 2014-08-22 14:46 ` Nick Dokos
2 siblings, 0 replies; 27+ messages in thread
From: Nick Dokos @ 2014-08-22 14:46 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>> Maybe they switched to the new parser between versions, that parses a
>> src-block with :post-blank's, but does not take them into account when
>> interpreting?
>
> I tried an experiment : (defun org-mode (&rest _) t) and refresh. The
> newlines didn't come back (but fontification obviously disappeared). So
> I guess it isn't org-mode's fault.
>
> I would like to blame (mm-uu-dissect) but I didn't look into it. I'll
> take the opportunity to test if it'll also eat multiple blank lines (I
> think it will) :
>
> #+BEGIN_QUOTE
> hallo world
> #+END_QUOTE
>
> #+BEGIN_COMMENT
> hallo world
> #+END_COMMENT
>
> #+BEGIN_EXAMPLE
> hallo world
> #+END_EXAMPLE
>
> #+BEGIN_SRC emacs-lisp
> hallo world
> #+END_SRC
>
> (There should be 1, then 2, then 3 blanks lines between the successives
> blocks above.)
No blank lines in v5.13, a single blank line in Ma Gnus v. 0.12.
--
Nick
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-22 4:02 ` Nick Dokos
2014-08-22 5:22 ` Nicolas Richard
2014-08-22 10:28 ` Thorsten Jolitz
@ 2014-08-22 17:07 ` Rasmus
2 siblings, 0 replies; 27+ messages in thread
From: Rasmus @ 2014-08-22 17:07 UTC (permalink / raw)
To: emacs-orgmode
Nick Dokos <ndokos@gmail.com> writes:
> Nick Dokos <ndokos@gmail.com> writes:
>
>> Sebastien Vauban <sva-news@mygooglest.com>
>> writes:
>>
>>> Nick Dokos wrote:
>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>>
>>>>> As a side-remark, I did send these blocks with emptly lines between them,
>>>>> and when I look at my post in gmane the format looks alright, however
>>>>> when I open it in gnus the empty lines are gone and it looks like this:
>>>>>
>>>>>> * ORG SCRATCH
>>>>>>
>>>>>> #+BEGIN_QUOTE
>>>>>> hallo world
>>>>>> #+END_QUOTE
>>>>>> #+BEGIN_COMMENT
>>>>>> hallo world
>>>>>> #+END_COMMENT
>>>>>> #+BEGIN_EXAMPLE
>>>>>> hallo world
>>>>>> #+END_EXAMPLE
>>>>>> #+BEGIN_SRC emacs-lisp
>>>>>> hallo world
>>>>>> #+END_SRC
>>>>>
>>>>> Am I the only one seeing this? Bug in gnus/message mode?
>>>>
>>>> I see empty lines between the blocks in gnus.
>>>
>>> I don't see the empty lines, like Thorsten.
>>>
>>
>> ... and on a different machine, I don't see them either.
>> Now I have to figure out what's different between them.
>>
>
> One machine is running Gnus v. 5.13: that one smooshes the code
> blocks together.
>
> The other is running Ma Gnus v. 0.12: that one leaves empty
> lines between blocks.
I cannot reproduce on my system.
For Ma I use the git head from today. I tested v5.13 using emacs-bzr
from today (rev. 117722) and rev. 117624 from the beginning of August.
—Rasmus
--
Evidence suggests Snowden used a powerful tool called monospaced fonts
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:12 ` Thorsten Jolitz
2014-08-20 12:17 ` Nick Dokos
@ 2014-08-20 12:41 ` Nicolas Richard
2014-08-21 20:03 ` Rasmus
2 siblings, 0 replies; 27+ messages in thread
From: Nicolas Richard @ 2014-08-20 12:41 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Am I the only one seeing this? Bug in gnus/message mode?
I also see the problem. I suspect that it happens when Gnus fontifies
the blocks. Doing "C-u g" shows that the "source" of the message is
correct (i.e. has the newlines).
--
Nico.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:12 ` Thorsten Jolitz
2014-08-20 12:17 ` Nick Dokos
2014-08-20 12:41 ` Nicolas Richard
@ 2014-08-21 20:03 ` Rasmus
2014-08-21 20:13 ` Rasmus
2014-08-21 20:35 ` Thorsten Jolitz
2 siblings, 2 replies; 27+ messages in thread
From: Rasmus @ 2014-08-21 20:03 UTC (permalink / raw)
To: emacs-orgmode
Hi Thorsten,
Thorsten Jolitz <tjolitz@gmail.com> writes:
> As a side-remark, I did send these blocks with emptly lines between them,
> and when I look at my post in gmane the format looks alright, however
> when I open it in gnus the empty lines are gone and it looks like this:
Do you by any chance have `gnus-article-strip-all-blank-lines' (W E A
from summary) in your `gnus-article-mode-hook' or, more dangerously,
in your `nnmail-prepare-incoming-hook'?
I have had terrible things happen when I applied "washing"
automatically.
(info "(gnus) article washing")
—Rasmus
--
This space is left intentionally blank
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-21 20:03 ` Rasmus
@ 2014-08-21 20:13 ` Rasmus
2014-08-21 20:35 ` Thorsten Jolitz
1 sibling, 0 replies; 27+ messages in thread
From: Rasmus @ 2014-08-21 20:13 UTC (permalink / raw)
To: emacs-orgmode
Rasmus <rasmus@gmx.us> writes:
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this:
>
> Do you by any chance have `gnus-article-strip-all-blank-lines' (W E A
> from summary) in your `gnus-article-mode-hook' or, more dangerously,
> in your `nnmail-prepare-incoming-hook'?
>
> I have had terrible things happen when I applied "washing"
> automatically.
>
> (info "(gnus) article washing")
Actually, washing may even be set via variables cf.
(info "(gnus) customizing articles")
—Rasmus
--
ツ
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-21 20:03 ` Rasmus
2014-08-21 20:13 ` Rasmus
@ 2014-08-21 20:35 ` Thorsten Jolitz
2014-08-21 20:49 ` Rasmus
1 sibling, 1 reply; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-21 20:35 UTC (permalink / raw)
To: emacs-orgmode
Rasmus <rasmus@gmx.us> writes:
Hi Rasmus,
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> As a side-remark, I did send these blocks with emptly lines between them,
>> and when I look at my post in gmane the format looks alright, however
>> when I open it in gnus the empty lines are gone and it looks like this:
>
> Do you by any chance have `gnus-article-strip-all-blank-lines' (W E A
> from summary) in your `gnus-article-mode-hook' or, more dangerously,
> in your `nnmail-prepare-incoming-hook'?
No:
,----[ C-h v gnus-article-mode-hook RET ]
| gnus-article-mode-hook is a variable defined in `gnus-art.el'.
| Its value is nil
`----
,----[ C-h v nnmail-prepare-incoming-hook RET ]
| nnmail-prepare-incoming-hook is a variable defined in `nnmail.el'.
| Its value is nil
`----
and not all blank lines are stripped, only those between consecutive
src-blocks.
> I have had terrible things happen when I applied "washing"
> automatically.
Gnus is a complex beast and I want to just *use* (not debug/fix/hack...)
it, so I don't do any fancy things, I just press 'g' quite often.
It worked flawlessly for a long time, but now I have some minor issues
(HTML washing does not work anymore, empty lines between src-blocks are
eaten), and since yesterday even a major issue: access to my gmail
accounts via gnus denied -> cannot open server (while it works via the
web UI) ;-(
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-21 20:35 ` Thorsten Jolitz
@ 2014-08-21 20:49 ` Rasmus
0 siblings, 0 replies; 27+ messages in thread
From: Rasmus @ 2014-08-21 20:49 UTC (permalink / raw)
To: emacs-orgmode
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Rasmus <rasmus@gmx.us> writes:
>
> Hi Rasmus,
>
>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>
>>> As a side-remark, I did send these blocks with emptly lines between them,
>>> and when I look at my post in gmane the format looks alright, however
>>> when I open it in gnus the empty lines are gone and it looks like this:
>>
>> Do you by any chance have `gnus-article-strip-all-blank-lines' (W E A
>> from summary) in your `gnus-article-mode-hook' or, more dangerously,
>> in your `nnmail-prepare-incoming-hook'?
>
> No:
>
> ,----[ C-h v gnus-article-mode-hook RET ]
> | gnus-article-mode-hook is a variable defined in `gnus-art.el'.
> | Its value is nil
> `----
>
> ,----[ C-h v nnmail-prepare-incoming-hook RET ]
> | nnmail-prepare-incoming-hook is a variable defined in `nnmail.el'.
> | Its value is nil
> `----
>
> and not all blank lines are stripped, only those between consecutive
> src-blocks.
I tried all washing methods, and the one I mentioned was the only way
I could get it to remove lines between SRC blocks. . .
>> I have had terrible things happen when I applied "washing"
>> automatically.
>
> Gnus is a complex beast and I want to just *use* (not debug/fix/hack...)
> it, so I don't do any fancy things, I just press 'g' quite often.
"Hacking" gnus is much fun! My init file suggest that I have around
1000 lines in my email section.
> It worked flawlessly for a long time, but now I have some minor issues
> (HTML washing does not work anymore, empty lines between src-blocks are
> eaten), and since yesterday even a major issue: access to my gmail
> accounts via gnus denied -> cannot open server (while it works via the
> web UI) ;-(
I use offlineimap for this, and have not experienced any problems. I
use a custom password for offlineimap (via OAUTH or something like
that).
On HTML-washing: maybe it switch from whatever to shr (eww-backend)
for rendering?
—Rasmus
--
To err is human. To screw up 10⁶ times per second, you need a computer
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-20 12:00 org-element-at-point fails in programming-modes Thorsten Jolitz
2014-08-20 12:12 ` Thorsten Jolitz
@ 2014-08-20 12:40 ` Nicolas Richard
2014-08-20 13:52 ` Thorsten Jolitz
1 sibling, 1 reply; 27+ messages in thread
From: Nicolas Richard @ 2014-08-20 12:40 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
> Although Org functions are of course made only for working in org-mode
> and its a bit hard to see at first sight how this could be useful, I
> wonder if the regexps could be made a bit more general to make
> `org-element-at-point' work in programming modes too (most likely this
> behaviour is caused by references to character-classes that differ in
> text-modes and programming-modes)?
The reason is that a newline has the "endcomment" syntax in programming
modes, but has "whitespace" syntax in text modes. So the regexp
"\\+BEGIN_\\(\\S-+\\)" (which can be found in org-element.el) matches
e.g. "+BEGIN_QUOTE\nhallo" instead of just "+BEGIN_QUOTE".
("\\S-" means "anything that doesn't have whitespace syntax")
You could wrap your code in a (with-syntax-table org-mode-syntax-table
...) and cross fingers, or simply do the (org-element-at-point)
computations in a temporary (org-mode) buffer.
HTH,
--
Nico.
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-20 12:40 ` Nicolas Richard
@ 2014-08-20 13:52 ` Thorsten Jolitz
2014-08-21 8:58 ` Nicolas Goaziou
0 siblings, 1 reply; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-20 13:52 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
>> Although Org functions are of course made only for working in org-mode
>> and its a bit hard to see at first sight how this could be useful, I
>> wonder if the regexps could be made a bit more general to make
>> `org-element-at-point' work in programming modes too (most likely this
>> behaviour is caused by references to character-classes that differ in
>> text-modes and programming-modes)?
>
> The reason is that a newline has the "endcomment" syntax in programming
> modes, but has "whitespace" syntax in text modes. So the regexp
> "\\+BEGIN_\\(\\S-+\\)" (which can be found in org-element.el) matches
> e.g. "+BEGIN_QUOTE\nhallo" instead of just "+BEGIN_QUOTE".
> ("\\S-" means "anything that doesn't have whitespace syntax")
Yes, thats more or less what I expected to be the root cause of the problem.
> You could wrap your code in a (with-syntax-table org-mode-syntax-table
> ...) and cross fingers, or simply do the (org-element-at-point)
> computations in a temporary (org-mode) buffer.
Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
mandatory, couldn't a more robust construct be used, either something
like this (untested) regexp:
,----
| "[^[:space:]\\n]+"
`----
or a custom character-class that consists of whitespace plus newline?
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-20 13:52 ` Thorsten Jolitz
@ 2014-08-21 8:58 ` Nicolas Goaziou
2014-08-21 11:22 ` Thorsten Jolitz
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Nicolas Goaziou @ 2014-08-21 8:58 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Hello,
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
> mandatory,
No, it isn't.
> couldn't a more robust construct be used, either something
> like this (untested) regexp:
>
> ,----
> | "[^[:space:]\\n]+"
> `----
AFAIK, [:space:] is not compatible with XEmacs. It could be "[^
\r\t\n]+", but even this could be too broad (e.g., "#+BEGIN_..."). We
could also limit block names to alphanumeric characters and a bunch of
symbols.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: org-element-at-point fails in programming-modes
2014-08-21 8:58 ` Nicolas Goaziou
@ 2014-08-21 11:22 ` Thorsten Jolitz
2014-08-22 13:47 ` Bastien
2014-09-23 10:29 ` Thorsten Jolitz
2 siblings, 0 replies; 27+ messages in thread
From: Thorsten Jolitz @ 2014-08-21 11:22 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
>> mandatory,
>
> No, it isn't.
>
>> couldn't a more robust construct be used, either something
>> like this (untested) regexp:
>>
>> ,----
>> | "[^[:space:]\\n]+"
>> `----
>
> AFAIK, [:space:] is not compatible with XEmacs. It could be "[^
> \r\t\n]+", but even this could be too broad (e.g., "#+BEGIN_..."). We
> could also limit block names to alphanumeric characters and a bunch of
> symbols.
I would support that, since the current regexp limits the function's use
unnecessarily to text-modes.
I have no strong argument (real use-case) for making
`org-element-at-point' work with programming-modes too, except the
'principle of least surprise' - I was surprised that my formerly working
`org-dp-wrap-in-block' suddenly did not work anymore when playing around
with it in the *scratch* buffer and spend some time debugging my code,
only to find out that there was no bug but the input from
`org-element-at-point' was not what I expected.
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-21 8:58 ` Nicolas Goaziou
2014-08-21 11:22 ` Thorsten Jolitz
@ 2014-08-22 13:47 ` Bastien
2014-09-23 10:29 ` Thorsten Jolitz
2 siblings, 0 replies; 27+ messages in thread
From: Bastien @ 2014-08-22 13:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Thorsten Jolitz
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> AFAIK, [:space:] is not compatible with XEmacs.
FWIW, I'm less and less sure why we should worry about XEmacs
compatibility. I wish some XEmacs user could step up and take
care of all these XEmacs compatibility issue.
--
Bastien
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-08-21 8:58 ` Nicolas Goaziou
2014-08-21 11:22 ` Thorsten Jolitz
2014-08-22 13:47 ` Bastien
@ 2014-09-23 10:29 ` Thorsten Jolitz
2014-09-23 21:27 ` Nicolas Goaziou
2 siblings, 1 reply; 27+ messages in thread
From: Thorsten Jolitz @ 2014-09-23 10:29 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Ok, thanks, that sounds promising. OTOH, is the use of "\\S-" really
>> mandatory,
>
> No, it isn't.
>
>> couldn't a more robust construct be used, either something
>> like this (untested) regexp:
>>
>> ,----
>> | "[^[:space:]\\n]+"
>> `----
>
> AFAIK, [:space:] is not compatible with XEmacs. It could be "[^
> \r\t\n]+", but even this could be too broad (e.g., "#+BEGIN_..."). We
> could also limit block names to alphanumeric characters and a bunch of
> symbols.
I noticed this issue again when calling `org-element-at-point` with
point before the stars in
,----
| ** [#A] whatsup :mytag:it:
| hello world
`----
in an emacs-lisp-mode buffer - it results in:
,----
| (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245
| :post-blank 1 :post-affiliated 206 ...))
`----
so it kind-of works outside org major-mode, but not correctly due to
character-class problem in the regexp(s).
PS
My org-mode is up to date
#+BEGIN_SRC emacs-lisp
(call-interactively 'org-version)
#+END_SRC
#+results:
: Org-mode version 8.3beta (release_8.3beta-277-g698705 @
/usr/share/emacs/24.3/lisp/org/lisp/)
--
cheers,
Thorsten
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: org-element-at-point fails in programming-modes
2014-09-23 10:29 ` Thorsten Jolitz
@ 2014-09-23 21:27 ` Nicolas Goaziou
0 siblings, 0 replies; 27+ messages in thread
From: Nicolas Goaziou @ 2014-09-23 21:27 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
Hello,
Thorsten Jolitz <tjolitz@gmail.com> writes:
> I noticed this issue again when calling `org-element-at-point` with
> point before the stars in
>
> ,----
> | ** [#A] whatsup :mytag:it:
> | hello world
> `----
>
> in an emacs-lisp-mode buffer - it results in:
>
> ,----
> | (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245
> | :post-blank 1 :post-affiliated 206 ...))
> `----
>
> so it kind-of works outside org major-mode, but not correctly due to
> character-class problem in the regexp(s).
Again, `org-element-at-point' is not meant to be used outside of an Org
buffer. You can improve the situation by changing regexps, but you will
get bitten sooner or later.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2014-09-23 21:27 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-20 12:00 org-element-at-point fails in programming-modes Thorsten Jolitz
2014-08-20 12:12 ` Thorsten Jolitz
2014-08-20 12:17 ` Nick Dokos
2014-08-20 12:39 ` Sebastien Vauban
2014-08-20 14:28 ` Nick Dokos
2014-08-22 4:02 ` Nick Dokos
2014-08-22 5:22 ` Nicolas Richard
2014-08-22 13:23 ` Nick Dokos
2014-08-22 10:28 ` Thorsten Jolitz
2014-08-22 13:46 ` Nick Dokos
2014-08-22 13:53 ` Nicolas Richard
2014-08-22 14:20 ` Nicolas Richard
2014-08-22 14:26 ` Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes) Thorsten Jolitz
2014-08-22 14:46 ` org-element-at-point fails in programming-modes Nick Dokos
2014-08-22 17:07 ` Rasmus
2014-08-20 12:41 ` Nicolas Richard
2014-08-21 20:03 ` Rasmus
2014-08-21 20:13 ` Rasmus
2014-08-21 20:35 ` Thorsten Jolitz
2014-08-21 20:49 ` Rasmus
2014-08-20 12:40 ` Nicolas Richard
2014-08-20 13:52 ` Thorsten Jolitz
2014-08-21 8:58 ` Nicolas Goaziou
2014-08-21 11:22 ` Thorsten Jolitz
2014-08-22 13:47 ` Bastien
2014-09-23 10:29 ` Thorsten Jolitz
2014-09-23 21:27 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).