Re: [O] org-element discovered inconsistensies

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

Re: [O] org-element discovered inconsistensies

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

Re: [O] org-element discovered inconsistensies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Grant Rettke g...@wisdomandwonder.com writes: On Sun, Aug 9, 2015 at 2:44 AM, Nicolas Goaziou m...@nicolasgoaziou.fr 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

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

Hello, Grant Rettke g...@wisdomandwonder.com 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

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

On Sun, Aug 9, 2015 at 2:44 AM, Nicolas Goaziou m...@nicolasgoaziou.fr 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.

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

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.

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

Hello, Rasmus ras...@gmx.us 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

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

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 )

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

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.

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

On March 4, 2015 7:18:11 PM James Harkins jamshar...@qq.com 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)) ...

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

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

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

Jonathan Leech-Pepin jonathan.leechpe...@gmail.com 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

Re: [O] Org-element once again

Eric Abrahamsen e...@ericabrahamsen.net writes: Marcin Borkowski mb...@wmi.amu.edu.pl 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

Re: [O] Org-element once again

Thorsten Jolitz tjol...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Marcin Borkowski mb...@wmi.amu.edu.pl 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

[O] Org-element once again

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

Re: [O] Org-element once again

Marcin Borkowski mb...@wmi.amu.edu.pl 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.

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

Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: Ok, thanks, that sounds promising. OTOH, is the use of \\S- really mandatory, No, it isn't. couldn't a more robust construct be used, either something like this (untested) regexp: , |

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

Hello, Thorsten Jolitz tjol...@gmail.com writes: I noticed this issue again when calling `org-element-at-point` with point before the stars in , | ** [#A] whatsup :mytag:it: | hello world ` in an emacs-lisp-mode buffer - it results in: , | (paragraph (:begin 193 :end 246

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

Nick Dokos ndo...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines

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

Nicolas Richard theonewiththeevill...@yahoo.fr writes: Nick Dokos ndo...@gmail.com writes: One machine is running Gnus v. 5.13: that one smooshes the code blocks together. The other is running Ma Gnus v. 0.12: that one leaves empty lines between blocks. Do they both fontify blocks ? Yes.

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

Thorsten Jolitz tjol...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: ... Am I the only

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

Nicolas Goaziou m...@nicolasgoaziou.fr writes: AFAIK, [:space:] is not compatible with XEmacs. FWIW, I'm less and less sure why we should worry about XEmacs compatibility. I wish some XEmacs user could step up and take care of all these XEmacs compatibility issue. -- Bastien

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

Thorsten Jolitz tjol...@gmail.com writes: Maybe they switched to the new parser between versions, that parses a src-block with :post-blank's, but does not take them into account when interpreting? I tried an experiment : (defun org-mode (rest _) t) and refresh. The newlines didn't come back

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

Nicolas Richard theonewiththeevill...@yahoo.fr writes: I would like to blame (mm-uu-dissect) but I didn't look into it. I now blame (mm-uu-dissect). The following patch fixes it, but that part of the code must be there for a reason... and I don't know what it is. Modified

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

Nicolas Richard theonewiththeevill...@yahoo.fr writes: Thorsten Jolitz tjol...@gmail.com writes: Maybe they switched to the new parser between versions, that parses a src-block with :post-blank's, but does not take them into account when interpreting? I tried an experiment : (defun

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

Nick Dokos ndo...@gmail.com writes: Nick Dokos ndo...@gmail.com writes: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines

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

Hello, Thorsten Jolitz tjol...@gmail.com writes: Ok, thanks, that sounds promising. OTOH, is the use of \\S- really mandatory, No, it isn't. couldn't a more robust construct be used, either something like this (untested) regexp: , | [^[:space:]\\n]+ ` AFAIK, [:space:] is not

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

Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: Ok, thanks, that sounds promising. OTOH, is the use of \\S- really mandatory, No, it isn't. couldn't a more robust construct be used, either something like this (untested) regexp: , |

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

Hi Thorsten, Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks like this: Do you by any chance

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

Rasmus ras...@gmx.us writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks like this: Do

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

Rasmus ras...@gmx.us writes: Hi Rasmus, Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks like

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

Thorsten Jolitz tjol...@gmail.com writes: Rasmus ras...@gmx.us writes: Hi Rasmus, Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in

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

Nick Dokos ndo...@gmail.com writes: Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post

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

Nick Dokos ndo...@gmail.com writes: One machine is running Gnus v. 5.13: that one smooshes the code blocks together. The other is running Ma Gnus v. 0.12: that one leaves empty lines between blocks. Do they both fontify blocks ? -- Nico.

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

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

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

Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks like this: * ORG SCRATCH #+BEGIN_QUOTE hallo

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

Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are gone and it looks

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

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

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

Thorsten Jolitz tjol...@gmail.com writes: Am I the only one seeing this? Bug in gnus/message mode? I also see the problem. I suspect that it happens when Gnus fontifies the blocks. Doing C-u g shows that the source of the message is correct (i.e. has the newlines). -- Nico.

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

Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright, however when I open it in gnus the empty lines are

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

Nicolas Richard theonewiththeevill...@yahoo.fr writes: Although Org functions are of course made only for working in org-mode and its a bit hard to see at first sight how this could be useful, I wonder if the regexps could be made a bit more general to make `org-element-at-point' work in

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

Sebastien Vauban sva-n...@mygooglest.com writes: Nick Dokos wrote: Thorsten Jolitz tjol...@gmail.com writes: Thorsten Jolitz tjol...@gmail.com writes: As a side-remark, I did send these blocks with emptly lines between them, and when I look at my post in gmane the format looks alright,

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

Hello, Thorsten Jolitz tjol...@gmail.com 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

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

Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com 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

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

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

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

Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Matt Lundin m...@imapmail.org 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

[O] org-element checks make flyspell prohibitively slow

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

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

Hello, Matt Lundin m...@imapmail.org 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 @

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

Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr writes: Could you review this ? thanks. Applied, thanks! -- Bastien

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

Hello, Bastien b...@gnu.org 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,

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

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

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

Hello, Daimrod daim...@gmail.com 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',

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

Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com 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]] ^

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

Hello, Daimrod daim...@gmail.com 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

Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com 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

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

Daimrod daim...@gmail.com 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

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

Hi Nicolas and Greg, Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com 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

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

Hello Nicolas On 5 March 2014 09:25, Nicolas Goaziou n.goaz...@gmail.com wrote: Daimrod daim...@gmail.com 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

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

Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com 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

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

Bastien b...@gnu.org writes: Hi Nicolas and Greg, Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com 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,

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

Hello, Bastien b...@gnu.org 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:

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

Daimrod daim...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Daimrod daim...@gmail.com 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

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

Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com 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 =

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

Daimrod daim...@gmail.com 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

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

Bastien b...@gnu.org 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

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

Bastien b...@gnu.org writes: Daimrod daim...@gmail.com 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

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

Nicolas Goaziou n.goaz...@gmail.com 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

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

Bastien b...@gnu.org writes: Daimrod daim...@gmail.com 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

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

Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr 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

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

Bastien b...@gnu.org writes: Hi Nicolas, Nicolas Richard theonewiththeevill...@yahoo.fr 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

Re: [O] org-element cache and LAST_REPEAT

Hello, Michael Brand michael.ch.br...@gmail.com writes: On Tue, Mar 4, 2014 at 8:58 PM, Matt Lundin m...@imapmail.org 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.

Re: [O] org-element cache and LAST_REPEAT

Hi Nicolas On Wed, Mar 5, 2014 at 8:11 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: This should be fixed. Thanks to both of you for reporting it. It works, thank you. Michael

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

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:

[O] org-element cache and LAST_REPEAT

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

Re: [O] org-element cache and LAST_REPEAT

Michael Brand michael.ch.br...@gmail.com 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:

Re: [O] org-element cache and LAST_REPEAT

Hi Matt On Tue, Mar 4, 2014 at 8:58 PM, Matt Lundin m...@imapmail.org 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-map no-recursion argument?

Hello, James Harkins jamshar...@gmail.com 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

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

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

[O] org-element, spurious command??

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.

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

Hello, Robert Klein rokl...@roklein.de 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

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

On Sat, Nov 9, 2013 at 2:48 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Matt Price mopto...@gmail.com 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

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

Hi, I'm trying to write a query that will check to see if the current element has any of several properties set; the properties are defined in a defcustom so I don't know in advance which properties I'm interested in. So I have the following code which INSERTS properties: (defcustom

  1   2   >