org-element-at-point fails in programming-modes

org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

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

Re: org-element-at-point fails in programming-modes

[Sebastien Vauban]

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

Re: org-element-at-point fails in programming-modes

[Nicolas Richard]

> 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.

Re: org-element-at-point fails in programming-modes

[Nicolas Richard]

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.

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

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

Re: org-element-at-point fails in programming-modes

[Nicolas Goaziou]

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

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Rasmus]

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

Re: org-element-at-point fails in programming-modes

[Rasmus]

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

-- 
ツ

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Rasmus]

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

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

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

Re: org-element-at-point fails in programming-modes

[Nicolas Richard]

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.

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> 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 ?

Yes.

-- 
Nick

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

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

Re: org-element-at-point fails in programming-modes

[Bastien]

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

Re: org-element-at-point fails in programming-modes

[Nicolas Richard]

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.

Re: org-element-at-point fails in programming-modes

[Nicolas Richard]

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.

Article Mode eats newlines between src-blocks (was Re: org-element-at-point fails in programming-modes)

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Nick Dokos]

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

Re: org-element-at-point fails in programming-modes

[Rasmus]

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

Re: org-element-at-point fails in programming-modes

[Thorsten Jolitz]

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

Re: org-element-at-point fails in programming-modes

[Nicolas Goaziou]

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