Org src-blocks not shown correctly

[Eric S Fraga]

Hi list,
since a few weeks I noticed that when I send Org src-blocks in a post
via gnus, the empty lines between them are lost when I open up my own
post in gnus later (while C-u g shows that the raw message does have
them).

What does the following look like when you receive it from somebody
else?

#+BEGIN_SRC emacs-lisp
(+ 3 3)
#+END_SRC

#+BEGIN_SRC emacs-lisp
(- 2 2)
#+END_SRC

This is a much a question as a test so that I can see what happens in my
case.

[Jorge A. Alfaro-Murillo]

Post by Eric S Fraga
What does the following look like when you receive it from
somebody else?
#+BEGIN_SRC emacs-lisp
(+ 3 3)
#+END_SRC
#+BEGIN_SRC emacs-lisp
(- 2 2)
#+END_SRC

It has a empty line in between for me. Are you using
hard-newlines? Maybe one is missing after SRC.

Best,

[Thorsten Jolitz]

Post by Eric S Fraga

Hi list,
since a few weeks I noticed that when I send Org src-blocks in a post
via gnus, the empty lines between them are lost when I open up my own
post in gnus later (while C-u g shows that the raw message does have
them).

What does the following look like when you receive it from somebody
else?
#+BEGIN_SRC emacs-lisp
(+ 3 3)
#+END_SRC
#+BEGIN_SRC emacs-lisp
(- 2 2)
#+END_SRC
This is a much a question as a test so that I can see what happens in my
case.

I see it like this, without the empty lines, and following up keeps that
state. But C-u g shows the empty lines between the blocks, and following
up from that raw message does quote it correctly too (with empty lines).

[Eric S Fraga]

On Thursday, 21 Aug 2014 at 20:20, Thorsten Jolitz wrote:

[...]

Post by Thorsten Jolitz
I see it like this, without the empty lines, and following up keeps that
state. But C-u g shows the empty lines between the blocks, and following
up from that raw message does quote it correctly too (with empty lines).

Are you doing any /article washing/ perhaps, something that's doing more
than you wish? Maybe one of the gnus-treat- variables, although none
should be doing this as far as I can tell.

My own message looked fine to me, by the way.

[Thorsten Jolitz]

Post by Eric S Fraga
[...]

Post by Thorsten Jolitz
I see it like this, without the empty lines, and following up keeps that
state. But C-u g shows the empty lines between the blocks, and following
up from that raw message does quote it correctly too (with empty lines).

Are you doing any /article washing/ perhaps, something that's doing more
than you wish? Maybe one of the gnus-treat- variables, although none
should be doing this as far as I can tell.

no, actually I did not touch my gnus configuration for quite some time
now, this symptom just appeared out of nowhere, at it seems other people
see it too.

Post by Eric S Fraga
My own message looked fine to me, by the way.

hmm ... I don't even know "who" is rendering/fontifying these blocks in
article mode. I'm not really up-to-date with gnus, but fairly up-to-date
with Org - is Org at all involved here?

[Eric S Fraga]

On Thursday, 21 Aug 2014 at 21:09, Thorsten Jolitz wrote:

[...]

Post by Thorsten Jolitz
hmm ... I don't even know "who" is rendering/fontifying these blocks in
article mode. I'm not really up-to-date with gnus, but fairly up-to-date
with Org - is Org at all involved here?

Good questions. I know that I used to have, a very long time ago now,
my own customisations for viewing org snippets with fontification but
there is no sign of any such customisations in my files any
longer. Gnus itself must be taking care of it. So, from the git log of
gnus:

,----
| commit 3313cd8482c0ac34077ae1ca4721bb6af8b0e0b6
| Author: Lars Ingebrigtsen <***@gnus.org>
| Date: Sat Jan 28 20:33:23 2012 +0100
|
| Make fontification of org modes work again
|
| * mm-view.el (mm-display-inline-fontify): Bind `font-lock-support-mode'
| instead of setting it locally, since the latter doesn't seem to have
| any effect (most of the time).
`----

Maybe have a look at mm-view.el, specifically mm-display-inline-fontify?

In any case, org must be involved somehow as the faces used are those
defined by org...

HTH,
eric

[Eric Abrahamsen]

Post by Eric S Fraga
[...]

Post by Thorsten Jolitz
hmm ... I don't even know "who" is rendering/fontifying these blocks in
article mode. I'm not really up-to-date with gnus, but fairly up-to-date
with Org - is Org at all involved here?

Good questions. I know that I used to have, a very long time ago now,
my own customisations for viewing org snippets with fontification but
there is no sign of any such customisations in my files any
longer. Gnus itself must be taking care of it. So, from the git log of
,----
| commit 3313cd8482c0ac34077ae1ca4721bb6af8b0e0b6
| Date: Sat Jan 28 20:33:23 2012 +0100
|
| Make fontification of org modes work again
|
| * mm-view.el (mm-display-inline-fontify): Bind `font-lock-support-mode'
| instead of setting it locally, since the latter doesn't seem to have
| any effect (most of the time).
`----
Maybe have a look at mm-view.el, specifically mm-display-inline-fontify?
In any case, org must be involved somehow as the faces used are those
defined by org...

Looks like that function was touched in Gnus commit ceed93, late May --
are you guys using Gnus or Emacs from git?

[Thorsten Jolitz]

Post by Eric Abrahamsen

Post by Eric S Fraga
,----
| commit 3313cd8482c0ac34077ae1ca4721bb6af8b0e0b6
| Date: Sat Jan 28 20:33:23 2012 +0100
|
| Make fontification of org modes work again
|
| * mm-view.el (mm-display-inline-fontify): Bind
| font-lock-support-mode'
| instead of setting it locally, since the latter doesn't seem
| to have
| any effect (most of the time).
`----

Looks like that function was touched in Gnus commit ceed93, late May --
are you guys using Gnus or Emacs from git?

No I use the fairly up-to-date Emacs from the Archlinux repo:

#+BEGIN_SRC emacs-lisp
(emacs-version)
#+END_SRC

#+results:
: GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
: of 2014-06-11 on var-lib-archbuild-staging-x86_64-jgc

#+BEGIN_SRC emacs-lisp
(gnus-version)
#+END_SRC

#+results:
: Gnus v5.13

[Eric S Fraga]

On Friday, 22 Aug 2014 at 16:24, Eric Abrahamsen wrote:

[...]

Post by Eric Abrahamsen
Looks like that function was touched in Gnus commit ceed93, late May --
are you guys using Gnus or Emacs from git?

I am using the weekly emacs snapshot (so bleeding edge) and gnus from
git, normally updated every couple of weeks.

[Katsumi Yamaoka]

Post by Eric S Fraga
,----
| commit 3313cd8482c0ac34077ae1ca4721bb6af8b0e0b6
| Date: Sat Jan 28 20:33:23 2012 +0100
|
| Make fontification of org modes work again
|
| * mm-view.el (mm-display-inline-fontify): Bind `font-lock-support-mode'
| instead of setting it locally, since the latter doesn't seem to have
| any effect (most of the time).
`----

I'm not quite sure of the topic in this thread, but I made
a change[1] in 'mm-display-inline-fontify' in question today
since I got an error[2] when I read articles in this thread.
I'm using the very fresh Emacs from the trunk and get a good
fontification on those articles.

[1] <http://article.gmane.org/gmane.emacs.gnus.cvs/12674>
[2]
Debugger entered--Lisp error:
(error "`recenter'ing a window that does not display current-buffer.")
recenter((4))
org-overview()
org-set-startup-visibility()
org-mode()
funcall(org-mode)
[...]
mm-display-inline-fontify((#<buffer *mm-uu*-275065> ("text/x-org") ...
mm-display-org-inline((#<buffer *mm-uu*-275065> ("text/x-org") ...
mm-display-inline((#<buffer *mm-uu*-275065> ("text/x-org") ...
mm-display-part((#<buffer *mm-uu*-275065> ("text/x-org") ...
[...]
gnus-summary-show-article(nil)

[Thorsten Jolitz]

Post by Eric S Fraga
[...]

Post by Thorsten Jolitz
hmm ... I don't even know "who" is rendering/fontifying these blocks in
article mode. I'm not really up-to-date with gnus, but fairly up-to-date
with Org - is Org at all involved here?

Good questions. I know that I used to have, a very long time ago now,
my own customisations for viewing org snippets with fontification but
there is no sign of any such customisations in my files any
longer. Gnus itself must be taking care of it. So, from the git log of
,----
| commit 3313cd8482c0ac34077ae1ca4721bb6af8b0e0b6
| Date: Sat Jan 28 20:33:23 2012 +0100
|
| Make fontification of org modes work again
|
| * mm-view.el (mm-display-inline-fontify): Bind
| font-lock-support-mode'
| instead of setting it locally, since the latter doesn't seem to have
| any effect (most of the time).
`----
Maybe have a look at mm-view.el, specifically mm-display-inline-fontify?

Yes, this is the function doing the job:

,----[ C-h f mm-display-inline-fontify RET ]
| mm-display-inline-fontify is a 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.
`----

It looks alright to me, the only problem is that 'handle, i.e. the
org-element src-block in this case, lacks a trailing linefeed:

,----
| Result: "#+BEGIN_SRC emacs-lisp\n (- 2 2)\n#+END_SRC\n"
`----

now we need only to find out the place where 'handle' is parsed (I could
not find it in mm-view.el in reasonable time) then we would see the
cause of the problem.

If this uses the new parser, this is parsed:

,----[ C-h f org-element-src-block-parser RET ]
| org-element-src-block-parser is a compiled Lisp function in
| `org-element.el'.
| [...]
| Return a list whose CAR is `src-block' and CDR is a plist
| containing `:language', `:switches', `:parameters', `:begin',
| `:end', `:number-lines', `:retain-labels', `:use-labels',
| `:label-fmt', `:preserve-indent', `:value', `:post-blank' and
| `:post-affiliated' keywords.
`----

but the interpreter

,----[ C-h f org-element-src-block-interpreter RET ]
| org-element-src-block-interpreter is a compiled Lisp function in
| `org-element.el'.
|
| (org-element-src-block-interpreter SRC-BLOCK CONTENTS)
|
| Interpret SRC-BLOCK element as Org syntax.
| CONTENTS is nil.
`----

uses only these properties, thus the :post-blank's are lost.

,----
| (:language :switches :parameters :value :preserve-indent)
`----

Otherwise, with old-school regexp-matching, the trailing blank
line isn't part of the match either.