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
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,
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
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
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
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.
>
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
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
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
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
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_
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 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
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
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
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
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
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,
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
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-
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:
>>
>>
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
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'
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 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
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
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
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 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
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<---
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:
> 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
98 matches
Mail list logo
