The Org fragment
\[
r = a
+ b
- c
\]
gets interpreted as something strange with a list inbetween. Thus it gets
exported as:
$\backslash$[
r = a
\begin{itemize}
\item b
\item c
\end{itemize}
$\backslash$]
How is one supposed to write (longer) equations out on multiple lines (leaving
the operato
Hi,
I'm playing a bit with org-element for org-contacts and I wanted to know
what is the prefered way to change an element.
For example, ATM, when I want to change an element property to add a new
value, I do:
#+BEGIN_SRC emacs-lisp
(org-entry-put nil property
(concat (org-ent
On Fri, Feb 22, 2013 at 11:38:16AM +, Achim Gratz wrote:
>
> How is one supposed to write (longer) equations out on multiple lines (leaving
> the operators behind on the previous line obviously works, but is ugly)?
I use LaTeX blocks. So your example would translate to:
#+begin_latex
\beg
Suvayu Ali writes:
> I use LaTeX blocks. So your example would translate to:
>
> #+begin_latex
> \begin{equation}
> r = a
> + b
> - c
> \end{equation}
> #+begin_latex
>
> With easy templates, entering blocks is trivial ( blocks).
Of course, the next question is whether we want t
Suvayu Ali writes:
> On Fri, Feb 22, 2013 at 11:38:16AM +, Achim Gratz wrote:
>>
>> How is one supposed to write (longer) equations out on multiple lines
>> (leaving
>> the operators behind on the previous line obviously works, but is ugly)?
>
> I use LaTeX blocks. So your example would tr
On Fri, Feb 22, 2013 at 02:25:13PM +0100, Nicolas Goaziou wrote:
> Suvayu Ali writes:
>
> > On Fri, Feb 22, 2013 at 11:38:16AM +, Achim Gratz wrote:
> >>
> >> How is one supposed to write (longer) equations out on multiple lines
> >> (leaving
> >> the operators behind on the previous line o
Suvayu Ali gmail.com> writes:
> I use LaTeX blocks. So your example would translate to:
Sure, but then the equation would only be exported for LaTeX
and I would need to copy the same thing just again for
HTML export.
I didn't put a [Bug] tag on the OP on purpose, since I don't
really know what'
Hello,
Daimrod writes:
> I'm playing a bit with org-element for org-contacts and I wanted to know
> what is the prefered way to change an element.
>
> For example, ATM, when I want to change an element property to add a new
> value, I do:
>
> #+BEGIN_SRC emacs-lisp
> (org-entry-put nil propert
Nicolas Goaziou writes:
> Hello,
Hello Nicolas,
> Daimrod writes:
>
>> I'm playing a bit with org-element for org-contacts and I wanted to know
>> what is the prefered way to change an element.
>>
>> For example, ATM, when I want to change an element property to add a new
>> value, I do:
>>
>>
Daimrod writes:
> Nicolas Goaziou writes:
>
>> See `org-element-put-property' and friends.
>
> I've tried to use `org-element-put-property' but it only modifies the
> object in memory, not the element in the file. Is there a way to write
> the object into a file?
I misread your question.
"org-
Hi Nicolas,
I have been trying out the `org-element-drag-backward' and
`org-element-drag-forward' navigation commands. I believe they stopped
working yesterday when I updated my org-mode (Git: dab2505 -> a69f4b8).
When I try to move list items, I get the backtrace shown below. FWIW,
promotion and
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.
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
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,
suvayu ali writes:
> I have been trying out the `org-element-drag-backward' and
> `org-element-drag-forward' navigation commands. I believe they stopped
> working yesterday when I updated my org-mode (Git: dab2505 -> a69f4b8).
>
> When I try to move list items, I get the backtrace shown b
On Wed, Jul 4, 2012 at 5:56 PM, Nicolas Goaziou wrote:
> Could you provide an ECM? I cannot reproduce the problem.
>
> Also, is the move that you're trying to achieve allowed?
Yes the move is allowed. I can reproduce the problem with the attached
ECM. Evaluate the lisp block in a minimal Emacs se
Hello,
suvayu ali writes:
> Yes the move is allowed. I can reproduce the problem with the attached
> ECM. Evaluate the lisp block in a minimal Emacs session and try to
> reorder the list below with M-.
I see. This behaviour is documented in `org-element-at-point' docstring:
--8<---
Hi Nicolas,
On Wed, Jul 4, 2012 at 6:22 PM, Nicolas Goaziou wrote:
> It means that if point is at the very beginning of the list, it will try
> to move the whole list. Since there is nothing after the list, it
> returns an error.
>
> In order to drag the first item, you have to move one character
Remove the spaces before #+name OR take out the '- item' and org-export-dispatch
succeeds.
As is, it fails with
org-element-paragraph-parser: Invalid search bound (wrong side of point)
,
| * export dispatcher
|
| - item
|
| #+name: xyz
| #+BEGIN_SRC emacs-lisp
| (pwd)
| #+E
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 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
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
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
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
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
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:
> 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
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
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,
Charles Berry writes:
> Remove the spaces before #+name OR take out the '- item' and
> org-export-dispatch
> succeeds.
>
> As is, it fails with
>
> org-element-paragraph-parser: Invalid search bound (wrong side of point)
>
>
> ,
> | * export dispatcher
> |
> | - item
> |
> |
Hi,
After updating org-mode from git, I noticed, that
org-element-parse-buffer uppercases the properties now. Is this a
feature or a bug?
Example:
* TODO test
DEADLINE: <2013-06-18 Tue 12:00>
:PROPERTIES:
:notify: test
:END:
Result of (org-element-parse-buffer 'headline):
(headline (
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.
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 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
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
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
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
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 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 :
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
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
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
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-
Hello,
Peter Münster writes:
> After updating org-mode from git, I noticed, that
> org-element-parse-buffer uppercases the properties now. Is this a
> feature or a bug?
>
> Example:
>
> * TODO test
> DEADLINE: <2013-06-18 Tue 12:00>
> :PROPERTIES:
> :notify: test
> :END:
>
> Result of
Hi List,
when mapping a parse tree with `org-element-map', this
,-
| (org-element-map tree iorg-all-types-no-text
| (lambda (--elem)
| (if (eq (org-element-type --elem) 'org-data) [...]
`-
wi
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
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
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
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
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
Hello,
Thorsten Jolitz writes:
> The returned mapped tree starts with the first (section (...)) element,
> org-data is simply ignored and missing.
>
> How can I make `org-element-map' act on the 'org-data' element too?
You can't. This behaviour is hard-coded.
Regards,
--
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
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_
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
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.
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 ""
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 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
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 /
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
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:
> 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
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 org-writers-
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
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_
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
>>
> 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:
> 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.
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
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
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
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
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]
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
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
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
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
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
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:
> 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
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
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 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:
> 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 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/
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
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 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:
> 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
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
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
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
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,
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
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 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 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
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
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
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
1 - 100 of 122 matches
Mail list logo
