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
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 l
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
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/
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-
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 e
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 befo
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 fairl
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-ado
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 befo
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 /
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
>> par
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 co
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 i
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
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
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-p
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 :
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)))
> (w
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))
(mes
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 se
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.
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.
>
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.
[Th
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-par
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 ""
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 chok
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.
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 give
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 walk
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 mysterio
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
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
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
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 :cont
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]
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 form
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
> newli
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/
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 fontificat
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
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
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
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 th
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.
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
wh
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
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 an
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 hav
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-arti
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]
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 compati
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 li
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
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
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.
> 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 ca
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
>>
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_
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 c
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
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 n
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
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_
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
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
Hi Nicolas,
Nicolas Richard writes:
> Could you review this ? thanks.
Applied, thanks!
--
Bastien
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,
> ma
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 anc
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
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 bot
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
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
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 interact
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 t
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 interact
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 (
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.)
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
>
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 l
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:
[remo
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.
>
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 g
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 comp
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-vers
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
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 forg
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
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
>>
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 `or
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
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.em
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
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_E
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 s
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.
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
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.
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 p
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 (c
1 - 100 of 122 matches
Mail list logo
