Re: [O] org-element discovered inconsistensies

[Nicolas Goaziou]

Hello,

ihor  writes:

> I think you missed Node Properties - they are still located under
> Elements on Syntax page

Node properties are elements, so there is no omission there.

> I have also discovered more:
>
> Syntax page states:
>

[...]

> So Pragraph, Property Drawer, Sections and Headlines are missing from
> this list

I added property drawers, sections and headlines. However, paragraphs
can have affiliated keywords.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-element discovered inconsistensies

[ihor]

Great! Thanks,

I think you missed Node Properties - they are still located under 
Elements on Syntax page


https://orgmode.org/worg/dev/org-syntax.html#Elements

https://orgmode.org/worg/dev/org-syntax.html#Node_Properties

I think it should be moved to Greater Elements section

And it is also listed as Element on API page

https://orgmode.org/worg/dev/org-element-api.htm


I have also discovered more:

Syntax page states:

> With the exception of inlinetasks 
, items 
, 
planning 
, 
clocks 
, 
node properties 
 and table 
rows , every 
other element type can be assigned attributes.


But  this list is not full - if you check the source code 
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L3866


   ;; Item. +
   ;; Table Row. +
   ;; Node Property. +
   ;; Headline.
   ;; Sections (must be checked after headline).
   ;; Planning.+
   ;; Property drawer.
   ;; Paragraph.
   ;; Clock. +
   ;; Inlinetask. +
;; From there, elements can have affiliated keywords.

So Pragraph, Property Drawer, Sections and Headlines are missing from 
this list




On 6/8/19 6:56 PM, Nicolas Goaziou wrote:

Hello,

ihor  writes:


So these are things that I have discovered so far:

[...]

I think I fixed the issues you pointed out. Thank you.

Regards,

Re: [O] org-element discovered inconsistensies

[Nicolas Goaziou]

Hello,

ihor  writes:

> So these are things that I have discovered so far:

[...]

I think I fixed the issues you pointed out. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] org-element discovered inconsistensies

[ihor]

So these are things that I have discovered so far:

    Property Drawer:
   - Element in 
https://orgmode.org/worg/dev/org-element-api.html#orgf47acc7
 It also states that it has :properties field which is simply 
not there in the code

https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L1514
 My assumption in is that Property Drawer contains Node 
Properties directly, as children, instead of :properties filed


   - Greater Element in 
https://orgmode.org/worg/dev/org-syntax.html#Property_Drawers
   - Greater Element in source code 
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L233



 Node Property:
   - Element in 
https://orgmode.org/worg/dev/org-syntax.html#Node_Properties

   - Missing from https://orgmode.org/worg/dev/org-element-api.htm
   - Greater Element in source code 
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L226


 Line Break:
   - Object in https://orgmode.org/worg/dev/org-syntax.html#Line_Breaks
   - Element in https://orgmode.org/worg/dev/org-element-api.htm
   - Object in source code 
https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L239


Secondly, function that collects affiliated keywords 
(|org-element--collect-affiliated-keywords) |


https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L3988

does not take  granularity 
(https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L4076) 
as argument


and parse objects any way:

https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L4029

https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-element.el#L4036

Is there a reason behind this or is this a bug?


On 5/29/19 11:43 PM, Nick Dokos wrote:

Ngor  writes:


Hi Org community.

I am re-posting my questions here according to Nicolas' recommendation.

I am working on a standalone parser implementation for Org which is basically a 
translation of elisp program to Rust
https://github.com/org-rs/org-rs

There are couple of things I wanted to ask about:

1) I have discovered several inconsistencies and errors in the Syntax/API 
documentation
https://orgmode.org/worg/dev/org-element-api.html vs 
https://orgmode.org/worg/dev/org-syntax.html vs elisp source
And I don't know the right way to report them.

2) I think I have found a bug in the algorithm (org-element-collect affiliated 
keywords does not take granularity into accound and seems to be always parsing 
objects in Caption
keyword)

3) I have a question regarding the elisp source source (specifically about the 
:parent of the parsed objects of the keyword)

I can elaborate on each point but I don't want to overwhelm everybody with 
details right from the start. I guess the meta-question is where and how
should I discuss these points? - I never used mailing lists before (If I did 
something incorrectly or do not follow the established rituals/traditions 
please do not judge me harshly.
)


No need for metaquestions: ask away.

You might want to report related problems together, but if the
connection is tenuous or non-existent, then separate posts to the
mailing list will probably work better. Asking your question in a
separate post is probably best, so it doesn't get lost in the forest
of detail when reporting problems.

If you suspect a bug, then use 'M-x org-submit-bug-report`: the bug
report will end up here and will contain a lot of information about
your set-up which might be helpful.

Finally, be patient: do not expect answers (particularly when the
questions are complicated, as it seems yours will be). It takes
a while for people to get around to even reading the posts, let
alone coming up with answers (or, as is likely, more quesions for
you).

And welcome to mailing lists in general and this mailing list in
particular!

Re: [O] Org-element-put-property, bug?

[Nicolas Goaziou]

Hello,

Ivan Tadeu Ferreira Antunes Filho  writes:

> If I put a custom property in a headline, e.g.
> (org-element-put-property headline :EXPORT_FILE_NAME "a")
>
> Then, when accessing the org element headline it shows: :EXPORT_FILE_NAME a
>
> However, when I proceed to interpret the data,
> (org-element-interpret-data headline)
>
> The custom property does not exist in the properties drawer.

Properties in headlines elements are just references to the real
properties. Those are located in node properties elements within
a property drawer element.

> Is there a way of modifying custom properties of a headline by using
> org-element, and have the custom properties show up when interpreting the
> data?

You can modify `property-drawer' and `node-property' elements instead.


Regards,

-- 
Nicolas Goaziou

[O] Org-element-put-property, bug?

[Ivan Tadeu Ferreira Antunes Filho]

If I put a custom property in a headline, e.g.
(org-element-put-property headline :EXPORT_FILE_NAME "a")

Then, when accessing the org element headline it shows: :EXPORT_FILE_NAME a

However, when I proceed to interpret the data,
(org-element-interpret-data headline)

The custom property does not exist in the properties drawer.


Is there a way of modifying custom properties of a headline by using
org-element, and have the custom properties show up when interpreting the
data?


*Ivan Tadeu Ferreira Antunes Filho*

Re: [O] org-element-adopt-elements, append before children

[Nicolas Goaziou]

Hello,

Ivan Tadeu Ferreira Antunes Filho  writes:

> Org element insert before would insert the new element before the selected
> element, not as the first element child (I think)
>
>
> At the moment I'm finding the first child, checking if it is non nil, and
> if it is not nil, dolist insert before the first child, else, adopt the
> elements. Which is a fairly convoluted way

The current way would be: find first child if any; if there is not,
adopt, otherwise, insert before it.

In any case, feel free to provide a patch, along with some tests to
implement what you suggest.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] org-element-adopt-elements, append before children

[Ivan Tadeu Ferreira Antunes Filho]

Org element insert before would insert the new element before the selected
element, not as the first element child (I think)


At the moment I'm finding the first child, checking if it is non nil, and
if it is not nil, dolist insert before the first child, else, adopt the
elements. Which is a fairly convoluted way

On Sun, Sep 2, 2018, 8:27 AM Nicolas Goaziou  wrote:

> Hello,
>
> Ivan Tadeu Ferreira Antunes Filho  writes:
>
> > At the moment  org-element-adopt-elements always appends the new elements
> > after the elements original children.  In many cases one might want to
> > append before the original children.
> >
> > I want to propose adding an argument to org-element-adopt-elements that
> > defines if the elements should be added before or after the children,
> i.e.
> > (if append-before
> >   (nconc children (org-element-contents parent))
> >   (nconc (org-element-contents parent) children))
> >
> > Would this be okay?
>
> You can simply use `org-element-insert-before'.
>
> Regards,
>
> --
> Nicolas Goaziou
> ___
> Ita mailing list
> i...@mit.edu
> http://mailman.mit.edu/mailman/listinfo/ita
>

Re: [O] org-element-adopt-elements, append before children

[Nicolas Goaziou]

Hello,

Ivan Tadeu Ferreira Antunes Filho  writes:

> At the moment  org-element-adopt-elements always appends the new elements
> after the elements original children.  In many cases one might want to
> append before the original children.
>
> I want to propose adding an argument to org-element-adopt-elements that
> defines if the elements should be added before or after the children, i.e.
> (if append-before
>   (nconc children (org-element-contents parent))
>   (nconc (org-element-contents parent) children))
>
> Would this be okay?

You can simply use `org-element-insert-before'.

Regards,

-- 
Nicolas Goaziou

[O] org-element-adopt-elements, append before children

[Ivan Tadeu Ferreira Antunes Filho]

At the moment  org-element-adopt-elements always appends the new elements
after the elements original children.  In many cases one might want to
append before the original children.

I want to propose adding an argument to org-element-adopt-elements that
defines if the elements should be added before or after the children, i.e.
(if append-before
  (nconc children (org-element-contents parent))
  (nconc (org-element-contents parent) children))

Would this be okay?

Re: [O] org-element-at-point and special blocks

[Nicolas Goaziou]

Rasmus  writes:

> Out of curiosity, why is it "more" consistent to return paragraph
> here?

Notwithstanding this case, if `org-element-at-point' returns
`special-block', you /know/ that you are either on block boundaries
(#+begin_special or #+end_special) or on any affiliated keyword above,
but /never/ within the block.

If `org-element-at-point' returns `special-block' here, you create an
exception, which you have to handle later on.

Besides, the truly empty contents are

  #+begin_special
  #+end_special

therefore, I'm not shocked if

  #+begin_special
  
  #+end_special

is a special block with an empty paragraph instead.

Regards,

Re: [O] org-element-at-point and special blocks

[Rasmus]

Hi Nicolas,

Thanks for the helpful reply.

Nicolas Goaziou  writes:

>> Is there a reason why org-element-at-point reports the type to be a
>> paragraph for special blocks?  E.g. in the examples at the bottom of this
>> mail, where | is the cursor, the types are: export-block, src-block and
>> paragraph with a nested special block.
>
> This is a corner-case. `org-element-at-point' returns the closest
> element at point, but prefers to see an empty paragraph than a special
> block, for consistency. I.e., when point is within block boundaries, you
> never return `special-block'.

Out of curiosity, why is it "more" consistent to return paragraph here?

>> Is there a neat way to detect if point is inside a block?  I’m trying to
>> write a function for structures (e.g. #+begin_latex) that works like
>> org-babel-demarcate-block.
>
> (org-element-lineage (org-element-at-point) '(special-block) t)

That's very cool.  Thanks.

Rasmus

-- 
Even a three-legged dog has three good legs to lose

Re: [O] org-element-at-point and special blocks

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Is there a reason why org-element-at-point reports the type to be a
> paragraph for special blocks?  E.g. in the examples at the bottom of this
> mail, where | is the cursor, the types are: export-block, src-block and
> paragraph with a nested special block.

This is a corner-case. `org-element-at-point' returns the closest
element at point, but prefers to see an empty paragraph than a special
block, for consistency. I.e., when point is within block boundaries, you
never return `special-block'.

> Is there a neat way to detect if point is inside a block?  I’m trying to
> write a function for structures (e.g. #+begin_latex) that works like
> org-babel-demarcate-block.

(org-element-lineage (org-element-at-point) '(special-block) t)

Regards,

-- 
Nicolas Goaziou

[O] org-element-at-point and special blocks

[Rasmus]

Hi,

Is there a reason why org-element-at-point reports the type to be a
paragraph for special blocks?  E.g. in the examples at the bottom of this
mail, where | is the cursor, the types are: export-block, src-block and
paragraph with a nested special block.

Is there a neat way to detect if point is inside a block?  I’m trying to
write a function for structures (e.g. #+begin_latex) that works like
org-babel-demarcate-block.

Thanks,
Rasmus

#+BEGIN_LaTeX
|
#+END_LaTeX


#+BEGIN_SRC emacs-lisp
|
#+END_SRC


#+begin_abstract
|
#+end_abstract


-- 
Dung makes an excellent fertilizer

Re: [O] (org-element-context) :end property

[Kyle Meyer]

John Kitchin  writes:

> Neat! Where does one find org-link-edit.el? Is it this one:
> https://github.com/kyleam/org-link-edit?

It is that one, but it's also in contrib.

-- 
Kyle

Re: [O] (org-element-context) :end property

[John Kitchin]

Neat! Where does one find org-link-edit.el? Is it this one:
https://github.com/kyleam/org-link-edit?



Thomas S. Dye writes:

> Aloha all,
>
> Nicolas Goaziou  writes:
>
>> Hello,
>>
>>
>> White spaces following an object are included in the object. They are
>> stored in :post-blank property. You can add them with
>>
>>   (setf (buffer-substring start end)
>> (concat (or desc path)
>> (make-string (org-element-property :post-blank eop) ?\s)))
>
> To wrap this up, the revised unlinkify function (and a hydra with the
> org-link-edit functions) are here:
>
> https://github.com/abo-abo/hydra/wiki/Org-mode-links
>
> All the best,
> Tom

--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: [O] (org-element-context) :end property

[Thomas S . Dye]

Aloha all,

Nicolas Goaziou  writes:

> Hello,
>
>
> White spaces following an object are included in the object. They are
> stored in :post-blank property. You can add them with
>
>   (setf (buffer-substring start end)
> (concat (or desc path) 
> (make-string (org-element-property :post-blank eop) ?\s)))

To wrap this up, the revised unlinkify function (and a hydra with the
org-link-edit functions) are here:

https://github.com/abo-abo/hydra/wiki/Org-mode-links

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] (org-element-context) :end property

[Thomas S . Dye]

Aloha Nicolas,

Nicolas Goaziou  writes:

> White spaces following an object are included in the object. They are
> stored in :post-blank property. You can add them with
>
>   (setf (buffer-substring start end)
> (concat (or desc path) 
> (make-string (org-element-property :post-blank eop) ?\s)))

Perfect.  Thanks!

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] (org-element-context) :end property

[Nicolas Goaziou]

Hello,

Thomas S. Dye  writes:

> I've started to use John Kitchin's unlinkify function, which he posted
> to the list last year.
>
> (defun jk/unlinkify ()
>   "Replace an org-link with the description, or if this absent, the path."
>   (interactive)
>   (let ((eop (org-element-context)))
> (when (eq 'link (car eop))
>   (message "%s" eop)
>   (let* ((start (org-element-property :begin eop))
>  (end (org-element-property :end eop))
>  (contents-begin (org-element-property :contents-begin eop))
>  (contents-end (org-element-property :contents-end eop))
>  (path (org-element-property :path eop))
>  (desc (and contents-begin
> contents-end
> (buffer-substring contents-begin contents-end
> (setf (buffer-substring start end) (or desc path))
>
> However, I get different results depending on whether the link ends with
> a space or a character, e.g.
>
> Foo [[http:www.tsdye.com][desc]] bar.
> Foo [[http:www.tsdye.com][desc]], bar.
>
> Foo descbar.
> Foo desc, bar.
>
> How can I fix this?  I'm guessing that org-element-context sets :end
> differently depending on the character following the link?

White spaces following an object are included in the object. They are
stored in :post-blank property. You can add them with

  (setf (buffer-substring start end)
(concat (or desc path) 
(make-string (org-element-property :post-blank eop) ?\s)))


Regards,

-- 
Nicolas Goaziou

[O] (org-element-context) :end property

[Thomas S . Dye]

Aloha all,

I've started to use John Kitchin's unlinkify function, which he posted
to the list last year.

(defun jk/unlinkify ()
  "Replace an org-link with the description, or if this absent, the path."
  (interactive)
  (let ((eop (org-element-context)))
(when (eq 'link (car eop))
  (message "%s" eop)
  (let* ((start (org-element-property :begin eop))
 (end (org-element-property :end eop))
 (contents-begin (org-element-property :contents-begin eop))
 (contents-end (org-element-property :contents-end eop))
 (path (org-element-property :path eop))
 (desc (and contents-begin
contents-end
(buffer-substring contents-begin contents-end
(setf (buffer-substring start end) (or desc path))

However, I get different results depending on whether the link ends with
a space or a character, e.g.

Foo [[http:www.tsdye.com][desc]] bar.
Foo [[http:www.tsdye.com][desc]], bar.

Foo descbar.
Foo desc, bar.

How can I fix this?  I'm guessing that org-element-context sets :end
differently depending on the character following the link?

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] org-element approach to modify or add ID to every headline

[Samuel W. Flint]

Grant Rettke  writes:

> On Sun, Aug 9, 2015 at 2:44 AM, Nicolas Goaziou  
> wrote:
>> Anyway, the following should do:
>
> That works perfectly. Thank you.
>
> Tempted to run it in a on-save hook just to ensure that the document
> *always* has IDs. At least for tangle comments.
>

You might try setting `org-id-link-to-org-use-id' to either t or
'create-if-interactive.  I believe I have it set to t, and I get ids
generated when I tangle.

HTH,

Sam

-- 
Samuel W. Flint
4096R/266596F4
  (9477 D23E 389E 40C5 2F10  DE19 68E5 318E 2665 96F4)
(λs.s s) λs.s s


signature.asc
Description: PGP signature

Re: [O] org-element approach to modify or add ID to every headline

[Grant Rettke]

On Sun, Aug 9, 2015 at 2:44 AM, Nicolas Goaziou  wrote:
> Anyway, the following should do:

That works perfectly. Thank you.

Tempted to run it in a on-save hook just to ensure that the document
*always* has IDs. At least for tangle comments.

Re: [O] org-element approach to modify or add ID to every headline

[Nicolas Goaziou]

Hello,

Grant Rettke  writes:

> Goal:
>
> 1) Visit every headline
> 2) If there is an ID property
>1) Then replace it's value with a UUID
> 3) If there is not an ID property
>1) Add an ID property and give it a UUID.
>
> `org-uuid' [provides] the functionality to add the ID with a UUID.
>
> [This post] explains how to do it:
>
> ┌
> │ (require 'org-id)
> │(save-excursion
> │   (goto-char (point-max))
> │   (while (outline-previous-heading)
> │ (org-id-get-create)))
> └
>
> What is the best way to do it with `org-element'?

Using `org-element' here would be sub-optimal. Headlines are context
insensitive, i.e., you don't need a parser to find one. 

Anyway, the following should do:

  (dolist (p (nreverse
  (org-element-map (org-element-parse-buffer 'headline) 'headline
(lambda (headline) (org-element-property :begin headline)
(goto-char p)
(org-id-get-create))


Regards,

-- 
Nicolas Goaziou

[O] org-element approach to modify or add ID to every headline

[Grant Rettke]

Good evening,

Emacs 24.4 and Org from Git.

Goal:

1) Visit every headline
2) If there is an ID property
   1) Then replace it's value with a UUID
3) If there is not an ID property
   1) Add an ID property and give it a UUID.

`org-uuid' [provides] the functionality to add the ID with a UUID.

[This post] explains how to do it:

┌
│ (require 'org-id)
│(save-excursion
│   (goto-char (point-max))
│   (while (outline-previous-heading)
│ (org-id-get-create)))
└

What is the best way to do it with `org-element'?


[provides]
http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/org-id.el;hb=HEAD

[This post]
https://stackoverflow.com/questions/13340616/assign-ids-to-every-entry-in-org-mode

Re: [O] [org-element, FR] make secondary-string midnight compatible

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> As is evident from the git log, I have made the following mistake at least
> twice:
>
>(org-element-parse-secondary-string nil restrictions)
>
> I wish this would just return nil instead of an error.  In particular, in
> ox files you have to do
>
>(org-element-parse-secondary-string (or whatever "") restrictions)
>
> Which is a bit noisy.

Done in bcf6970369e0cbf183ab2b2865fa215d0781e7ab.


Regards,

-- 
Nicolas Goaziou

[O] [org-element, FR] make secondary-string midnight compatible

[Rasmus]

Hi,

As is evident from the git log, I have made the following mistake at least
twice:

   (org-element-parse-secondary-string nil restrictions)

I wish this would just return nil instead of an error.  In particular, in
ox files you have to do

   (org-element-parse-secondary-string (or whatever "") restrictions)

Which is a bit noisy.

For me the confusion arise because (org-export-data nil info) does not
throw an error.

Note, I have no idea if the error behavior is needed elsewhere, so it
don't know how feasible this request is or if it's heretic for that
matter.

—Rasmus

-- 
The right to be left alone is a human right

Re: [O] (org-element-property :title ...) not returning a string

[James Harkins]

On March 4, 2015 7:18:11 PM James Harkins  wrote:


I've got:

(defun org-scdoc-headline (headline contents info)
  (unless (org-element-property :footnote-section-p headline)
(let* ((title (org-element-property :title headline))
   (allcaps (upcase title))
... blah blah

It's choking on (upcase...) because 'title' ends up being an element 
object, and *not* the value of the :title property.


Never mind, I needed to wrap the org-element-property call inside 
org-export-data.


That much is working now! Next question... maybe tomorrow.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

[O] (org-element-property :title ...) not returning a string

[James Harkins]

I've got:

(defun org-scdoc-headline (headline contents info)
  "Transcode a HEADLINE element from Org to ASCII.
CONTENTS holds the contents of the headline.  INFO is a plist
holding contextual information."
  ;; Don't export footnote section, which will be handled at the end
  ;; of the template.
  (unless (org-element-property :footnote-section-p headline)
(let* ((title (org-element-property :title headline))
   (allcaps (upcase title))
... blah blah

It's choking on (upcase...) because 'title' ends up being an element object, 
and *not* the value of the :title property.

Why?

http://orgmode.org/worg/dev/org-export-reference.html is not helpful in 
answering this question.

hjh

Re: [O] org-element-at-point keep-trail?

[Nicolas Goaziou]

Jonathan Leech-Pepin  writes:

> Previously, org-element-at-point had an optional keep-trail variable that
> was supposed to show the siblings, parents, aunts/uncles, grandparents, etc.
>
> This feature no longer seems to be present.
>
> What would the process be now to obtain the parents of a given
> element?

  (org-element-property :parent element)
>
> This would be useful for walking back up the tree to obtain a sparse-tree
> structure for archiving (see:
> http://lists.gnu.org/archive/html/emacs-orgmode/2014-10/msg00228.html)

Note that `org-element-at-point' doesn't parse ancestors of headlines.
You need `org-element-parse-buffer' for that.


Regards,

-- 
Nicolas Goaziou

[O] org-element-at-point keep-trail?

[Jonathan Leech-Pepin]

Previously, org-element-at-point had an optional keep-trail variable that
was supposed to show the siblings, parents, aunts/uncles, grandparents, etc.

This feature no longer seems to be present.

What would the process be now to obtain the parents of a given element?

This would be useful for walking back up the tree to obtain a sparse-tree
structure for archiving (see:
http://lists.gnu.org/archive/html/emacs-orgmode/2014-10/msg00228.html)

Regards,
Jonathan

Re: [O] Org-element once again

[Eric Abrahamsen]

Thorsten Jolitz  writes:

> Eric Abrahamsen  writes:
>
>> Marcin Borkowski  writes:
>>
>>> Hi list,
>>>
>>> does there exist any place I could find the specs of the org-element
>>> data structure?  From what I can see, it is a list whose car is the type
>>> of the element, then a (somewhat mysterious or me) plist follows, and
>>> then the children.  Where could I find more info?  If the answer is
>>> "read the source, Luke" ;-) , which functions should I start with?
>>>
>>> Best,
>>
>> Have you looked at this page?
>>
>> http://orgmode.org/worg/dev/org-element-api.html
>>
>> That and the pages linked from it seem to cover most of what's going on.
>>
>> The mysterious plist holds all the properties for a given element. Most
>> are generated by the parsing process (eg :contents-begin and
>> :contents-end, see the link above for all the different properties the
>> various elements/objects might get), while headlines will also have
>> their actual property-drawer properties put into the list.
>>
>> The only thing that remains a little opaque to me is the "section"
>> element, which apparently gets wrapped around a heading's subtree. I
>> don't know what it does, but it's never gotten in my way so I haven't
>> worried about it.
>
> in simple terms, the data structure is just:
>
> ,
> | (element-typ (plist) (section))
> `
>
> i.e. the plist describes the element itself, the section is its
> content. 
>
>
> * TODO Test :@home:
>   DEADLINE: <2014-10-09 Do>
>   :PROPERTIES:
>   :ARCHIVE:  foo
>   :END:
>
>
> org-element-at-point does not parse the contents of an element, it
> thus simply returns
>
> ,
> | (element-typ (plist))
> `
>
> #+NAME: foo
> #+BEGIN_SRC emacs-lisp
>
>  (save-excursion
>  (outline-previous-heading)
>  (org-element-at-point))
> #+END_SRC
>
> # [:results pp]
> #+results:
> : (headline
> :  (:raw-value "Test" :begin 1432 :end 2214 :pre-blank 0 :contents-begin 1452 
> :contents-end 2214 :level 1 :priority nil :tags
> :  ("@home")
> :  :todo-keyword "TODO" :todo-type todo :post-blank 0 
> :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1432 
> :deadline
> :  (timestamp
> : (:type active :raw-value "<2014-10-09 Do>" :year-start 2014
> :month-start 10 :day-start 9 :hour-start nil :minute-start nil
> :year-end 2014 :month-end 10 :day-end 9 :hour-end nil :minute-end nil
> :begin 1464 :end 1479 :post-blank 0))
> :  :ARCHIVE "foo" :title "Test"))
>
> #+NAME: bar
> #+BEGIN_SRC emacs-lisp :var x=foo 
>
>  (org-element-interpret-data x) 
> #+END_SRC
>
> #+results: bar
> : * TODO Test :@home:
>
>
> so this is (just) the element (headline) as specified by its plist.
>
> You can get the contents e.g. with 
>
> #+BEGIN_SRC emacs-lisp :results wrap
> (require 'org-dp-lib)
>  (save-excursion
>  (outline-previous-heading)
>  (org-dp-contents nil t)))
> #+END_SRC
>
> #+results:
> :RESULTS:
> DEADLINE: <2014-10-09 Do>
> :PROPERTIES:
> :ARCHIVE:  foo
> :END:
>
> [...]
> :END:
>
> but the default org-element-parse-buffer parses everything (when specified), 
> the
> contents too, so it would give you 
>
> ,
> | (element-typ (plist) (section))
> `
>
> with section recursively containing other elements with the same
> structure -> a nested list.

Interesting! I didn't realize that all elements came with a section when
you parsed the buffer, thanks for pointing that out.

E

Re: [O] Org-element once again

[Thorsten Jolitz]

Eric Abrahamsen  writes:

> Marcin Borkowski  writes:
>
>> Hi list,
>>
>> does there exist any place I could find the specs of the org-element
>> data structure?  From what I can see, it is a list whose car is the type
>> of the element, then a (somewhat mysterious or me) plist follows, and
>> then the children.  Where could I find more info?  If the answer is
>> "read the source, Luke" ;-) , which functions should I start with?
>>
>> Best,
>
> Have you looked at this page?
>
> http://orgmode.org/worg/dev/org-element-api.html
>
> That and the pages linked from it seem to cover most of what's going on.
>
> The mysterious plist holds all the properties for a given element. Most
> are generated by the parsing process (eg :contents-begin and
> :contents-end, see the link above for all the different properties the
> various elements/objects might get), while headlines will also have
> their actual property-drawer properties put into the list.
>
> The only thing that remains a little opaque to me is the "section"
> element, which apparently gets wrapped around a heading's subtree. I
> don't know what it does, but it's never gotten in my way so I haven't
> worried about it.

in simple terms, the data structure is just:

,
| (element-typ (plist) (section))
`

i.e. the plist describes the element itself, the section is its
content. 


* TODO Test :@home:
  DEADLINE: <2014-10-09 Do>
  :PROPERTIES:
  :ARCHIVE:  foo
  :END:


org-element-at-point does not parse the contents of an element, it
thus simply returns

,
| (element-typ (plist))
`


#+NAME: foo
#+BEGIN_SRC emacs-lisp
 (save-excursion
 (outline-previous-heading)
 (org-element-at-point))
#+END_SRC

# [:results pp]
#+results:
: (headline
:  (:raw-value "Test" :begin 1432 :end 2214 :pre-blank 0 :contents-begin 1452 
:contents-end 2214 :level 1 :priority nil :tags
:("@home")
::todo-keyword "TODO" :todo-type todo :post-blank 0 
:footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1432 
:deadline
:(timestamp
: (:type active :raw-value "<2014-10-09 Do>" :year-start 2014 
:month-start 10 :day-start 9 :hour-start nil :minute-start nil :year-end 2014 
:month-end 10 :day-end 9 :hour-end nil :minute-end nil :begin 1464 :end 1479 
:post-blank 0))
::ARCHIVE "foo" :title "Test"))

#+NAME: bar
#+BEGIN_SRC emacs-lisp :var x=foo 
 (org-element-interpret-data x) 
#+END_SRC

#+results: bar
: * TODO Test :@home:

so this is (just) the element (headline) as specified by its plist.

You can get the contents e.g. with 

#+BEGIN_SRC emacs-lisp :results wrap
(require 'org-dp-lib)
 (save-excursion
 (outline-previous-heading)
 (org-dp-contents nil t)))
#+END_SRC

#+results:
:RESULTS:
DEADLINE: <2014-10-09 Do>
:PROPERTIES:
:ARCHIVE:  foo
:END:

[...]
:END:

but the default org-element-parse-buffer parses everything (when specified), the
contents too, so it would give you 

,
| (element-typ (plist) (section))
`

with section recursively containing other elements with the same
structure -> a nested list.

-- 
cheers,
Thorsten

Re: [O] Org-element once again

[Eric Abrahamsen]

Marcin Borkowski  writes:

> Hi list,
>
> does there exist any place I could find the specs of the org-element
> data structure?  From what I can see, it is a list whose car is the type
> of the element, then a (somewhat mysterious or me) plist follows, and
> then the children.  Where could I find more info?  If the answer is
> "read the source, Luke" ;-) , which functions should I start with?
>
> Best,

Have you looked at this page?

http://orgmode.org/worg/dev/org-element-api.html

That and the pages linked from it seem to cover most of what's going on.

The mysterious plist holds all the properties for a given element. Most
are generated by the parsing process (eg :contents-begin and
:contents-end, see the link above for all the different properties the
various elements/objects might get), while headlines will also have
their actual property-drawer properties put into the list.

The only thing that remains a little opaque to me is the "section"
element, which apparently gets wrapped around a heading's subtree. I
don't know what it does, but it's never gotten in my way so I haven't
worried about it.

Hope that helps,
Eric

[O] Org-element once again

[Marcin Borkowski]

Hi list,

does there exist any place I could find the specs of the org-element
data structure?  From what I can see, it is a list whose car is the type
of the element, then a (somewhat mysterious or me) plist follows, and
then the children.  Where could I find more info?  If the answer is
"read the source, Luke" ;-) , which functions should I start with?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: [O] org-element-at-point fails in programming-modes

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  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

Re: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Hello,
>
> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Rasmus]

Nick Dokos  writes:

> Nick Dokos  writes:
>
>> Sebastien Vauban 
>> writes:
>>
>>> Nick Dokos wrote:
 Thorsten Jolitz  writes:
> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Nicolas Richard  writes:

> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nicolas Richard]

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

Re: [O] org-element-at-point fails in programming-modes

[Nicolas Richard]

Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Bastien]

Nicolas Goaziou  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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Thorsten Jolitz  writes:

> Nick Dokos  writes:
>
>> Nick Dokos  writes:
>>
>>> Sebastien Vauban 
>>> writes:
>>>
 Nick Dokos wrote:
> Thorsten Jolitz  writes:
>> Thorsten Jolitz  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((# ("text/x-org") nil nil 
nil nil nil nil) org-mode)
  mm-display-org-inline((# ("text/x-org") nil nil nil 
nil nil nil))
  mm-display-inline((# ("text/x-org") nil nil nil nil 
nil nil))
  mm-display-part((# ("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((# ("text/x-org") nil nil 
nil nil nil nil))
  gnus-mime-display-part((# ("text/x-org") nil nil nil 
nil nil nil))
  mapcar(gnus-mime-display-part ((# ("text/plain" (charset . 
gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region 
# 
#))) nil nil nil nil) 
(# ("text/x-org") nil (lambda nil (let 
((inhibit-read-only t)) (delete-region # #))) nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# ("text/plain" 
(charset . gnus-decoded)) nil nil nil nil nil nil)))
  gnus-mime-display-mixed(((# ("text/plain" (charset . 
gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) (delete-region 
# 
#))) nil nil nil nil) 
(# ("text/x-org") nil (lambda nil (let 
((inhibit-read-only t)) (delete-region # #))) nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# ("text/plain" 
(charset . gnus-decoded)) nil nil nil nil nil nil)))
  gnus-mime-display-part(("multipart/mixed" (# ("text/plain" 
(charset . gnus-decoded)) nil (lambda nil (let ((inhibit-read-only t)) 
(delete-region # #))) nil 
nil nil nil) (# ("text/x-org") nil (lambda nil (let 
((inhibit-read-only t)) (delete-region # #))) nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# 
("text/x-org") nil nil nil nil nil nil) (# ("text/plain" 
(charset . 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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Nicolas Richard  writes:

> Nick Dokos  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: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Nick Dokos  writes:

> Nick Dokos  writes:
>
>> Sebastien Vauban 
>> writes:
>>
>>> Nick Dokos wrote:
 Thorsten Jolitz  writes:
> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nicolas Richard]

Nick Dokos  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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Nick Dokos  writes:

> Sebastien Vauban 
> writes:
>
>> Nick Dokos wrote:
>>> Thorsten Jolitz  writes:
 Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Rasmus]

Thorsten Jolitz  writes:

> Rasmus  writes:
>
> Hi Rasmus,
>
>> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Rasmus  writes:

Hi Rasmus,

> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Rasmus]

Rasmus  writes:

> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Rasmus]

Hi Thorsten,

Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Hello,
>
> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Sebastien Vauban 
writes:

> Nick Dokos wrote:
>> Thorsten Jolitz  writes:
>>> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Nicolas Richard  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: [O] org-element-at-point fails in programming-modes

[Sebastien Vauban]

Nick Dokos wrote:
> Thorsten Jolitz  writes:
>> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Nicolas Richard]

Thorsten Jolitz  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: [O] 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: [O] org-element-at-point fails in programming-modes

[Nick Dokos]

Thorsten Jolitz  writes:

> Thorsten Jolitz  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: [O] org-element-at-point fails in programming-modes

[Thorsten Jolitz]

Thorsten Jolitz  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

[O] 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: [O] org-element - canonical way to parse only headline at point?

[Thorsten Jolitz]

Nicolas Goaziou  writes:

> Hello,
>
> Thorsten Jolitz  writes:
>
>> with the new parser, how do I parse only the headline at point?  There
>> are ARGS in the parser/mapper functions that restrict parsing, but I
>> suspect that still the whole buffer is parsed for the genealogy - right?
>>
>> With my current knowledge I would either narrow the buffer to the subtree at
>> point or copy this subtree to a temp-buffer before parsing/mapping it,
>> but maybe there is a better way?
>>
>> Would this be a valid template (a simple and fast solution)?
>>
>> #+begin_src emacs-lisp
>>   (save-restriction
>>(org-narrow-to-subtree
>> (org-element-map (org-element-parse-buffer 'headline t) 'headline
>>   (lambda () ...)
>>   nil t t)))
>> #+end_src
>
> What about (org-element-at-point) ?

Thats why I asked - exactly the function I was looking for. Thanks.

-- 
cheers,
Thorsten

Re: [O] org-element - canonical way to parse only headline at point?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz  writes:

> with the new parser, how do I parse only the headline at point?  There
> are ARGS in the parser/mapper functions that restrict parsing, but I
> suspect that still the whole buffer is parsed for the genealogy - right?
>
> With my current knowledge I would either narrow the buffer to the subtree at
> point or copy this subtree to a temp-buffer before parsing/mapping it,
> but maybe there is a better way?
>
> Would this be a valid template (a simple and fast solution)?
>
> #+begin_src emacs-lisp
>   (save-restriction
>(org-narrow-to-subtree
> (org-element-map (org-element-parse-buffer 'headline t) 'headline
>   (lambda () ...)
>   nil t t)))
> #+end_src

What about (org-element-at-point) ?


Regards,

-- 
Nicolas Goaziou

[O] org-element - canonical way to parse only headline at point?

[Thorsten Jolitz]

Hi List,

with the new parser, how do I parse only the headline at point?  There
are ARGS in the parser/mapper functions that restrict parsing, but I
suspect that still the whole buffer is parsed for the genealogy - right?

With my current knowledge I would either narrow the buffer to the subtree at
point or copy this subtree to a temp-buffer before parsing/mapping it,
but maybe there is a better way?

Would this be a valid template (a simple and fast solution)?

#+begin_src emacs-lisp
  (save-restriction
   (org-narrow-to-subtree
(org-element-map (org-element-parse-buffer 'headline t) 'headline
  (lambda () ...)
  nil t t)))
#+end_src

-- 
cheers,
Thorsten

Re: [O] org-element checks make flyspell prohibitively slow

[Matt Lundin]

Hi Nicolas,

Nicolas Goaziou  writes:

> Matt Lundin  writes:
>
>> The rewrite of org-mode-flyspell-verify in commit
>> 4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating
>> org-mode files with large chunks of text very slow.
>
> [...]
>
>> => Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @
>> /home/matt/org-mode/lisp/)
>
> Could you update and try again? Parser's cache was inadvertently
> disabled. I re-enabled it.

Yes, I can confirm that it is faster now. Thanks.

>> core/acl 2.2.52-2 [installed]
>> Access control list utilities, libraries and headers
>> core/archlinux-keyring 20140220-1 [installed]
>> Arch Linux PGP keyring
>> core/attr 2.4.47-1 [installed]
>> Extended attribute support library for ACL support
>> core/autoconf 2.69-1 (base-devel) [installed]
>> A GNU tool for automatically configuring source code
>> core/automake 1.14.1-1 (base-devel) [installed]
>> A GNU tool for automatically creating Makefiles
>>  
>> All in all, it's 12680 lines 
>
> Note that it is a contrived example: the whole buffer is a single
> paragraph containing around 150 objects. The current algorithm for
> `org-element-context' is clearly not on par with such a density of
> objects per paragraph.

Yes, it is indeed a contrived example. I originally thought I had a use
for it --- i.e., analyzing the packages I had installed --- but soon
realized that such a task is better accomplished in a separate text
file.

> Also, cache cannot help here, because each time you edit a paragraph,
> all objects within are removed from the cache (because, AFAIK, there
> is no way to know if the edition altered a previously parsed object or
> not, so, as a security measure, all of them are wiped out) and you
> have to parse them again.
>
> Therefore, navigation should be fast but editing (with flyspell-mode
> enabled) is going to be slow.

Good to know.
Thanks again!

Matt

Re: [O] org-element checks make flyspell prohibitively slow

[Nicolas Goaziou]

Hello,

Matt Lundin  writes:

> The rewrite of org-mode-flyspell-verify in commit
> 4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating
> org-mode files with large chunks of text very slow.

[...]

> => Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @
> /home/matt/org-mode/lisp/)

Could you update and try again? Parser's cache was inadvertently
disabled. I re-enabled it.

> I open a test.org file containing the following.
>
> * A headline * Arch packages * Another headline
>
> After opening a line under "Arch Packages" I call...
>
> C-u M-! pacman -Ss [RET]
>
> (Of course, this only works with archlinux.) This inserts a long list of
> packages that look like this:
>
> core/acl 2.2.52-2 [installed]
> Access control list utilities, libraries and headers
> core/archlinux-keyring 20140220-1 [installed]
> Arch Linux PGP keyring
> core/attr 2.4.47-1 [installed]
> Extended attribute support library for ACL support
> core/autoconf 2.69-1 (base-devel) [installed]
> A GNU tool for automatically configuring source code
> core/automake 1.14.1-1 (base-devel) [installed]
> A GNU tool for automatically creating Makefiles
>  
> All in all, it's 12680 lines 

Note that it is a contrived example: the whole buffer is a single
paragraph containing around 150 objects. The current algorithm for
`org-element-context' is clearly not on par with such a density of
objects per paragraph.

Also, cache cannot help here, because each time you edit a paragraph,
all objects within are removed from the cache (because, AFAIK, there is
no way to know if the edition altered a previously parsed object or not,
so, as a security measure, all of them are wiped out) and you have to
parse them again.

Therefore, navigation should be fast but editing (with flyspell-mode
enabled) is going to be slow.

> But this works (more or less) with other very large chunks of text.
> E.g.,
>
> C-u M-! w3m -dump 
> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html

This one should be reasonably fast in both cases.

> Is it possible to speed up org-element-context here?

Certainly. `org-element-context' is the less optimized part of the
parser code. There is room for improvements.

> For something called as often as org-mode-flyspell-verify, do we need
> all the overhead of the org-element parser?

Of course.

> Or would a hack optimized for speed (which is what the older version
> of org-mode-flyspell-verify represented) be enough?

IMO, the old version of this function was annoying as soon as you
switched to a non-english language. YMMV.

> I recall (though my memory may be faulty) discussions on the list
> quite some time back in which we decided to prioritize
> speed/efficiency over thoroughness/completeness in the checks run by
> org-mode-flyspell-verify.

Why prioritize when we can have both?

I agree that `org-mode-flyspell-verify' is not fast enough at the time
being, but it is quite usable anyway. Also, as a very demanding
function, it is a good benchmark for the parser.

In order to improve the current state, reports (like those in your
message) help a lot. You can also help improving the algorithms.

Thank you.


Regards,

-- 
Nicolas Goaziou

[O] org-element checks make flyspell prohibitively slow

[Matt Lundin]

The rewrite of org-mode-flyspell-verify in commit
4a27c2b4b67201e0b23f431bdaeb6460b31e1394 (Nov 21, 2013) makes navigating
org-mode files with large chunks of text very slow.

For instance, I started up a minimal emacs:

/usr/bin/emacs -Q -l ~/config/minimal.el

...where minimal.el is...



minimal.el
Description: application/emacs-lisp

and (insert "\n\n=> " (emacs-version))

=> GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.7)
 of 2014-01-28 on var-lib-archbuild-extra-x86_64-juergen

and (insert "\n\n=> " (org-version nil t))

=> Org-mode version 8.2.5h (release_8.2.5h-757-gc444e4 @ 
/home/matt/org-mode/lisp/)

I open a test.org file containing the following.

--8<---cut here---start->8---
* A headline
* Arch packages
* Another headline
--8<---cut here---end--->8---

After opening a line under "Arch Packages" I call...

C-u M-! pacman -Ss [RET]

(Of course, this only works with archlinux.) This inserts a long list of
packages that look like this:

--8<---cut here---start->8---
core/acl 2.2.52-2 [installed]
Access control list utilities, libraries and headers
core/archlinux-keyring 20140220-1 [installed]
Arch Linux PGP keyring
core/attr 2.4.47-1 [installed]
Extended attribute support library for ACL support
core/autoconf 2.69-1 (base-devel) [installed]
A GNU tool for automatically configuring source code
core/automake 1.14.1-1 (base-devel) [installed]
A GNU tool for automatically creating Makefiles
--8<---cut here---end--->8---
 
All in all, it's 12680 lines 

I navigate to the bottom of the file. I type... 

M-x elp-instrument-package [RET] org [RET]
M-x elp-instrument-package [RET] flyspell [RET]
M-x elp-instrument-function [RET] scroll-down-command [RET] 

Then I hit M-v three times. This takes a while.

Here are the top elp offenders:

--8<---cut here---start->8---
flyspell-post-command-hook  6   10.753828775  
1.7923047959
flyspell-word   6   10.752069764  
1.7920116273
org-mode-flyspell-verify5   8.973166134   
1.7946332267
org-element-context 5   8.364142505   
1.6728285010
org-element--get-next-object-candidates 699 8.307898326   
0.0118854053
org-element-latex-or-entity-successor   5   3.7592736849  
0.7518547369
org-element-link-successor  40  1.1079495280  
0.0276987382
org-element-sub/superscript-successor   659 1.0986591029  
0.0016671610
org-element-line-break-successor5   0.9729438699  
0.194588774
org-element-at-point5   0.607910786   
0.1215821572
org-element--parse-to   5   0.606992172   
0.1213984344
org-element--current-element10  0.4201667370  
0.0420166737
org-element-paragraph-parser10  0.416739094   
0.0416739094
org-element-inline-src-block-successor  5   0.3740871620  
0.0748174324
org-element-text-markup-successor   10  0.309006309   
0.0309006308
org-element-timestamp-successor 5   0.087275674   
0.0174551348
org-element-statistics-cookie-successor 5   0.086838821   
0.0173677642
org-element-footnote-reference-successor5   0.0866179840  
0.0173235968
org-element-target-successor5   0.086057234   
0.0172114468
org-element-radio-target-successor  5   0.083322691   
0.0166645382
org-element-export-snippet-successor5   0.083078665   
0.016615733
org-element-macro-successor 5   0.0828692849  
0.0165738569
scroll-down-command 3   0.059660938   
0.0198869793
--8<---cut here---end--->8---

Interestingly, after calling elp-results, just trying to navigate to the
org buffer with other-window takes some time. Here's the top of the new
elp list:

--8<---cut here---start->8---
flyspell-post-command-hook  1   1.780324266   
1.780324266
flyspell-word   1   1.780091208   
1.780091208
org-mode-flyspell-verify1   1.779600437   
1.779600437
org-element-context 1   1.6563819400  
1.6563819400
org-element--get-next-object-candidates 137 1.6448783359  
0.0120064112
org-element-latex-or-entity-successor   1   0.753972365   
0.753972365
org-element-link-successor  

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Hi Nicolas,

Nicolas Richard  writes:

> Could you review this ? thanks.

Applied, thanks!

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Please do
>
> ~$ git fetch --tags
>
> to update all your tags, and make again.

That worked. Thank you.

> Tags are on commits, not on "branches", and commmits can belong to
> multiple branches.
>
> Since the tagged commit is both on the maint and the master branch,
> make autoloads will use the same tag to generate Org's version in
> both case.

Ah, right. Oddly, I was pretty sure that some tags were identifying
master branch only, e.g, I can't remember seeing 8.2.5c on master.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Achim Gratz]

Nicolas Goaziou writes:
> That is what I don't understand. You added "8.2.5h" to "maint", and
> master wasn't merged into "maint" since then. How can the tag
> propagate to "master"?

It doesn't.  But maint is included in master as an ancestor and git
describe uses the most recent tag in common ancestry to label a commit
from.  You can add the option --first-parent to only check tags in the
current branch.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [O] org-element cache and LAST_REPEAT

[Michael Brand]

Hi Nicolas

On Wed, Mar 5, 2014 at 8:11 PM, Nicolas Goaziou  wrote:
> This should be fixed. Thanks to both of you for reporting it.

It works, thank you.

Michael

Re: [O] org-element cache and LAST_REPEAT

[Nicolas Goaziou]

Hello,

Michael Brand  writes:

> On Tue, Mar 4, 2014 at 8:58 PM, Matt Lundin  wrote:
>> I suspect this is related the bug I reported earlier today:
>>
>> http://permalink.gmane.org/gmane.emacs.orgmode/82979
>
> I guess the same bug. I have overseen your report.

This should be fixed. Thanks to both of you for reporting it.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Richard]

Bastien  writes:

> Hi Nicolas,
>
> Nicolas Richard  writes:
>
>> OTOH, I find it a bad idea that some arguments are ignored in
>> non-interactive uses, it'd be better to have a function which fully
>> obeys its arguments, and has an interactive spec which sets the
>> argument. If you're interested I can do that.
>
> Of course I'm interested, thanks in advance!

Could you review this ? thanks.

From: Nicolas Richard 
Date: Wed, 5 Mar 2014 17:25:45 +0100
Subject: [PATCH] lisp/org.el (org-version): obey all arguments in
 non-interactive uses.

---
 lisp/org.el | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 5c1b61e..11184cc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -297,12 +297,11 @@ identifier."
 
 ;;;###autoload
 (defun org-version (&optional here full message)
-  "Show the org-mode version in the echo area.
-With prefix argument HERE (this is ignored in non-interactive
-uses), insert it at point.
-When FULL is non-nil, use a verbose version string.
-When MESSAGE is non-nil, display a message with the version."
-  (interactive "P")
+  "Show the org-mode version.
+Interactively, or when MESSAGE is non-nil, show it in echo area.
+With prefix argument, or when HERE is non-nil, insert it at point.
+In non-interactive uses, a reduced version string is output unless FULL is 
given."
+  (interactive (list current-prefix-arg t (not current-prefix-arg)))
   (let* ((org-dir (ignore-errors (org-find-library-dir "org")))
 (save-load-suffixes (when (boundp 'load-suffixes) load-suffixes))
 (load-suffixes (list ".el"))
@@ -322,12 +321,12 @@ When MESSAGE is non-nil, display a message with the 
version."
(concat "mixed installation! " org-install-dir 
" and " org-dir))
"org-loaddefs.el can not be found!")))
 (version1 (if full version org-version)))
-(if (org-called-interactively-p 'interactive)
-   (if here
-   (insert version)
- (message version))
-  (if message (message version1))
-  version1)))
+(when here (insert version1))
+(when message (message "%s" version1))
+version1))
+
+
+
 
 (defconst org-version (org-version))
 
-- 
1.8.3.2

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Hi Nicolas,

Nicolas Richard  writes:

> OTOH, I find it a bad idea that some arguments are ignored in
> non-interactive uses, it'd be better to have a function which fully
> obeys its arguments, and has an interactive spec which sets the
> argument. If you're interested I can do that.

Of course I'm interested, thanks in advance!

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Richard]

Bastien  writes:

> Daimrod  writes:
>
>> Awww that's tricky, M-x org-version doesn't have the same behavior than
>> M-: (org-version)
>
> That's on purpose: (org-version) is what you want to call in a
> program, hence the short version, while M-x org-version RET is what
> you want to call interactively (hence the longer one.)

I tried (org-version t) C-x C-e but it inserted nothing. Looking at the
code, I'd suggest the following patch.

OTOH, I find it a bad idea that some arguments are ignored in
non-interactive uses, it'd be better to have a function which fully
obeys its arguments, and has an interactive spec which sets the
argument. If you're interested I can do that.


From: Nicolas Richard 
Date: Wed, 5 Mar 2014 16:38:58 +0100
Subject: [PATCH] org.el (org-version): mention that HERE is ignored in
 non-interactive uses.

---
 lisp/org.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 64ee668..5c1b61e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -298,7 +298,8 @@ identifier."
 ;;;###autoload
 (defun org-version (&optional here full message)
   "Show the org-mode version in the echo area.
-With prefix argument HERE, insert it at point.
+With prefix argument HERE (this is ignored in non-interactive
+uses), insert it at point.
 When FULL is non-nil, use a verbose version string.
 When MESSAGE is non-nil, display a message with the version."
   (interactive "P")
-- 
1.8.3.2

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Nicolas Goaziou  writes:

> I always do:
>
>   make && org-reload
>
> from Eshell. That doesn't change anything.

Please do

~$ git fetch --tags

to update all your tags, and make again.

>> I always add the release tag on maint, that's where both minor and
>> major releases are made from (expect that I merge master into maint
>> before a major release.)
>
> That is what I don't understand. You added "8.2.5h" to "maint", and
> master wasn't merged into "maint" since then. How can the tag propagate
> to "master"?

Tags are on commits, not on "branches", and commmits can belong to
multiple branches.

Since the tagged commit is both on the maint and the master branch,
make autoloads will use the same tag to generate Org's version in
both case.

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Thorsten Jolitz]

Bastien  writes:

> Daimrod  writes:
>
>> Awww that's tricky, M-x org-version doesn't have the same behavior than
>> M-: (org-version)
>
> That's on purpose: (org-version) is what you want to call in a
> program, hence the short version, while M-x org-version RET is what
> you want to call interactively (hence the longer one.)

Now I understand this annoying behaviour - whenever I wrote a function
for quick insertion of system-info into a mail I only got the short
version but wanted the long one.

So it must be 

#+begin_src emacs-lisp
  (call-interactively 'org-version)
#+end_src

#+results:
: Org-mode version 8.2.5g (release_8.2.5g-564-ge45d13 @
/usr/share/emacs/24.3/lisp/org/lisp/)

instead of 

#+begin_src emacs-lisp
  (org-version)
#+end_src

#+results:
: 8.2.5g

-- 
cheers,
Thorsten

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Bastien  writes:

> Well, make sure you did a ~$ make or ~$ make autoloads so that
> lisp/org-version.el is correct.

I always do:

  make && org-reload

from Eshell. That doesn't change anything.

> I always add the release tag on maint, that's where both minor and
> major releases are made from (expect that I merge master into maint
> before a major release.)

That is what I don't understand. You added "8.2.5h" to "maint", and
master wasn't merged into "maint" since then. How can the tag propagate
to "master"?


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Daimrod  writes:

> Awww that's tricky, M-x org-version doesn't have the same behavior than
> M-: (org-version)

That's on purpose: (org-version) is what you want to call in a
program, hence the short version, while M-x org-version RET is what
you want to call interactively (hence the longer one.)

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Hi Nicolas,

Nicolas Goaziou  writes:

> Good question. I have absolutely no clue. OTOH, my tree looks
> up-to-date, and my .git/config reports:
>
> [remote "origin"]
>   fetch = +refs/heads/*:refs/remotes/origin/*
>   url = orgm...@orgmode.org:org-mode.git
> [branch "master"]
>   remote = origin
>   merge = refs/heads/master
>
> I don't see anything suspicious here.

Well, make sure you did a ~$ make or ~$ make autoloads so that
lisp/org-version.el is correct.

> Also, how comes that master gets a "maint" tag? AFAIU, "release_8.2.5h"
> was put on 53c664c, which belongs to maint.

I always add the release tag on maint, that's where both minor and
major releases are made from (expect that I merge master into maint
before a major release.)

We could have a dedicated tag for the master branch, but for any
move here I'd refer to Achim.

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Daimrod  writes:

> Nicolas Goaziou  writes:
>
>> Daimrod  writes:
>>
>>> I had forgotten to rerun make after I pulled the latest version.
>>> `org-version' now returns "8.2.5h".
>>
>> This is still not right. 8.2.5h refers to "maint" branch, where cache
>> doesn't exist.
>>
>> When I compile the latest release on "master", I get:
>>
>>   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)
>>
>> So, I'm confused. On what branch are you?
>
> I really don't understand. I am on the master branch, the latest commit
> I see is yours (51718d9 Fix last commit).
>
> I'm trying with a fresh clone.

Still the same with a fresh clone.

>> Regards,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Hello,

Bastien  writes:

> Mhh... now *I* am confused.  The latest release on master is
>
>   Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04)
>
> How can it be 8.2.5e for you?

Good question. I have absolutely no clue. OTOH, my tree looks
up-to-date, and my .git/config reports:

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = orgm...@orgmode.org:org-mode.git
[branch "master"]
remote = origin
merge = refs/heads/master

I don't see anything suspicious here.

Also, how comes that master gets a "maint" tag? AFAIU, "release_8.2.5h"
was put on 53c664c, which belongs to maint.


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Bastien  writes:

> Hi Nicolas and Greg,
>
> Nicolas Goaziou  writes:
>
>> Daimrod  writes:
>>
>>> I had forgotten to rerun make after I pulled the latest version.
>>> `org-version' now returns "8.2.5h".
>>
>> This is still not right. 8.2.5h refers to "maint" branch, where cache
>> doesn't exist.
>
> I think Greg did C-h v org-version RET, which returns "8.2.5h" both
> from the maint and the master branch.
>
> Greg: M-x org-version RET gives all the information we need.

Awww that's tricky, M-x org-version doesn't have the same behavior than
M-: (org-version)

M-x org-version returns: Org-mode version 8.2.5h (release_8.2.5h-678-gd8c717 @ 
...)

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou  writes:

> Daimrod  writes:
>
>> I had forgotten to rerun make after I pulled the latest version.
>> `org-version' now returns "8.2.5h".
>
> This is still not right. 8.2.5h refers to "maint" branch, where cache
> doesn't exist.
>
> When I compile the latest release on "master", I get:
>
>   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)
>
> So, I'm confused. On what branch are you?

I really don't understand. I am on the master branch, the latest commit
I see is yours (51718d9 Fix last commit).

I'm trying with a fresh clone.

> Regards,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Jonathan Leech-Pepin]

Hello Nicolas

On 5 March 2014 09:25, Nicolas Goaziou  wrote:

> Daimrod  writes:
>
> > I had forgotten to rerun make after I pulled the latest version.
> > `org-version' now returns "8.2.5h".
>
> This is still not right. 8.2.5h refers to "maint" branch, where cache
> doesn't exist.
>
> When I compile the latest release on "master", I get:
>
>   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)
>
> So, I'm confused. On what branch are you?
>

Output from eshell freshly pulling right now:

,--
| ~/build/org $ git
stat
| git: 'stat' is not a git command. See 'git
--help'.
|

| Did you mean one of
these?
|
status

|
stage

|
stash

| ~/build/org $ git
status
| On branch
master
| Your branch is up-to-date with
'origin/master'.
|

| nothing to commit, working directory
clean
| ~/build/org $ c:/cygwin/bin/make
autoloads
| /usr/bin/make -C lisp
autoloads
| make[1]: Entering directory
'/cygdrive/c/Users/jonpe/build/org/lisp'
| rm -f org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
org-install.elc
| cygwin
warning:

|   MS-DOS style path detected:
c:/Users/jonpe/build/org
|   Preferred POSIX equivalent is:
/cygdrive/c/Users/jonpe/build/org
|   CYGWIN environment variable option "nodosfilewarning" turns off this
warning.
|   Consult the user's guide for more details about POSIX
paths:
| http://cygwin.com/cygwin-ug-net/using.html#using-pathnames

| org-version: 8.2.5h
(release_8.2.5h-678-g51718d)
`--

I initially cloned Org onto this machine 1 week ago.  8.2.5h should be on
master as well according to the above

>
> Regards,
>
> --
> Nicolas Goaziou
>
>
Regards,
Jon

Re: [O] org-element-context doesn't parse consistently link with spaces

[Bastien]

Hi Nicolas and Greg,

Nicolas Goaziou  writes:

> Daimrod  writes:
>
>> I had forgotten to rerun make after I pulled the latest version.
>> `org-version' now returns "8.2.5h".
>
> This is still not right. 8.2.5h refers to "maint" branch, where cache
> doesn't exist.

I think Greg did C-h v org-version RET, which returns "8.2.5h" both
from the maint and the master branch.

Greg: M-x org-version RET gives all the information we need.

> When I compile the latest release on "master", I get:
>
>   Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)
>
> So, I'm confused. On what branch are you?

Mhh... now *I* am confused.  The latest release on master is

  Org-mode version 8.2.5h (release_8.2.5h-676-gfb8a04)

How can it be 8.2.5e for you?

-- 
 Bastien

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Daimrod  writes:

> I had forgotten to rerun make after I pulled the latest version.
> `org-version' now returns "8.2.5h".

This is still not right. 8.2.5h refers to "maint" branch, where cache
doesn't exist.

When I compile the latest release on "master", I get:

  Org-mode version 8.2.5e (release_8.2.5e-231-g51718d)

So, I'm confused. On what branch are you?


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou  writes:

> Hello,
>
> Daimrod  writes:
>
>> I use org-mode version release_8.0.2-101-gce5988 (I follow the git
>> upstream) and I tried it with `org-element-use-cache' set to nil.
>
> There was no `org-element-use-cache' in Org 8.0. Could you update Org
> and try again?

I had forgotten to rerun make after I pulled the latest version.
`org-version' now returns "8.2.5h".

And you're right, it doesn't happen when `org-element-use-cache' is set
to nil.

However, when `org-element-use-cache' is set to t, then it looks like
`org-element-context' uses the link's title instead of the link's value.
e.g.
#+BEGIN_EXAMPLE
  v-- with the cursor here, it returns (link (:type "file" :path "foo" ...))
[[file:foo][file:test 1 2 3]]
   ^-^
when the cursor is in this zone, it returns (link (:type "file" :path 
"test" ...))
  ^-- when the cursor is after this point (after the
  first space) it returns (link (:type "file" :path "test 1 
2 3" ...))
#+END_EXAMPLE

Best,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Hello,

Daimrod  writes:

> I use org-mode version release_8.0.2-101-gce5988 (I follow the git
> upstream) and I tried it with `org-element-use-cache' set to nil.

There was no `org-element-use-cache' in Org 8.0. Could you update Org
and try again?


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Nicolas Goaziou  writes:

> Hello,
>
> Daimrod  writes:
>
>> I think that there is a bug in `org-element-context' because it doesn't
>> seem to parse link with spaces consistently.
>>
>> For example:
>>
>> #+BEGIN_EXAMPLE
>> v
>> [[file:test 1 2 3]]
>> ^
>> #+END_EXAMPLE
>>
>> If the cursor is before the '1', then `org-element-context' will return:
>>
>> #+BEGIN_EXAMPLE
>> (link (:type "file" :path "test" :raw-link "file:test" :application nil 
>> :search-option nil :begin 26 ...))
>> #+END_EXAMPLE
>>
>> if the cursor is one or after the '1', then `org-element-context' will 
>> return:
>>
>> #+BEGIN_EXAMPLE
>> (link (:type "file" :path "test%201%202%203" :raw-link 
>> "file:test%201%202%203" :application nil :search-option nil :begin 1 ...))
>> #+END_EXAMPLE
>
> I cannot reproduce it. What Org version do you use? Did you try to
> disable `org-element-use-cache'?

Sorry, it happens with:
#+BEGIN_EXAMPLE
[[file:test%201%202%203][file:test 1 2 3]]
#+END_EXAMPLE

I use org-mode version release_8.0.2-101-gce5988 (I follow the git
upstream) and I tried it with `org-element-use-cache' set to nil.


It doesn't happen with:
#+BEGIN_EXAMPLE
[[file:test 1 2 3]]
#+END_EXAMPLE
but as soon as the cursor leaves the link, org-mode rewrite the link to:
#+BEGIN_EXAMPLE
[[file:test%201%202%203][file:test 1 2 3]]
#+END_EXAMPLE


Best,

-- 
Daimrod/Greg

Re: [O] org-element-context doesn't parse consistently link with spaces

[Nicolas Goaziou]

Hello,

Daimrod  writes:

> I think that there is a bug in `org-element-context' because it doesn't
> seem to parse link with spaces consistently.
>
> For example:
>
> #+BEGIN_EXAMPLE
> v
> [[file:test 1 2 3]]
> ^
> #+END_EXAMPLE
>
> If the cursor is before the '1', then `org-element-context' will return:
>
> #+BEGIN_EXAMPLE
> (link (:type "file" :path "test" :raw-link "file:test" :application nil 
> :search-option nil :begin 26 ...))
> #+END_EXAMPLE
>
> if the cursor is one or after the '1', then `org-element-context' will return:
>
> #+BEGIN_EXAMPLE
> (link (:type "file" :path "test%201%202%203" :raw-link 
> "file:test%201%202%203" :application nil :search-option nil :begin 1 ...))
> #+END_EXAMPLE

I cannot reproduce it. What Org version do you use? Did you try to
disable `org-element-use-cache'?


Regards,

-- 
Nicolas Goaziou

Re: [O] org-element cache and LAST_REPEAT

[Michael Brand]

Hi Matt

On Tue, Mar 4, 2014 at 8:58 PM, Matt Lundin  wrote:
> I suspect this is related the bug I reported earlier today:
>
> http://permalink.gmane.org/gmane.emacs.orgmode/82979

I guess the same bug. I have overseen your report.

Michael

Re: [O] org-element cache and LAST_REPEAT

[Matt Lundin]

Michael Brand  writes:

> Hi Nicolas
>
> With today's release_8.2.5h-676-gfb8a042 and C-c C-t on the todo
> below, the last headline gets corrupted. Only when cache is enabled.

Hi Michael and Nicolas,

I suspect this is related the bug I reported earlier today:

http://permalink.gmane.org/gmane.emacs.orgmode/82979

I had not realized it had to do with org-element-cache. I can confirm
that setting org-element-cache to nil solves the problem.

Matt

>
> --
> * bla
> :PROPERTIES:
> :bla:  bla
> :END:
> * TODO bla
> SCHEDULED: <2014-03-04 Tue +1d>
> :PROPERTIES:
> :LAST_REPEAT: [2014-03-04 Tue 12:00]
> :LOGGING:  logrepeat
> :END:
> * bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
> --
>
> Michael

[O] org-element cache and LAST_REPEAT

[Michael Brand]

Hi Nicolas

With today's release_8.2.5h-676-gfb8a042 and C-c C-t on the todo
below, the last headline gets corrupted. Only when cache is enabled.

--
* bla
:PROPERTIES:
:bla:  bla
:END:
* TODO bla
SCHEDULED: <2014-03-04 Tue +1d>
:PROPERTIES:
:LAST_REPEAT: [2014-03-04 Tue 12:00]
:LOGGING:  logrepeat
:END:
* bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla bla
--

Michael

[O] org-element-context doesn't parse consistently link with spaces

[Daimrod]

Hello,

I think that there is a bug in `org-element-context' because it doesn't
seem to parse link with spaces consistently.

For example:
#+BEGIN_EXAMPLE
v
[[file:test 1 2 3]]
^
#+END_EXAMPLE
If the cursor is before the '1', then `org-element-context' will return:
#+BEGIN_EXAMPLE
(link (:type "file" :path "test" :raw-link "file:test" :application nil 
:search-option nil :begin 26 ...))
#+END_EXAMPLE
if the cursor is one or after the '1', then `org-element-context' will return:
#+BEGIN_EXAMPLE
(link (:type "file" :path "test%201%202%203" :raw-link "file:test%201%202%203" 
:application nil :search-option nil :begin 1 ...))
#+END_EXAMPLE

Best,

-- 
Daimrod/Greg


signature.asc
Description: PGP signature

Re: [O] org-element-map no-recursion argument?

[Nicolas Goaziou]

Hello,

James Harkins  writes:

> I've written some emacs-lisp using org-element-map to iterate over
> source code blocks in an org buffer and insert them into another
> buffer, including a listing number and caption (so it's different from
> tangling).
>
> I was just trying to tweak it to ignore source code blocks in
> a comment section.
>
> More specifically -- I had moved some material into a "Removed"
> subtree (with a tag "noexport"). This subtree contains some source
> blocks, but I want my function to ignore these.
>
> I thought I could wrap the entire "Removed" section in
> #+begin/end_comment, and then tell org-element-map to skip comment
> blocks for recursion.
>
> (org-element-map tree 'src-block (lambda (element) ...)
>  nil nil 'comment)
>
> But this has no effect. I guess the src-block filter erases the
> distinction between "live" and commented sections.
>
> I can work around it by commenting out the captions, but it would be
> nicer to have an entire "off-limits" section of the document.

This is a reasonable request, indeed.

One (backward compatible) solution could be to extend possible values
for NO-RECURSION argument, and allow functions on one argument (the
current element) in addition to symbols.

When the NO-RECURSION function returns a non-nil value for a given
element, the main function from `org-element-map' is applied to the
element, but not to its contents.


What do you think?


Regards,

-- 
Nicolas Goaziou

[O] org-element-map no-recursion argument?

[James Harkins]

I've written some emacs-lisp using org-element-map to iterate over source 
code blocks in an org buffer and insert them into another buffer, including 
a listing number and caption (so it's different from tangling).


I was just trying to tweak it to ignore source code blocks in a comment 
section.


More specifically -- I had moved some material into a "Removed" subtree 
(with a tag "noexport"). This subtree contains some source blocks, but I 
want my function to ignore these.


I thought I could wrap the entire "Removed" section in #+begin/end_comment, 
and then tell org-element-map to skip comment blocks for recursion.


(org-element-map tree 'src-block (lambda (element) ...)
 nil nil 'comment)

But this has no effect. I guess the src-block filter erases the distinction 
between "live" and commented sections.


I can work around it by commenting out the captions, but it would be nicer 
to have an entire "off-limits" section of the document.


hjh

Re: [O] org-element, spurious command??

[Nicolas Goaziou]

Hello,

Robert Klein  writes:

> I've been reading lisp/org-element.el, when I found a command lounging
> around in the middle of the file outside of any defun:
>
> (put 'org-element-map 'lisp-indent-function 2)
>
> on line 4275 (maint tree this morning).
>
> Is this intended to be there?

Yes, it is. `org-element-map' is defined just above. This sexp sets
indentations rules for it.


Regards,

-- 
Nicolas Goaziou

[O] org-element, spurious command??

[Robert Klein]

Hi,

I've been reading lisp/org-element.el, when I found a command lounging
around in the middle of the file outside of any defun:

(put 'org-element-map 'lisp-indent-function 2)

on line 4275 (maint tree this morning).

Is this intended to be there?


PS: it is also in the master tree, line 4276.

Thanks and best regards
Robert

Re: [O] org-element-property syntax (turning strings into keyword symbols)

[Matt Price]

On Sat, Nov 9, 2013 at 2:48 AM, Nicolas Goaziou  wrote:
> Hello,
>
> Matt Price  writes:
>
>> This works fine.  Now when I come back to this buffer I want to check
>> whether any of the properties are actually there.  So I am trying
>> something like this:
>>
>> (let ((hasprops nil))
>>   (dolist prop org-writers-room-properties
>>   (if (org-element-property (car prop) (org-element-at-point))
>>(setq hasprops t))
>>   (if (hasprops)
>>   (etc.))
>>
>> However this doesn't work because (1) the car of "prop" (which is in
>> fact the property name) is not necessarily capitalized and
>
> Then `upcase' the property name first. I assume you will only refer to
> user-defined properties so their equivalent keyword will always be in
> upper cases.
>
>> (2) the "property" parameter of org-element-property is not a string,
>> but a "keyword symbol". Somehow I have to turn my string into the
>> appropriate keyword symbol. Does anyone know how to do this?
>
> Use `intern'.
>
> For efficiency reasons, I also suggest to store `org-element-at-point'
> in a variable instead of computing it again each time you are looking
> for a property:
>
>   (let ((hashprops nil)
> (element (org-element-at-point)))
> (dolist (prop org-writers-room-properties)
>   (if (org-element-property (intern (concat ":" (upcase prop))) element)
>   ...)))
>
ah, thank you so much for this. I don't know how I would ever have
found intern on my own.  makes my life much easier!

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] org-element-property syntax (turning strings into keyword symbols)

[Nicolas Goaziou]

Hello,

Matt Price  writes:

> This works fine.  Now when I come back to this buffer I want to check
> whether any of the properties are actually there.  So I am trying
> something like this:
>
> (let ((hasprops nil))
>   (dolist prop org-writers-room-properties
>   (if (org-element-property (car prop) (org-element-at-point))
>(setq hasprops t))
>   (if (hasprops)
>   (etc.))
>
> However this doesn't work because (1) the car of "prop" (which is in
> fact the property name) is not necessarily capitalized and

Then `upcase' the property name first. I assume you will only refer to
user-defined properties so their equivalent keyword will always be in
upper cases.

> (2) the "property" parameter of org-element-property is not a string,
> but a "keyword symbol". Somehow I have to turn my string into the
> appropriate keyword symbol. Does anyone know how to do this?

Use `intern'.

For efficiency reasons, I also suggest to store `org-element-at-point'
in a variable instead of computing it again each time you are looking
for a property:

  (let ((hashprops nil)
(element (org-element-at-point)))
(dolist (prop org-writers-room-properties)
  (if (org-element-property (intern (concat ":" (upcase prop))) element)
  ...)))


Regards,

-- 
Nicolas Goaziou