* (no subject)
@ 2006-05-25 10:43 Thomas Baumann
2006-05-25 12:49 ` Carsten Dominik
0 siblings, 1 reply; 135+ messages in thread
From: Thomas Baumann @ 2006-05-25 10:43 UTC (permalink / raw)
To: emacs-orgmode
Hi Carsten,
I guess org-publish should either be integrated into org-el or committed
to emacs-cvs because otherwise the menu entries related to publishing
will fail.
Thomas
following the lively development with great interest but with too little
time to test all new features :-)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2006-05-25 10:43 Thomas Baumann
@ 2006-05-25 12:49 ` Carsten Dominik
0 siblings, 0 replies; 135+ messages in thread
From: Carsten Dominik @ 2006-05-25 12:49 UTC (permalink / raw)
To: thomas.baumann; +Cc: emacs-orgmode
David has started the process of transferring his copyright to the FSF.
Once that is complete we will hopefully be able to quickly install
this file in Emacs.
- Carsten
On May 25, 2006, at 12:43, Thomas Baumann wrote:
> Hi Carsten,
>
> I guess org-publish should either be integrated into org-el or
> committed
> to emacs-cvs because otherwise the menu entries related to publishing
> will fail.
>
> Thomas
>
> following the lively development with great interest but with too
> little
> time to test all new features :-)
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2007-10-20 10:33 Kevin Brubeck Unhammer
2007-10-21 22:20 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Kevin Brubeck Unhammer @ 2007-10-20 10:33 UTC (permalink / raw)
To: dominik; +Cc: emacs-orgmode
Carsten Dominik <dominik@science.uva.nl> writes:
> - The agenda dispatcher
> + `<' cycles through restriction states.
Is there still a reason for the agenda timeline ("L") having to be
restricted to the current buffer?
--
Kevin Brubeck Unhammer
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2007-10-20 10:33 Kevin Brubeck Unhammer
@ 2007-10-21 22:20 ` Bastien
0 siblings, 0 replies; 135+ messages in thread
From: Bastien @ 2007-10-21 22:20 UTC (permalink / raw)
To: emacs-orgmode
"Kevin Brubeck Unhammer" <unhammer@gmail.com> writes:
> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> - The agenda dispatcher
>> + `<' cycles through restriction states.
>
> Is there still a reason for the agenda timeline ("L") having to be
> restricted to the current buffer?
Please check these threads:
http://search.gmane.org/?query=timeline+all+agenda-files&group=gmane.emacs.orgmode
From the manual:
The timeline summarizes all time-stamped items from a single Org-mode
file in a _time-sorted view_. The main purpose of this command is to
give an overview over events in a project.
You can still create your own agenda view displaying the agenda for any
number of days by using `org-agenda-ndays':
(setq org-agenda-custom-commands
'(("n" agenda ""
((org-agenda-ndays 100)))))
But this can take longer than displaying the timeline for just one file.
HTH,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2007-11-13 20:35 François Puitg
0 siblings, 0 replies; 135+ messages in thread
From: François Puitg @ 2007-11-13 20:35 UTC (permalink / raw)
To: emacs-orgmode; +Cc: tim.ocallaghan, Dr.Volker.Zell
Subject: Re: [Orgmode] undo in org.el
In-Reply-To: <200711131703.lADH3ive000962@imag.imag.fr>
References: <200711131703.lADH3ive000962@imag.imag.fr>
X-Mailer: VM 7.19 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid--text follows this line--
FCC: ~/Mail/messages_envoyés
> Well, the fact that it is in Emacs CVS has not kept me from
> supporting XEmacs for quite a while now. But it is extra work and
> requires catering for missing features and different implementations
> - so it is important for me to know that this is used and still
> appreciated.
>
> How about someone stepping forward and trying to release an XEmacs
> package containing noutline.el and org-mode? Anyone who feels up to
> this? Because I will not have the time.
>
> - Carsten
I'm another (happy) user of XEmacs, and a (not less happy) user of
org-mode.
I don't think I could maintain an XEmacs package for org-mode (not
only a question of time, but also capability), but I'm willing to help
by testing org-mode under XEmacs and tracking down bugs.
-- Frnçs
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2008-01-28 11:20 Dimitris Kapetanakis
2008-01-29 9:39 ` Bastien Guerry
0 siblings, 1 reply; 135+ messages in thread
From: Dimitris Kapetanakis @ 2008-01-28 11:20 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 330 bytes --]
This is really a question for Bastien
I tried to use blorg.el but I can't load it
it says
Compiling file g:/Emacs/site-lisp/blorg.el at Mon Jan 28 13:17:20 2008
blorg.el:133:1:Warning: value returned from (fboundp (quote
replace-regexp-in-string)) is unused
blorg.el:1405:1:Error: Invalid read syntax: "?"
can you help me?
[-- Attachment #1.2: Type: text/html, Size: 396 bytes --]
[-- Attachment #2: Type: text/plain, Size: 204 bytes --]
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2008-01-28 11:20 Dimitris Kapetanakis
@ 2008-01-29 9:39 ` Bastien Guerry
0 siblings, 0 replies; 135+ messages in thread
From: Bastien Guerry @ 2008-01-29 9:39 UTC (permalink / raw)
To: Dimitris Kapetanakis; +Cc: emacs-orgmode
Hi Dimitri,
"Dimitris Kapetanakis" <katepano@gmail.com> writes:
> This is really a question for Bastien
> I tried to use blorg.el but I can't load it
>
> it says
>
> Compiling file g:/Emacs/site-lisp/blorg.el at Mon Jan 28 13:17:20 2008
> blorg.el:133:1:Warning: value returned from (fboundp (quote
> replace-regexp-in-string)) is unused
> blorg.el:1405:1:Error: Invalid read syntax: "?"
>
> can you help me?
I've uploaded a small fix for this. Please check blorg.el 0.75b:
http://www.cogintion.ens.fr/~guerry/u/blorg.el
HTH,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2009-02-17 18:57 Matthew Lundin
2009-02-17 20:26 ` Carsten Dominik
0 siblings, 1 reply; 135+ messages in thread
From: Matthew Lundin @ 2009-02-17 18:57 UTC (permalink / raw)
To: emacs-orgmode
Hi everyone,
With one of the recent updates to org (not sure which one), I started to
have some formatting issues with numbers in html headlines when
exporting from org.
Let's take the following org file:
--8<---------------cut here---------------start------------->8---
#+TITLE: Test
* Headline One
** Subheading One
--8<---------------cut here---------------end--------------->8---
The headline and subheading export to html as:
,----
| <div id="outline-container-1" class="outline-2">
| <h2 id="sec-1"><span class="section-number-2"> 1</span>Headline One </h2>
| <div class="outline-text-2" id="text-1">
|
|
| </div>
|
| <div id="outline-container-1.1" class="outline-3">
| <h3 id="sec-1.1"><span class="section-number-3"> 1.1</span>Subheading One </h3>
`----
Which appears as:
,----
| 1Headline One
|
| 1.1Subheading One
`----
In other words, a space is missing in the exported html.
Thanks,
Matt
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2009-02-17 18:57 Matthew Lundin
@ 2009-02-17 20:26 ` Carsten Dominik
0 siblings, 0 replies; 135+ messages in thread
From: Carsten Dominik @ 2009-02-17 20:26 UTC (permalink / raw)
To: Matthew Lundin; +Cc: emacs-orgmode
Fixed, thanks.
- Carsten
On Feb 17, 2009, at 7:57 PM, Matthew Lundin wrote:
> Hi everyone,
>
> With one of the recent updates to org (not sure which one), I
> started to
> have some formatting issues with numbers in html headlines when
> exporting from org.
>
> Let's take the following org file:
>
> --8<---------------cut here---------------start------------->8---
> #+TITLE: Test
>
> * Headline One
> ** Subheading One
> --8<---------------cut here---------------end--------------->8---
>
> The headline and subheading export to html as:
>
> ,----
> | <div id="outline-container-1" class="outline-2">
> | <h2 id="sec-1"><span class="section-number-2"> 1</span>Headline
> One </h2>
> | <div class="outline-text-2" id="text-1">
> |
> |
> | </div>
> |
> | <div id="outline-container-1.1" class="outline-3">
> | <h3 id="sec-1.1"><span class="section-number-3"> 1.1</
> span>Subheading One </h3>
> `----
>
> Which appears as:
>
> ,----
> | 1Headline One
> |
> | 1.1Subheading One
> `----
>
> In other words, a space is missing in the exported html.
>
> Thanks,
> Matt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2009-09-18 12:35 Robin Green
0 siblings, 0 replies; 135+ messages in thread
From: Robin Green @ 2009-09-18 12:35 UTC (permalink / raw)
To: emacs-orgmode
Is there any equivalent to planner-mode's planner-rank.el for org-mode? I want to automatically compute some sort of combined measure of urgency and importance for each of my TODOs, and rank them according to this measure. (Of course, I could write my own code to do this, and I might do just that if there isn't anything suitable already out there.)
--
Robin
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2010-06-29 17:50 amscopub-mail
0 siblings, 0 replies; 135+ messages in thread
From: amscopub-mail @ 2010-06-29 17:50 UTC (permalink / raw)
To: emacs-orgmode
The following latex options produce the right format (an article scaled up to 20pts using the "arev" font):
#+LaTeX_CLASS: article
#+LaTeX_CLASS_OPTIONS: [12pt]
#+LATEX_HEADER: \usepackage{amsmath,amsthm,amssymb} \usepackage[T1]{fontenc} \usepackage[20pt]{extsizes} \usepackage{arev} \usepackage[utf8]{inputenc}
However, when I export to HTML, the math equations fail to export. And yes, I set the right variable for exporting latex snippets in HTML.
Ideas? The culprit seems to be the arev package. Export works fine if I remove that. However, why would that cause a problem?
Using org-mode 6.36
--
--Thanks!
U.
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2011-02-21 22:13 Vincent-Xavier JUMEL
2011-02-23 19:52 ` Bernt Hansen
2011-02-23 19:54 ` Bernt Hansen
0 siblings, 2 replies; 135+ messages in thread
From: Vincent-Xavier JUMEL @ 2011-02-21 22:13 UTC (permalink / raw)
To: emacs-orgmode
From: Vincent-Xavier JUMEL <endymion@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
To: emacs-orgmode@gnu.org
Subject: Bug: Bug in agenda on DEADLINE/SCHEDULE with -3d [7.4]
Date: Mon, 21 Feb 2011 23:13:32 +0100
Message-ID: <87d3mlyr1v.fsf@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
An entry with a SCHEDULE or a DEADLINE using the <date -%d[dwm]> doesn't
produce the documented behavior. Anyone does have the same issue ?
----
Emacs : GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.21.6)
of 2010-09-01 on rhenium, modified by Debian
Package: Org-mode version 7.4
current state:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(setq
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-files '("~/org/parinux.org")
org-blocker-hook '(org-block-todo-from-checkboxes)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-templates '(("a" "Ajoute un atelier" entry
(file+headline "~/org/parinux.org"
"Premier Samedi")
(file
"~/.emacs.d/org/templates/atelier_parinux.tpl")
)
("c" "Ajoute une conf=C3=A9rence" entry
(file+headline "~/org/parinux.org"
"Conf=C3=A9rences")
(file
"~/.emacs.d/org/templates/conference_parinux.tpl=
")
)
("v" "Ajoute un vote" entry
(file+headline "~/org/parinux.org"
"Votes")
(file
"~/.emacs.d/org/templates/vote_parinux_ca_2011.t=
pl")
)
)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-startup-folded 'content
org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
org-export-latex-format-toc-function 'org-export-latex-format-toc-default
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe
org-babel-hide-result-toggle-maybe)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-default-notes-file "~/org/notes"
org-babel-pre-tangle-hook '(save-buffer)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link=
-modifiers)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-show-block-all append local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec
org-babel-hide-all-hashes)
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-export-interblocks '((lob org-babel-exp-lob-one-liners)
(src org-babel-exp-inline-src-blocks))
org-occur-hook '(org-first-headline-recenter)
org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-sele=
ct-beamer-code)
org-export-latex-final-hook '(org-beamer-amend-header
org-beamer-fix-toc
org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
org-enforce-todo-checkbox-dependencies t
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-blocks '((src org-babel-exp-src-blocks nil)
(comment org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil)
(dot org-export-blocks-format-dot nil))
)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2011-02-21 22:13 Vincent-Xavier JUMEL
@ 2011-02-23 19:52 ` Bernt Hansen
2011-02-23 19:54 ` Bernt Hansen
1 sibling, 0 replies; 135+ messages in thread
From: Bernt Hansen @ 2011-02-23 19:52 UTC (permalink / raw)
To: Vincent-Xavier JUMEL; +Cc: emacs-orgmode
"Vincent-Xavier JUMEL" <endymion@thetys-retz.net> writes:
> From: Vincent-Xavier JUMEL <endymion@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
> To: emacs-orgmode@gnu.org
> Subject: Bug: Bug in agenda on DEADLINE/SCHEDULE with -3d [7.4]
> Date: Mon, 21 Feb 2011 23:13:32 +0100
> Message-ID: <87d3mlyr1v.fsf@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
>
> An entry with a SCHEDULE or a DEADLINE using the <date -%d[dwm]> doesn't
> produce the documented behavior. Anyone does have the same issue ?
>
> ----
>
>
>
> Emacs : GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.21.6)
> of 2010-09-01 on rhenium, modified by Debian
> Package: Org-mode version 7.4
>
> current state:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> (setq
> org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
> org-speed-command-hook '(org-speed-command-default-hook
> org-babel-speed-command-hook)
> org-agenda-files '("~/org/parinux.org")
> org-blocker-hook '(org-block-todo-from-checkboxes)
> org-metaup-hook '(org-babel-load-in-session-maybe)
> org-capture-templates '(("a" "Ajoute un atelier" entry
> (file+headline "~/org/parinux.org"
> "Premier Samedi")
> (file
> "~/.emacs.d/org/templates/atelier_parinux.tpl")
> )
> ("c" "Ajoute une conf=C3=A9rence" entry
> (file+headline "~/org/parinux.org"
> "Conf=C3=A9rences")
> (file
> "~/.emacs.d/org/templates/conference_parinux.tpl=
> ")
> )
> ("v" "Ajoute un vote" entry
> (file+headline "~/org/parinux.org"
> "Votes")
> (file
> "~/.emacs.d/org/templates/vote_parinux_ca_2011.t=
> pl")
> )
> )
> org-after-todo-state-change-hook '(org-clock-out-if-current)
> org-startup-folded 'content
> org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
> org-export-latex-format-toc-function 'org-export-latex-format-toc-default
> org-tab-first-hook '(org-hide-block-toggle-maybe
> org-src-native-tab-command-maybe
> org-babel-hide-result-toggle-maybe)
> org-src-mode-hook '(org-src-babel-configure-edit-buffer
> org-src-mode-configure-edit-buffer)
> org-confirm-shell-link-function 'yes-or-no-p
> org-export-first-hook '(org-beamer-initialize-open-trackers)
> org-agenda-before-write-hook '(org-agenda-add-entry-text)
> org-default-notes-file "~/org/notes"
> org-babel-pre-tangle-hook '(save-buffer)
> org-cycle-hook '(org-cycle-hide-archived-subtrees
> org-cycle-hide-drawers org-cycle-show-empty-lines
> org-optimize-window-after-visibility-change)
> org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link=
> -modifiers)
> org-mode-hook '(#[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook
> org-show-block-all append local]
> 5]
> #[nil "\300\301\302\303\304$\207"
> [org-add-hook change-major-mode-hook
> org-babel-show-result-all append local]
> 5]
> org-babel-result-hide-spec
> org-babel-hide-all-hashes)
> org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
> org-babel-execute-safely-maybe)
> org-confirm-elisp-link-function 'yes-or-no-p
> org-export-interblocks '((lob org-babel-exp-lob-one-liners)
> (src org-babel-exp-inline-src-blocks))
> org-occur-hook '(org-first-headline-recenter)
> org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-sele=
> ct-beamer-code)
> org-export-latex-final-hook '(org-beamer-amend-header
> org-beamer-fix-toc
> org-beamer-auto-fragile-frames
> org-beamer-place-default-actions-for-lists)
> org-enforce-todo-checkbox-dependencies t
> org-metadown-hook '(org-babel-pop-to-session-maybe)
> org-export-blocks '((src org-babel-exp-src-blocks nil)
> (comment org-export-blocks-format-comment t)
> (ditaa org-export-blocks-format-ditaa nil)
> (dot org-export-blocks-format-dot nil))
> )
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2011-02-21 22:13 Vincent-Xavier JUMEL
2011-02-23 19:52 ` Bernt Hansen
@ 2011-02-23 19:54 ` Bernt Hansen
2011-04-09 9:41 ` Vincent-Xavier JUMEL
1 sibling, 1 reply; 135+ messages in thread
From: Bernt Hansen @ 2011-02-23 19:54 UTC (permalink / raw)
To: Vincent-Xavier JUMEL; +Cc: emacs-orgmode
"Vincent-Xavier JUMEL" <endymion@thetys-retz.net> writes:
> From: Vincent-Xavier JUMEL <endymion@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
> To: emacs-orgmode@gnu.org
> Subject: Bug: Bug in agenda on DEADLINE/SCHEDULE with -3d [7.4]
> Date: Mon, 21 Feb 2011 23:13:32 +0100
> Message-ID: <87d3mlyr1v.fsf@tauceticentral.i-did-not-set--mail-host-address--so-tickle-me>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
>
> An entry with a SCHEDULE or a DEADLINE using the <date -%d[dwm]> doesn't
> produce the documented behavior. Anyone does have the same issue ?
>
> ----
>
>
>
> Emacs : GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.21.6)
> of 2010-09-01 on rhenium, modified by Debian
> Package: Org-mode version 7.4
>
Please provide a sample task and a description of what you get and what
you expected. AFAIK SCHEDULE and -3d is not intended to work - this is
for DEADLINES: only to specify the number of days before the deadline
that you want the entry to show up in your agenda. I don't think it has
any meaning for SCHEDULED: entries.
-Bernt
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2011-02-23 19:54 ` Bernt Hansen
@ 2011-04-09 9:41 ` Vincent-Xavier JUMEL
0 siblings, 0 replies; 135+ messages in thread
From: Vincent-Xavier JUMEL @ 2011-04-09 9:41 UTC (permalink / raw)
To: Bernt Hansen; +Cc: emacs-orgmode
:SCHEDULED: and :DEADLINE: which is confusing. Documentation
<http://orgmode.org/manual/Repeated-tasks.html#Repeated-tasks> example
Le 23 février à 20:54 Bernt Hansen a écrit
>
> Please provide a sample task and a description of what you get and what
> you expected. AFAIK SCHEDULE and -3d is not intended to work - this is
> for DEADLINES: only to specify the number of days before the deadline
> that you want the entry to show up in your agenda. I don't think it has
> any meaning for SCHEDULED: entries.
>
In my opinion, documentation doesn't make a clear separation between
let me think that <date -3d> will work with SCHEDULED.
Documentation should have a paragraph on repetear <date +d> and on
paragraph on delaying.
--
Vincent-Xavier JUMEL GPG Id: 0x2E14CE70 http://thetys-retz.net
Rejoignez les 5500 adhérents de l'April http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2011-08-06 1:19 Vikas Rawal
0 siblings, 0 replies; 135+ messages in thread
From: Vikas Rawal @ 2011-08-06 1:19 UTC (permalink / raw)
To: emacs-orgmode
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-01-05 17:36 Ab Cd
0 siblings, 0 replies; 135+ messages in thread
From: Ab Cd @ 2012-01-05 17:36 UTC (permalink / raw)
To: emacs-orgmode@gnu.org
Hello,
Please consider the following file :
------------------------------8<------------------------------
* TODO working
** TODO 1st part of the work
CLOCK: [2012-01-05 jeu. 17:18]
** TODO second part of the work [0/3]
- [ ] Task 1
- [ ] Subtask 1
- [ ] Subtask 2
- [ ] Subtask 3
- [ ] Task 2
- [ ] Task 3
------------------------------>8------------------------------
It I switch the second TODO (ie: C-c C-t on the line "1st part of the work"), it clocks out the headline.
So
------------------------------8<------------------------------
** TODO 1st part of the work
CLOCK: [2012-01-05 jeu. 17:18]
------------------------------>8------------------------------
becomes
------------------------------8<------------------------------
** DONE 1st part of the work
CLOCK: [2012-01-05 jeu. 17:18]--[2012-01-05 jeu. 18:25] => 1:07
------------------------------>8------------------------------
And that's fine.
Now, if I try to toggle the "Subtask"s with cc, it toggles Task 1 accordingly (to "[-] Task 1" and then later to "[X] Task 1"). And then switching all tasks switche the headline checkbox counter (to [1/3], [2/3] and then [3/3]).
Again it's fine.
But why shoudln't a TODO headline containing only checkbox that are all completed ([3/3] in this case) be switched to done?
Also, why can't I toggle "Task 1" ? Let's assume I was away from my computer when completing some or all of the subtasks. I would really like to check Task 1 and have all the Subtasks checked automatically.
The same thing applies if I switch the 2 headlines "{1st,second} part of the work" to DONE. Shouldn't that switch the "working" headline to DONE too?
One last thing. I also think I would be nice that, if I switch "second part of the work" to DONE, the counter would be set to [3/3] and all the tasks and subtasks be checked as done.
What do you think?
Cheers.
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-01-23 12:00 Tom Regner
2012-01-23 16:34 ` Tom Regner
2012-01-23 20:31 ` Eric Schulte
0 siblings, 2 replies; 135+ messages in thread
From: Tom Regner @ 2012-01-23 12:00 UTC (permalink / raw)
To: emacs-orgmode
From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001
From: Tom Regner <tom@goochesa.de>
Rcpt To: emacs-orgmode@gnu.org
Date: Mon, 23 Jan 2012 12:39:52 +0100
Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing.
At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken
because the newlines before the #+end_src line are excluded from the output. This patch uses :padline
to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct
results; code depending on the (errorneous?) behaviour would be broken though.
---
lisp/ob.el | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lisp/ob.el b/lisp/ob.el
index 47be708..398a997 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -2211,13 +2211,16 @@ block but are passed literally to the \"example-block\"."
(nth 4 i))
source-name)
(let* ((body (org-babel-expand-noweb-references i))
- (full (if comment
+ (padded (if (not (string= "no" (cdr (assoc :padline (nth 2 i)))))
+ (concat body "\n")
+ body ))
+ (full (if comment
((lambda (cs)
(concat (c-wrap (car cs)) "\n"
- body "\n"
+ padded "\n"
(c-wrap (cadr cs))))
(org-babel-tangle-comment-links i))
- body)))
+ padded)))
(setq expansion (concat expansion full))))))))
expansion)
;; possibly raise an error if named block doesn't exist
--
1.7.5.4
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-01-23 12:00 Tom Regner
@ 2012-01-23 16:34 ` Tom Regner
2012-01-23 20:31 ` Eric Schulte
1 sibling, 0 replies; 135+ messages in thread
From: Tom Regner @ 2012-01-23 16:34 UTC (permalink / raw)
To: emacs-orgmode
Tom Regner <tom@goochesa.de> writes:
> From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001
> From: Tom Regner <tom@goochesa.de>
> Rcpt To: emacs-orgmode@gnu.org
> Date: Mon, 23 Jan 2012 12:39:52 +0100
> Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing.
[...]
I'm awfully sorry -- shall I remail the patch without the errorneous
empty line in between the headers, so that the patchwork server will
receive it?
kind regards,
Tom
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-01-23 12:00 Tom Regner
2012-01-23 16:34 ` Tom Regner
@ 2012-01-23 20:31 ` Eric Schulte
2012-01-24 1:55 ` Tom Regner
1 sibling, 1 reply; 135+ messages in thread
From: Eric Schulte @ 2012-01-23 20:31 UTC (permalink / raw)
To: Tom Regner; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 272 bytes --]
I'd rather not change the default silently in this way.
Could you provide a minimal example of the difference you describe? I
just tried viewing the expanded form of the following code block and saw
no difference between :noweb-ref and normal #+name: based expansions.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: nowebs.org --]
[-- Type: text/x-org, Size: 175 bytes --]
* examples
#+name: first
#+begin_src sh
echo 1
#+end_src
#+begin_src sh :noweb-ref second
echo 2
#+end_src
#+begin_src sh :noweb yes
<<first>>
<<second>>
#+end_src
[-- Attachment #3: Type: text/plain, Size: 1730 bytes --]
Thanks,
Tom Regner <tom@goochesa.de> writes:
> From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001
> From: Tom Regner <tom@goochesa.de>
> Rcpt To: emacs-orgmode@gnu.org
> Date: Mon, 23 Jan 2012 12:39:52 +0100
> Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing.
>
> At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken
> because the newlines before the #+end_src line are excluded from the output. This patch uses :padline
> to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct
> results; code depending on the (errorneous?) behaviour would be broken though.
> ---
> lisp/ob.el | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/ob.el b/lisp/ob.el
> index 47be708..398a997 100644
> --- a/lisp/ob.el
> +++ b/lisp/ob.el
> @@ -2211,13 +2211,16 @@ block but are passed literally to the \"example-block\"."
> (nth 4 i))
> source-name)
> (let* ((body (org-babel-expand-noweb-references i))
> - (full (if comment
> + (padded (if (not (string= "no" (cdr (assoc :padline (nth 2 i)))))
> + (concat body "\n")
> + body ))
> + (full (if comment
> ((lambda (cs)
> (concat (c-wrap (car cs)) "\n"
> - body "\n"
> + padded "\n"
> (c-wrap (cadr cs))))
> (org-babel-tangle-comment-links i))
> - body)))
> + padded)))
> (setq expansion (concat expansion full))))))))
> expansion)
> ;; possibly raise an error if named block doesn't exist
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-01-23 20:31 ` Eric Schulte
@ 2012-01-24 1:55 ` Tom Regner
0 siblings, 0 replies; 135+ messages in thread
From: Tom Regner @ 2012-01-24 1:55 UTC (permalink / raw)
To: emacs-orgmode
Eric Schulte <eric.schulte@gmx.com> writes:
> I'd rather not change the default silently in this way.
I understand that.
>
> Could you provide a minimal example of the difference you describe? I
> just tried viewing the expanded form of the following code block and saw
> no difference between :noweb-ref and normal #+name: based expansions.
>
> * examples
>
> #+name: first
> #+begin_src sh
> echo 1
> #+end_src
>
> #+begin_src sh :noweb-ref second
> echo 2
> #+end_src
> #+begin_src sh :noweb yes
> <<first>>
> <<second>>
> #+end_src
>
> Thanks,
>
Example document:
--------------------------->%--------------------------------
* Subtree
:PROPERTIES:
:noweb-ref: subtree
:END:
** Part 1
#+begin_src sh
Line One
#+end_src sh
** Part 2
#+begin_src sh
Line Two
#+end_src sh
* Assamble it
#+begin_src sh :tangle yes :noweb tangle
<<subtree>>
#+end_src sh
--------------------------->%--------------------------------
tangled without my patch:
--------------------------->%--------------------------------
Line OneLine Two
--------------------------->%--------------------------------
tangled with my patch
--------------------------->%--------------------------------
Line One
Line Two
--------------------------->%--------------------------------
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-05-11 20:56 Rick Frankel
@ 2012-05-11 20:38 ` Eric Schulte
2012-05-11 22:43 ` Bernt Hansen
2012-05-17 6:23 ` Bastien
0 siblings, 2 replies; 135+ messages in thread
From: Eric Schulte @ 2012-05-11 20:38 UTC (permalink / raw)
To: Rick Frankel; +Cc: emacs-orgmode
Thanks for the patch, I would like to apply it.
Have you signed the FSF papers for contribution to Org-mode and Emacs?
If you haven't would you be willing to? See the Org-mode contribution
instructions for more information.
http://orgmode.org/worg/org-contribute.html
Thanks!
rick@rickster.com (Rick Frankel) writes:
> From 113bbbe1ce9540e2af8c613ba655599fc474cedd Mon Sep 17 00:00:00 2001
> From: Rick Frankel <rick@rickster.com>
> Date: Fri, 11 May 2012 16:54:32 -0400
> Subject: [PATCH] Add support for perl dbi to SQL code block
>
> * lisp/ob-sql.el (org-babel-execute:sql): Add dbi as a suppored engine.
>
> Invokes `dbish' with the arguments specified to ":cmdline". Minimum is
> usually the "dbi:{dbd}" argument, plus the username and password if
> required.
> For example:
>
> lisp/ob-sql.el | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
> index e3f6edd..c6d4790 100644
> --- a/lisp/ob-sql.el
> +++ b/lisp/ob-sql.el
> @@ -71,6 +71,11 @@ This function is called by `org-babel-execute-src-block'."
> (org-babel-temp-file "sql-out-")))
> (header-delim "")
> (command (case (intern engine)
> + ('dbi (format "dbish --batch %s < %s | sed '%s' > %s"
> + (or cmdline "")
> + (org-babel-process-file-name in-file)
> + "/^+/d;s/^\|//;$d"
> + (org-babel-process-file-name out-file)))
> ('monetdb (format "mclient -f tab %s < %s > %s"
> (or cmdline "")
> (org-babel-process-file-name in-file)
> @@ -90,7 +95,11 @@ This function is called by `org-babel-execute-src-block'."
> (or cmdline "")))
> (t (error "no support for the %s sql engine" engine)))))
> (with-temp-file in-file
> - (insert (org-babel-expand-body:sql body params)))
> + (insert
> + (case (intern engine)
> + ('dbi "/format partbox\n")
> + (t ""))
> + (org-babel-expand-body:sql body params)))
> (message command)
> (shell-command command)
> (if (or (member "scalar" result-params)
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-05-11 20:56 Rick Frankel
2012-05-11 20:38 ` Eric Schulte
0 siblings, 1 reply; 135+ messages in thread
From: Rick Frankel @ 2012-05-11 20:56 UTC (permalink / raw)
To: emacs-orgmode
From 113bbbe1ce9540e2af8c613ba655599fc474cedd Mon Sep 17 00:00:00 2001
From: Rick Frankel <rick@rickster.com>
Date: Fri, 11 May 2012 16:54:32 -0400
Subject: [PATCH] Add support for perl dbi to SQL code block
* lisp/ob-sql.el (org-babel-execute:sql): Add dbi as a suppored engine.
Invokes `dbish' with the arguments specified to ":cmdline". Minimum is
usually the "dbi:{dbd}" argument, plus the username and password if
required.
For example:
#+begin_src sql :engine dbi :cmdline dbi:Pg:database=postgres
---
lisp/ob-sql.el | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index e3f6edd..c6d4790 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -71,6 +71,11 @@ This function is called by `org-babel-execute-src-block'."
(org-babel-temp-file "sql-out-")))
(header-delim "")
(command (case (intern engine)
+ ('dbi (format "dbish --batch %s < %s | sed '%s' > %s"
+ (or cmdline "")
+ (org-babel-process-file-name in-file)
+ "/^+/d;s/^\|//;$d"
+ (org-babel-process-file-name out-file)))
('monetdb (format "mclient -f tab %s < %s > %s"
(or cmdline "")
(org-babel-process-file-name in-file)
@@ -90,7 +95,11 @@ This function is called by `org-babel-execute-src-block'."
(or cmdline "")))
(t (error "no support for the %s sql engine" engine)))))
(with-temp-file in-file
- (insert (org-babel-expand-body:sql body params)))
+ (insert
+ (case (intern engine)
+ ('dbi "/format partbox\n")
+ (t ""))
+ (org-babel-expand-body:sql body params)))
(message command)
(shell-command command)
(if (or (member "scalar" result-params)
--
1.7.10.1
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-05-11 20:38 ` Eric Schulte
@ 2012-05-11 22:43 ` Bernt Hansen
2012-05-17 6:23 ` Bastien
1 sibling, 0 replies; 135+ messages in thread
From: Bernt Hansen @ 2012-05-11 22:43 UTC (permalink / raw)
To: Eric Schulte; +Cc: Rick Frankel, emacs-orgmode
Eric Schulte <eric.schulte@gmx.com> writes:
>> * lisp/ob-sql.el (org-babel-execute:sql): Add dbi as a suppored engine.
s/suppored/supported/
-Bernt
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-05-11 20:38 ` Eric Schulte
2012-05-11 22:43 ` Bernt Hansen
@ 2012-05-17 6:23 ` Bastien
1 sibling, 0 replies; 135+ messages in thread
From: Bastien @ 2012-05-17 6:23 UTC (permalink / raw)
To: Eric Schulte; +Cc: Rick Frankel, emacs-orgmode
Hi Eric and Rick,
Eric Schulte <eric.schulte@gmx.com> writes:
> Thanks for the patch, I would like to apply it.
>
> Have you signed the FSF papers for contribution to Org-mode and Emacs?
I guess some communication happened offlist -- if Rick does not have the
FSF papers, we need to mark the change as TINYCHANGE.
> If you haven't would you be willing to? See the Org-mode contribution
> instructions for more information.
> http://orgmode.org/worg/org-contribute.html
Also the ChangeLog should start with an uppercase letter and end with a
point... sorry to nitpick on this, but I try to ease my life in
emacs-devel :)
Thanks for the patch anyway,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-05-30 0:51 ` Mark E. Shoulson
@ 2012-05-31 1:50 ` Mark Shoulson
2012-05-31 13:38 ` Nicolas Goaziou
0 siblings, 1 reply; 135+ messages in thread
From: Mark Shoulson @ 2012-05-31 1:50 UTC (permalink / raw)
To: emacs-orgmode
Mark E. Shoulson <mark <at> kli.org> writes:
>
> All right, bottom line, this is sort of what I'm seeing. I'm not 100%
> sure which files should house these things, but something like this:
>
> 1) a variable containing for each language regexp for each of: open
> double-quote, close double-quote, open single-quote, close single-quote,
> and maybe mid-word apostrophe. Odds are these regexps are going to be
> the same for just about all languages (the regexps detecting them, mind
> you), so probably should have some sort of default that the alist can
> just reference. A language should also be allowed to define other quote
> regexps in its list too. We need these to be ordered, with a standard
> set, so that we can have...
>
> 2) for each *exporter* (including on-screen display), a variable that
> defines, for each language, what the *substitution* will be for
> open-double-quote, close-double-quote, etc. Other extras can be defined
> too. That way we can have an exporter-independent way to detect quotes
> to be smartified, but each exporter has its own way to smartify them.
>
> 3) Since most exporters are probably going to be handling doing the
> process approximately the same (match the regexp, stick in the
> associated substitution), org-export.el should have a generic function
> that does this which each exporter *may* call in (or as) its
> quote-smartifier in its text translator, unless it needs something more
> specific which it can provide itself.
>
> In terms of what is handled, the idea in my head is that we would expect
> the writer to be using " or ' to surround their quotes, regardless of
> what their native custom is (if they're doing it using their
> language-specific quote-marks, we don't need to bother with all this
> anyway). Goal is to handle either "quotes" or 'quotes' in either
> nesting (or no nesting, if someone does "quote' for some reason), and
> with any luck not get too confused with other uses of apostrophe.
>
> It makes sense to me, but I bet I explained it badly and people are
> going to have all kinds of issues with it. :)
>
> No telling when (if?) I'll be able to produce something along these
> lines, but it's something to start thinking about anyway.
>
> ~mark
>
>
Regarding the "this is what I'm seeing", I paste at the bottom a
preliminary patch. It is totally *not* worth actually applying it unless you
want to develop this; it's a snapshot mid-development. But it does seem to
actually work. The same set of regexps is used, and the same function, though
that is defeasible and an exporter can define its own. The hardest part was
getting the onscreen versions showing right (also the most recently and probably
best tested, so the actual exporters might be more bumpy). Actual substitutions
being used are not necessarily typologically sensible; chosen more so it's
easier to see the action of the process. Nothing is in the right place, things
that should be customizables aren't... it's proof-of-concept. Am I going in the
right direction, as far as export-engine is concerned?
==========
From 420048063e3fd2af1b019c48864d58d82cef62ef Mon Sep 17 00:00:00 2001
From: Mark Shoulson <mark@kli.org>
Date: Tue, 29 May 2012 23:01:12 -0400
Subject: [PATCH] Just barely works, nothing in the right places. For
entertainment purposes only.
---
contrib/lisp/org-e-html.el | 5 ++++
contrib/lisp/org-e-latex.el | 53 +++++++++++++++++++++----------------------
contrib/lisp/org-export.el | 52 ++++++++++++++++++++++++++++++++++++++++++
lisp/org.el | 50 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 133 insertions(+), 27 deletions(-)
diff --git a/contrib/lisp/org-e-html.el b/contrib/lisp/org-e-html.el
index de98493..b851713 100644
--- a/contrib/lisp/org-e-html.el
+++ b/contrib/lisp/org-e-html.el
@@ -1077,6 +1077,11 @@ in order to mimic default behaviour:
;;;; Plain text
+(defvar org-e-html-quote-replacements
+ '(("fr" "« " " »" "‘" "’" "’")
+ ("en" "“" "”" "‘" "’" "’")
+ ("de" "„" "“" "‚" "‘" "’"))
+
(defcustom org-e-html-quotes
'(("fr"
("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index 67e9197..540ebe1 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -687,6 +687,10 @@ during latex export it will output
;;;; Plain text
+(defvar org-e-latex-quote-replacements
+ '(("fr" "«~" "~»" "‹~" "~›" "/!")
+ ("en" "((" "))" ".(" ")." "/")))
+
(defcustom org-e-latex-quotes
'(("fr"
("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
@@ -699,25 +703,22 @@ during latex export it will output
"Alist for quotes to use when converting english double-quotes.
The CAR of each item in this alist is the language code.
-The CDR of each item in this alist is a list of three CONS:
-- the first CONS defines the opening quote;
-- the second CONS defines the closing quote;
-- the last CONS defines single quotes.
+The CDR of each item in this alist is a list of CONS:
+- the first CONS should define the opening quote;
+- the second CONS should define the closing quote;
+- subsequent CONS should define any other quotes, e.g. single, etc.
For each item in a CONS, the first string is a regexp
for allowed characters before/after the quote, the second
string defines the replacement string for this quote."
:group 'org-export-e-latex
- :type '(list
- (cons :tag "Opening quote"
- (string :tag "Regexp for char before")
- (string :tag "Replacement quote "))
- (cons :tag "Closing quote"
- (string :tag "Regexp for char after ")
- (string :tag "Replacement quote "))
- (cons :tag "Single quote"
- (string :tag "Regexp for char before")
- (string :tag "Replacement quote "))))
+ :type '(repeat
+ (cons
+ (string :tag "language code")
+ (repeat
+ (cons :tag "Quote"
+ (string :tag "Regexp ")
+ (string :tag "Replacement quote "))))))
;;;; Compilation
@@ -852,19 +853,17 @@ nil."
options
","))
-(defun org-e-latex--quotation-marks (text info)
- "Export quotation marks depending on language conventions.
-TEXT is a string containing quotation marks to be replaced. INFO
-is a plist used as a communication channel."
- (mapc (lambda(l)
- (let ((start 0))
- (while (setq start (string-match (car l) text start))
- (let ((new-quote (concat (match-string 1 text) (cdr l))))
- (setq text (replace-match new-quote t t text))))))
- (cdr (or (assoc (plist-get info :language) org-e-latex-quotes)
- ;; Falls back on English.
- (assoc "en" org-e-latex-quotes))))
- text)
+(defun org-e-latex--quotation-marks (text info)
+ (org-export-quotation-marks text info org-e-latex-quote-replacements))
+ ;; (mapc (lambda(l)
+ ;; (let ((start 0))
+ ;; (while (setq start (string-match (car l) text start))
+ ;; (let ((new-quote (concat (match-string 1 text) (cdr l))))
+ ;; (setq text (replace-match new-quote t t text))))))
+ ;; (cdr (or (assoc (plist-get info :language) org-e-latex-quotes)
+ ;; ;; Falls back on English.
+ ;; (assoc "en" org-e-latex-quotes))))
+ ;; text)
(defun org-e-latex--wrap-label (element output)
"Wrap label associated to ELEMENT around OUTPUT, if appropriate.
diff --git a/contrib/lisp/org-export.el b/contrib/lisp/org-export.el
index b9294e5..aacb448 100644
--- a/contrib/lisp/org-export.el
+++ b/contrib/lisp/org-export.el
@@ -284,6 +284,58 @@ rules.")
:tag "Org Export General"
:group 'org-export)
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+;; Probably a defcustom eventually.
+
+;; Each element of this consists of: car=language code, cdr=list of
+;; double-quote-open-regexp, double-quote-close-regexp,
+;; single-quote-open-regexp, single-quote-close-regexp, &optional
+;; single-apostrophe regexp?
+;; Just about all will be the same anyway, so mostly language DEFAULT.
+
+;; For testing purposes, poorly-designed at first.
+(defvar org-export-quotes-regexps
+ '((DEFAULT
+ "\\(?:\\s-\\|[[(]\\|^\\)\\(\"\\)\\w"
+ "\\(?:\\S-\\)\\(\"\\)\\s-"
+ "\\(?:\\s-\\|(\\|^\\)\\('\\)\\w"
+ "\\w\\('\\)\\(?:\\s-\\|\\s.\\|$\\)"
+ "\\w\\('\\)\\w")))
+
+;; Generic function, usable by exporters, but they can define their own
+;; instead.
+(defun org-export-quotation-marks (text info replacements)
+ "Export quotation marks depending on language conventions.
+TEXT is a string containing quotation marks to be replaced. INFO
+is a plist used as a communication channel."
+ (let* ((start 0)
+ (regexps
+ (cdr
+ (or
+ (assoc (plist-get info :language)
+ org-export-quotes-regexps)
+ (assoc 'DEFAULT org-export-quotes-regexps))))
+ (subs (cdr (or (assoc (plist-get info :language)
+ replacements)
+ (assoc "en" replacements))))
+ (quotes (pairlis regexps subs)))
+ (mapc (lambda (p)
+ (let ((re (car p))
+ (su (cdr p)))
+ (while (setq start (string-match re text start))
+ (setq text (replace-match su t t text 1)))))
+ quotes))
+ text)
+
+(defvar org-screen-smart-quotes
+ '(("en" "“" "”" "‘" "’" "’")
+ ("fr" "«" "»" "‹" "›" "’")
+ ("de" "„" "“" "‚" "’" "’")))
+
+
+
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
(defcustom org-export-with-archived-trees 'headline
"Whether sub-trees with the ARCHIVE tag should be exported.
diff --git a/lisp/org.el b/lisp/org.el
index 8a141cf..72bf4b0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5927,6 +5927,7 @@ needs to be inserted at a specific position in the
font-lock sequence.")
;; Specials
'(org-do-latex-and-special-faces)
'(org-fontify-entities)
+ '(org-fontify-quotes)
'(org-raise-scripts)
;; Code
'(org-activate-code (1 'org-code t))
@@ -5948,6 +5949,55 @@ needs to be inserted at a specific position in the
font-lock sequence.")
'(org-font-lock-keywords t nil nil backward-paragraph))
(kill-local-variable 'font-lock-keywords) nil))
+(defvar org-smart-quotes nil)
+(defvar org-smart-quotes-replacements
+ '("«" "»" "‹" "›" "’"))
+;; '("“" "”" "‘" "’" "’"))
+
+;; Nother idea, try this: like in original smart-quotes attempt.
+;; String all the regexps into one big regexp with \\| between them.
+;; Possibly have to parenthesize them but that's okay, since if
+;; each elt is in its own group, then those will be the odd-numbered groups
+;; and the inner group (of the actual quote) will be groups 2,4,6, etc.
+
+(defun splice-string (lst join)
+ (if (null (cdr lst)) (car lst)
+ (concat (car lst) join (splice-string (cdr lst) join))))
+
+(defun org-fontify-quotes (limit)
+ (require 'org-export)
+ (when org-smart-quotes
+ (let* ((start (point))
+ k su
+ (regexps
+ (cdr
+ (assoc 'DEFAULT org-export-quotes-regexps)))
+ (allreg (splice-string regexps "\\|"))
+ (quotes (pairlis regexps org-smart-quotes-replacements)))
+ ;; (message "%s" allreg)
+ (catch 'match
+ (while (re-search-forward allreg limit t)
+ (cond ((match-string 1)
+ (setq k 1 su (nth 0 org-smart-quotes-replacements)))
+ ((match-string 2)
+ (setq k 2 su (nth 1 org-smart-quotes-replacements)))
+ ((match-string 3)
+ (setq k 3 su (nth 2 org-smart-quotes-replacements)))
+ ((match-string 4)
+ (setq k 4 su (nth 3 org-smart-quotes-replacements)))
+ ((match-string 5)
+ (setq k 5 su (nth 4 org-smart-quotes-replacements)))
+ ;;(t
+ ;; (message "????")))
+ )
+ ;; (message "%s %s" k (match-data))
+ (add-text-properties (match-beginning k) (match-end k)
+ (list 'font-lock-fontified t
+ 'face 'org-warning))
+ (compose-region (match-beginning k) (match-end k) su nil)
+ (backward-char 1)
+ (throw 'match t))))))
+
(defun org-toggle-pretty-entities ()
"Toggle the composition display of entities as UTF8 characters."
(interactive)
--
1.7.7.6
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-05-31 1:50 ` (no subject) Mark Shoulson
@ 2012-05-31 13:38 ` Nicolas Goaziou
0 siblings, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2012-05-31 13:38 UTC (permalink / raw)
To: Mark Shoulson; +Cc: emacs-orgmode
Hello,
Mark Shoulson <mark@kli.org> writes:
> +(defvar org-e-html-quote-replacements
> + '(("fr" "« " " »" "‘" "’" "’")
> + ("en" "“" "”" "‘" "’" "’")
> + ("de" "„" "“" "‚" "‘" "’"))
A docstring will be required for this variable. It should be
a defcustom.
> +(defvar org-e-latex-quote-replacements
> + '(("fr" "«~" "~»" "‹~" "~›" "/!")
> + ("en" "((" "))" ".(" ")." "/")))
Ditto.
> (defcustom org-e-latex-quotes
> '(("fr"
> ("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
> @@ -699,25 +703,22 @@ during latex export it will output
> "Alist for quotes to use when converting english double-quotes.
>
> The CAR of each item in this alist is the language code.
> -The CDR of each item in this alist is a list of three CONS:
> -- the first CONS defines the opening quote;
> -- the second CONS defines the closing quote;
> -- the last CONS defines single quotes.
> +The CDR of each item in this alist is a list of CONS:
> +- the first CONS should define the opening quote;
> +- the second CONS should define the closing quote;
> +- subsequent CONS should define any other quotes, e.g. single, etc.
>
> For each item in a CONS, the first string is a regexp
> for allowed characters before/after the quote, the second
> string defines the replacement string for this quote."
> :group 'org-export-e-latex
> - :type '(list
> - (cons :tag "Opening quote"
> - (string :tag "Regexp for char before")
> - (string :tag "Replacement quote "))
> - (cons :tag "Closing quote"
> - (string :tag "Regexp for char after ")
> - (string :tag "Replacement quote "))
> - (cons :tag "Single quote"
> - (string :tag "Regexp for char before")
> - (string :tag "Replacement quote "))))
> + :type '(repeat
> + (cons
> + (string :tag "language code")
> + (repeat
> + (cons :tag "Quote"
> + (string :tag "Regexp ")
> + (string :tag "Replacement quote "))))))
The docstring is not valid. It's now an an alist whose key is the
language code and the value is a list of strings, not cons cells.
> +(defun org-e-latex--quotation-marks (text info)
> + (org-export-quotation-marks text info org-e-latex-quote-replacements))
> + ;; (mapc (lambda(l)
> + ;; (let ((start 0))
> + ;; (while (setq start (string-match (car l) text start))
> + ;; (let ((new-quote (concat (match-string 1 text) (cdr l))))
> + ;; (setq text (replace-match new-quote t t text))))))
> + ;; (cdr (or (assoc (plist-get info :language) org-e-latex-quotes)
> + ;; ;; Falls back on English.
> + ;; (assoc "en" org-e-latex-quotes))))
> + ;; text)
Use directly `org-e-latex-quote-replacements' in code then.
> +;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> +;; Probably a defcustom eventually.
> +
> +;; Each element of this consists of: car=language code, cdr=list of
> +;; double-quote-open-regexp, double-quote-close-regexp,
> +;; single-quote-open-regexp, single-quote-close-regexp, &optional
> +;; single-apostrophe regexp?
> +;; Just about all will be the same anyway, so mostly language DEFAULT.
> +
> +;; For testing purposes, poorly-designed at first.
> +(defvar org-export-quotes-regexps
> + '((DEFAULT
> + "\\(?:\\s-\\|[[(]\\|^\\)\\(\"\\)\\w"
> + "\\(?:\\S-\\)\\(\"\\)\\s-"
> + "\\(?:\\s-\\|(\\|^\\)\\('\\)\\w"
> + "\\w\\('\\)\\(?:\\s-\\|\\s.\\|$\\)"
> + "\\w\\('\\)\\w")))
I'm not sure this variable can be used for both the buffer and the
export engine. Export back-ends will only see chunks of the paragraph.
For example, in the following text,
He crossed the Rubicon and said: "/Alea jacta est./"
Plain text translators will see three strings:
1. "He crossed the Rubicon and said: \""
2. "Alea jacta est."
3. "\""
In case 1, you have an opening quote with nothing after it. In case 3,
you have a closing quote with nothing before or after it. Plain regexps
can't help here.
The only solution in can think of is to do quote substitutions in
paragraphs within the parse tree before they reach the translators (i.e.
with `org-export-filter-parse-tree-functions').
That's the only way to know if "\"" is an opening or a closing quote,
for example. The current approach won't work.
> +;; Generic function, usable by exporters, but they can define their own
> +;; instead.
> +(defun org-export-quotation-marks (text info replacements)
> + "Export quotation marks depending on language conventions.
> +TEXT is a string containing quotation marks to be replaced. INFO
> +is a plist used as a communication channel."
Please document each argument in the docstring.
> + (let* ((start 0)
> + (regexps
> + (cdr
> + (or
> + (assoc (plist-get info :language)
> + org-export-quotes-regexps)
> + (assoc 'DEFAULT org-export-quotes-regexps))))
Use `assq' instead of `assoc' in the second case.
> + (subs (cdr (or (assoc (plist-get info :language)
> + replacements)
> + (assoc "en" replacements))))
> + (quotes (pairlis regexps subs)))
> + (mapc (lambda (p)
> + (let ((re (car p))
> + (su (cdr p)))
> + (while (setq start (string-match re text start))
> + (setq text (replace-match su t t text 1)))))
Use `replace-regexp-in-string' instead.
(replace-regexp-in-string (car p) (cdr p) text t t 1)
> + quotes))
> + text)
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-08-24 16:21 Feiming Chen
0 siblings, 0 replies; 135+ messages in thread
From: Feiming Chen @ 2012-08-24 16:21 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 28 bytes --]
Sincerely,
Feiming Chen
[-- Attachment #2: Type: text/html, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-09-29 7:30 Neuwirth Erich
2012-09-29 7:39 ` Bastien
2012-09-29 9:52 ` Achim Gratz
0 siblings, 2 replies; 135+ messages in thread
From: Neuwirth Erich @ 2012-09-29 7:30 UTC (permalink / raw)
To: emacs-orgmode@gnu.org emacs-orgmode@gnu.org
I just did make up2
And on OSX 10.8.2 and Emacs 24.2 I get:
Ran 208 tests, 207 results as expected, 1 unexpected (2012-09-29 09:27:47+0200)
6 expected failures
1 unexpected results:
FAILED test-ob/org-babel-remove-result--results-org
make[1]: *** [test-dirty] Error 1
make: *** [up2] Error 2
Perhaps this is useful information
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-09-29 7:30 Neuwirth Erich
@ 2012-09-29 7:39 ` Bastien
2012-09-29 8:09 ` Achim Gratz
2012-09-29 9:52 ` Achim Gratz
1 sibling, 1 reply; 135+ messages in thread
From: Bastien @ 2012-09-29 7:39 UTC (permalink / raw)
To: Neuwirth Erich; +Cc: emacs-orgmode@gnu.org emacs-orgmode@gnu.org
Neuwirth Erich <erich.neuwirth@univie.ac.at> writes:
> 1 unexpected results:
> FAILED test-ob/org-babel-remove-result--results-org
Fixed, thanks.
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-09-29 7:39 ` Bastien
@ 2012-09-29 8:09 ` Achim Gratz
2012-09-29 9:12 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2012-09-29 8:09 UTC (permalink / raw)
To: emacs-orgmode
Bastien writes:
>> 1 unexpected results:
>> FAILED test-ob/org-babel-remove-result--results-org
>
> Fixed, thanks.
There are some tests that are supposed to have whitespace errors, based
on the comments in the file, but you've removed them along with all the
others. I've reverted that hunk of the commit.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-09-29 8:09 ` Achim Gratz
@ 2012-09-29 9:12 ` Bastien
0 siblings, 0 replies; 135+ messages in thread
From: Bastien @ 2012-09-29 9:12 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> There are some tests that are supposed to have whitespace errors, based
> on the comments in the file, but you've removed them along with all the
> others. I've reverted that hunk of the commit.
Thanks,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-09-29 7:30 Neuwirth Erich
2012-09-29 7:39 ` Bastien
@ 2012-09-29 9:52 ` Achim Gratz
1 sibling, 0 replies; 135+ messages in thread
From: Achim Gratz @ 2012-09-29 9:52 UTC (permalink / raw)
To: emacs-orgmode
Neuwirth Erich writes:
> Perhaps this is useful information
It would be more useful if the Org version you are trying to make was
included, but since it's probably not installed in lispdir yet, your
installed emacs would show a different version. So I've implemented a
new target `config-version´ to make this easy to produce with make…
org-mode> make config-version
========= Org version
make: Org-mode version 7.9.1 (release_7.9.1-442-g9ab8cb => /usr/local/share/emacs/site-lisp/org)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-11-07 18:50 Kevin Buchs
0 siblings, 0 replies; 135+ messages in thread
From: Kevin Buchs @ 2012-11-07 18:50 UTC (permalink / raw)
To: Org Mode
I would like to solve a problem I have: C-e (org-end-of-line) does not
move to the end of the line with long lines that are not headings. I
find myself wanting to get to the end of a long line often and have to
hit multiple C-e sequences to get there. I don't have the
org-special-ctrl-a/e set to non-nil. My line-move-visual value is the
default value of t, so I get the end-of-visual-line movement one
screen's worth. Before I start hacking, I thought I should be clear on
the design goals here. It seems as if the declaration of
line-move-visual says it is dealing with vertical motion, not
horizontal motion. I don't see any behavior elsewhere that uses the
interpretation that line-move-visual is for horizontal motion. Anyone
have thoughts on this subject?
BTW - I posted this back in May, but I neglected to keep the topic alive.
Kevin Buchs
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2012-11-11 15:36 Fabrice Popineau
2012-11-11 23:09 ` Nicolas Goaziou
0 siblings, 1 reply; 135+ messages in thread
From: Fabrice Popineau @ 2012-11-11 15:36 UTC (permalink / raw)
To: emacs-orgmode@gnu.org
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
I just updated a few hours ago with the git current version and I now get:
Debugger entered--Lisp error: (invalid-read-syntax "#")
eval-buffer(#<buffer *load*> nil "c:/Home/.org-timestamps/CQP-org.cache"
nil t) ; Reading at buffer position 621
load-with-code-conversion("c:/Home/.org-timestamps/CQP-org.cache"
"c:/Home/.org-timestamps/CQP-org.cache" nil nil)
load("c:/Home/.org-timestamps/CQP-org.cache" nil nil t)
load-file("c:/Home/.org-timestamps/CQP-org.cache")
Actually, the .cache file reads :
...
(puthash "c:/Home/Cours/CQP-ArTech/org/CQP-Artech-slides.org" '(:title
#("CQP-ArTech Slides" 0 17 (:parent (#("CQP-ArTech Slides" 0 17 (:parent
#3)))))) org-e-publish-cache)
...
I guess the #3 is the culprit. Any idea what went wrong?
Fabrice
[-- Attachment #2: Type: text/html, Size: 1077 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-11-11 15:36 Fabrice Popineau
@ 2012-11-11 23:09 ` Nicolas Goaziou
2012-11-12 7:40 ` Fabrice Popineau
0 siblings, 1 reply; 135+ messages in thread
From: Nicolas Goaziou @ 2012-11-11 23:09 UTC (permalink / raw)
To: Fabrice Popineau; +Cc: emacs-orgmode@gnu.org
Hello,
Fabrice Popineau <fabrice.popineau@gmail.com> writes:
> I just updated a few hours ago with the git current version and I now get:
>
> Debugger entered--Lisp error: (invalid-read-syntax "#")
> eval-buffer(#<buffer *load*> nil "c:/Home/.org-timestamps/CQP-org.cache"
> nil t) ; Reading at buffer position 621
> load-with-code-conversion("c:/Home/.org-timestamps/CQP-org.cache"
> "c:/Home/.org-timestamps/CQP-org.cache" nil nil)
> load("c:/Home/.org-timestamps/CQP-org.cache" nil nil t)
> load-file("c:/Home/.org-timestamps/CQP-org.cache")
>
> Actually, the .cache file reads :
>
> ...
> (puthash "c:/Home/Cours/CQP-ArTech/org/CQP-Artech-slides.org" '(:title
> #("CQP-ArTech Slides" 0 17 (:parent (#("CQP-ArTech Slides" 0 17 (:parent
> #3)))))) org-e-publish-cache)
> ...
>
> I guess the #3 is the culprit. Any idea what went wrong?
To sum it up, I added :parent property to each string but org-e-publish
tries to store them in the cache, which is impossible since cache is
eventually written to a file.
I have pushed a fix for that problem. Is it correct now?
Thanks for submitting this.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2012-11-11 23:09 ` Nicolas Goaziou
@ 2012-11-12 7:40 ` Fabrice Popineau
0 siblings, 0 replies; 135+ messages in thread
From: Fabrice Popineau @ 2012-11-12 7:40 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Seems to be ok on my side.
I wonder if my problem could have been triggered by the fact I had a
spurious file in the way of the (new) exporter: I had a foo.org file
exported to some other directory, but also a foo.html in the source
directory that had to be copied to the target directory by another
dependency of the project.
Thanks anyway for taking care of this.
Fabrice
2012/11/12 Nicolas Goaziou <n.goaziou@gmail.com>
> Hello,
>
> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
>
> > I just updated a few hours ago with the git current version and I now
> get:
> >
> > Debugger entered--Lisp error: (invalid-read-syntax "#")
> > eval-buffer(#<buffer *load*> nil
> "c:/Home/.org-timestamps/CQP-org.cache"
> > nil t) ; Reading at buffer position 621
> > load-with-code-conversion("c:/Home/.org-timestamps/CQP-org.cache"
> > "c:/Home/.org-timestamps/CQP-org.cache" nil nil)
> > load("c:/Home/.org-timestamps/CQP-org.cache" nil nil t)
> > load-file("c:/Home/.org-timestamps/CQP-org.cache")
> >
> > Actually, the .cache file reads :
> >
> > ...
> > (puthash "c:/Home/Cours/CQP-ArTech/org/CQP-Artech-slides.org" '(:title
> > #("CQP-ArTech Slides" 0 17 (:parent (#("CQP-ArTech Slides" 0 17 (:parent
> > #3)))))) org-e-publish-cache)
> > ...
> >
> > I guess the #3 is the culprit. Any idea what went wrong?
>
> To sum it up, I added :parent property to each string but org-e-publish
> tries to store them in the cache, which is impossible since cache is
> eventually written to a file.
>
> I have pushed a fix for that problem. Is it correct now?
>
> Thanks for submitting this.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
[-- Attachment #2: Type: text/html, Size: 2440 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2013-01-15 19:26 Rick Frankel
0 siblings, 0 replies; 135+ messages in thread
From: Rick Frankel @ 2013-01-15 19:26 UTC (permalink / raw)
To: emacs-orgmode
From 8aca214f0aefe3d89162115b9d241766ae62c5c1 Mon Sep 17 00:00:00 2001
From: Rick Frankel <org@rickster.com>
Date: Fri, 11 Jan 2013 13:41:10 -0500
Subject: [PATCH] ob-tangle: Correctly process tangling of single source block
* lisp/ob-tangle.el
(org-babel-tangle):
- remove un-executed attempt to ask user for file-name if
tangling a single block (`:tangle' always has a value)
- change handling of block accumulation
(org-babel-tangle-collect-block): new function to collect a single block
When attempting to tangle a single block, `org-babel-tangle' would use
`narrow-to-region', causing any header arguments not on the
"#+BEGIN_SRC" line to be excluded from the tangled file.
---
lisp/ob-tangle.el | 166 +++++++++++++++++++++++++++++-------------------------
1 file changed, 90 insertions(+), 76 deletions(-)
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 0db4335..725d3af 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -192,18 +192,16 @@ source blocks. Optional argument LANG can be used to limit the
exported source code blocks by language."
(interactive "P")
(run-hooks 'org-babel-pre-tangle-hook)
- ;; possibly restrict the buffer to the current code block
(save-restriction
- (when only-this-block
- (unless (org-babel-where-is-src-block-head)
- (error "Point is not currently inside of a code block"))
- (save-match-data
- (unless (or (cdr (assoc :tangle (nth 2 (org-babel-get-src-block-info))))
- target-file)
- (setq target-file
- (read-from-minibuffer "Tangle to: " (buffer-file-name)))))
- (narrow-to-region (match-beginning 0) (match-end 0)))
(save-excursion
+ ;; check if tangle restricted to the current code block and
+ ;; move to beginning of block so begin_src line not
+ ;; included in commments
+ (when only-this-block
+ (let ((head (org-babel-where-is-src-block-head)))
+ (if head
+ (goto-char head)
+ (error "Point is not currently inside of a code block"))))
(let ((block-counter 0)
(org-babel-default-header-args
(if target-file
@@ -270,7 +268,9 @@ exported source code blocks by language."
(setq block-counter (+ 1 block-counter))
(add-to-list 'path-collector file-name)))))
specs)))
- (org-babel-tangle-collect-blocks lang))
+ (if only-this-block
+ (org-babel-tangle-collect-block 1 t)
+ (org-babel-tangle-collect-blocks lang)))
(message "Tangled %d code block%s from %s" block-counter
(if (= block-counter 1) "" "s")
(file-name-nondirectory
@@ -353,7 +353,7 @@ Return an association list of source-code block specifications of
the form used by `org-babel-spec-to-string' grouped by language.
Optional argument LANG can be used to limit the collected source
code blocks by language."
- (let ((block-counter 1) (current-heading "") blocks)
+ (let ((block-counter 1) (current-heading "") blocks by-lang)
(org-babel-map-src-blocks (buffer-file-name)
((lambda (new-heading)
(if (not (string= new-heading current-heading))
@@ -366,73 +366,18 @@ code blocks by language."
(or (nth 4 (org-heading-components))
"(dummy for heading without text)")
(error (buffer-file-name)))))
- (let* ((start-line (save-restriction (widen)
- (+ 1 (line-number-at-pos (point)))))
- (file (buffer-file-name))
- (info (org-babel-get-src-block-info 'light))
+ (let* ((info (org-babel-get-src-block-info 'light))
(src-lang (nth 0 info)))
(unless (string= (cdr (assoc :tangle (nth 2 info))) "no")
(unless (and language (not (string= language src-lang)))
- (let* ((info (org-babel-get-src-block-info))
- (params (nth 2 info))
- (link ((lambda (link)
- (and (string-match org-bracket-link-regexp link)
- (match-string 1 link)))
- (org-no-properties
- (org-store-link nil))))
- (source-name
- (intern (or (nth 4 info)
- (format "%s:%d"
- current-heading block-counter))))
- (expand-cmd
- (intern (concat "org-babel-expand-body:" src-lang)))
- (assignments-cmd
- (intern (concat "org-babel-variable-assignments:" src-lang)))
- (body
- ((lambda (body) ;; run the tangle-body-hook
- (with-temp-buffer
- (insert body)
- (run-hooks 'org-babel-tangle-body-hook)
- (buffer-string)))
- ((lambda (body) ;; expand the body in language specific manner
- (if (assoc :no-expand params)
- body
- (if (fboundp expand-cmd)
- (funcall expand-cmd body params)
- (org-babel-expand-body:generic
- body params
- (and (fboundp assignments-cmd)
- (funcall assignments-cmd params))))))
- (if (org-babel-noweb-p params :tangle)
- (org-babel-expand-noweb-references info)
- (nth 1 info)))))
- (comment
- (when (or (string= "both" (cdr (assoc :comments params)))
- (string= "org" (cdr (assoc :comments params))))
- ;; from the previous heading or code-block end
- (funcall
- org-babel-process-comment-text
- (buffer-substring
- (max (condition-case nil
- (save-excursion
- (org-back-to-heading t) ; sets match data
- (match-end 0))
- (error (point-min)))
- (save-excursion
- (if (re-search-backward
- org-babel-src-block-regexp nil t)
- (match-end 0)
- (point-min))))
- (point)))))
- by-lang)
- ;; add the spec for this block to blocks under it's language
- (setq by-lang (cdr (assoc src-lang blocks)))
- (setq blocks (delq (assoc src-lang blocks) blocks))
- (setq blocks (cons
- (cons src-lang
- (cons (list start-line file link
- source-name params body comment)
- by-lang)) blocks)))))))
+ ;; add the spec for this block to blocks under it's language
+ (setq by-lang (cdr (assoc src-lang blocks)))
+ (setq blocks (delq (assoc src-lang blocks) blocks))
+ (setq blocks (cons
+ (cons src-lang
+ (cons
+ (org-babel-tangle-collect-block
+ block-counter) by-lang)) blocks))))))
;; ensure blocks in the correct order
(setq blocks
(mapcar
@@ -440,6 +385,75 @@ code blocks by language."
blocks))
blocks))
+(defun org-babel-tangle-collect-block
+ (block-counter &optional only-this-block)
+ "Collect tangled source for current block.
+Returns list of block attributes needed by
+`org-babel-tangle-collect-blocks'. If ONLY-THIS-BLOCK is set,
+then return full association list in format needed for
+`org-babel-tangle' directly."
+ (let* ((info (org-babel-get-src-block-info))
+ (start-line
+ (save-restriction (widen)
+ (+ 1 (line-number-at-pos (point)))))
+ (file (buffer-file-name))
+ (src-lang (nth 0 info))
+ (params (nth 2 info))
+ (link ((lambda (link)
+ (and (string-match org-bracket-link-regexp link)
+ (match-string 1 link)))
+ (org-no-properties
+ (org-store-link nil))))
+ (source-name
+ (intern (or (nth 4 info)
+ (format "%s:%d" (nth 4 (org-heading-components))
+ block-counter))))
+ (expand-cmd
+ (intern (concat "org-babel-expand-body:" src-lang)))
+ (assignments-cmd
+ (intern (concat "org-babel-variable-assignments:" src-lang)))
+ (body
+ ((lambda (body) ;; run the tangle-body-hook
+ (with-temp-buffer
+ (insert body)
+ (run-hooks 'org-babel-tangle-body-hook)
+ (buffer-string)))
+ ((lambda (body) ;; expand the body in language specific manner
+ (if (assoc :no-expand params)
+ body
+ (if (fboundp expand-cmd)
+ (funcall expand-cmd body params)
+ (org-babel-expand-body:generic
+ body params
+ (and (fboundp assignments-cmd)
+ (funcall assignments-cmd params))))))
+ (if (org-babel-noweb-p params :tangle)
+ (org-babel-expand-noweb-references info)
+ (nth 1 info)))))
+ (comment
+ (when (or (string= "both" (cdr (assoc :comments params)))
+ (string= "org" (cdr (assoc :comments params))))
+ ;; from the previous heading or code-block end
+ (funcall
+ org-babel-process-comment-text
+ (buffer-substring
+ (max (condition-case nil
+ (save-excursion
+ (org-back-to-heading t) ; sets match data
+ (match-end 0))
+ (error (point-min)))
+ (save-excursion
+ (if (re-search-backward
+ org-babel-src-block-regexp nil t)
+ (match-end 0)
+ (point-min))))
+ (point)))))
+ (result
+ (list start-line file link source-name params body comment)))
+ (if only-this-block
+ (list (cons src-lang (list result)))
+ result)))
+
(defun org-babel-tangle-comment-links ( &optional info)
"Return a list of begin and end link comments for the code block at point."
(let* ((start-line (org-babel-where-is-src-block-head))
--
1.8.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* (no subject)
@ 2013-01-24 12:11 Herbert Sitz
0 siblings, 0 replies; 135+ messages in thread
From: Herbert Sitz @ 2013-01-24 12:11 UTC (permalink / raw)
To: noel, nonka1717, nonaadams, PDR, molver, orderhelp, emacs-orgmode,
pariss, patricks
http://hickorystreetlounge.com/wp-content/plugins/zajvtixgeoo/yahool321.php
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2013-01-29 9:43 Martin Beck
2013-01-30 12:12 ` Bernt Hansen
0 siblings, 1 reply; 135+ messages in thread
From: Martin Beck @ 2013-01-29 9:43 UTC (permalink / raw)
To: emacs orgmode-mailinglist
[-- Attachment #1: Type: text/html, Size: 772 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-01-29 9:43 Martin Beck
@ 2013-01-30 12:12 ` Bernt Hansen
0 siblings, 0 replies; 135+ messages in thread
From: Bernt Hansen @ 2013-01-30 12:12 UTC (permalink / raw)
To: Martin Beck; +Cc: emacs orgmode-mailinglist
"Martin Beck" <elwood151@web.de> writes:
> I'm trying to create a custom agenda setup for my org-mode and I wonder how I can sort the agenda-items by date (Scheduled
> or deadline): newest first.
>
> I only found time-up / time-down in the parameters, but that does not seem to do what I need.
>
> Another important point would be how to handle items with no scheduled/date or deadline.. they should be placed at the end
> of the list.
>
> I've been searching some time but did not find a solution. :-(
Hi Martin,
I sort my daily agenda items specifically using a bunch of complicated
sorting functions. They are all documented here:
http://doc.norang.ca/org-mode.html#AgendaViewTweaks
HTH,
Bernt
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2013-03-03 0:55 Vikas Rawal
0 siblings, 0 replies; 135+ messages in thread
From: Vikas Rawal @ 2013-03-03 0:55 UTC (permalink / raw)
To: emacs-orgmode
>
> You may be using an outdated version (maint branch?). Otherwise, latex
> back-end may not be loaded, but it is by default (see
> `org-export-backends').
I am using 7.9.3f updated using orgmode elpa repository. Is that a
problem?
Vikas
^ permalink raw reply [flat|nested] 135+ messages in thread
* [RFC] Org syntax (draft)
@ 2013-03-07 20:37 Nicolas Goaziou
2013-03-07 20:47 ` Carsten Dominik
` (7 more replies)
0 siblings, 8 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-07 20:37 UTC (permalink / raw)
To: Org Mode List
Hello,
As discussed a few days ago, here is a document describing the complete
Org syntax as read by the parser. I also added some comments. I am going
to put the Org file on Worg, so anyone can update it and fix mistakes.
━━━━━━━━━━━━━━━━━━━━
ORG SYNTAX (DRAFT)
━━━━━━━━━━━━━━━━━━━━
Table of Contents
─────────────────
1 Headlines and Sections
2 Affiliated Keywords
3 Greater Elements
.. 3.1 Greater Blocks
.. 3.2 Drawers and Property Drawers
.. 3.3 Dynamic Blocks
.. 3.4 Footnote Definitions
.. 3.5 Inlinetasks
.. 3.6 Plain Lists and Items
.. 3.7 Tables
4 Elements
.. 4.1 Babel Call
.. 4.2 Blocks
.. 4.3 Clock, Diary Sexp and Planning
.. 4.4 Comments
.. 4.5 Fixed Width Areas
.. 4.6 Horizontal Rules
.. 4.7 Keywords
.. 4.8 LaTeX Environments
.. 4.9 Node Properties
.. 4.10 Paragraphs
.. 4.11 Table Rows
5 Objects
.. 5.1 Entities and LaTeX Fragments
.. 5.2 Export Snippets
.. 5.3 Footnote References
.. 5.4 Inline Babel Calls and Source Blocks
.. 5.5 Line Breaks
.. 5.6 Links
.. 5.7 Macros
.. 5.8 Targets and Radio Targets
.. 5.9 Statistics Cookies
.. 5.10 Subscript and Superscript
.. 5.11 Table Cells
.. 5.12 Timestamps
.. 5.13 Text Markup
This document describes and comments Org syntax as it is currently read
by its parser (Org Elements) and, therefore, by the export framework.
It also includes a few comments on that syntax.
A core concept in this syntax is that only headlines and sections are
context-free[1][2]. Every other syntactical part only exists within
specific environments.
Three categories are used to classify these environments: “Greater
elements”, “elements”, and “objects”, from the broadest scope to the
narrowest.
The paragraph is the unit of measurement. An element defines
syntactical parts that are at the same level as a paragraph, i.e. which
cannot contain or be included in a paragraph. An object is a part that
could be included in an element. Greater elements are all parts that
can contain an element.
Empty lines belong to the largest element ending before them. For
example, in a list, empty lines between items belong are part of the
item before them, but empty lines at the end of a list belong to the
plain list element.
Unless specified otherwise, case is not significant.
1 Headlines and Sections
════════════════════════
A headline is defined as:
╭────
│ STARS KEYWORD PRIORITY TITLE TAGS
╰────
STARS is a string starting at column 0 and containing at least one
asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
library is loaded). It’s the sole compulsory part of a headline.
KEYWORD is a TODO keyword, which have to belong to the list defined in
`org-todo-keywords'. Case is significant.
PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
sign # and enclosed within square brackets. Case is significant.
TITLE can be made of any character but a new line. Though, it will
match after every other part have been matched.
TAGS is made of words containing any alpha-numeric character,
underscore, at sign, hash sign or percent sign, and separated with
colons.
Examples of valid headlines include:
╭────
│ *
│
│ ** DONE
│
│ *** Some e-mail
│
│ **** TODO [#A] COMMENT Title :tag:a2%:
╰────
If the first word appearing in the title is `org-comment-keyword', the
headline will be considered as “commented”. If that first word is
`org-quote-string', it will be considered as “quoted”. In both
situations, case is significant.
If its title is `org-footnote-section', it will be considered as
a “footnote section”. Case is significant.
If `org-archive-tag' is one of its tags, it will be considered as
“archived”. Case is significant.
A headline contains directly at most one section, followed by any
number of headlines. Only a section can contain another section.
A section contains directly any greater element or element. Only
a headline can contain a section. As an exception, text before the
first headline in the document also belongs to a section.
In a quoted headline contains a section, the latter will be considered
as a “quote section”.
As an example, consider the following document:
╭────
│ An introduction.
│
│ * A Headline
│
│ Some text.
│
│ ** Sub-Topic 1
│
│ ** Sub-Topic 2
│
│ *** Additional entry
│
│ ** QUOTE Another Sub-Topic
│
│ Some other text.
╰────
Its internal structure could be summarized as:
╭────
│ (document
│ (section)
│ (headline
│ (section)
│ (headline)
│ (headline
│ (headline))
│ (headline
│ (quote-section))))
╰────
2 Affiliated Keywords
═════════════════════
With the exception of [inlinetasks], [items], [planning], [clocks],
[node properties] and [table rows], every other element type can be
assigned attributes.
This is done by adding specific keywords, named “affiliated keywords”,
just above the element considered, no blank line allowed.
Affiliated keywords are built upon one of the following patterns:
“#+KEY: VALUE”, “#+KEY[OPTIONAL]: VALUE” or “#+ATTR_BACKEND: VALUE”.
KEY is either “CAPTION”, “HEADER”, “NAME”, “PLOT” or “RESULTS” string.
BACKEND is a string constituted of alpha-numeric characters, hyphens
or underscores.
OPTIONAL and VALUE can contain any character but a new line. Only
keywords in `org-element-dual-keywords' can have an optional value.
An affiliated keyword can appear on multiple lines if KEY belongs to
`org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
VALUE”.
Affiliated keywords whose KEY belong to `org-element-parsed-keywords'
can contain objects in their value and their optional value, if
applicable.
[inlinetasks] See section 3.5
[items] See section 3.6
[planning] See section 4.3
[clocks] See section 4.3
[node properties] See section 4.9
[table rows] See section 4.11
3 Greater Elements
══════════════════
Unless specified otherwise, greater elements can contain directly any
other element or greater element excepted:
• elements of their own type,
• [node properties], which can only be found in [property drawers],
• [items], which can only be found in [plain lists].
[node properties] See section 4.9
[property drawers] See section 3.2
[items] See section 3.6
[plain lists] See section 3.6
3.1 Greater Blocks
──────────────────
Greater blocks consist in the following pattern:
╭────
│ #+BEGIN_NAME PARAMETERS
│ CONTENTS
│ #+END_NAME
╰────
NAME can contain any non-whitespace character.
PARAMETERS can contain any character, and can be omitted.
If NAME is “CENTER”, it will be a “center block”. If it is “QUOTE”,
it will be a “quote block”.
If the block is neither a center block, a quote block or a [block
element], it will be a “special block”.
CONTENTS can contain any element, but another greater block of the
same type.
[block element] See section 4.2
3.2 Drawers and Property Drawers
────────────────────────────────
Pattern for drawers is:
╭────
│ :NAME:
│ CONTENTS
│ :END:
╰────
NAME has to either be “PROPERTIES” or belong to `org-drawers' list.
If NAME is “PROPERTIES”, the drawer will become a “property drawer”.
In a property drawers, CONTENTS can only contain [node property]
elements. Otherwise it can contain any element but another drawer or
property drawer.
―――――
It would be nice if users hadn’t to register drawers names before
using them in `org-drawers' (or through the `#+DRAWERS:' keyword).
Anything starting with `^[ \t]*:\w+:[ \t]$' and ending with
`^[ \t]*:END:[ \t]$' could be considered as a drawer. — ngz
[node property] See section 4.9
3.3 Dynamic Blocks
──────────────────
Pattern for dynamic blocks is:
╭────
│ #+BEGIN: NAME PARAMETERS
│ CONTENTS
│ #+END:
╰────
NAME cannot contain any whitespace character.
PARAMETERS can contain any character and can be omitted.
3.4 Footnote Definitions
────────────────────────
Pattern for footnote definitions is:
╭────
│ [LABEL] CONTENTS
╰────
It must start at column 0.
LABEL is either a number or follows the pattern “fn:WORD”, where word
can contain any word-constituent character, hyphens and underscore
characters.
CONTENTS can contain any element excepted another footnote definition.
It ends at the next footnote definition, the next headline, two
consecutive empty lines or the end of buffer.
3.5 Inlinetasks
───────────────
Inlinetasks are defined by `org-inlinetask-min-level' contiguous
asterisk characters starting at column 0, followed by a whitespace
character.
Optionally, inlinetasks can be ended with a string constituted of
`org-inlinetask-min-level' contiguous characters starting at column 0,
followed by a space and the “END” string.
Inlinetasks are recognized only after `org-inlinetask' library is
loaded.
3.6 Plain Lists and Items
─────────────────────────
Items are defined by a line starting with the following pattern:
“BULLET COUNTER-SET CHECK-BOX TAG”, in which only BULLET is mandatory.
BULLET is either an asterisk, a hyphen, a plus sign character or
follows either the pattern “COUNTER.” or “COUNTER)". In any case,
BULLET is follwed by a whitespace character or line ending.
COUNTER can be a number or a single letter.
COUNTER-SET follows the pattern [@COUNTER].
CHECK-BOX is either a single whitespace character, a “X” character or
a hyphen, enclosed within square brackets.
TAG follows “TAG-TEXT ::” pattern, where TAG-TEXT can contain any
character but a new line.
An item ends before the next item, the first line less or equally
indented than its starting line, or two consecutive empty lines.
Indentation of lines within other greater elements do not count,
neither do inlinetasks boundaries.
A plain list is a set of consecutive items of the same indentation.
It can only directly contain items.
If first item in a plain list has a counter in its bullet, the plain
list will be an “ordered plain-list”. If it contains a tag, it will
be a “descriptive list”. Otherwise, it will be an “unordered list”.
List types are mutually exclusive.
For example, consider the following excerpt of an Org document:
╭────
│ 1. item 1
│ 2. [X] item 2
│ - some tag :: item 2.1
╰────
Its internal structure is as follows:
╭────
│ (ordered-plain-list
│ (item)
│ (item
│ (descriptive-plain-list
│ (item))))
╰────
3.7 Tables
──────────
Tables start at lines beginning with either a vertical bar or the “+-”
string followed by plus or minus signs only, assuming they are not
preceded with lines of the same type. These lines can be indented.
A table starting with a vertical bar has “org” type. Otherwise it has
“table.el” type.
Org tables end at the first line not starting with a vertical bar.
Table.el tables end at the first line not starting with either
a vertical line or a plus sign. Such lines can be indented.
An org table can only contain table rows. A table.el table does not
contain anything.
4 Elements
══════════
Elements cannot contain any other element.
Only [keywords] whose name belongs to
`org-element-document-properties', [verse blocks] , [paragraphs] and
[table rows] can contain objects.
[keywords] See section 4.7
[verse blocks] See section 4.2
[paragraphs] See section 4.10
[table rows] See section 4.11
4.1 Babel Call
──────────────
Pattern for babel calls is:
╭────
│ #+CALL: VALUE
╰────
VALUE is optional. It can contain any character but a new line.
4.2 Blocks
──────────
Like [greater blocks], pattern for blocks is:
╭────
│ #+BEGIN_NAME DATA
│ CONTENTS
│ #+END_NAME
╰────
NAME cannot contain any whitespace character.
If NAME is “COMMENT”, it will be a “comment block”. If it is
“EXAMPLE”, it will be an “example block”. If it is “SRC”, it will be
a “source block”. If it is “VERSE”, it will be a “verse block”.
If NAME is a string matching the name of any export back-end loaded,
the block will be an “export block”.
DATA can contain any character but a new line. It can be ommitted,
unless the block is a “source block”. In this case, it must follow
the pattern “LANGUAGE SWITCHES ARGUMENTS”, where SWITCHES and
ARGUMENTS are optional.
LANGUAGE cannot contain any whitespace character.
SWITCHES is made of any number of “SWITCH” patterns, separated by
blank lines.
A SWITCH pattern is either “-l “FORMAT"", where FORMAT can contain any
character but a double quote and a new line, “-S” or “+S”, where
S stands for a single letter.
ARGUMENTS can contain any character but a new line.
CONTENTS can contain any character, including new lines. Though it
will only contain Org objects if the block is a verse block.
Otherwise, contents will not be parsed.
[greater blocks] See section 3.1
4.3 Clock, Diary Sexp and Planning
──────────────────────────────────
A clock follows the pattern:
╭────
│ CLOCK: TIMESTAMP DURATION
╰────
Both TIMESTAMP and DURATION are optional.
TIMESTAMP is a [timestamp] object.
DURATION follows the pattern:
╭────
│ => HH:MM
╰────
HH is a number containing any number of digits. MM is a two digit
numbers.
A diary sexp is a line starting at column 0 with “%%(" string. It can
then contain any character besides a new line.
A planning is a line filled with more at most three INFO parts, where
each INFO part follows the pattern:
╭────
│ KEYWORD: TIMESTAMP
╰────
KEYWORD is a string among `org-deadline-string',
`org-scheduled-string' and `org-closed-string'. TIMESTAMP is is
a [timestamp] object.
Even though a planning element can exist anywhere in a section or
a greater element, it will only affect the headline containing the
section if it is put on the line following that headline.
[timestamp] See section 5.12
4.4 Comments
────────────
A “comment line” starts with a hash signe and a whitespace character
or an end of line.
Comments can contain any number of consecutive comment lines.
4.5 Fixed Width Areas
─────────────────────
A “fixed-width line” start with a colon character and a whitespace or
an end of line.
Fixed width areas can contain any number of consecutive fixed-width
lines.
4.6 Horizontal Rules
────────────────────
A horizontal rule is a line made of at least 5 consecutive hyphens.
It can be indented.
4.7 Keywords
────────────
Keywords follow the syntax:
╭────
│ #+KEY: VALUE
╰────
KEY can contain any non-whitespace character, but it cannot be equal
to “CALL” or any affiliated keyword.
VALUE can contain any character excepted a new line.
If KEY belongs to `org-element-document-properties', VALUE can contain
objects.
4.8 LaTeX Environments
──────────────────────
Pattern for LaTeX environments is:
╭────
│ \begin{NAME}
│ CONTENTS
│ \end{NAME}
╰────
NAME is constituted of alpha-numeric characters and may end with an
asterisk.
CONTENTS can contain anything but the “\end{NAME}” string.
4.9 Node Properties
───────────────────
Patter for node properties is:
╭────
│ :PROPERTY: VALUE
╰────
PROPERTY can contain any non-whitespace character. VALUE can contain
any character but a new line.
Node properties can only exist in a [property drawers].
[property drawers] See section 3.2
4.10 Paragraphs
───────────────
Paragraphs are the default element, which means that any unrecognized
context is a paragraph.
Empty lines and other elements end paragraphs.
Paragraphs can contain every type of object.
4.11 Table Rows
───────────────
A table rows is either constituted of a vertical bar and any number of
[table cells] or a vertical bar followed by a hyphen.
In the first case the table row has the “standard” type. In the
second case, it has the “rule” type.
Table rows can only exist in [tables].
[table cells] See section 5.11
[tables] See section 3.7
5 Objects
═════════
Objects can only be found in the following locations:
• [affiliated keywords] defined in `org-element-parsed-keywords',
• [document properties],
• [headline] titles,
• [inlinetask] titles,
• [item] tags,
• [paragraphs],
• [table cells],
• [table rows], which can only contain table cell objects,
• [verse blocks].
Most objects cannot contain objects. Those which can will be
specified.
[affiliated keywords] See section 2
[document properties] See section 4.7
[headline] See section 1
[inlinetask] See section 3.5
[item] See section 3.6
[paragraphs] See section 4.10
[table cells] See section 5.11
[table rows] See section 4.11
[verse blocks] See section 4.2
5.1 Entities and LaTeX Fragments
────────────────────────────────
An entity follows the pattern:
╭────
│ \NAME POST
╰────
where NAME has a valid association in either `org-entities' or
`org-entities-user'.
POST is the end of line, "{}" string, or a non-alphabetical character.
It isn’t separated from NAME by a whitespace character.
A LaTeX fragment can follow multiple patterns:
╭────
│ \NAME POST
│ \(CONTENTS\)
│ \[CONTENTS\]
│ $$CONTENTS$$
│ PRE$CHAR$POST
│ PRE$BORDER1 BODY BORDER2$
╰────
NAME contains alphabetical characters only and must not have an
association in either `org-entities' or `org-entities-user'.
POST is the same as for entities.
CONTENTS can contain any character but cannot contain “\)" in the
second template or “\]" in the third one.
PRE is either the beginning of line or a character different from `$'.
CHAR is a non-whitespace character different from `.', ~,~, `?', `;',
~’~ or a double quote.
POST is any of `-', `.', ~,~, `?', `;', `:', ~’~, a double quote,
a whitespace character and the end of line.
BORDER1 is a non-whitespace character different from `.', `;', `.'
and `$'.
BODY can contain any character excepted `$', and may not span over
more than 3 lines.
BORDER2 is any non-whitespace character different from ~,~, `.' and
`$'.
―――――
It would introduce incompatibilities with previous Org
versions, but support for “$…$” (and for symmetry,
`$$...$$') constructs ought to be removed.
They are slow to parse, fragile, redundant, imply false
positives and do not look good in LaTeX output anyway.
Even the LaTeX community suggests to use `\(...\)' over
`$...$'. — ngz
5.2 Export Snippets
───────────────────
Patter for export snippets is:
╭────
│ @@NAME:VALUE@@
╰────
NAME can contain any alpha-numeric character and hyphens.
VALUE can contain anything but “@@” string.
5.3 Footnote References
───────────────────────
There are four patterns for footnote references:
╭────
│ [MARK]
│ [fn:LABEL]
│ [fn:LABEL:DEFINITION]
│ [fn::DEFINITION]
╰────
MARK is a number.
LABEL can contain any word constituent character, hyphens and
underscores.
DEFINITION can contain any character. Though opening and closing
square brackets must be balanced in it. It can contain any object
encountered in a paragraph, even other footnote references.
If the reference follows the third pattern, it is called an “inline
footnote”. If it follows the fourth one, i.e. if LABEL is omitted, it
is an “anonymous footnote”.
5.4 Inline Babel Calls and Source Blocks
────────────────────────────────────────
Inline Babel calls follow any of the following patterns:
╭────
│ call_NAME(ARGUMENTS)
│ call_NAME[HEADER](ARGUMENTS)[HEADER]
╰────
NAME can contain any character besides `(', `)' and “\n”.
HEADER can contain any character besides `]' and “\n”.
ARGUMENTS can contain any character besides `)' and “\n”.
Inline source blocks follow any of the following patterns:
╭────
│ src_LANG{BODY}
│ src_LANG[OPTIONS]{BODY}
╰────
LANG can contain any non-whitespace character.
OPTIONS and BODY can contain any character but “\n”.
5.5 Line Breaks
───────────────
A line break consists in “\\SPACE” pattern at the end of an otherwise
non-empty line.
SPACE can contain any number of tabs and spaces, including 0.
5.6 Links
─────────
There are 4 major types of links:
╭────
│ RADIO ("radio" link)
│ <PROTOCOL:PATH> ("angle" link)
│ PRE PROTOCOL:PATH2 POST ("plain" link)
│ [[PATH3]DESCRIPTION] ("regular" link)
╰────
RADIO is a string matched by some [radio target]. It can contain
[entities], [latex fragments], [subscript] and [superscript] only.
PROTOCOL is a string among `org-link-types'.
PATH can contain any character but `]', `<', `>' and `\n'.
PRE and POST are non word constituent. They can be, respectively, the
beginning or the end of a line.
PATH2 can contain any non-whitespace character excepted `(', `)', `<'
and `>'. It must end with a word-constituent character, or any
non-whitespace non-punctuation character followed by `/'.
DESCRIPTION must be enclosed within square brackets. It can contain
any character but square brackets. Object-wise, it can contain any
object found in a paragraph excepted a [footnote reference], a [radio
target] and a [line break]. It cannot contain another link either,
unless it is a plain link.
DESCRIPTION is optional.
PATH3 is built according to the following patterns:
╭────
│ FILENAME ("file" type)
│ PROTOCOL:PATH4 ("PROTOCOL" type)
│ id:ID ("id" type)
│ #CUSTOM-ID ("custom-id" type)
│ (CODEREF) ("coderef" type)
│ FUZZY ("fuzzy" type)
╰────
FILENAME is a file name, either absolute or relative.
PATH4 can contain any character besides square brackets.
ID is constituted of hexadecimal numbers separated with hyphens.
PATH4, CUSTOM-ID, CODEREF and FUZZY can contain any character besides
square brackets.
―――――
I suggest to remove angle links. If one needs spaces in
PATH, she can use standard link syntax instead.
I also suggest to remove `org-link-types' dependency in
PROTOCOL and match `[a-zA-Z]' instead, for portability. —
ngz
[radio target] See section 5.8
[entities] See section 5.1
[latex fragments] See section 5.1
[subscript] See section 5.10
[superscript] See section 5.10
[footnote reference] See section 5.3
[line break] See section 5.5
5.7 Macros
──────────
Macros follow the pattern:
╭────
│ {{{NAME(ARGUMENTS)}}}
╰────
NAME must start with a letter and can be followed by any number of
alpha-numeric characters, hyphens and underscores.
ARGUMENTS can contain anything but "}}}" string. Values within
ARGUMENTS are separated by commas. Non-separating commas have to be
escaped with a backslash character.
5.8 Targets and Radio Targets
─────────────────────────────
Radio targets follow the pattern:
╭────
│ <<<CONTENTS>>>
╰────
CONTENTS can be any character besides `<', `>' and “\n”. As far as
objects go, it can contain [entities], [latex fragments], [subscript]
and [superscript] only.
Targets follow the pattern:
╭────
│ <<TARGET>>
╰────
TARGET can contain any character besides `<', `>' and “\n”. It cannot
contain any object.
[entities] See section 5.1
[latex fragments] See section 5.1
[subscript] See section 5.10
[superscript] See section 5.10
5.9 Statistics Cookies
──────────────────────
Statistics cookies follow either pattern:
╭────
│ [PERCENT%]
│ [NUM1/NUM2]
╰────
PERCENT, NUM1 and NUM2 are numbers or the empty string.
5.10 Subscript and Superscript
──────────────────────────────
Pattern for subscript is:
╭────
│ CHAR_SCRIPT
╰────
Pattern for superscript is:
╭────
│ CHAR^SCRIPT
╰────
CHAR is any non-whitespace character.
SCRIPT can be `*', a string made of word-constituent characters maybe
preceded by a plus or a minus sign, an expression enclosed in
parenthesis (resp. curly brackets) containing balanced parenthesis
(resp. curly brackets).
5.11 Table Cells
────────────────
Table cells follow the pattern:
╭────
│ CONTENTS|
╰────
CONTENTS can contain any character excepted a vertical bar.
5.12 Timestamps
───────────────
There are seven possible patterns for timestamps:
╭────
│ <%%(SEXP)> (diary)
│ <DATE TIME REPEATER> (active)
│ [DATE TIME REPEATER] (inactive)
│ <DATE TIME REPEATER>--<DATE TIME REPEATER> (active range)
│ <DATE TIME-TIME REPEATER> (active range)
│ [DATE TIME REPEATER]--[DATE TIME REPEATER] (inactive range)
│ [DATE TIME-TIME REPEATER] (inactive range)
╰────
SEXP can contain any character excepted `>' and `\n'.
DATE follows the pattern:
╭────
│ YYYY-MM-DD DAYNAME
╰────
Y, M and D are digits. DAYNAME can contain any non
whitespace-character besides `+', `-', `]', `>', a digit or `\n'.
TIME follows the pattern =H:MM~. H can be one or two digit long and
can start with 0.
REPEATER follows the patter:
╭────
│ MARK VALUE UNIT
╰────
MARK is `+' (cumulate type), `++' (catch-up type) or `.+' (restart
type).
VALUE is a number.
UNIT is a character among `h' (hour), `d' (day), `w' (week), `m'
(month), `y' (year).
MARK, VALUE and UNIT are not separated by whitespace characters.
5.13 Text Markup
────────────────
Text markup follows the pattern:
╭────
│ PRE MARKER CONTENTS MARKER POST
╰────
PRE is a whitespace character, `(', `{' ~’~ or a double quote. It can
also be a beginning of line.
MARKER is a character among `*' (bold), `=' (verbatim), `/' (italic),
`+' (strike-through), `_' (underline), `~' (code).
CONTENTS is a string following the pattern:
╭────
│ BORDER BODY BORDER
╰────
BORDER can be any non-whitespace character excepted ~,~, ~’~ or
a double quote.
BODY can contain contain any character but may not span over more than
3 lines.
BORDER and BODY are not separated by whitespaces.
CONTENTS can contain any object encountered in a paragraph when markup
is “bold”, “italic”, “strike-through” or “underline”.
POST is a whitespace character, `-', `.', ~,~, `:', `!', `?', ~’~,
`)', `}' or a double quote. It can also be an end of line.
PRE, MARKER, CONTENTS, MARKER and POST are not separated by whitespace
characters.
―――――
All of this is wrong if `org-emphasis-regexp-components'
or `org-emphasis-alist' are modified.
This should really be simplified and made persistent
(i.e. no defcustom allowed). Otherwise, portability and
parsing are jokes.
Also, CONTENTS should be anything within code and verbatim
emphasis, by definition. — ngz
Footnotes
─────────
[1] In particular, the parser requires stars at column 0 to be quoted
by a comma when they do not define a headline.
[2] It also means that only headlines and sections can be recognized
just by looking at the beginning of the line.
As a consequence, using `org-element-at-point' or
`org-element-context' will move up to the parent headline, and parse
top-down from there until context around is found.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
@ 2013-03-07 20:47 ` Carsten Dominik
2013-03-07 22:07 ` Achim Gratz
` (6 subsequent siblings)
7 siblings, 0 replies; 135+ messages in thread
From: Carsten Dominik @ 2013-03-07 20:47 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
woooooow, this is awesome Nicolas, thank you!
- Carsten
On 7.3.2013, at 21:37, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser. I also added some comments. I am going
> to put the Org file on Worg, so anyone can update it and fix mistakes.
>
> ━━━━━━━━━━━━━━━━━━━━
> ORG SYNTAX (DRAFT)
> ━━━━━━━━━━━━━━━━━━━━
>
>
> Table of Contents
> ─────────────────
>
> 1 Headlines and Sections
> 2 Affiliated Keywords
> 3 Greater Elements
> .. 3.1 Greater Blocks
> .. 3.2 Drawers and Property Drawers
> .. 3.3 Dynamic Blocks
> .. 3.4 Footnote Definitions
> .. 3.5 Inlinetasks
> .. 3.6 Plain Lists and Items
> .. 3.7 Tables
> 4 Elements
> .. 4.1 Babel Call
> .. 4.2 Blocks
> .. 4.3 Clock, Diary Sexp and Planning
> .. 4.4 Comments
> .. 4.5 Fixed Width Areas
> .. 4.6 Horizontal Rules
> .. 4.7 Keywords
> .. 4.8 LaTeX Environments
> .. 4.9 Node Properties
> .. 4.10 Paragraphs
> .. 4.11 Table Rows
> 5 Objects
> .. 5.1 Entities and LaTeX Fragments
> .. 5.2 Export Snippets
> .. 5.3 Footnote References
> .. 5.4 Inline Babel Calls and Source Blocks
> .. 5.5 Line Breaks
> .. 5.6 Links
> .. 5.7 Macros
> .. 5.8 Targets and Radio Targets
> .. 5.9 Statistics Cookies
> .. 5.10 Subscript and Superscript
> .. 5.11 Table Cells
> .. 5.12 Timestamps
> .. 5.13 Text Markup
>
>
> This document describes and comments Org syntax as it is currently read
> by its parser (Org Elements) and, therefore, by the export framework.
> It also includes a few comments on that syntax.
>
> A core concept in this syntax is that only headlines and sections are
> context-free[1][2]. Every other syntactical part only exists within
> specific environments.
>
> Three categories are used to classify these environments: “Greater
> elements”, “elements”, and “objects”, from the broadest scope to the
> narrowest.
>
> The paragraph is the unit of measurement. An element defines
> syntactical parts that are at the same level as a paragraph, i.e. which
> cannot contain or be included in a paragraph. An object is a part that
> could be included in an element. Greater elements are all parts that
> can contain an element.
>
> Empty lines belong to the largest element ending before them. For
> example, in a list, empty lines between items belong are part of the
> item before them, but empty lines at the end of a list belong to the
> plain list element.
>
> Unless specified otherwise, case is not significant.
>
>
> 1 Headlines and Sections
> ════════════════════════
>
> A headline is defined as:
>
> ╭────
> │ STARS KEYWORD PRIORITY TITLE TAGS
> ╰────
>
> STARS is a string starting at column 0 and containing at least one
> asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
> library is loaded). It’s the sole compulsory part of a headline.
>
> KEYWORD is a TODO keyword, which have to belong to the list defined in
> `org-todo-keywords'. Case is significant.
>
> PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
> sign # and enclosed within square brackets. Case is significant.
>
> TITLE can be made of any character but a new line. Though, it will
> match after every other part have been matched.
>
> TAGS is made of words containing any alpha-numeric character,
> underscore, at sign, hash sign or percent sign, and separated with
> colons.
>
> Examples of valid headlines include:
>
> ╭────
> │ *
> │
> │ ** DONE
> │
> │ *** Some e-mail
> │
> │ **** TODO [#A] COMMENT Title :tag:a2%:
> ╰────
>
> If the first word appearing in the title is `org-comment-keyword', the
> headline will be considered as “commented”. If that first word is
> `org-quote-string', it will be considered as “quoted”. In both
> situations, case is significant.
>
> If its title is `org-footnote-section', it will be considered as
> a “footnote section”. Case is significant.
>
> If `org-archive-tag' is one of its tags, it will be considered as
> “archived”. Case is significant.
>
> A headline contains directly at most one section, followed by any
> number of headlines. Only a section can contain another section.
>
> A section contains directly any greater element or element. Only
> a headline can contain a section. As an exception, text before the
> first headline in the document also belongs to a section.
>
> In a quoted headline contains a section, the latter will be considered
> as a “quote section”.
>
> As an example, consider the following document:
>
> ╭────
> │ An introduction.
> │
> │ * A Headline
> │
> │ Some text.
> │
> │ ** Sub-Topic 1
> │
> │ ** Sub-Topic 2
> │
> │ *** Additional entry
> │
> │ ** QUOTE Another Sub-Topic
> │
> │ Some other text.
> ╰────
>
> Its internal structure could be summarized as:
>
> ╭────
> │ (document
> │ (section)
> │ (headline
> │ (section)
> │ (headline)
> │ (headline
> │ (headline))
> │ (headline
> │ (quote-section))))
> ╰────
>
>
> 2 Affiliated Keywords
> ═════════════════════
>
> With the exception of [inlinetasks], [items], [planning], [clocks],
> [node properties] and [table rows], every other element type can be
> assigned attributes.
>
> This is done by adding specific keywords, named “affiliated keywords”,
> just above the element considered, no blank line allowed.
>
> Affiliated keywords are built upon one of the following patterns:
> “#+KEY: VALUE”, “#+KEY[OPTIONAL]: VALUE” or “#+ATTR_BACKEND: VALUE”.
>
> KEY is either “CAPTION”, “HEADER”, “NAME”, “PLOT” or “RESULTS” string.
>
> BACKEND is a string constituted of alpha-numeric characters, hyphens
> or underscores.
>
> OPTIONAL and VALUE can contain any character but a new line. Only
> keywords in `org-element-dual-keywords' can have an optional value.
>
> An affiliated keyword can appear on multiple lines if KEY belongs to
> `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
> VALUE”.
>
> Affiliated keywords whose KEY belong to `org-element-parsed-keywords'
> can contain objects in their value and their optional value, if
> applicable.
>
>
> [inlinetasks] See section 3.5
>
> [items] See section 3.6
>
> [planning] See section 4.3
>
> [clocks] See section 4.3
>
> [node properties] See section 4.9
>
> [table rows] See section 4.11
>
>
> 3 Greater Elements
> ══════════════════
>
> Unless specified otherwise, greater elements can contain directly any
> other element or greater element excepted:
>
> • elements of their own type,
> • [node properties], which can only be found in [property drawers],
> • [items], which can only be found in [plain lists].
>
>
> [node properties] See section 4.9
>
> [property drawers] See section 3.2
>
> [items] See section 3.6
>
> [plain lists] See section 3.6
>
>
> 3.1 Greater Blocks
> ──────────────────
>
> Greater blocks consist in the following pattern:
>
> ╭────
> │ #+BEGIN_NAME PARAMETERS
> │ CONTENTS
> │ #+END_NAME
> ╰────
>
> NAME can contain any non-whitespace character.
>
> PARAMETERS can contain any character, and can be omitted.
>
> If NAME is “CENTER”, it will be a “center block”. If it is “QUOTE”,
> it will be a “quote block”.
>
> If the block is neither a center block, a quote block or a [block
> element], it will be a “special block”.
>
> CONTENTS can contain any element, but another greater block of the
> same type.
>
>
> [block element] See section 4.2
>
>
> 3.2 Drawers and Property Drawers
> ────────────────────────────────
>
> Pattern for drawers is:
>
> ╭────
> │ :NAME:
> │ CONTENTS
> │ :END:
> ╰────
>
> NAME has to either be “PROPERTIES” or belong to `org-drawers' list.
>
> If NAME is “PROPERTIES”, the drawer will become a “property drawer”.
>
> In a property drawers, CONTENTS can only contain [node property]
> elements. Otherwise it can contain any element but another drawer or
> property drawer.
>
> ―――――
>
> It would be nice if users hadn’t to register drawers names before
> using them in `org-drawers' (or through the `#+DRAWERS:' keyword).
> Anything starting with `^[ \t]*:\w+:[ \t]$' and ending with
> `^[ \t]*:END:[ \t]$' could be considered as a drawer. — ngz
>
>
> [node property] See section 4.9
>
>
> 3.3 Dynamic Blocks
> ──────────────────
>
> Pattern for dynamic blocks is:
>
> ╭────
> │ #+BEGIN: NAME PARAMETERS
> │ CONTENTS
> │ #+END:
> ╰────
>
> NAME cannot contain any whitespace character.
>
> PARAMETERS can contain any character and can be omitted.
>
>
> 3.4 Footnote Definitions
> ────────────────────────
>
> Pattern for footnote definitions is:
>
> ╭────
> │ [LABEL] CONTENTS
> ╰────
>
> It must start at column 0.
>
> LABEL is either a number or follows the pattern “fn:WORD”, where word
> can contain any word-constituent character, hyphens and underscore
> characters.
>
> CONTENTS can contain any element excepted another footnote definition.
> It ends at the next footnote definition, the next headline, two
> consecutive empty lines or the end of buffer.
>
>
> 3.5 Inlinetasks
> ───────────────
>
> Inlinetasks are defined by `org-inlinetask-min-level' contiguous
> asterisk characters starting at column 0, followed by a whitespace
> character.
>
> Optionally, inlinetasks can be ended with a string constituted of
> `org-inlinetask-min-level' contiguous characters starting at column 0,
> followed by a space and the “END” string.
>
> Inlinetasks are recognized only after `org-inlinetask' library is
> loaded.
>
>
> 3.6 Plain Lists and Items
> ─────────────────────────
>
> Items are defined by a line starting with the following pattern:
> “BULLET COUNTER-SET CHECK-BOX TAG”, in which only BULLET is mandatory.
>
> BULLET is either an asterisk, a hyphen, a plus sign character or
> follows either the pattern “COUNTER.” or “COUNTER)". In any case,
> BULLET is follwed by a whitespace character or line ending.
>
> COUNTER can be a number or a single letter.
>
> COUNTER-SET follows the pattern [@COUNTER].
>
> CHECK-BOX is either a single whitespace character, a “X” character or
> a hyphen, enclosed within square brackets.
>
> TAG follows “TAG-TEXT ::” pattern, where TAG-TEXT can contain any
> character but a new line.
>
> An item ends before the next item, the first line less or equally
> indented than its starting line, or two consecutive empty lines.
> Indentation of lines within other greater elements do not count,
> neither do inlinetasks boundaries.
>
> A plain list is a set of consecutive items of the same indentation.
> It can only directly contain items.
>
> If first item in a plain list has a counter in its bullet, the plain
> list will be an “ordered plain-list”. If it contains a tag, it will
> be a “descriptive list”. Otherwise, it will be an “unordered list”.
> List types are mutually exclusive.
>
> For example, consider the following excerpt of an Org document:
>
> ╭────
> │ 1. item 1
> │ 2. [X] item 2
> │ - some tag :: item 2.1
> ╰────
>
> Its internal structure is as follows:
>
> ╭────
> │ (ordered-plain-list
> │ (item)
> │ (item
> │ (descriptive-plain-list
> │ (item))))
> ╰────
>
>
> 3.7 Tables
> ──────────
>
> Tables start at lines beginning with either a vertical bar or the “+-”
> string followed by plus or minus signs only, assuming they are not
> preceded with lines of the same type. These lines can be indented.
>
> A table starting with a vertical bar has “org” type. Otherwise it has
> “table.el” type.
>
> Org tables end at the first line not starting with a vertical bar.
> Table.el tables end at the first line not starting with either
> a vertical line or a plus sign. Such lines can be indented.
>
> An org table can only contain table rows. A table.el table does not
> contain anything.
>
>
> 4 Elements
> ══════════
>
> Elements cannot contain any other element.
>
> Only [keywords] whose name belongs to
> `org-element-document-properties', [verse blocks] , [paragraphs] and
> [table rows] can contain objects.
>
>
> [keywords] See section 4.7
>
> [verse blocks] See section 4.2
>
> [paragraphs] See section 4.10
>
> [table rows] See section 4.11
>
>
> 4.1 Babel Call
> ──────────────
>
> Pattern for babel calls is:
>
> ╭────
> │ #+CALL: VALUE
> ╰────
>
> VALUE is optional. It can contain any character but a new line.
>
>
> 4.2 Blocks
> ──────────
>
> Like [greater blocks], pattern for blocks is:
>
> ╭────
> │ #+BEGIN_NAME DATA
> │ CONTENTS
> │ #+END_NAME
> ╰────
>
> NAME cannot contain any whitespace character.
>
> If NAME is “COMMENT”, it will be a “comment block”. If it is
> “EXAMPLE”, it will be an “example block”. If it is “SRC”, it will be
> a “source block”. If it is “VERSE”, it will be a “verse block”.
>
> If NAME is a string matching the name of any export back-end loaded,
> the block will be an “export block”.
>
> DATA can contain any character but a new line. It can be ommitted,
> unless the block is a “source block”. In this case, it must follow
> the pattern “LANGUAGE SWITCHES ARGUMENTS”, where SWITCHES and
> ARGUMENTS are optional.
>
> LANGUAGE cannot contain any whitespace character.
>
> SWITCHES is made of any number of “SWITCH” patterns, separated by
> blank lines.
>
> A SWITCH pattern is either “-l “FORMAT"", where FORMAT can contain any
> character but a double quote and a new line, “-S” or “+S”, where
> S stands for a single letter.
>
> ARGUMENTS can contain any character but a new line.
>
> CONTENTS can contain any character, including new lines. Though it
> will only contain Org objects if the block is a verse block.
> Otherwise, contents will not be parsed.
>
>
> [greater blocks] See section 3.1
>
>
> 4.3 Clock, Diary Sexp and Planning
> ──────────────────────────────────
>
> A clock follows the pattern:
>
> ╭────
> │ CLOCK: TIMESTAMP DURATION
> ╰────
>
> Both TIMESTAMP and DURATION are optional.
>
> TIMESTAMP is a [timestamp] object.
>
> DURATION follows the pattern:
>
> ╭────
> │ => HH:MM
> ╰────
>
> HH is a number containing any number of digits. MM is a two digit
> numbers.
>
> A diary sexp is a line starting at column 0 with “%%(" string. It can
> then contain any character besides a new line.
>
> A planning is a line filled with more at most three INFO parts, where
> each INFO part follows the pattern:
>
> ╭────
> │ KEYWORD: TIMESTAMP
> ╰────
>
> KEYWORD is a string among `org-deadline-string',
> `org-scheduled-string' and `org-closed-string'. TIMESTAMP is is
> a [timestamp] object.
>
> Even though a planning element can exist anywhere in a section or
> a greater element, it will only affect the headline containing the
> section if it is put on the line following that headline.
>
>
> [timestamp] See section 5.12
>
>
> 4.4 Comments
> ────────────
>
> A “comment line” starts with a hash signe and a whitespace character
> or an end of line.
>
> Comments can contain any number of consecutive comment lines.
>
>
> 4.5 Fixed Width Areas
> ─────────────────────
>
> A “fixed-width line” start with a colon character and a whitespace or
> an end of line.
>
> Fixed width areas can contain any number of consecutive fixed-width
> lines.
>
>
> 4.6 Horizontal Rules
> ────────────────────
>
> A horizontal rule is a line made of at least 5 consecutive hyphens.
> It can be indented.
>
>
> 4.7 Keywords
> ────────────
>
> Keywords follow the syntax:
>
> ╭────
> │ #+KEY: VALUE
> ╰────
>
> KEY can contain any non-whitespace character, but it cannot be equal
> to “CALL” or any affiliated keyword.
>
> VALUE can contain any character excepted a new line.
>
> If KEY belongs to `org-element-document-properties', VALUE can contain
> objects.
>
>
> 4.8 LaTeX Environments
> ──────────────────────
>
> Pattern for LaTeX environments is:
>
> ╭────
> │ \begin{NAME}
> │ CONTENTS
> │ \end{NAME}
> ╰────
>
> NAME is constituted of alpha-numeric characters and may end with an
> asterisk.
>
> CONTENTS can contain anything but the “\end{NAME}” string.
>
>
> 4.9 Node Properties
> ───────────────────
>
> Patter for node properties is:
>
> ╭────
> │ :PROPERTY: VALUE
> ╰────
>
> PROPERTY can contain any non-whitespace character. VALUE can contain
> any character but a new line.
>
> Node properties can only exist in a [property drawers].
>
>
> [property drawers] See section 3.2
>
>
> 4.10 Paragraphs
> ───────────────
>
> Paragraphs are the default element, which means that any unrecognized
> context is a paragraph.
>
> Empty lines and other elements end paragraphs.
>
> Paragraphs can contain every type of object.
>
>
> 4.11 Table Rows
> ───────────────
>
> A table rows is either constituted of a vertical bar and any number of
> [table cells] or a vertical bar followed by a hyphen.
>
> In the first case the table row has the “standard” type. In the
> second case, it has the “rule” type.
>
> Table rows can only exist in [tables].
>
>
> [table cells] See section 5.11
>
> [tables] See section 3.7
>
>
> 5 Objects
> ═════════
>
> Objects can only be found in the following locations:
>
> • [affiliated keywords] defined in `org-element-parsed-keywords',
> • [document properties],
> • [headline] titles,
> • [inlinetask] titles,
> • [item] tags,
> • [paragraphs],
> • [table cells],
> • [table rows], which can only contain table cell objects,
> • [verse blocks].
>
> Most objects cannot contain objects. Those which can will be
> specified.
>
>
> [affiliated keywords] See section 2
>
> [document properties] See section 4.7
>
> [headline] See section 1
>
> [inlinetask] See section 3.5
>
> [item] See section 3.6
>
> [paragraphs] See section 4.10
>
> [table cells] See section 5.11
>
> [table rows] See section 4.11
>
> [verse blocks] See section 4.2
>
>
> 5.1 Entities and LaTeX Fragments
> ────────────────────────────────
>
> An entity follows the pattern:
>
> ╭────
> │ \NAME POST
> ╰────
>
> where NAME has a valid association in either `org-entities' or
> `org-entities-user'.
>
> POST is the end of line, "{}" string, or a non-alphabetical character.
> It isn’t separated from NAME by a whitespace character.
>
> A LaTeX fragment can follow multiple patterns:
>
> ╭────
> │ \NAME POST
> │ \(CONTENTS\)
> │ \[CONTENTS\]
> │ $$CONTENTS$$
> │ PRE$CHAR$POST
> │ PRE$BORDER1 BODY BORDER2$
> ╰────
>
> NAME contains alphabetical characters only and must not have an
> association in either `org-entities' or `org-entities-user'.
>
> POST is the same as for entities.
>
> CONTENTS can contain any character but cannot contain “\)" in the
> second template or “\]" in the third one.
>
> PRE is either the beginning of line or a character different from `$'.
>
> CHAR is a non-whitespace character different from `.', ~,~, `?', `;',
> ~’~ or a double quote.
>
> POST is any of `-', `.', ~,~, `?', `;', `:', ~’~, a double quote,
> a whitespace character and the end of line.
>
> BORDER1 is a non-whitespace character different from `.', `;', `.'
> and `$'.
>
> BODY can contain any character excepted `$', and may not span over
> more than 3 lines.
>
> BORDER2 is any non-whitespace character different from ~,~, `.' and
> `$'.
>
> ―――――
>
> It would introduce incompatibilities with previous Org
> versions, but support for “$…$” (and for symmetry,
> `$$...$$') constructs ought to be removed.
>
> They are slow to parse, fragile, redundant, imply false
> positives and do not look good in LaTeX output anyway.
> Even the LaTeX community suggests to use `\(...\)' over
> `$...$'. — ngz
>
>
> 5.2 Export Snippets
> ───────────────────
>
> Patter for export snippets is:
>
> ╭────
> │ @@NAME:VALUE@@
> ╰────
>
> NAME can contain any alpha-numeric character and hyphens.
>
> VALUE can contain anything but “@@” string.
>
>
> 5.3 Footnote References
> ───────────────────────
>
> There are four patterns for footnote references:
>
> ╭────
> │ [MARK]
> │ [fn:LABEL]
> │ [fn:LABEL:DEFINITION]
> │ [fn::DEFINITION]
> ╰────
>
> MARK is a number.
>
> LABEL can contain any word constituent character, hyphens and
> underscores.
>
> DEFINITION can contain any character. Though opening and closing
> square brackets must be balanced in it. It can contain any object
> encountered in a paragraph, even other footnote references.
>
> If the reference follows the third pattern, it is called an “inline
> footnote”. If it follows the fourth one, i.e. if LABEL is omitted, it
> is an “anonymous footnote”.
>
>
> 5.4 Inline Babel Calls and Source Blocks
> ────────────────────────────────────────
>
> Inline Babel calls follow any of the following patterns:
>
> ╭────
> │ call_NAME(ARGUMENTS)
> │ call_NAME[HEADER](ARGUMENTS)[HEADER]
> ╰────
>
> NAME can contain any character besides `(', `)' and “\n”.
>
> HEADER can contain any character besides `]' and “\n”.
>
> ARGUMENTS can contain any character besides `)' and “\n”.
>
> Inline source blocks follow any of the following patterns:
>
> ╭────
> │ src_LANG{BODY}
> │ src_LANG[OPTIONS]{BODY}
> ╰────
>
> LANG can contain any non-whitespace character.
>
> OPTIONS and BODY can contain any character but “\n”.
>
>
> 5.5 Line Breaks
> ───────────────
>
> A line break consists in “\\SPACE” pattern at the end of an otherwise
> non-empty line.
>
> SPACE can contain any number of tabs and spaces, including 0.
>
>
> 5.6 Links
> ─────────
>
> There are 4 major types of links:
>
> ╭────
> │ RADIO ("radio" link)
> │ <PROTOCOL:PATH> ("angle" link)
> │ PRE PROTOCOL:PATH2 POST ("plain" link)
> │ [[PATH3]DESCRIPTION] ("regular" link)
> ╰────
>
> RADIO is a string matched by some [radio target]. It can contain
> [entities], [latex fragments], [subscript] and [superscript] only.
>
> PROTOCOL is a string among `org-link-types'.
>
> PATH can contain any character but `]', `<', `>' and `\n'.
>
> PRE and POST are non word constituent. They can be, respectively, the
> beginning or the end of a line.
>
> PATH2 can contain any non-whitespace character excepted `(', `)', `<'
> and `>'. It must end with a word-constituent character, or any
> non-whitespace non-punctuation character followed by `/'.
>
> DESCRIPTION must be enclosed within square brackets. It can contain
> any character but square brackets. Object-wise, it can contain any
> object found in a paragraph excepted a [footnote reference], a [radio
> target] and a [line break]. It cannot contain another link either,
> unless it is a plain link.
>
> DESCRIPTION is optional.
>
> PATH3 is built according to the following patterns:
>
> ╭────
> │ FILENAME ("file" type)
> │ PROTOCOL:PATH4 ("PROTOCOL" type)
> │ id:ID ("id" type)
> │ #CUSTOM-ID ("custom-id" type)
> │ (CODEREF) ("coderef" type)
> │ FUZZY ("fuzzy" type)
> ╰────
>
> FILENAME is a file name, either absolute or relative.
>
> PATH4 can contain any character besides square brackets.
>
> ID is constituted of hexadecimal numbers separated with hyphens.
>
> PATH4, CUSTOM-ID, CODEREF and FUZZY can contain any character besides
> square brackets.
>
> ―――――
>
> I suggest to remove angle links. If one needs spaces in
> PATH, she can use standard link syntax instead.
>
> I also suggest to remove `org-link-types' dependency in
> PROTOCOL and match `[a-zA-Z]' instead, for portability. —
> ngz
>
>
> [radio target] See section 5.8
>
> [entities] See section 5.1
>
> [latex fragments] See section 5.1
>
> [subscript] See section 5.10
>
> [superscript] See section 5.10
>
> [footnote reference] See section 5.3
>
> [line break] See section 5.5
>
>
> 5.7 Macros
> ──────────
>
> Macros follow the pattern:
>
> ╭────
> │ {{{NAME(ARGUMENTS)}}}
> ╰────
>
> NAME must start with a letter and can be followed by any number of
> alpha-numeric characters, hyphens and underscores.
>
> ARGUMENTS can contain anything but "}}}" string. Values within
> ARGUMENTS are separated by commas. Non-separating commas have to be
> escaped with a backslash character.
>
>
> 5.8 Targets and Radio Targets
> ─────────────────────────────
>
> Radio targets follow the pattern:
>
> ╭────
> │ <<<CONTENTS>>>
> ╰────
>
> CONTENTS can be any character besides `<', `>' and “\n”. As far as
> objects go, it can contain [entities], [latex fragments], [subscript]
> and [superscript] only.
>
> Targets follow the pattern:
>
> ╭────
> │ <<TARGET>>
> ╰────
>
> TARGET can contain any character besides `<', `>' and “\n”. It cannot
> contain any object.
>
>
> [entities] See section 5.1
>
> [latex fragments] See section 5.1
>
> [subscript] See section 5.10
>
> [superscript] See section 5.10
>
>
> 5.9 Statistics Cookies
> ──────────────────────
>
> Statistics cookies follow either pattern:
>
> ╭────
> │ [PERCENT%]
> │ [NUM1/NUM2]
> ╰────
>
> PERCENT, NUM1 and NUM2 are numbers or the empty string.
>
>
> 5.10 Subscript and Superscript
> ──────────────────────────────
>
> Pattern for subscript is:
>
> ╭────
> │ CHAR_SCRIPT
> ╰────
>
> Pattern for superscript is:
>
> ╭────
> │ CHAR^SCRIPT
> ╰────
>
> CHAR is any non-whitespace character.
>
> SCRIPT can be `*', a string made of word-constituent characters maybe
> preceded by a plus or a minus sign, an expression enclosed in
> parenthesis (resp. curly brackets) containing balanced parenthesis
> (resp. curly brackets).
>
>
> 5.11 Table Cells
> ────────────────
>
> Table cells follow the pattern:
>
> ╭────
> │ CONTENTS|
> ╰────
>
> CONTENTS can contain any character excepted a vertical bar.
>
>
> 5.12 Timestamps
> ───────────────
>
> There are seven possible patterns for timestamps:
>
> ╭────
> │ <%%(SEXP)> (diary)
> │ <DATE TIME REPEATER> (active)
> │ [DATE TIME REPEATER] (inactive)
> │ <DATE TIME REPEATER>--<DATE TIME REPEATER> (active range)
> │ <DATE TIME-TIME REPEATER> (active range)
> │ [DATE TIME REPEATER]--[DATE TIME REPEATER] (inactive range)
> │ [DATE TIME-TIME REPEATER] (inactive range)
> ╰────
>
> SEXP can contain any character excepted `>' and `\n'.
>
> DATE follows the pattern:
>
> ╭────
> │ YYYY-MM-DD DAYNAME
> ╰────
>
> Y, M and D are digits. DAYNAME can contain any non
> whitespace-character besides `+', `-', `]', `>', a digit or `\n'.
>
> TIME follows the pattern =H:MM~. H can be one or two digit long and
> can start with 0.
>
> REPEATER follows the patter:
>
> ╭────
> │ MARK VALUE UNIT
> ╰────
>
> MARK is `+' (cumulate type), `++' (catch-up type) or `.+' (restart
> type).
>
> VALUE is a number.
>
> UNIT is a character among `h' (hour), `d' (day), `w' (week), `m'
> (month), `y' (year).
>
> MARK, VALUE and UNIT are not separated by whitespace characters.
>
>
> 5.13 Text Markup
> ────────────────
>
> Text markup follows the pattern:
>
> ╭────
> │ PRE MARKER CONTENTS MARKER POST
> ╰────
>
> PRE is a whitespace character, `(', `{' ~’~ or a double quote. It can
> also be a beginning of line.
>
> MARKER is a character among `*' (bold), `=' (verbatim), `/' (italic),
> `+' (strike-through), `_' (underline), `~' (code).
>
> CONTENTS is a string following the pattern:
>
> ╭────
> │ BORDER BODY BORDER
> ╰────
>
> BORDER can be any non-whitespace character excepted ~,~, ~’~ or
> a double quote.
>
> BODY can contain contain any character but may not span over more than
> 3 lines.
>
> BORDER and BODY are not separated by whitespaces.
>
> CONTENTS can contain any object encountered in a paragraph when markup
> is “bold”, “italic”, “strike-through” or “underline”.
>
> POST is a whitespace character, `-', `.', ~,~, `:', `!', `?', ~’~,
> `)', `}' or a double quote. It can also be an end of line.
>
> PRE, MARKER, CONTENTS, MARKER and POST are not separated by whitespace
> characters.
>
> ―――――
>
> All of this is wrong if `org-emphasis-regexp-components'
> or `org-emphasis-alist' are modified.
>
> This should really be simplified and made persistent
> (i.e. no defcustom allowed). Otherwise, portability and
> parsing are jokes.
>
> Also, CONTENTS should be anything within code and verbatim
> emphasis, by definition. — ngz
>
>
>
> Footnotes
> ─────────
>
> [1] In particular, the parser requires stars at column 0 to be quoted
> by a comma when they do not define a headline.
>
> [2] It also means that only headlines and sections can be recognized
> just by looking at the beginning of the line.
>
> As a consequence, using `org-element-at-point' or
> `org-element-context' will move up to the parent headline, and parse
> top-down from there until context around is found.
>
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
2013-03-07 20:47 ` Carsten Dominik
@ 2013-03-07 22:07 ` Achim Gratz
2013-03-08 10:04 ` Bastien
` (5 subsequent siblings)
7 siblings, 0 replies; 135+ messages in thread
From: Achim Gratz @ 2013-03-07 22:07 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser. I also added some comments. I am going
> to put the Org file on Worg, so anyone can update it and fix mistakes.
Wonderful. This will be really useful!
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
2013-03-07 20:47 ` Carsten Dominik
2013-03-07 22:07 ` Achim Gratz
@ 2013-03-08 10:04 ` Bastien
2013-03-08 10:39 ` was: " Andreas Röhler
` (4 subsequent siblings)
7 siblings, 0 replies; 135+ messages in thread
From: Bastien @ 2013-03-08 10:04 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Org Mode List
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser. I also added some comments. I am going
> to put the Org file on Worg, so anyone can update it and fix mistakes.
Thanks Nicolas -- yep, that's really *great*!
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* was: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
` (2 preceding siblings ...)
2013-03-08 10:04 ` Bastien
@ 2013-03-08 10:39 ` Andreas Röhler
2013-03-08 10:46 ` (no subject) Bastien
2013-03-08 13:25 ` [RFC] Org syntax (draft) François Pinard
` (3 subsequent siblings)
7 siblings, 1 reply; 135+ messages in thread
From: Andreas Röhler @ 2013-03-08 10:39 UTC (permalink / raw)
To: emacs-orgmode
[ ... ]
>
> ╭────
> │ STARS KEYWORD PRIORITY TITLE TAGS
> ╰────
>
Hi,
my thanks too.
BTW does that mean, stars are hard-coded in a way, they can't be replaced by another car?
If yes, what about to keep the core more abstract?
Best,
Andreas
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 10:39 ` was: " Andreas Röhler
@ 2013-03-08 10:46 ` Bastien
2013-03-08 10:59 ` Andreas Röhler
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-08 10:46 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-orgmode
Hi Andreas,
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> BTW does that mean, stars are hard-coded in a way, they can't be
> replaced by another car?
Yes, this is the case.
> If yes, what about to keep the core more abstract?
This is a hard problem and I personally don't think it's worth
tackling it. But I don't want to decourage anyone, of course :)
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 10:46 ` (no subject) Bastien
@ 2013-03-08 10:59 ` Andreas Röhler
2013-03-08 11:05 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Andreas Röhler @ 2013-03-08 10:59 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Am 08.03.2013 11:46, schrieb Bastien:
> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> BTW does that mean, stars are hard-coded in a way, they can't be
>> replaced by another car?
>
> Yes, this is the case.
>
>> If yes, what about to keep the core more abstract?
>
> This is a hard problem
Hi Bastien,
can it be more difficult than related use of comment-start?
[ ... ]
Cheers,
Andreas
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 10:59 ` Andreas Röhler
@ 2013-03-08 11:05 ` Bastien
2013-03-08 11:18 ` Andreas Röhler
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-08 11:05 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-orgmode
Hi Andreas,
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> can it be more difficult than related use of comment-start?
Yes -- check this FAQ:
http://orgmode.org/worg/org-faq.html#sec-8-12
HTH,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 11:05 ` Bastien
@ 2013-03-08 11:18 ` Andreas Röhler
2013-03-08 11:23 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Andreas Röhler @ 2013-03-08 11:18 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Am 08.03.2013 12:05, schrieb Bastien:
> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> can it be more difficult than related use of comment-start?
>
> Yes -- check this FAQ:
> http://orgmode.org/worg/org-faq.html#sec-8-12
>
> HTH,
>
Thanks, still non-believing :)
(defcustom outline-regexp "[*\^L]+"
"Regular expression to match the beginning of a heading.
Any line whose beginning matches this regexp is considered to start a heading.
Note that Outline mode only checks this regexp at the start of a line,
so the regexp need not (and usually does not) start with `^'.
The recommended way to set this is with a Local Variables: list
in the file it applies to. See also `outline-heading-end-regexp'."
:type 'regexp
:group 'outlines)
IMHO remains to make that buffer-local and use outline-regexp from inside org-mode.
Andreas
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 11:18 ` Andreas Röhler
@ 2013-03-08 11:23 ` Bastien
2013-03-08 13:00 ` Andreas Röhler
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-08 11:23 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-orgmode
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> IMHO remains to make that buffer-local and use outline-regexp from
> inside org-mode.
Have a go and let us know :)
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 11:23 ` Bastien
@ 2013-03-08 13:00 ` Andreas Röhler
2013-03-08 13:12 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Andreas Röhler @ 2013-03-08 13:00 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
Am 08.03.2013 12:23, schrieb Bastien:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> IMHO remains to make that buffer-local and use outline-regexp from
>> inside org-mode.
>
> Have a go and let us know :)
>
That should work already - to start with.
[-- Attachment #2: org-heading-char.patch --]
[-- Type: text/x-patch, Size: 1194 bytes --]
commit 8cf6bc6faeb2a3b3fec0780e56a04ef0e13c3c62
Author: Andreas Roehler <andreas.roehler@online.de>
Date: Fri Mar 8 13:58:13 2013 +0100
Enable different heading chars, not just `*'
Use variable `org-heading-char', customizable later on,
instead of hard-coded `*'
TINYCHANGE
diff --git a/lisp/org.el b/lisp/org.el
index 811506a..2db63ae 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -90,13 +90,17 @@
;; `org-outline-regexp'. The only function still directly relying on
;; `outline-regexp' is `org-overview' so that `org-cycle' can do its
;; job when `orgstruct-mode' is active.
+(defvar org-heading-char "*")
+
(defvar org-outline-regexp "\\*+ "
"Regexp to match Org headlines.")
+(setq org-outline-regexp (concat (regexp-quote org-heading-char) "+ "))
(defvar org-outline-regexp-bol "^\\*+ "
"Regexp to match Org headlines.
This is similar to `org-outline-regexp' but additionally makes
sure that we are at the beginning of the line.")
+(setq org-outline-regexp-bol (concat "^" (regexp-quote org-heading-char) "+ "))
(defvar org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
"Matches a headline, putting stars and text into groups.
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 13:00 ` Andreas Röhler
@ 2013-03-08 13:12 ` Bastien
2013-03-08 15:22 ` Andreas Röhler
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-08 13:12 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-orgmode
Hi Andreas,
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Am 08.03.2013 12:23, schrieb Bastien:
>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>
>>> IMHO remains to make that buffer-local and use outline-regexp from
>>> inside org-mode.
>>
>> Have a go and let us know :)
>
> That should work already - to start with.
Sorry, I should not let you go into that direction without a warning
that I won't commit anything related to this myself.
Btw, did you read the thread as the FAQ suggests?
One reason why the stars are hardcoded (like the comment characters
and other syntactic elements) is that Org files are used outside Emacs
and allowing users to use something else here is calling for trouble.
So -- just to let you know that it's fine playing with the idea and
providing proof-of-concept patches, but there are many reasons why
this cannot be considered.
Also, we are trying to focus on 8.0 right now... help welcome!
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
` (3 preceding siblings ...)
2013-03-08 10:39 ` was: " Andreas Röhler
@ 2013-03-08 13:25 ` François Pinard
2013-03-08 15:23 ` Nicolas Richard
` (2 subsequent siblings)
7 siblings, 0 replies; 135+ messages in thread
From: François Pinard @ 2013-03-08 13:25 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser.
Fantastique! :-) I'm preciously saving this!
François
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 13:12 ` Bastien
@ 2013-03-08 15:22 ` Andreas Röhler
2013-03-08 15:40 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Andreas Röhler @ 2013-03-08 15:22 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Am 08.03.2013 14:12, schrieb Bastien:
> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Am 08.03.2013 12:23, schrieb Bastien:
>>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>
>>>> IMHO remains to make that buffer-local and use outline-regexp from
>>>> inside org-mode.
>>>
>>> Have a go and let us know :)
>>
>> That should work already - to start with.
>
> Sorry, I should not let you go into that direction without a warning
> that I won't commit anything related to this myself.
>
Hi Bastien,
don't worry, didn't expect that for now or soon.
> Btw, did you read the thread as the FAQ suggests?
Nothing different resp. new so far. Let's stress that solution in mind also would be quite simple.
See the example patch.
No-one would be compelled to change the default BTW, it would just open the possibility.
>
> One reason why the stars are hardcoded (like the comment characters
> and other syntactic elements) is that Org files are used outside Emacs
> and allowing users to use something else here is calling for trouble.
>
Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred--
org-file while the default is active.
But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the
stars where expected.
[ ... ]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
` (4 preceding siblings ...)
2013-03-08 13:25 ` [RFC] Org syntax (draft) François Pinard
@ 2013-03-08 15:23 ` Nicolas Richard
2013-03-08 22:06 ` Nicolas Goaziou
2013-03-09 23:16 ` Achim Gratz
2013-03-17 7:18 ` Achim Gratz
7 siblings, 1 reply; 135+ messages in thread
From: Nicolas Richard @ 2013-03-08 15:23 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser. I also added some comments. I am going
> to put the Org file on Worg, so anyone can update it and fix mistakes.
[for the record, the org file mentionned by Nicolas is currently at
<http://orgmode.org/worg/dev/org-syntax.org>]
This looks truly awesome. I give some (naïve) comments below, from my
non-expert point of view.
> The paragraph is the unit of measurement. An element defines
> syntactical parts that are at the same level as a paragraph, i.e. which
> cannot contain or be included in a paragraph. An object is a part that
> could be included in an element. Greater elements are all parts that
> can contain an element.
This is very clear but I'm slightly worried about confusion that might come
from "Greater element" not being an "element", and the word "element"
being a common word :
> Empty lines belong to the largest element ending before them. For
> example, in a list, empty lines between items belong are part of the
> item before them, but empty lines at the end of a list belong to the
> plain list element.
Is the word "element" (in /largest element ending.../) to be understood
as an "element" from the above definition ? I guess not (this would
require both list items and plain lists to be on the level 'element',
from your example)
> 1 Headlines and Sections
> ════════════════════════
>
> A headline is defined as:
>
> ╭────
> │ STARS KEYWORD PRIORITY TITLE TAGS
> ╰────
>
> STARS is a string starting at column 0 and containing at least one
> asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
> library is loaded). It’s the sole compulsory part of a headline.
Perhaps it should be mentionned that STARS has to end by a space (see
below). I suggest adding : The number of stars defines the level of the
headline.
> KEYWORD is a TODO keyword, which have to belong to the list defined in
> `org-todo-keywords'. Case is significant.
The option #+TODO: is used also.
> PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
> sign # and enclosed within square brackets. Case is significant.
I suggest dropping "Case is significant" (or maybe give the whole story :
IIRC, it is the ascii code of the given letter that is used as priority)
> ╭────
> │ *
I don't see a space character after that one in your email and it
doesn't seem to be recognized as a headline by the exporter (hence my
above suggestion)
> If the first word appearing in the title is `org-comment-keyword',
> the
That should be `org-comment-string' I guess.
> A headline contains directly at most one section, followed by any
> number of headlines. Only a section can contain another section.
From what I understand, "A section is delimited by two headlines (and
buffer limits)." [I initially thought it was "by two headlines of the
same level", which it is not from the structure example you give later.]
> A section contains directly any greater element or element. Only
> a headline can contain a section. As an exception, text before the
> first headline in the document also belongs to a section.
> In a quoted headline contains a section, the latter will be considered
> as a “quote section”.
s/In/If/
unsure: s/quote section/quoted section/ ?
> As an example, consider the following document:
<snip, useful example>
> BACKEND is a string constituted of alpha-numeric characters, hyphens
> or underscores.
I suggest: BACKEND is a string which is an element of (mapcar 'car
org-export-registered-backends).
> OPTIONAL and VALUE can contain any character but a new line. Only
> keywords in `org-element-dual-keywords' can have an optional value.
I guess OPTIONAL cannot contain a closing square bracket ]
> An affiliated keyword can appear on multiple lines if KEY belongs to
> `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
> VALUE”.
I suggest s/on multiple lines/more than once/
> PARAMETERS can contain any character, and can be omitted.
any other than new line, I guess.
> CONTENTS can contain any element, but another greater block of the
> same type.
What is the type of a greater block ? the /name/ ?
I did have a quick look at the rest of your mail, and it is very nice to
have all of it written down explicitly, so again a big thanks for all of
this (and the rest of your) work. Unfortunately I don't have much time
right now to read it thoroughtfully, so just one single comment :
> Even the LaTeX community suggests to use `\(...\)' over
> `$...$'. — ngz
AFAIK that's not for technical reasons and also I would be curious to
know who does that in real documents : '$' is so much more convenient.
But one might think of rebinding $ to a command which would insert \( and
\) appropriately within org-mode (see below). (OTOH, there are technical
reasons for avoiding $$ and $$.)
Here some elisp for the above behaviour :
(defun yf/org-electric-dollar nil
"When called once, insert \\(\\) and leave point in between.
When called twice, replace the previously inserted \\(\\) by one $."
(interactive)
(if (and (looking-at "\\\\)") (looking-back "\\\\("))
(progn (delete-char 2)
(delete-char -2)
(insert "$"))
(insert "\\(\\)")
(backward-char 2)))
(define-key org-mode-map (kbd "$") 'yf/org-electric-dollar)
--
N.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 15:22 ` Andreas Röhler
@ 2013-03-08 15:40 ` Bastien
2013-03-08 20:39 ` T.F. Torrey
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-08 15:40 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-orgmode
Hi Andreas,
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Hmm, AFAIS trouble might occur only if someone tries to load a
> non-default --i.e. not-starred-- org-file while the default is
> active.
... or if someone shares a file online using non-star character
as the prefix for headlines: this file won't be processed by
Org tools like org-ruby and the like.
> But even then it's quite easy to write a guess, which might start if
> org-mode didn't encounter the stars where expected.
Org files are not just for Emacs, that's were the problem lies...
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 15:40 ` Bastien
@ 2013-03-08 20:39 ` T.F. Torrey
2013-03-08 21:19 ` Nicolas Goaziou
` (2 more replies)
0 siblings, 3 replies; 135+ messages in thread
From: T.F. Torrey @ 2013-03-08 20:39 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Hello,
Bastien <bzg@altern.org> writes:
> Hi Andreas,
>
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Hmm, AFAIS trouble might occur only if someone tries to load a
>> non-default --i.e. not-starred-- org-file while the default is
>> active.
>
> ... or if someone shares a file online using non-star character
> as the prefix for headlines: this file won't be processed by
> Org tools like org-ruby and the like.
>
>> But even then it's quite easy to write a guess, which might start if
>> org-mode didn't encounter the stars where expected.
>
> Org files are not just for Emacs, that's were the problem lies...
I don't understand this heavy-handed approach.
Plain text is great because I can do whatever I want. What I come up
with might not work correctly in other tools (or anything at all), but I
have the freedom to do interesting things, and to have my files look
just the way I want them to.
Emacs is great because it allows me the freedom of near-infinite
customization. It has sensible defaults, but it allows me to break
things however I want.
Org, on the other hand, seems to be moving away from that in many ways.
Headlines must start with stars because I might someday post something
on the web and it wouldn't work for someone else? Other tools might not
recognize my file correctly? A developer of some other tool might
someday have a problem? These are not good reasons for limiting what I
can do with my own Org files.
I don't need or want supervision in how I create my files. I want
freedom. If I wanted supervision, I wouldn't be using Emacs. Have you
seen the lisp posted to the web? Somehow, Emacs and I survive that.
Org started as a great tool that let me do cool things with my text
files. I don't want to see it change to a rigid format for me to force
my files into, where my only options are conform or leave.
Org should err on the side of user freedom.
IMHO,
Terry
--
T.F. Torrey
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 20:39 ` T.F. Torrey
@ 2013-03-08 21:19 ` Nicolas Goaziou
2013-03-08 21:57 ` Suvayu Ali
2013-03-08 22:15 ` interoperability matters " Gregor Zattler
2013-03-09 14:09 ` Bastien
2 siblings, 1 reply; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-08 21:19 UTC (permalink / raw)
To: T.F. Torrey; +Cc: Bastien, emacs-orgmode
Hello,
tftorrey@tftorrey.com (T.F. Torrey) writes:
> Hello,
>
> Bastien <bzg@altern.org> writes:
>
>> Hi Andreas,
>>
>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>
>>> Hmm, AFAIS trouble might occur only if someone tries to load a
>>> non-default --i.e. not-starred-- org-file while the default is
>>> active.
>>
>> ... or if someone shares a file online using non-star character
>> as the prefix for headlines: this file won't be processed by
>> Org tools like org-ruby and the like.
>>
>>> But even then it's quite easy to write a guess, which might start if
>>> org-mode didn't encounter the stars where expected.
>>
>> Org files are not just for Emacs, that's were the problem lies...
>
> I don't understand this heavy-handed approach.
>
> Plain text is great because I can do whatever I want. What I come up
> with might not work correctly in other tools (or anything at all), but I
> have the freedom to do interesting things, and to have my files look
> just the way I want them to.
>
> Emacs is great because it allows me the freedom of near-infinite
> customization. It has sensible defaults, but it allows me to break
> things however I want.
>
> Org, on the other hand, seems to be moving away from that in many ways.
> Headlines must start with stars because I might someday post something
> on the web and it wouldn't work for someone else? Other tools might not
> recognize my file correctly? A developer of some other tool might
> someday have a problem? These are not good reasons for limiting what I
> can do with my own Org files.
>
> I don't need or want supervision in how I create my files. I want
> freedom. If I wanted supervision, I wouldn't be using Emacs. Have you
> seen the lisp posted to the web? Somehow, Emacs and I survive that.
>
> Org started as a great tool that let me do cool things with my text
> files. I don't want to see it change to a rigid format for me to force
> my files into, where my only options are conform or leave.
>
I disagree.
Org is a plain text format. Like any format, plain-text or not, it needs
a proper definition. At least, it helps users and developers to agree on
what they are talking about. As for myself, I cannot play any game if
I don't know its rules.
My point of view is the following: Org (as a format) definition
shouldn't depend on Emacs. It should be totally parseable by any
language (which is not the case actually, since syntax relies on
variables defined in Emacs). IOW, we should work to make it a real
plain-text markup format.
> Org should err on the side of user freedom.
You still have the freedom to choose what you write down in Org format.
You have the freedom use, or to not use Org. You have the freedom to
modify Org code to bend it to your will. IMO, freedom is totally
unrelated to this subject.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 21:19 ` Nicolas Goaziou
@ 2013-03-08 21:57 ` Suvayu Ali
0 siblings, 0 replies; 135+ messages in thread
From: Suvayu Ali @ 2013-03-08 21:57 UTC (permalink / raw)
To: emacs-orgmode
Hi,
On Fri, Mar 08, 2013 at 10:19:56PM +0100, Nicolas Goaziou wrote:
> tftorrey@tftorrey.com (T.F. Torrey) writes:
> >
> > Org, on the other hand, seems to be moving away from that in many ways.
> > Headlines must start with stars because I might someday post something
> > on the web and it wouldn't work for someone else? Other tools might not
> > recognize my file correctly? A developer of some other tool might
> > someday have a problem? These are not good reasons for limiting what I
> > can do with my own Org files.
[...]
> My point of view is the following: Org (as a format) definition
> shouldn't depend on Emacs. It should be totally parseable by any
> language (which is not the case actually, since syntax relies on
> variables defined in Emacs). IOW, we should work to make it a real
> plain-text markup format.
This discussion comes up again and again over the years. Every time the
conclusion has been, there are many who want to use other characters
instead of a star but the rational is always cosmetic. And in the end
people end up agreeing it is not worth the pain.
To give you an example of breakage, after long whining github started
supporting org file formatting for READMEs via org-ruby (even source
blocks I think!). Do you expect we can have similar support if
something as fundamental as the headline is not well defined? Other
possible breakages could be in org-merge-driver, VimOrganizer, org-sync,
some of the collaborative editing projects that have been spawning, and
the list goes on ...
FWIW, assuming that the rational behind this feature request is
cosmetic, there was a proposal to implement this as overlays. So the
file still uses *-s but a user can customise how they are displayed. I
think this addresses almost all requests in this category (majority
being "I want really cool UTF characters instead of boring old
asterisk"). If someone is interested in implementing this, I'm pretty
sure the maintainers would give that a serious consideration for
inclusion. Changing the file format on the other hand is a no go
amongst many of the users (myself included) and developers alike.
Hope my 2¢ shed some light on the implications of a change like this.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-08 15:23 ` Nicolas Richard
@ 2013-03-08 22:06 ` Nicolas Goaziou
2013-03-09 10:52 ` Waldemar Quevedo
2013-03-13 14:07 ` Nicolas Richard
0 siblings, 2 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-08 22:06 UTC (permalink / raw)
To: Nicolas Richard; +Cc: emacs-orgmode
Hello,
"Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> As discussed a few days ago, here is a document describing the complete
>> Org syntax as read by the parser. I also added some comments. I am going
>> to put the Org file on Worg, so anyone can update it and fix mistakes.
>
> [for the record, the org file mentionned by Nicolas is currently at
> <http://orgmode.org/worg/dev/org-syntax.org>]
>
> This looks truly awesome. I give some (naïve) comments below, from my
> non-expert point of view.
Thank you for your comments.
>> The paragraph is the unit of measurement. An element defines
>> syntactical parts that are at the same level as a paragraph, i.e. which
>> cannot contain or be included in a paragraph. An object is a part that
>> could be included in an element. Greater elements are all parts that
>> can contain an element.
>
> This is very clear but I'm slightly worried about confusion that might come
> from "Greater element" not being an "element", and the word "element"
> being a common word :
element means "Element + Greater Element". It is to be understood as the
opposite of object. I think there shouldn't be much ambiguity according
to context.
>> Empty lines belong to the largest element ending before them. For
>> example, in a list, empty lines between items belong are part of the
>> item before them, but empty lines at the end of a list belong to the
>> plain list element.
>
> Is the word "element" (in /largest element ending.../) to be understood
> as an "element" from the above definition ? I guess not (this would
> require both list items and plain lists to be on the level 'element',
> from your example)
Again, it's a shortcut for "in the largest element or greater element
ending before them".
>> 1 Headlines and Sections
>> ════════════════════════
>>
>> A headline is defined as:
>>
>> ╭────
>> │ STARS KEYWORD PRIORITY TITLE TAGS
>> ╰────
>>
>> STARS is a string starting at column 0 and containing at least one
>> asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
>> library is loaded). It’s the sole compulsory part of a headline.
>
> Perhaps it should be mentionned that STARS has to end by a space (see
> below).
I agree.
> I suggest adding : The number of stars defines the level of the
> headline.
Does it belong to the syntax definition? Level is how Org uses syntax
internally. Also the sentence, although right, is misleading, because
level definition also depends on `org-odd-levels-only'.
>> KEYWORD is a TODO keyword, which have to belong to the list defined in
>> `org-todo-keywords'. Case is significant.
>
> The option #+TODO: is used also.
Then it should be ~org-todo-keywords-1~, which is where all TODO
keywords are added eventually.
>> PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
>> sign # and enclosed within square brackets. Case is significant.
>
> I suggest dropping "Case is significant" (or maybe give the whole story :
> IIRC, it is the ascii code of the given letter that is used as
> priority)
I'm not sure that the purpose of this document should be to explain how
syntax will be used.
>> ╭────
>> │ *
>
> I don't see a space character after that one in your email and it
> doesn't seem to be recognized as a headline by the exporter (hence my
> above suggestion)
>
>> If the first word appearing in the title is `org-comment-keyword',
>> the
>
> That should be `org-comment-string' I guess.
Indeed. Btw, I think this variable should be a defconst, not
a defcustom. It just makes things harder for little benefit.
>> A headline contains directly at most one section, followed by any
>> number of headlines. Only a section can contain another section.
>
> From what I understand, "A section is delimited by two headlines (and
> buffer limits)." [I initially thought it was "by two headlines of the
> same level", which it is not from the structure example you give
> later.]
"Only a section can contain another section" is wrong. It should be
removed.
>> A section contains directly any greater element or element. Only
>> a headline can contain a section. As an exception, text before the
>> first headline in the document also belongs to a section.
>
>
>> In a quoted headline contains a section, the latter will be considered
>> as a “quote section”.
>
> s/In/If/
Yes.
> unsure: s/quote section/quoted section/ ?
No, it is "quote section".
>> BACKEND is a string constituted of alpha-numeric characters, hyphens
>> or underscores.
>
> I suggest: BACKEND is a string which is an element of (mapcar 'car
> org-export-registered-backends).
Not really. Parser can understand #+attr_foo even if foo is not
registered as a valid back-end.
>> OPTIONAL and VALUE can contain any character but a new line. Only
>> keywords in `org-element-dual-keywords' can have an optional value.
>
> I guess OPTIONAL cannot contain a closing square bracket ]
It can.
>> An affiliated keyword can appear on multiple lines if KEY belongs to
>> `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
>> VALUE”.
>
> I suggest s/on multiple lines/more than once/
Ok.
>> PARAMETERS can contain any character, and can be omitted.
>
> any other than new line, I guess.
Correct.
>> CONTENTS can contain any element, but another greater block of the
>> same type.
>
> What is the type of a greater block ? the /name/ ?
Yes. I think it should be better to say something like: CONTENTS cannot
contain the string "#+END_NAME" on a line on its own.
> I did have a quick look at the rest of your mail, and it is very nice to
> have all of it written down explicitly, so again a big thanks for all of
> this (and the rest of your) work. Unfortunately I don't have much time
> right now to read it thoroughtfully, so just one single comment :
>
>> Even the LaTeX community suggests to use `\(...\)' over
>> `$...$'. — ngz
>
> AFAIK that's not for technical reasons and also I would be curious to
> know who does that in real documents : '$' is so much more convenient.
Yes, I mixed $$...$$ and $...$. This sentence could be removed. Though
I still maintain my POV about $...$. It may be convenient in a latex
file, but in a free-form text format like Org, it's error prone.
I also forgot to write about optional #+tblfm: line below Org tables.
Would you (or Someone) mind updating the org-syntax.org file on Worg?
Thank you again.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* interoperability matters Re: (no subject)
2013-03-08 20:39 ` T.F. Torrey
2013-03-08 21:19 ` Nicolas Goaziou
@ 2013-03-08 22:15 ` Gregor Zattler
2013-03-09 14:09 ` Bastien
2 siblings, 0 replies; 135+ messages in thread
From: Gregor Zattler @ 2013-03-08 22:15 UTC (permalink / raw)
To: emacs-orgmode
Hi T.F.,
* T.F. Torrey <tftorrey@tftorrey.com> [08. Mar. 2013]:
> Plain text is great because I can do whatever I want. What I come up
> with might not work correctly in other tools (or anything at all), but I
> have the freedom to do interesting things, and to have my files look
> just the way I want them to.
One argument against changing the headlne marker was
interoperability: Share org files with others, use other tools to
manipulate org files. Interoperability is a product of
rules/formats/protocols.
Email is a plain text protocol too, but some headers are required
for interoperability. It wouldn't make sense for instance for me
to use my freedom to create/change headers arbitrary, "and to
have my emails look just the way I want them to". E.g. to use
german words Betreff, Datum, An, Von instead of Subject, Date,
To, From, only because I can --> no mail transport agent would
handle this plain text file.
Regards, Gregor
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-08 22:06 ` Nicolas Goaziou
@ 2013-03-09 10:52 ` Waldemar Quevedo
2013-03-09 14:23 ` Carsten Dominik
` (3 more replies)
2013-03-13 14:07 ` Nicolas Richard
1 sibling, 4 replies; 135+ messages in thread
From: Waldemar Quevedo @ 2013-03-09 10:52 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Nicolas Richard, emacs-orgmode
Hey Nicolas, this looks very detailed and I think it could be useful
for people trying to write other parsers implementations for org-mode.
Thanks for sharing!
By the way, does it exist somewhere a set of examples of Emacs
org-mode -> html conversion for all org-mode features?
(How are changes from org-mode -> html converstion from Emacs tested
during development?)
I am mantaining the org-ruby gem which is used to render org-mode texts to html,
and currently there is no "roadmap" of features to implement for it.
As a result, features and tweaks are added to the library
as long as someone submits a ticket requesting the feature in Github.
(Here is a list of the export features supported in case someone wants
to take a look:
https://github.com/bdewey/org-ruby/tree/master/spec/html_examples )
Having a set of examples features from org-mode would be very useful
to see how much coverage other implementations of org-mode exporting
features have.
Cheers everyone, keep org-mode being an awesome tool :)
- Waldemar
On Sat, Mar 9, 2013 at 7:06 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> "Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>> As discussed a few days ago, here is a document describing the complete
>>> Org syntax as read by the parser. I also added some comments. I am going
>>> to put the Org file on Worg, so anyone can update it and fix mistakes.
>>
>> [for the record, the org file mentionned by Nicolas is currently at
>> <http://orgmode.org/worg/dev/org-syntax.org>]
>>
>> This looks truly awesome. I give some (naïve) comments below, from my
>> non-expert point of view.
>
> Thank you for your comments.
>
>>> The paragraph is the unit of measurement. An element defines
>>> syntactical parts that are at the same level as a paragraph, i.e. which
>>> cannot contain or be included in a paragraph. An object is a part that
>>> could be included in an element. Greater elements are all parts that
>>> can contain an element.
>>
>> This is very clear but I'm slightly worried about confusion that might come
>> from "Greater element" not being an "element", and the word "element"
>> being a common word :
>
> element means "Element + Greater Element". It is to be understood as the
> opposite of object. I think there shouldn't be much ambiguity according
> to context.
>
>>> Empty lines belong to the largest element ending before them. For
>>> example, in a list, empty lines between items belong are part of the
>>> item before them, but empty lines at the end of a list belong to the
>>> plain list element.
>>
>> Is the word "element" (in /largest element ending.../) to be understood
>> as an "element" from the above definition ? I guess not (this would
>> require both list items and plain lists to be on the level 'element',
>> from your example)
>
> Again, it's a shortcut for "in the largest element or greater element
> ending before them".
>
>>> 1 Headlines and Sections
>>> ════════════════════════
>>>
>>> A headline is defined as:
>>>
>>> ╭────
>>> │ STARS KEYWORD PRIORITY TITLE TAGS
>>> ╰────
>>>
>>> STARS is a string starting at column 0 and containing at least one
>>> asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
>>> library is loaded). It’s the sole compulsory part of a headline.
>>
>> Perhaps it should be mentionned that STARS has to end by a space (see
>> below).
>
> I agree.
>
>> I suggest adding : The number of stars defines the level of the
>> headline.
>
> Does it belong to the syntax definition? Level is how Org uses syntax
> internally. Also the sentence, although right, is misleading, because
> level definition also depends on `org-odd-levels-only'.
>
>>> KEYWORD is a TODO keyword, which have to belong to the list defined in
>>> `org-todo-keywords'. Case is significant.
>>
>> The option #+TODO: is used also.
>
> Then it should be ~org-todo-keywords-1~, which is where all TODO
> keywords are added eventually.
>
>>> PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
>>> sign # and enclosed within square brackets. Case is significant.
>>
>> I suggest dropping "Case is significant" (or maybe give the whole story :
>> IIRC, it is the ascii code of the given letter that is used as
>> priority)
>
> I'm not sure that the purpose of this document should be to explain how
> syntax will be used.
>
>>> ╭────
>>> │ *
>>
>> I don't see a space character after that one in your email and it
>> doesn't seem to be recognized as a headline by the exporter (hence my
>> above suggestion)
>>
>>> If the first word appearing in the title is `org-comment-keyword',
>>> the
>>
>> That should be `org-comment-string' I guess.
>
> Indeed. Btw, I think this variable should be a defconst, not
> a defcustom. It just makes things harder for little benefit.
>
>>> A headline contains directly at most one section, followed by any
>>> number of headlines. Only a section can contain another section.
>>
>> From what I understand, "A section is delimited by two headlines (and
>> buffer limits)." [I initially thought it was "by two headlines of the
>> same level", which it is not from the structure example you give
>> later.]
>
> "Only a section can contain another section" is wrong. It should be
> removed.
>
>>> A section contains directly any greater element or element. Only
>>> a headline can contain a section. As an exception, text before the
>>> first headline in the document also belongs to a section.
>>
>>
>>> In a quoted headline contains a section, the latter will be considered
>>> as a “quote section”.
>>
>> s/In/If/
>
> Yes.
>
>> unsure: s/quote section/quoted section/ ?
>
> No, it is "quote section".
>
>>> BACKEND is a string constituted of alpha-numeric characters, hyphens
>>> or underscores.
>>
>> I suggest: BACKEND is a string which is an element of (mapcar 'car
>> org-export-registered-backends).
>
> Not really. Parser can understand #+attr_foo even if foo is not
> registered as a valid back-end.
>
>>> OPTIONAL and VALUE can contain any character but a new line. Only
>>> keywords in `org-element-dual-keywords' can have an optional value.
>>
>> I guess OPTIONAL cannot contain a closing square bracket ]
>
> It can.
>
>>> An affiliated keyword can appear on multiple lines if KEY belongs to
>>> `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
>>> VALUE”.
>>
>> I suggest s/on multiple lines/more than once/
>
> Ok.
>
>>> PARAMETERS can contain any character, and can be omitted.
>>
>> any other than new line, I guess.
>
> Correct.
>
>>> CONTENTS can contain any element, but another greater block of the
>>> same type.
>>
>> What is the type of a greater block ? the /name/ ?
>
> Yes. I think it should be better to say something like: CONTENTS cannot
> contain the string "#+END_NAME" on a line on its own.
>
>> I did have a quick look at the rest of your mail, and it is very nice to
>> have all of it written down explicitly, so again a big thanks for all of
>> this (and the rest of your) work. Unfortunately I don't have much time
>> right now to read it thoroughtfully, so just one single comment :
>>
>>> Even the LaTeX community suggests to use `\(...\)' over
>>> `$...$'. — ngz
>>
>> AFAIK that's not for technical reasons and also I would be curious to
>> know who does that in real documents : '$' is so much more convenient.
>
> Yes, I mixed $$...$$ and $...$. This sentence could be removed. Though
> I still maintain my POV about $...$. It may be convenient in a latex
> file, but in a free-form text format like Org, it's error prone.
>
> I also forgot to write about optional #+tblfm: line below Org tables.
>
> Would you (or Someone) mind updating the org-syntax.org file on Worg?
>
> Thank you again.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-08 20:39 ` T.F. Torrey
2013-03-08 21:19 ` Nicolas Goaziou
2013-03-08 22:15 ` interoperability matters " Gregor Zattler
@ 2013-03-09 14:09 ` Bastien
2013-03-10 22:40 ` T.F. Torrey
2 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-09 14:09 UTC (permalink / raw)
To: T.F. Torrey; +Cc: emacs-orgmode
Hi Terry,
I hear you. I completely agree that Org should not be less flexible
than it has been so far. At least not for very good reasons, shared
by both the developers and the users. IOW: ease of maintainance and
code consistency should not let us introduce rigidity for the users.
Let's focus on the regressions and let's try to fix the ones that we
can fix.
As discussions have shown so far, Nicolas holds the keys when it comes
to honoring Org's consistency regarding its syntax -- the document he
wrote will help us all to speak about the same syntax and rules. But
as you may have felt, I'm more on the "user conveniency" side, even if
we need to sacrifice some consistency. There is a balance here, and I
hope we keep a good one.
So as I said: let's focus on what you perceive as regressions wrt what
Org allows.
The subject of this thread does not fall in this category: headlines
have always been starting with stars, there is no regression here. On
the contrary: a few years ago, we had no answer to this FAQ, now we
can help users with several solution when the problem is aesthetic.
Finally, I agree with Suvayu that the problem *is* mostly aesthetic,
so the solutions we provide are enough (i.e., the FAQ, org-bullets.el
in contrib/.) The question is rather whether we should have an Org
option in core to allow users to tweak the appearance of the stars:
my answer here is "no", because I don't see why users would stop here.
Once we offer such an option for headlines, why not for comments and
other characters with a syntactic role? (I replied a question on
stackoverflow on how to use "%" instead of "#" for comments...)
Anyway -- Org still stands on the side of users' freedom, let's
fix the real regressions.
Thanks!
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 10:52 ` Waldemar Quevedo
@ 2013-03-09 14:23 ` Carsten Dominik
2013-03-09 14:42 ` Nicolas Goaziou
2013-03-15 20:22 ` Nicolas Goaziou
` (2 subsequent siblings)
3 siblings, 1 reply; 135+ messages in thread
From: Carsten Dominik @ 2013-03-09 14:23 UTC (permalink / raw)
To: Waldemar Quevedo; +Cc: Nicolas Richard, emacs-orgmode, Nicolas Goaziou
On 9.3.2013, at 11:52, Waldemar Quevedo <waldemar.quevedo@gmail.com> wrote:
> Hey Nicolas, this looks very detailed and I think it could be useful
> for people trying to write other parsers implementations for org-mode.
> Thanks for sharing!
Maybe someone knowledgeable can turn Nicola's description into a formal parser description that can then be used by something like yacc to produce code for arbitrary languages? I am not sure if I am making sense though.
- Carsten
>
> By the way, does it exist somewhere a set of examples of Emacs
> org-mode -> html conversion for all org-mode features?
> (How are changes from org-mode -> html converstion from Emacs tested
> during development?)
>
> I am mantaining the org-ruby gem which is used to render org-mode texts to html,
> and currently there is no "roadmap" of features to implement for it.
> As a result, features and tweaks are added to the library
> as long as someone submits a ticket requesting the feature in Github.
> (Here is a list of the export features supported in case someone wants
> to take a look:
> https://github.com/bdewey/org-ruby/tree/master/spec/html_examples )
> Having a set of examples features from org-mode would be very useful
> to see how much coverage other implementations of org-mode exporting
> features have.
>
> Cheers everyone, keep org-mode being an awesome tool :)
>
> - Waldemar
>
> On Sat, Mar 9, 2013 at 7:06 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> Hello,
>>
>> "Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:
>>
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>> As discussed a few days ago, here is a document describing the complete
>>>> Org syntax as read by the parser. I also added some comments. I am going
>>>> to put the Org file on Worg, so anyone can update it and fix mistakes.
>>>
>>> [for the record, the org file mentionned by Nicolas is currently at
>>> <http://orgmode.org/worg/dev/org-syntax.org>]
>>>
>>> This looks truly awesome. I give some (naïve) comments below, from my
>>> non-expert point of view.
>>
>> Thank you for your comments.
>>
>>>> The paragraph is the unit of measurement. An element defines
>>>> syntactical parts that are at the same level as a paragraph, i.e. which
>>>> cannot contain or be included in a paragraph. An object is a part that
>>>> could be included in an element. Greater elements are all parts that
>>>> can contain an element.
>>>
>>> This is very clear but I'm slightly worried about confusion that might come
>>> from "Greater element" not being an "element", and the word "element"
>>> being a common word :
>>
>> element means "Element + Greater Element". It is to be understood as the
>> opposite of object. I think there shouldn't be much ambiguity according
>> to context.
>>
>>>> Empty lines belong to the largest element ending before them. For
>>>> example, in a list, empty lines between items belong are part of the
>>>> item before them, but empty lines at the end of a list belong to the
>>>> plain list element.
>>>
>>> Is the word "element" (in /largest element ending.../) to be understood
>>> as an "element" from the above definition ? I guess not (this would
>>> require both list items and plain lists to be on the level 'element',
>>> from your example)
>>
>> Again, it's a shortcut for "in the largest element or greater element
>> ending before them".
>>
>>>> 1 Headlines and Sections
>>>> ════════════════════════
>>>>
>>>> A headline is defined as:
>>>>
>>>> ╭────
>>>> │ STARS KEYWORD PRIORITY TITLE TAGS
>>>> ╰────
>>>>
>>>> STARS is a string starting at column 0 and containing at least one
>>>> asterisk (and up to `org-inlinetask-min-level' if `org-inlinetask'
>>>> library is loaded). It’s the sole compulsory part of a headline.
>>>
>>> Perhaps it should be mentionned that STARS has to end by a space (see
>>> below).
>>
>> I agree.
>>
>>> I suggest adding : The number of stars defines the level of the
>>> headline.
>>
>> Does it belong to the syntax definition? Level is how Org uses syntax
>> internally. Also the sentence, although right, is misleading, because
>> level definition also depends on `org-odd-levels-only'.
>>
>>>> KEYWORD is a TODO keyword, which have to belong to the list defined in
>>>> `org-todo-keywords'. Case is significant.
>>>
>>> The option #+TODO: is used also.
>>
>> Then it should be ~org-todo-keywords-1~, which is where all TODO
>> keywords are added eventually.
>>
>>>> PRIORITY is a priority cookie, i.e. a single letter preceded by a hash
>>>> sign # and enclosed within square brackets. Case is significant.
>>>
>>> I suggest dropping "Case is significant" (or maybe give the whole story :
>>> IIRC, it is the ascii code of the given letter that is used as
>>> priority)
>>
>> I'm not sure that the purpose of this document should be to explain how
>> syntax will be used.
>>
>>>> ╭────
>>>> │ *
>>>
>>> I don't see a space character after that one in your email and it
>>> doesn't seem to be recognized as a headline by the exporter (hence my
>>> above suggestion)
>>>
>>>> If the first word appearing in the title is `org-comment-keyword',
>>>> the
>>>
>>> That should be `org-comment-string' I guess.
>>
>> Indeed. Btw, I think this variable should be a defconst, not
>> a defcustom. It just makes things harder for little benefit.
>>
>>>> A headline contains directly at most one section, followed by any
>>>> number of headlines. Only a section can contain another section.
>>>
>>> From what I understand, "A section is delimited by two headlines (and
>>> buffer limits)." [I initially thought it was "by two headlines of the
>>> same level", which it is not from the structure example you give
>>> later.]
>>
>> "Only a section can contain another section" is wrong. It should be
>> removed.
>>
>>>> A section contains directly any greater element or element. Only
>>>> a headline can contain a section. As an exception, text before the
>>>> first headline in the document also belongs to a section.
>>>
>>>
>>>> In a quoted headline contains a section, the latter will be considered
>>>> as a “quote section”.
>>>
>>> s/In/If/
>>
>> Yes.
>>
>>> unsure: s/quote section/quoted section/ ?
>>
>> No, it is "quote section".
>>
>>>> BACKEND is a string constituted of alpha-numeric characters, hyphens
>>>> or underscores.
>>>
>>> I suggest: BACKEND is a string which is an element of (mapcar 'car
>>> org-export-registered-backends).
>>
>> Not really. Parser can understand #+attr_foo even if foo is not
>> registered as a valid back-end.
>>
>>>> OPTIONAL and VALUE can contain any character but a new line. Only
>>>> keywords in `org-element-dual-keywords' can have an optional value.
>>>
>>> I guess OPTIONAL cannot contain a closing square bracket ]
>>
>> It can.
>>
>>>> An affiliated keyword can appear on multiple lines if KEY belongs to
>>>> `org-element-multiple-keywords' or if its pattern is “#+ATTR_BACKEND:
>>>> VALUE”.
>>>
>>> I suggest s/on multiple lines/more than once/
>>
>> Ok.
>>
>>>> PARAMETERS can contain any character, and can be omitted.
>>>
>>> any other than new line, I guess.
>>
>> Correct.
>>
>>>> CONTENTS can contain any element, but another greater block of the
>>>> same type.
>>>
>>> What is the type of a greater block ? the /name/ ?
>>
>> Yes. I think it should be better to say something like: CONTENTS cannot
>> contain the string "#+END_NAME" on a line on its own.
>>
>>> I did have a quick look at the rest of your mail, and it is very nice to
>>> have all of it written down explicitly, so again a big thanks for all of
>>> this (and the rest of your) work. Unfortunately I don't have much time
>>> right now to read it thoroughtfully, so just one single comment :
>>>
>>>> Even the LaTeX community suggests to use `\(...\)' over
>>>> `$...$'. — ngz
>>>
>>> AFAIK that's not for technical reasons and also I would be curious to
>>> know who does that in real documents : '$' is so much more convenient.
>>
>> Yes, I mixed $$...$$ and $...$. This sentence could be removed. Though
>> I still maintain my POV about $...$. It may be convenient in a latex
>> file, but in a free-form text format like Org, it's error prone.
>>
>> I also forgot to write about optional #+tblfm: line below Org tables.
>>
>> Would you (or Someone) mind updating the org-syntax.org file on Worg?
>>
>> Thank you again.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 14:23 ` Carsten Dominik
@ 2013-03-09 14:42 ` Nicolas Goaziou
2013-03-09 15:05 ` Carsten Dominik
0 siblings, 1 reply; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-09 14:42 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Nicolas Richard, Waldemar Quevedo, emacs-orgmode
Hello,
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On 9.3.2013, at 11:52, Waldemar Quevedo <waldemar.quevedo@gmail.com> wrote:
>
>> Hey Nicolas, this looks very detailed and I think it could be useful
>> for people trying to write other parsers implementations for org-mode.
>> Thanks for sharing!
>
> Maybe someone knowledgeable can turn Nicola's description into
> a formal parser description that can then be used by something like
> yacc to produce code for arbitrary languages? I am not sure if I am
> making sense though.
*cough* you mean GNU Bison or, perhaps better, Wisent (from Semantic).
I don't know how well they handle context sensitive grammars, though..
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 14:42 ` Nicolas Goaziou
@ 2013-03-09 15:05 ` Carsten Dominik
0 siblings, 0 replies; 135+ messages in thread
From: Carsten Dominik @ 2013-03-09 15:05 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Nicolas Richard, Waldemar Quevedo, emacs-orgmode
On 9.3.2013, at 15:42, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On 9.3.2013, at 11:52, Waldemar Quevedo <waldemar.quevedo@gmail.com> wrote:
>>
>>> Hey Nicolas, this looks very detailed and I think it could be useful
>>> for people trying to write other parsers implementations for org-mode.
>>> Thanks for sharing!
>>
>> Maybe someone knowledgeable can turn Nicola's description into
>> a formal parser description that can then be used by something like
>> yacc to produce code for arbitrary languages? I am not sure if I am
>> making sense though.
>
> *cough* you mean GNU Bison
Told you I am not sure if I am making sense.
Anyway, a general parser would be useful for extensions like org-ruby...
- Carsten
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
` (5 preceding siblings ...)
2013-03-08 15:23 ` Nicolas Richard
@ 2013-03-09 23:16 ` Achim Gratz
2013-03-09 23:49 ` Nicolas Goaziou
2013-03-17 7:18 ` Achim Gratz
7 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2013-03-09 23:16 UTC (permalink / raw)
To: emacs-orgmode
Hi Nicolas,
here are my first comments. I'm still trying to wrap my head around some
things, so if I'm off the map on something, please be patient.
Do you mind if I fix some obvious typos directly on Worg or do you'd
rather want patches?
Nicolas Goaziou writes:
> A core concept in this syntax is that only headlines and sections are
> context-free[1][2]. Every other syntactical part only exists within
> specific environments.
Blank lines or empty lines are also context-free syntactical elements,
I'd think.
> Three categories are used to classify these environments: “Greater
> elements”, “elements”, and “objects”, from the broadest scope to the
> narrowest.
It might be easier to talk about those things if "Greater Element" was
called "Collection" to perhaps keep with the thingies theme of naming
the syntax.
> The paragraph is the unit of measurement. An element defines
> syntactical parts that are at the same level as a paragraph, i.e. which
> cannot contain or be included in a paragraph. An object is a part that
> could be included in an element. Greater elements are all parts that
> can contain an element.
Here's my main contention with that model: I think there should be an
greater element, maybe named "paragraph block" that translates into a
paragraph at the backend level. Most backends will have a paragraph
model that is much less limited than what the current definition of an
Org paragraph is. This could be optionally be an implicit greater
block that is defined by the presence or absence of blank lines between
elements, I'd think.
> 3.1 Greater Blocks
> ──────────────────
The same naming confusion as with the various "elements", for now I'd
link to think of these as "Box".
> Greater blocks consist in the following pattern:
>
> ╭────
> │ #+BEGIN_NAME PARAMETERS
> │ CONTENTS
> │ #+END_NAME
> ╰────
I'm beginning to wonder if these should have the same syntax as blocks.
Maybe that's a too fine a distinction visually, but adding a colon would
disambiguate the greater blocks from the normal ones. In other words
#+BEGIN_CENTER: humdum
…
#+END_CENTER:
would be a center block, while
#+BEGIN_CENTER humdum
…
#+END_CENTER
would be an export block for the center backend.
> 4.2 Blocks
> ──────────
>
> Like [greater blocks], pattern for blocks is:
>
> ╭────
> │ #+BEGIN_NAME DATA
> │ CONTENTS
> │ #+END_NAME
> ╰────
[…]
> DATA can contain any character but a new line.
I'd keep with PARAMETERS here.
> If NAME is a string matching the name of any export back-end loaded,
> the block will be an “export block”.
Conversely, blocks that are not having a recognizable name will simply
insert their content as if the block markers were not there, e.g. it
seems to treat these as parsed blocks. I don't think this should
happen, instead Org should parse this as an unknown export backend and
drop the content with a warning, not unlike a comment.
This will be a major sticking point with external parsers: they'd
otherwise need to know about the Org export backends to when to use the
content of the block and when not. A portable Org document should be
able to specify which export backends it expects to be available (and
maybe what standard backend it is derived from) to elicit the correct
behaviour.
> CONTENTS can contain any character, including new lines. Though it
> will only contain Org objects if the block is a verse block.
> Otherwise, contents will not be parsed.
Would it make sense to make a general distinction between parsed and
non-parsed blocks based on some configuration, even though this would
produce the same issue as with export backends?
> I suggest to remove angle links. If one needs spaces in
> PATH, she can use standard link syntax instead.
They are very ubiquitous on certain platforms, so copy&paste would be
made frustrating there if you'd need to re-format them each time around.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 23:16 ` Achim Gratz
@ 2013-03-09 23:49 ` Nicolas Goaziou
2013-03-10 4:35 ` Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-09 23:49 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> Do you mind if I fix some obvious typos directly on Worg or do you'd
> rather want patches?
Please go ahead. This is on Worg so anyone can improve it.
> Nicolas Goaziou writes:
>> A core concept in this syntax is that only headlines and sections are
>> context-free[1][2]. Every other syntactical part only exists within
>> specific environments.
>
> Blank lines or empty lines are also context-free syntactical elements,
> I'd think.
No, the aren't, as they belong to the broadest element ending before
them. So you need to know what this element is.
>> Three categories are used to classify these environments: “Greater
>> elements”, “elements”, and “objects”, from the broadest scope to the
>> narrowest.
>
> It might be easier to talk about those things if "Greater Element" was
> called "Collection" to perhaps keep with the thingies theme of naming
> the syntax.
Collection could also be ambiguous as a paragraph may be seen as
a collection of objects.
>> The paragraph is the unit of measurement. An element defines
>> syntactical parts that are at the same level as a paragraph, i.e. which
>> cannot contain or be included in a paragraph. An object is a part that
>> could be included in an element. Greater elements are all parts that
>> can contain an element.
>
> Here's my main contention with that model: I think there should be an
> greater element, maybe named "paragraph block" that translates into a
> paragraph at the backend level. Most backends will have a paragraph
> model that is much less limited than what the current definition of an
> Org paragraph is. This could be optionally be an implicit greater
> block that is defined by the presence or absence of blank lines between
> elements, I'd think.
I don't get it. What would be the exact definition of a "paragraph
block"? What limitations are you talking about?
>> 3.1 Greater Blocks
>> ──────────────────
>
> The same naming confusion as with the various "elements", for now I'd
> link to think of these as "Box".
This naming was for the org-syntax file only. "Greater blocks" means
nothing for org-element.el, but "center block", "quote block", "special
block" do.
>> Greater blocks consist in the following pattern:
>>
>> ╭────
>> │ #+BEGIN_NAME PARAMETERS
>> │ CONTENTS
>> │ #+END_NAME
>> ╰────
>
> I'm beginning to wonder if these should have the same syntax as blocks.
> Maybe that's a too fine a distinction visually, but adding a colon would
> disambiguate the greater blocks from the normal ones. In other words
>
> #+BEGIN_CENTER: humdum
> &
> #+END_CENTER:
>
> would be a center block, while
>
> #+BEGIN_CENTER humdum
> &
> #+END_CENTER
>
> would be an export block for the center backend.
I agree. More on that below.
>> 4.2 Blocks
>> ──────────
>>
>> Like [greater blocks], pattern for blocks is:
>>
>> ╭────
>> │ #+BEGIN_NAME DATA
>> │ CONTENTS
>> │ #+END_NAME
>> ╰────
> […]
>> DATA can contain any character but a new line.
>
> I'd keep with PARAMETERS here.
Ok. Just fix it.
>> If NAME is a string matching the name of any export back-end loaded,
>> the block will be an “export block”.
>
> Conversely, blocks that are not having a recognizable name will simply
> insert their content as if the block markers were not there, e.g. it
> seems to treat these as parsed blocks.
You are talking about "special blocks", right? They have a special
purpose. In latex back-end,
#+begin_special
...
#+end_special
becomes
\begin{special}
...
\end{special}
IOW this is an Org feature.
> I don't think this should happen, instead Org should parse this as an
> unknown export backend and drop the content with a warning, not unlike
> a comment.
This would remove special blocks.
> This will be a major sticking point with external parsers: they'd
> otherwise need to know about the Org export backends to when to use the
> content of the block and when not. A portable Org document should be
> able to specify which export backends it expects to be available (and
> maybe what standard backend it is derived from) to elicit the correct
> behaviour.
I agree, as notified above. If we want to separate Org /format/ from
Emacs, we need to separate special blocks from export blocks. The former
cannot be the fallback type when the latter isn't recognized.
In that case, a different syntax for export blocks would be needed.
Maybe the colons you suggested above. I think that something more
visible would be better, though.
>> CONTENTS can contain any character, including new lines. Though it
>> will only contain Org objects if the block is a verse block.
>> Otherwise, contents will not be parsed.
>
> Would it make sense to make a general distinction between parsed and
> non-parsed blocks based on some configuration, even though this would
> produce the same issue as with export backends?
This is inherent from the block type. This mustn't be configurable.
There is no point in parsing a src-block, for example. On the other
hand, if you don't parse (partially) contents of a verse-block, you get
an example-block, and one of them becomes useless.
Then, there are special blocks. It was suggested, a few days ago, that
a parameter could be set in order to tell the parser what to do with
their contents. That's an interesting idea. But it only makes sense if
there is also a way to specify a transformation function on these
contents (otherwise, an export block would be sufficient). Also the same
could be achieved with Babel, the non-parsed data being an example
block, and the transformation function a src-block.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 23:49 ` Nicolas Goaziou
@ 2013-03-10 4:35 ` Jambunathan K
2013-03-10 7:08 ` Nicolas Goaziou
0 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-10 4:35 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Achim Gratz, emacs-orgmode
Nicolas
>> Do you mind if I fix some obvious typos directly on Worg or do you'd
>> rather want patches?
>
> Please go ahead. This is on Worg so anyone can improve it.
Please consider adding the Org spec (and also the exporter reference)
document to the Org manual.
This will be a good excuse for exercising the TexInfo exporter and see
where it leads.
Committing to Org or Worg has same load cycle. I feel there is more
value if it is right within the Org manual (i.e, part of Emacs).
Only reason you may want to have it on Worg is possibly because it is
likely to be read by wider audience. People seem to like browsers.
(You can consider building a standalone PDF/HTML document out of .texi
sources and have people read it)
--
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 4:35 ` Jambunathan K
@ 2013-03-10 7:08 ` Nicolas Goaziou
2013-03-10 10:14 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-10 7:08 UTC (permalink / raw)
To: Jambunathan K; +Cc: Achim Gratz, emacs-orgmode
Hello,
Jambunathan K <kjambunathan@gmail.com> writes:
> Please consider adding the Org spec (and also the exporter reference)
> document to the Org manual.
>
> This will be a good excuse for exercising the TexInfo exporter and see
> where it leads.
>
> Committing to Org or Worg has same load cycle. I feel there is more
> value if it is right within the Org manual (i.e, part of Emacs).
>
> Only reason you may want to have it on Worg is possibly because it is
> likely to be read by wider audience. People seem to like browsers.
It is not ready to go into the manual in its current state. As specified
in its title, it's nothing more than a draft. Some parts have to be
rewritten, some information is missing, my notes have to be removed,
etc. Once it becomes clear enough, Bastien may consider adding it to the
manual.
The same holds for the exporter document.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 7:08 ` Nicolas Goaziou
@ 2013-03-10 10:14 ` Bastien
2013-03-10 10:16 ` Bastien
` (2 more replies)
0 siblings, 3 replies; 135+ messages in thread
From: Bastien @ 2013-03-10 10:14 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Achim Gratz, emacs-orgmode, Jambunathan K
Hi Nicolas,
the manual would enjoy a subsection in "Hacking" on how to create
a new exporter, either from scratch or as a derived exporter.
(Such a subsection can be short enough, thanks to derived backend.)
From this section, we can throw links to the exporter reference
document and the Org syntax document published on Worgs.
We may also add footnotes referring to the Org syntax relevant
sections, when needed.
But both reference documents don't fit into the manual IMO. They
are great resources for developers, not for users. The footnotes
are enough for advanced users who want to go beyond the manual.
Thanks!
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 10:14 ` Bastien
@ 2013-03-10 10:16 ` Bastien
2013-03-10 13:07 ` Achim Gratz
2013-03-10 15:44 ` Jambunathan K
2013-04-09 16:37 ` Bastien
2 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-10 10:16 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Achim Gratz, emacs-orgmode, Jambunathan K
Bastien <bzg@altern.org> writes:
> But both reference documents don't fit into the manual IMO. They
> are great resources for developers, not for users. The footnotes
> are enough for advanced users who want to go beyond the manual.
That said, we can also bundle both documents into Org's distribution,
as .org files in the doc/ directory. And have a make rule to convert
them to .pdf and info docs.
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 10:16 ` Bastien
@ 2013-03-10 13:07 ` Achim Gratz
2013-03-10 14:11 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2013-03-10 13:07 UTC (permalink / raw)
To: emacs-orgmode
Bastien writes:
> That said, we can also bundle both documents into Org's distribution,
> as .org files in the doc/ directory. And have a make rule to convert
> them to .pdf and info docs.
I don't want to be the party pooper, but if these documents should go
into the distribution, then we must insist that all modifications be FSF
copyrighted, otherwise we'd have to remove and/or rewrite the ones that
aren't when they are incorporated into the distribution.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 13:07 ` Achim Gratz
@ 2013-03-10 14:11 ` Bastien
2013-03-10 16:02 ` Achim Gratz
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2013-03-10 14:11 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Bastien writes:
>> That said, we can also bundle both documents into Org's distribution,
>> as .org files in the doc/ directory. And have a make rule to convert
>> them to .pdf and info docs.
>
> I don't want to be the party pooper, but if these documents should go
> into the distribution, then we must insist that all modifications be FSF
> copyrighted, otherwise we'd have to remove and/or rewrite the ones that
> aren't when they are incorporated into the distribution.
No, the documents can go into the distribution with contributions from
anyone, because they won't be in Emacs. FSF assignment is needed only
for things that go into Emacs.
Best,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 10:14 ` Bastien
2013-03-10 10:16 ` Bastien
@ 2013-03-10 15:44 ` Jambunathan K
2013-03-14 16:58 ` Eric S Fraga
2013-04-09 16:37 ` Bastien
2 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-10 15:44 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Bastien
> But both reference documents don't fit into the manual IMO.
You are a jerk, a BIG JERK.
Jambunathan K.
--
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 14:11 ` Bastien
@ 2013-03-10 16:02 ` Achim Gratz
2013-03-10 16:09 ` Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2013-03-10 16:02 UTC (permalink / raw)
To: emacs-orgmode
Bastien writes:
> No, the documents can go into the distribution with contributions from
> anyone, because they won't be in Emacs. FSF assignment is needed only
> for things that go into Emacs.
I understood that these or substantial parts of it will end up in the
Org manual, which is in Emacs. If that's not the case, then disregard
my comment.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 16:02 ` Achim Gratz
@ 2013-03-10 16:09 ` Jambunathan K
2013-03-10 17:12 ` Achim Gratz
0 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-10 16:09 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
Achim Gratz <Stromeko@nexgo.de> writes:
> Bastien writes:
>> No, the documents can go into the distribution with contributions from
>> anyone, because they won't be in Emacs. FSF assignment is needed only
>> for things that go into Emacs.
>
> I understood that these or substantial parts of it will end up in the
> Org manual, which is in Emacs. If that's not the case, then disregard
> my comment.
Emacs lisp has a manual of it's own. I don't see how Org export
reference *cannot* end in Emacs.
Bastien is doing what(ever) suits his whims and you are approving of it.
I disapprove of what you are doing, Achim. Export syntax deserves to be
part of Org/Emacs. Let the maintainer go to hell. He is talking
irreverently/hand-wavingly about some work which has stretched to good
part of around 3 years. The Orgmode maintainership is in the hands of
the wrong person, he calls shots based on his owh whims and I regret it.
Jambunathan K.
>
>
> Regards,
> Achim.
--
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 16:09 ` Jambunathan K
@ 2013-03-10 17:12 ` Achim Gratz
2013-03-10 21:44 ` Jonathan Leech-Pepin
0 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2013-03-10 17:12 UTC (permalink / raw)
To: emacs-orgmode
Jambunathan K writes:
> Emacs lisp has a manual of it's own. I don't see how Org export
> reference *cannot* end in Emacs.
I said that I'm expecting these references to become part of the
manual(s). I still expect that and will try to help it along, but it
doesn't necessarily need to take the exact sequence of events that I
envisioned.
> Bastien is doing what(ever) suits his whims and you are approving of
> it.
I haven't approved or disapproved anything. I have only stated the
plain fact that if my understanding of the future course of events is
incorrect, then my comment does not apply (and conversely, if it does,
then the issue I've stated needs to be dealt with).
> I disapprove of what you are doing, Achim.
You're welcome. (Sun Tzu, III/2)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 17:12 ` Achim Gratz
@ 2013-03-10 21:44 ` Jonathan Leech-Pepin
0 siblings, 0 replies; 135+ messages in thread
From: Jonathan Leech-Pepin @ 2013-03-10 21:44 UTC (permalink / raw)
To: Achim Gratz; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]
Hello
On 10 March 2013 13:12, Achim Gratz <Stromeko@nexgo.de> wrote:
> Jambunathan K writes:
> > Emacs lisp has a manual of it's own. I don't see how Org export
> > reference *cannot* end in Emacs.
>
> I said that I'm expecting these references to become part of the
> manual(s). I still expect that and will try to help it along, but it
> doesn't necessarily need to take the exact sequence of events that I
> envisioned.
>
I have to agree with Bastien that they do not really fit into the main
Org manual.
Providing them with Emacs (so that they are immediately available) is
a good thing in my mind, however I would put them as a separate
document similarly to how the Elisp manual is separate.
Regards,
Jon
> > Bastien is doing what(ever) suits his whims and you are approving of
> > it.
>
> I haven't approved or disapproved anything. I have only stated the
> plain fact that if my understanding of the future course of events is
> incorrect, then my comment does not apply (and conversely, if it does,
> then the issue I've stated needs to be dealt with).
>
> > I disapprove of what you are doing, Achim.
>
> You're welcome. (Sun Tzu, III/2)
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>
>
>
[-- Attachment #2: Type: text/html, Size: 2174 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-03-09 14:09 ` Bastien
@ 2013-03-10 22:40 ` T.F. Torrey
0 siblings, 0 replies; 135+ messages in thread
From: T.F. Torrey @ 2013-03-10 22:40 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
Thank you for your thoughtful reply. -- T.
Bastien <bzg@altern.org> writes:
> Hi Terry,
>
> I hear you. I completely agree that Org should not be less flexible
> than it has been so far. At least not for very good reasons, shared
> by both the developers and the users. IOW: ease of maintainance and
> code consistency should not let us introduce rigidity for the users.
>
> Let's focus on the regressions and let's try to fix the ones that we
> can fix.
>
> As discussions have shown so far, Nicolas holds the keys when it comes
> to honoring Org's consistency regarding its syntax -- the document he
> wrote will help us all to speak about the same syntax and rules. But
> as you may have felt, I'm more on the "user conveniency" side, even if
> we need to sacrifice some consistency. There is a balance here, and I
> hope we keep a good one.
>
> So as I said: let's focus on what you perceive as regressions wrt what
> Org allows.
>
> The subject of this thread does not fall in this category: headlines
> have always been starting with stars, there is no regression here. On
> the contrary: a few years ago, we had no answer to this FAQ, now we
> can help users with several solution when the problem is aesthetic.
>
> Finally, I agree with Suvayu that the problem *is* mostly aesthetic,
> so the solutions we provide are enough (i.e., the FAQ, org-bullets.el
> in contrib/.) The question is rather whether we should have an Org
> option in core to allow users to tweak the appearance of the stars:
> my answer here is "no", because I don't see why users would stop here.
> Once we offer such an option for headlines, why not for comments and
> other characters with a syntactic role? (I replied a question on
> stackoverflow on how to use "%" instead of "#" for comments...)
>
> Anyway -- Org still stands on the side of users' freedom, let's
> fix the real regressions.
>
> Thanks!
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-08 22:06 ` Nicolas Goaziou
2013-03-09 10:52 ` Waldemar Quevedo
@ 2013-03-13 14:07 ` Nicolas Richard
2013-03-15 20:39 ` Nicolas Goaziou
1 sibling, 1 reply; 135+ messages in thread
From: Nicolas Richard @ 2013-03-13 14:07 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I obviously did not send and actually lost a message I prepared two days
ago. I'll try again.
>> I suggest adding : The number of stars defines the level of the
>> headline.
>
> Does it belong to the syntax definition? Level is how Org uses syntax
> internally. Also the sentence, although right, is misleading, because
> level definition also depends on `org-odd-levels-only'.
I think it's partly in the syntax, since it defines "parentness" for
headlines (the numeric level is of no importance, but the relative level
is used).
>
>> I suggest dropping "Case is significant" (or maybe give the whole story :
>> IIRC, it is the ascii code of the given letter that is used as
>> priority)
>
> I'm not sure that the purpose of this document should be to explain how
> syntax will be used.
That is why I suggested dropping the mention : case is not significant
for the syntax. Very minor though, obviously.
>> That should be `org-comment-string' I guess.
>
> Indeed. Btw, I think this variable should be a defconst, not
> a defcustom. It just makes things harder for little benefit.
As you know, "Comment" is also a french word meaning "how", and that
could very well appear uppercased as the first word of a title. (I'd
personally recommend against uppercasing titles, but I'd understand if
someone wanted to customize the word for such reasons)
> Would you (or Someone) mind updating the org-syntax.org file on Worg?
Please review the attached patch and apply parts as you wish (even if I
wanted to do it myself, I don't have worg access.)
Last word about #+TBLFM: I'm not sure if that should go into the "affiliated
keywords" section (thus rewriting parts of it, because that one goes
below the table, unlike other affiliated keywords) or a special section
on its own. Thus I'm not changing anything wrt that.
From f97c00bfbd8a14d0b2953ee0e8b6817a2b9f0306 Mon Sep 17 00:00:00 2001
From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
Date: Mon, 11 Mar 2013 16:25:21 +0100
Subject: [PATCH] dev/org-syntax.org: minor
---
dev/org-syntax.org | 34 +++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/dev/org-syntax.org b/dev/org-syntax.org
index 9b2a843..a918a75 100644
--- a/dev/org-syntax.org
+++ b/dev/org-syntax.org
@@ -15,7 +15,8 @@ within specific environments.
Three categories are used to classify these environments: "Greater
elements", "elements", and "objects", from the broadest scope to the
-narrowest.
+narrowest. The word "element" is used for both Greater and non-Greater
+elements, the context should make that clear.
The paragraph is the unit of measurement. An element defines
syntactical parts that are at the same level as a paragraph,
@@ -41,16 +42,17 @@ Unless specified otherwise, case is not significant.
STARS KEYWORD PRIORITY TITLE TAGS
#+END_EXAMPLE
- STARS is a string starting at column 0 and containing at least one
+ STARS is a string starting at column 0, containing at least one
asterisk (and up to ~org-inlinetask-min-level~ if =org-inlinetask=
- library is loaded). It's the sole compulsory part of a headline.
+ library is loaded) and ended by a space character. The number of
+ asterisks is used to define the level of the headline. It's the
+ sole compulsory part of a headline.
KEYWORD is a TODO keyword, which has to belong to the list defined
- in ~org-todo-keywords~. Case is significant.
+ in ~org-todo-keywords-1~. Case is significant.
PRIORITY is a priority cookie, i.e. a single letter preceded by
- a hash sign # and enclosed within square brackets. Case is
- significant.
+ a hash sign # and enclosed within square brackets.
TITLE can be made of any character but a new line. Though, it will
match after every other part have been matched.
@@ -71,7 +73,7 @@ Unless specified otherwise, case is not significant.
,**** TODO [#A] COMMENT Title :tag:a2%:
#+END_EXAMPLE
- If the first word appearing in the title is ~org-comment-keyword~,
+ If the first word appearing in the title is ~org-comment-string~,
the headline will be considered as "commented". If that first word
is ~org-quote-string~, it will be considered as "quoted". In both
situations, case is significant.
@@ -82,14 +84,14 @@ Unless specified otherwise, case is not significant.
If ~org-archive-tag~ is one of its tags, it will be considered as
"archived". Case is significant.
- A headline contains directly at most one section, followed by any
- number of headlines. Only a section can contain another section.
+ A headline contains directly one section, followed by any
+ number of deeper level headlines.
A section contains directly any greater element or element. Only
a headline can contain a section. As an exception, text before the
first headline in the document also belongs to a section.
- In a quoted headline contains a section, the latter will be
+ If a quoted headline contains a section, the latter will be
considered as a "quote section".
As an example, consider the following document:
@@ -136,7 +138,8 @@ Unless specified otherwise, case is not significant.
attributes.
This is done by adding specific keywords, named "affiliated
- keywords", just above the element considered, no blank line allowed.
+ keywords", just above the element considered, no blank line
+ allowed.
Affiliated keywords are built upon one of the following patterns:
"#+KEY: VALUE", "#+KEY[OPTIONAL]: VALUE" or "#+ATTR_BACKEND: VALUE".
@@ -150,7 +153,7 @@ Unless specified otherwise, case is not significant.
OPTIONAL and VALUE can contain any character but a new line. Only
"CAPTION" and "RESULTS" keywords can have an optional value.
- An affiliated keyword can appear on multiple lines if KEY is either
+ An affiliated keyword can appear more than once if KEY is either
"CAPTION" or "HEADER" or if its pattern is "#+ATTR_BACKEND: VALUE".
"CAPTION", "AUTHOR", "DATE" and "TITLE" keywords can contain objects
@@ -183,7 +186,8 @@ Unless specified otherwise, case is not significant.
NAME can contain any non-whitespace character.
- PARAMETERS can contain any character, and can be omitted.
+ PARAMETERS can contain any character other than new line, and can
+ be omitted.
If NAME is "CENTER", it will be a "center block". If it is
"QUOTE", it will be a "quote block".
@@ -191,8 +195,8 @@ Unless specified otherwise, case is not significant.
If the block is neither a center block, a quote block or a [[#Blocks][block
element]], it will be a "special block".
- CONTENTS can contain any element, but another greater block of the
- same type.
+ CONTENTS can contain any element, except : a line =#+END_NAME= on
+ its own and lines beginning with STARS must be quoted by a comma.
** Drawers and Property Drawers
:PROPERTIES:
--
1.8.1.4
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 15:44 ` Jambunathan K
@ 2013-03-14 16:58 ` Eric S Fraga
2013-03-14 18:26 ` Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: Eric S Fraga @ 2013-03-14 16:58 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Jambunathan K <kjambunathan@gmail.com> writes:
> You are a jerk, a BIG JERK.
This is completely uncalled. What satisfaction do you gain from this?
This is a brilliant, informative and polite mailing list except when it
comes to your contributions.
Don't bother answering because I've added you to my spam database. I've
not had to do this for an individual for some years now. I'll never see
any of your emails again. Bye.
--
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-14 16:58 ` Eric S Fraga
@ 2013-03-14 18:26 ` Jambunathan K
2013-03-14 18:51 ` David Engster
0 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-14 18:26 UTC (permalink / raw)
To: emacs-orgmode
Eric
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> You are a jerk, a BIG JERK.
>
> This is completely uncalled. What satisfaction do you gain from this?
> This is a brilliant, informative and polite mailing list except when it
> comes to your contributions.
>
> Don't bother answering because I've added you to my spam database. I've
> not had to do this for an individual for some years now. I'll never see
> any of your emails again. Bye.
Still you haven't answered my "Fudging the mail reply headers" question
to my satisfaction. I just let you off the hook (at the last moment)
before charging ahead.
Jambunathan K.
--
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-14 18:26 ` Jambunathan K
@ 2013-03-14 18:51 ` David Engster
2013-03-14 19:03 ` [Out-of-Thread] " Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: David Engster @ 2013-03-14 18:51 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Jambunathan K. writes:
> Still you haven't answered my "Fudging the mail reply headers" question
> to my satisfaction.
http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html
"A mailing list poster can use MFT to express that responses should be
sent to just the list, and not the poster as well. This will happen if
the poster is already subscribed to the list."
-David
^ permalink raw reply [flat|nested] 135+ messages in thread
* [Out-of-Thread] Re: [RFC] Org syntax (draft)
2013-03-14 18:51 ` David Engster
@ 2013-03-14 19:03 ` Jambunathan K
2013-03-14 19:15 ` David Engster
0 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-14 19:03 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> Jambunathan K. writes:
>> Still you haven't answered my "Fudging the mail reply headers" question
>> to my satisfaction.
>
> http://www.gnu.org/software/emacs/manual/html_node/message/Mailing-Lists.html
>
> "A mailing list poster can use MFT to express that responses should be
> sent to just the list, and not the poster as well. This will happen if
> the poster is already subscribed to the list."
(Nicolas, I am sorry. I have added OT to this post)
I know that.
But that doesn't answer the question why Carsten will appear in the To
header of a mail that I reply to a mail I receive from Eric S Fraga.
See my question here:
http://lists.gnu.org/archive/html/emacs-orgmode/2013-02/msg00525.html
If I "wide reply" to your post, I see that the TO header points to the
ML. Why it doesn't happen with Eric S Fraga's post? The said behaviour
will change based on the phase of moon.
I have noticed such fudging of the To headers by Eric for a long time.
Unless there is a satisfactory explanataion, I will assume Eric is
faking innocence.
> -David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)
2013-03-14 19:03 ` [Out-of-Thread] " Jambunathan K
@ 2013-03-14 19:15 ` David Engster
2013-03-14 19:23 ` Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: David Engster @ 2013-03-14 19:15 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Jambunathan K. writes:
> I know that.
>
> But that doesn't answer the question why Carsten will appear in the To
> header of a mail that I reply to a mail I receive from Eric S Fraga.
Because Carsten started the thread and did not set MFT.
-David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)
2013-03-14 19:15 ` David Engster
@ 2013-03-14 19:23 ` Jambunathan K
2013-03-14 19:29 ` David Engster
0 siblings, 1 reply; 135+ messages in thread
From: Jambunathan K @ 2013-03-14 19:23 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> Jambunathan K. writes:
>> I know that.
>>
>> But that doesn't answer the question why Carsten will appear in the To
>> header of a mail that I reply to a mail I receive from Eric S Fraga.
>
> Because Carsten started the thread and did not set MFT.
In this very specific thread - the one I am typing right now, Nicolas
Goaziou doesn't appear in To - why? Normally, when I wide reply to a
Ngz's post it gets sent to him as well as the mailing list.
If your argument is right, Ngz should appear in To or CC headers of the
post. I see only ML address. So what am I missing?
> -David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)
2013-03-14 19:23 ` Jambunathan K
@ 2013-03-14 19:29 ` David Engster
2013-03-14 19:52 ` Jambunathan K
0 siblings, 1 reply; 135+ messages in thread
From: David Engster @ 2013-03-14 19:29 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode
Jambunathan K. writes:
> David Engster <deng@randomsample.de> writes:
>
>> Jambunathan K. writes:
>>> I know that.
>>>
>>> But that doesn't answer the question why Carsten will appear in the To
>>> header of a mail that I reply to a mail I receive from Eric S Fraga.
>>
>> Because Carsten started the thread and did not set MFT.
>
> In this very specific thread - the one I am typing right now, Nicolas
> Goaziou doesn't appear in To - why? Normally, when I wide reply to a
> Ngz's post it gets sent to him as well as the mailing list.
>
> If your argument is right, Ngz should appear in To or CC headers of the
> post. I see only ML address. So what am I missing?
You didn't do a wide reply in <871ubntg32.fsf@gmail.com>.
-David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [Out-of-Thread] Re: [RFC] Org syntax (draft)
2013-03-14 19:29 ` David Engster
@ 2013-03-14 19:52 ` Jambunathan K
0 siblings, 0 replies; 135+ messages in thread
From: Jambunathan K @ 2013-03-14 19:52 UTC (permalink / raw)
To: emacs-orgmode
David Engster <deng@randomsample.de> writes:
> Jambunathan K. writes:
>> David Engster <deng@randomsample.de> writes:
>>
>>> Jambunathan K. writes:
>>>> I know that.
>>>>
>>>> But that doesn't answer the question why Carsten will appear in the To
>>>> header of a mail that I reply to a mail I receive from Eric S Fraga.
>>>
>>> Because Carsten started the thread and did not set MFT.
>>
>> In this very specific thread - the one I am typing right now, Nicolas
>> Goaziou doesn't appear in To - why? Normally, when I wide reply to a
>> Ngz's post it gets sent to him as well as the mailing list.
>>
>> If your argument is right, Ngz should appear in To or CC headers of the
>> post. I see only ML address. So what am I missing?
>
> You didn't do a wide reply in <871ubntg32.fsf@gmail.com>.
I don't what that mail is. My Gnus-foo is just OKish.
Anyways, S W is what I do on all my mails - those that I reply to on the
ML and on those that I reply to from my Inbox.
If I reply to ESF's posts, I might have edited the headers myself.
Normally - 99% of the cases - I don't edit headers by hand.
ps: I don't want to continue this thread further. For your
satisfaction, I am willing to concede that I am wrong.
> -David
>
>
--
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 10:52 ` Waldemar Quevedo
2013-03-09 14:23 ` Carsten Dominik
@ 2013-03-15 20:22 ` Nicolas Goaziou
2013-03-17 18:48 ` Samuel Wales
2013-04-05 17:01 ` Bastien
3 siblings, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-15 20:22 UTC (permalink / raw)
To: Waldemar Quevedo; +Cc: Nicolas Richard, emacs-orgmode
Hello,
Waldemar Quevedo <waldemar.quevedo@gmail.com> writes:
> By the way, does it exist somewhere a set of examples of Emacs
> org-mode -> html conversion for all org-mode features?
> (How are changes from org-mode -> html converstion from Emacs tested
> during development?)
I don't think something like this exists. Though, html back-end supports
all Org syntax described in the document.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-13 14:07 ` Nicolas Richard
@ 2013-03-15 20:39 ` Nicolas Goaziou
0 siblings, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2013-03-15 20:39 UTC (permalink / raw)
To: Nicolas Richard; +Cc: emacs-orgmode
Hello,
"Nicolas Richard" <theonewiththeevillook@yahoo.fr> writes:
> As you know, "Comment" is also a french word meaning "how", and that
> could very well appear uppercased as the first word of a title. (I'd
> personally recommend against uppercasing titles, but I'd understand if
> someone wanted to customize the word for such reasons)
"Comment" is not "COMMENT", as you say. Also, it is a minor annoyance.
On the other hand, crippling portability of Org format because it
depends on an external variable is a major problem.
Therefore, I stand on my ground: I suggest to turn `org-comment-string'
and al. into defconst.
>> Would you (or Someone) mind updating the org-syntax.org file on Worg?
>
> Please review the attached patch and apply parts as you wish (even if I
> wanted to do it myself, I don't have worg access.)
I applied the patch. Thank you.
> Last word about #+TBLFM: I'm not sure if that should go into the "affiliated
> keywords" section (thus rewriting parts of it, because that one goes
> below the table, unlike other affiliated keywords) or a special section
> on its own. Thus I'm not changing anything wrt that.
TBLFM is not an affiliated keyword. It's a keyword specific to Org
tables. It can exist anywhere, but it only makes sense right after
a table.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
` (6 preceding siblings ...)
2013-03-09 23:16 ` Achim Gratz
@ 2013-03-17 7:18 ` Achim Gratz
2013-03-17 9:36 ` Sebastien Vauban
7 siblings, 1 reply; 135+ messages in thread
From: Achim Gratz @ 2013-03-17 7:18 UTC (permalink / raw)
To: emacs-orgmode
Nicolas Goaziou writes:
> As discussed a few days ago, here is a document describing the complete
> Org syntax as read by the parser. I also added some comments. I am going
> to put the Org file on Worg, so anyone can update it and fix mistakes.
after some playing with the Org manual in Org that Tom has been working
on I am starting to think that there should be a way to define the same
macro differently for different export backends. That would be mainly
so that you could have a macro expansion use export snippets tailored to
that backend where (after stripping the export snippets) the expansion
makes little or no sense in other backends. What do you think?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-17 7:18 ` Achim Gratz
@ 2013-03-17 9:36 ` Sebastien Vauban
0 siblings, 0 replies; 135+ messages in thread
From: Sebastien Vauban @ 2013-03-17 9:36 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Achim,
Achim Gratz wrote:
> Nicolas Goaziou writes:
>> As discussed a few days ago, here is a document describing the complete
>> Org syntax as read by the parser. I also added some comments. I am going
>> to put the Org file on Worg, so anyone can update it and fix mistakes.
>
> after some playing with the Org manual in Org that Tom has been working
> on I am starting to think that there should be a way to define the same
> macro differently for different export backends. That would be mainly
> so that you could have a macro expansion use export snippets tailored to
> that backend where (after stripping the export snippets) the expansion
> makes little or no sense in other backends. What do you think?
This is already possible, as once explained by Nicolas on this ML:
╭────
│ You can also have macros generating raw code geared towards LaTeX or HTML
│ back-ends (through export-snippets). For example:
│
│ #+MACRO: my-mod @@e-latex:\something{$1}@@@@e-html:<div class="something">$1</div>@@
│
│ This is an example: {{{my-mod(text)}}}.
╰────
Best regards,
Seb
--
Sebastien Vauban
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 10:52 ` Waldemar Quevedo
2013-03-09 14:23 ` Carsten Dominik
2013-03-15 20:22 ` Nicolas Goaziou
@ 2013-03-17 18:48 ` Samuel Wales
2013-04-05 17:01 ` Bastien
3 siblings, 0 replies; 135+ messages in thread
From: Samuel Wales @ 2013-03-17 18:48 UTC (permalink / raw)
To: Waldemar Quevedo; +Cc: Nicolas Richard, emacs-orgmode, Nicolas Goaziou
On 3/9/13, Waldemar Quevedo <waldemar.quevedo@gmail.com> wrote:
> By the way, does it exist somewhere a set of examples of Emacs
> org-mode -> html conversion for all org-mode features?
> (How are changes from org-mode -> html converstion from Emacs tested
> during development?)
+1
That would be great. I'd definitely donate any of my blog posts, but
perhaps others have more comprehensive tests.
Samuel
--
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
The disease DOES progress. MANY people have died from it. Just like
AIDS, it attacks MANY body systems. ANYBODY can get it. There is NO
hope without activist action. This means YOU.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-09 10:52 ` Waldemar Quevedo
` (2 preceding siblings ...)
2013-03-17 18:48 ` Samuel Wales
@ 2013-04-05 17:01 ` Bastien
3 siblings, 0 replies; 135+ messages in thread
From: Bastien @ 2013-04-05 17:01 UTC (permalink / raw)
To: Waldemar Quevedo; +Cc: Nicolas Richard, emacs-orgmode, Nicolas Goaziou
Hi Waldemar,
Waldemar Quevedo <waldemar.quevedo@gmail.com> writes:
> By the way, does it exist somewhere a set of examples of Emacs
> org-mode -> html conversion for all org-mode features?
Not really -- and it would be nice to have one, especially for
developers like you who are in charge of an external exporter!
> I am mantaining the org-ruby gem which is used to render org-mode texts to html,
> and currently there is no "roadmap" of features to implement for it.
> As a result, features and tweaks are added to the library
> as long as someone submits a ticket requesting the feature in Github.
> (Here is a list of the export features supported in case someone wants
> to take a look:
> https://github.com/bdewey/org-ruby/tree/master/spec/html_examples )
> Having a set of examples features from org-mode would be very useful
> to see how much coverage other implementations of org-mode exporting
> features have.
>
> Cheers everyone, keep org-mode being an awesome tool :)
Thank *you* for maintaining the org-ruby gem -- truly a gem to the
github community! Hopefully you'll be able to update the gem wrt
the latest syntactic changes. There are not too many of them, and
not every will use Org 8.0 so soon, but still.
Best,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [RFC] Org syntax (draft)
2013-03-10 10:14 ` Bastien
2013-03-10 10:16 ` Bastien
2013-03-10 15:44 ` Jambunathan K
@ 2013-04-09 16:37 ` Bastien
2 siblings, 0 replies; 135+ messages in thread
From: Bastien @ 2013-04-09 16:37 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: Achim Gratz, emacs-orgmode, Jambunathan K
Hi all,
Bastien <bzg@altern.org> writes:
> the manual would enjoy a subsection in "Hacking" on how to create
> a new exporter, either from scratch or as a derived exporter.
> (Such a subsection can be short enough, thanks to derived backend.)
FWIW, I started a rudimentary one.
This is "Adding export back-ends" in the current manual from master.
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-10-11 20:35 ` Samuel Wales
@ 2013-10-14 8:46 ` Martin Beck
0 siblings, 0 replies; 135+ messages in thread
From: Martin Beck @ 2013-10-14 8:46 UTC (permalink / raw)
To: emacs-orgmode
Samuel Wales <samologist <at> gmail.com> writes:
> (setq org-agenda-inactive-leader "Inactive: ")
> (setq org-agenda-include-inactive-timestamps t)
>
> Custom command:
>
> ("ip" "past 7d"
> ;; faster than tags
> agenda ""
> ((org-agenda-start-day "-7d")
> (org-agenda-span 7)
> (org-agenda-repeating-timestamp-show-all nil)
> ;; %s is only for agenda views
> ;; (org-agenda-prefix-format "%s")
> ;; maybe not make much difference ka
> ;; (org-agenda-use-tag-inheritance nil)
> ))
>
> ===
>
> Samuel
>
great - thanks a lot. I'll test that for some time, but it seems to do what
I need.
Just the list created is very long.
Would it be possible to limit it to inactive timestamps only?
Martin
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2013-11-06 6:13 Cecil Westerhof
2013-11-06 8:32 ` Bastien
2013-11-06 8:42 ` Bastien
0 siblings, 2 replies; 135+ messages in thread
From: Cecil Westerhof @ 2013-11-06 6:13 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
At the moment I get something like this:
* Hours Today
#+BEGIN: clocktable :maxlevel 2 :scope subtree
Clock summary at [2013-11-04 Mon 15:53]
| Headline | Time | |
|-------------------------------+--------+------|
| *Total time* | *6:35* | |
|-------------------------------+--------+------|
| Hours Today | 6:35 | |
| Workshop shell scripting | | 2:12 |
| Security Intake | | 2:39 |
| Internal Project | | 1:44 |
#+END:
*** Workshop shell scripting
CLOCK: [2013-11-04 Mon 13:49]--[2013-11-04 Mon 13:56] => 0:07
CLOCK: [2013-11-04 Mon 11:03]--[2013-11-04 Mon 11:55] => 0:52
CLOCK: [2013-11-04 Mon 08:45]--[2013-11-04 Mon 09:58] => 1:13
*** Security Intake
CLOCK: [2013-11-04 Mon 15:05]--[2013-11-04 Mon 15:45] => 0:40
CLOCK: [2013-11-04 Mon 13:56]--[2013-11-04 Mon 14:01] => 0:05
CLOCK: [2013-11-04 Mon 11:55]--[2013-11-04 Mon 13:49] => 1:54
*** Internal Project
CLOCK: [2013-11-04 Mon 14:26]--[2013-11-04 Mon 15:05] => 0:39
CLOCK: [2013-11-04 Mon 09:58]--[2013-11-04 Mon 11:03] => 1:05
But because ‘Hours Today’ already is a summation, I would like to get
something like this:
* Hours Today
#+BEGIN: clocktable :maxlevel 2 :scope subtree
Clock summary at [2013-11-04 Mon 15:53]
|-------------------------------+--------+------|
| Hours Today | 6:35 | |
|-------------------------------+--------+------|
| Workshop shell scripting | | 2:12 |
| Security Intake | | 2:39 |
| Internal Project | | 1:44 |
|-------------------------------+--------+------|
#+END:
*** Workshop shell scripting
CLOCK: [2013-11-04 Mon 13:49]--[2013-11-04 Mon 13:56] => 0:07
CLOCK: [2013-11-04 Mon 11:03]--[2013-11-04 Mon 11:55] => 0:52
CLOCK: [2013-11-04 Mon 08:45]--[2013-11-04 Mon 09:58] => 1:13
*** Security Intake
CLOCK: [2013-11-04 Mon 15:05]--[2013-11-04 Mon 15:45] => 0:40
CLOCK: [2013-11-04 Mon 13:56]--[2013-11-04 Mon 14:01] => 0:05
CLOCK: [2013-11-04 Mon 11:55]--[2013-11-04 Mon 13:49] => 1:54
*** Internal Project
CLOCK: [2013-11-04 Mon 14:26]--[2013-11-04 Mon 15:05] => 0:39
CLOCK: [2013-11-04 Mon 09:58]--[2013-11-04 Mon 11:03] => 1:05
Is that possible?
--
Cecil Westerhof
[-- Attachment #2: Type: text/html, Size: 3003 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-11-06 6:13 Cecil Westerhof
@ 2013-11-06 8:32 ` Bastien
2013-11-06 8:42 ` Bastien
1 sibling, 0 replies; 135+ messages in thread
From: Bastien @ 2013-11-06 8:32 UTC (permalink / raw)
To: Cecil Westerhof; +Cc: emacs-orgmode
Cecil Westerhof <cldwesterhof@gmail.com> writes:
> Is that possible?
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2013-11-06 6:13 Cecil Westerhof
2013-11-06 8:32 ` Bastien
@ 2013-11-06 8:42 ` Bastien
[not found] ` <CAG-LmmDGaczy8pyeCTU6-YJ9oTBeEufqU6kC2PUb-U6ucexhZA@mail.gmail.com>
1 sibling, 1 reply; 135+ messages in thread
From: Bastien @ 2013-11-06 8:42 UTC (permalink / raw)
To: Cecil Westerhof; +Cc: emacs-orgmode
Hi Cecil,
Cecil Westerhof <cldwesterhof@gmail.com> writes:
> Is that possible?
Well, I'd simply not use a "Hours spent" headline, which seems
redundant.
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
[not found] ` <CAG-LmmDFjqbuqfF1YJoeX6x_UdujK+0noeFcGSD15hs49Tbo=Q@mail.gmail.com>
@ 2013-11-06 18:38 ` Cecil Westerhof
0 siblings, 0 replies; 135+ messages in thread
From: Cecil Westerhof @ 2013-11-06 18:38 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
2013/11/6 Cecil Westerhof <cldwesterhof@gmail.com>
> > I would like to keep things in the three "Hours Today". Is there a
>
>> > way to get something like:
>> > | Headline | Time |
>> > |-------------------------------+--------|
>> > | *Total time* | *6:35* |
>> > |-------------------------------+--------|
>> > | Workshop shell scripting | 2:12 |
>> > | Security Intake | 2:39 |
>> > | Internal Project | 1:44 |
>>
>> No.
>
>
> OK. I'll have to live with it, or make a workaround.
>
I solved it with:
#+BEGIN: clocktable :maxlevel 1 :scope nil :compact nil
And using narrow-region.
--
Cecil Westerhof
[-- Attachment #2: Type: text/html, Size: 1400 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2014-01-30 0:03 Ken Okada
2014-01-30 0:15 ` Bastien
0 siblings, 1 reply; 135+ messages in thread
From: Ken Okada @ 2014-01-30 0:03 UTC (permalink / raw)
To: emacs-orgmode
Hello,
I have a question. By default tables are centered in LaTeX export.
Sometimes I prefere to make it flush left or right. I thought this was
done with, for example,
#+ATTR_LATEX: :center nil
| a | b |
| 1 | 2 |
but it does not work in my environment. I'm using Org-mode version 7.8.11.
Could anyone point out what I mistook?
Sincerely,
Ken Okada
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-30 0:03 Ken Okada
@ 2014-01-30 0:15 ` Bastien
2014-01-30 0:22 ` John Hendy
0 siblings, 1 reply; 135+ messages in thread
From: Bastien @ 2014-01-30 0:15 UTC (permalink / raw)
To: Ken Okada; +Cc: emacs-orgmode
Hi Ken,
Ken Okada <keno.ss57@gmail.com> writes:
> I have a question. By default tables are centered in LaTeX export.
> Sometimes I prefere to make it flush left or right. I thought this was
> done with, for example,
>
> #+ATTR_LATEX: :center nil
> | a | b |
> | 1 | 2 |
The use of the :center parameter suggests you consulted a recent
version of the documentation, for Org >=8.0.
This is how it works for Org 8.0 and above:
#+ATTR_LATEX: :environment longtable :align l|lp{3cm}r|l
| a | b | c |
| 1 | 2 | 3 |
If you can, please upgrade. Otherwise, someone needs to check the
documentation for Org 7.8.11...
HTH,
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-30 0:15 ` Bastien
@ 2014-01-30 0:22 ` John Hendy
2014-01-30 7:17 ` Ken Okada
0 siblings, 1 reply; 135+ messages in thread
From: John Hendy @ 2014-01-30 0:22 UTC (permalink / raw)
To: Bastien; +Cc: Ken Okada, emacs-orgmode
On Wed, Jan 29, 2014 at 6:15 PM, Bastien <bzg@gnu.org> wrote:
>
> Hi Ken,
>
> Ken Okada <keno.ss57@gmail.com> writes:
>
> > I have a question. By default tables are centered in LaTeX export.
> > Sometimes I prefere to make it flush left or right. I thought this was
> > done with, for example,
> >
> > #+ATTR_LATEX: :center nil
> > | a | b |
> > | 1 | 2 |
>
> The use of the :center parameter suggests you consulted a recent
> version of the documentation, for Org >=8.0.
>
> This is how it works for Org 8.0 and above:
>
> #+ATTR_LATEX: :environment longtable :align l|lp{3cm}r|l
> | a | b | c |
> | 1 | 2 | 3 |
>
> If you can, please upgrade. Otherwise, someone needs to check the
> documentation for Org 7.8.11...
Bastien beat me to it. Yes, the example syntax is for Org > 8.0.
Here's a version of the manual for v7.9:
- http://www.gnu.org/software/emacs/manual/html_mono/org.html#Tables-in-LaTeX-export
I'm not sure what the proper argument is and can't test since I'm on
the current version of Org from git. You might take a look at the
placement= argument?
I'm having a tough time finding info on LaTeX with what makes a table
left or right aligned (not the columns, but the table itself). Most of
the hits are on how to *center* the table, which seems to suggest they
will be left aligned by default.
Sorry not to be of better help -- I think Bastien's suggestion to
upgrade to 8.0 is the right move. A lot of the mailing list has likely
made the move and thus it's hard to troubleshoot versions with the old
exporter syntax.
Best regards,
John
>
> HTH,
>
> --
> Bastien
>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-30 0:22 ` John Hendy
@ 2014-01-30 7:17 ` Ken Okada
2014-01-31 6:29 ` John Hendy
0 siblings, 1 reply; 135+ messages in thread
From: Ken Okada @ 2014-01-30 7:17 UTC (permalink / raw)
To: John Hendy; +Cc: Bastien, emacs-orgmode
John,
Thanks for advising.
On Org 7.8.11, placement=[l] and placement={l} parameter does not make
sense for tables as I tried.
I tried to install the current version. (There was a compile error
arising from the fact that BSD make is not GNU make, but it's no matter.)
A simple example for :center nil works well. For main org file I have to
do more work... not about centering.
However there seems not to be a parameter for flush right. At present
this is not a serious problem because :center nil works well, so we can
control directory with #+LATEX: \begin ... and \end . But it's tiresome.
I also feel something about the difference between the way to designate
centering and flush left/right. For HTML export we use :align parameter;
for LaTeX, :center parameter, which only allows us to control centering
or not. :align parameter is used for alignment of contents of table.
I'm confused. I guess there's a problem about backward compatibility or
something.
As you wrote there's a way to change default behaviour, but I feel
centering is confortable in the most typesetting *with Org*.
I think such searching result is due to the default behaviour of LaTeX.
File local option switching the behaviour would be useful, I think.
Best regards,
Ken Okada
At Wed, 29 Jan 2014 18:22:38 -0600,
John Hendy wrote:
>
> On Wed, Jan 29, 2014 at 6:15 PM, Bastien <bzg@gnu.org> wrote:
> >
> > Hi Ken,
> >
> > Ken Okada <keno.ss57@gmail.com> writes:
> >
> > > I have a question. By default tables are centered in LaTeX export.
> > > Sometimes I prefere to make it flush left or right. I thought this was
> > > done with, for example,
> > >
> > > #+ATTR_LATEX: :center nil
> > > | a | b |
> > > | 1 | 2 |
> >
> > The use of the :center parameter suggests you consulted a recent
> > version of the documentation, for Org >=8.0.
> >
> > This is how it works for Org 8.0 and above:
> >
> > #+ATTR_LATEX: :environment longtable :align l|lp{3cm}r|l
> > | a | b | c |
> > | 1 | 2 | 3 |
> >
> > If you can, please upgrade. Otherwise, someone needs to check the
> > documentation for Org 7.8.11...
>
> Bastien beat me to it. Yes, the example syntax is for Org > 8.0.
> Here's a version of the manual for v7.9:
> - http://www.gnu.org/software/emacs/manual/html_mono/org.html#Tables-in-LaTeX-export
>
> I'm not sure what the proper argument is and can't test since I'm on
> the current version of Org from git. You might take a look at the
> placement= argument?
>
> I'm having a tough time finding info on LaTeX with what makes a table
> left or right aligned (not the columns, but the table itself). Most of
> the hits are on how to *center* the table, which seems to suggest they
> will be left aligned by default.
>
> Sorry not to be of better help -- I think Bastien's suggestion to
> upgrade to 8.0 is the right move. A lot of the mailing list has likely
> made the move and thus it's hard to troubleshoot versions with the old
> exporter syntax.
>
>
> Best regards,
> John
>
> >
> > HTH,
> >
> > --
> > Bastien
> >
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-30 7:17 ` Ken Okada
@ 2014-01-31 6:29 ` John Hendy
2014-01-31 7:11 ` Nick Dokos
0 siblings, 1 reply; 135+ messages in thread
From: John Hendy @ 2014-01-31 6:29 UTC (permalink / raw)
To: Ken Okada; +Cc: Bastien, emacs-orgmode
On Thu, Jan 30, 2014 at 1:17 AM, Ken Okada <keno.ss57@gmail.com> wrote:
> John,
>
> Thanks for advising.
>
> On Org 7.8.11, placement=[l] and placement={l} parameter does not make
> sense for tables as I tried.
>
> I tried to install the current version. (There was a compile error
> arising from the fact that BSD make is not GNU make, but it's no matter.)
> A simple example for :center nil works well. For main org file I have to
> do more work... not about centering.
If you're still running into the make issue, this is how I manage
Org-git on Windows since I don't want to futz with cygwin or other
stuff:
- http://orgmode.org/worg/org-hacks.html#compiling-org-without-make
> However there seems not to be a parameter for flush right. At present
> this is not a serious problem because :center nil works well, so we can
> control directory with #+LATEX: \begin ... and \end . But it's tiresome.
I was hunting around for the LaTeX parameter directly to specify the
table alignment and honestly wasn't finding anything specifically
related to tabular. My best hunting suggests that you need to put the
table inside of some sort of float environment and then specify the
placement that way, but I'm not sure if this plays nicely with any of
Org's built in table environments or not.
For example, I see there's a way to specify right alignment when
trying to wrap text around a figure:
- http://en.wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions#Wrapping_text_around_figures
I was able to do this successfully with tabular instead of the example
they showed, but if you have no text to wrap, the table will just be
left-aligned.
\begin{wrapfigure}{r}{0.5\textwidth}
\begin{tabular}{lll}
a & b & c \\
\hline
word & word & word \\
word & word & word \\
\end{tabular}
\end{wrapfigure}
I also don't know how to next multiple environments with Org's
#+attr_latex options. I was able to place it inside wrap figure like
so:
#+attr_latex: :environment wrapfigure
| a | b | c |
|------+------+------|
| word | word | word |
| word | word | word |
But one still needs a \begin/end{tabular} wrapped around the table. I
tried the obvious =:environment wrapfigure tabular=, but this creates
the literal set of words inside \begin{} vs. separate environments.
That's the best I can do for now...
Good luck!
John
>
> I also feel something about the difference between the way to designate
> centering and flush left/right. For HTML export we use :align parameter;
> for LaTeX, :center parameter, which only allows us to control centering
> or not. :align parameter is used for alignment of contents of table.
> I'm confused. I guess there's a problem about backward compatibility or
> something.
>
> As you wrote there's a way to change default behaviour, but I feel
> centering is confortable in the most typesetting *with Org*.
> I think such searching result is due to the default behaviour of LaTeX.
> File local option switching the behaviour would be useful, I think.
>
> Best regards,
> Ken Okada
>
>
> At Wed, 29 Jan 2014 18:22:38 -0600,
> John Hendy wrote:
>>
>> On Wed, Jan 29, 2014 at 6:15 PM, Bastien <bzg@gnu.org> wrote:
>> >
>> > Hi Ken,
>> >
>> > Ken Okada <keno.ss57@gmail.com> writes:
>> >
>> > > I have a question. By default tables are centered in LaTeX export.
>> > > Sometimes I prefere to make it flush left or right. I thought this was
>> > > done with, for example,
>> > >
>> > > #+ATTR_LATEX: :center nil
>> > > | a | b |
>> > > | 1 | 2 |
>> >
>> > The use of the :center parameter suggests you consulted a recent
>> > version of the documentation, for Org >=8.0.
>> >
>> > This is how it works for Org 8.0 and above:
>> >
>> > #+ATTR_LATEX: :environment longtable :align l|lp{3cm}r|l
>> > | a | b | c |
>> > | 1 | 2 | 3 |
>> >
>> > If you can, please upgrade. Otherwise, someone needs to check the
>> > documentation for Org 7.8.11...
>>
>> Bastien beat me to it. Yes, the example syntax is for Org > 8.0.
>> Here's a version of the manual for v7.9:
>> - http://www.gnu.org/software/emacs/manual/html_mono/org.html#Tables-in-LaTeX-export
>>
>> I'm not sure what the proper argument is and can't test since I'm on
>> the current version of Org from git. You might take a look at the
>> placement= argument?
>>
>> I'm having a tough time finding info on LaTeX with what makes a table
>> left or right aligned (not the columns, but the table itself). Most of
>> the hits are on how to *center* the table, which seems to suggest they
>> will be left aligned by default.
>>
>> Sorry not to be of better help -- I think Bastien's suggestion to
>> upgrade to 8.0 is the right move. A lot of the mailing list has likely
>> made the move and thus it's hard to troubleshoot versions with the old
>> exporter syntax.
>>
>>
>> Best regards,
>> John
>>
>> >
>> > HTH,
>> >
>> > --
>> > Bastien
>> >
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-31 6:29 ` John Hendy
@ 2014-01-31 7:11 ` Nick Dokos
2014-02-03 22:13 ` Marcin Borkowski
0 siblings, 1 reply; 135+ messages in thread
From: Nick Dokos @ 2014-01-31 7:11 UTC (permalink / raw)
To: emacs-orgmode
John Hendy <jw.hendy@gmail.com> writes:
>>> I'm having a tough time finding info on LaTeX with what makes a table
>>> left or right aligned (not the columns, but the table itself). Most of
>>> the hits are on how to *center* the table, which seems to suggest they
>>> will be left aligned by default.
>>>
Does something like this help?
--8<---------------cut here---------------start------------->8---
* Align tables on the page
Here is a table on the left side:
#+LATEX: \noindent
#+ATTR_LATEX: :center nil
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
#+LATEX: \hfill
The noindent just gets rid of the indentation of the first line of a paragraph
which in this case is the table. The hfill adds infinite stretch after the table,
so it pushes the table to the left.
Here is a centered table:
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
And here's a table on the right side:
#+LATEX: \hfill
#+ATTR_LATEX: :center nil
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
Here the hfill adds infinite stretch before the table, so it pushes the table to the right.
--8<---------------cut here---------------end--------------->8---
--
Nick
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-01-31 7:11 ` Nick Dokos
@ 2014-02-03 22:13 ` Marcin Borkowski
0 siblings, 0 replies; 135+ messages in thread
From: Marcin Borkowski @ 2014-02-03 22:13 UTC (permalink / raw)
To: emacs-orgmode
Dnia 2014-01-31, o godz. 02:11:21
Nick Dokos <ndokos@gmail.com> napisał(a):
> John Hendy <jw.hendy@gmail.com> writes:
>
> >>> I'm having a tough time finding info on LaTeX with what makes a
> >>> table left or right aligned (not the columns, but the table
> >>> itself). Most of the hits are on how to *center* the table, which
> >>> seems to suggest they will be left aligned by default.
> >>>
>
> Does something like this help?
What about simply putting your tabular into \begin{flushright} ...
\end{flushright} (or -left, or center)? You don't need floats for
that. And if you /do/ need floats, just say \centering or \raggedright
or \raggedleft before your tabular.
"Left aligned by default" is connected with the boxes-and-glue model of
TeX page, and the way paragraph and page formatters work. It is
described in detail in The TeXbook (in case you are curious).
HTH,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2014-05-03 1:52 Ryan Moszynski
2014-05-03 3:01 ` William Henney
0 siblings, 1 reply; 135+ messages in thread
From: Ryan Moszynski @ 2014-05-03 1:52 UTC (permalink / raw)
To: emacs-orgmode
If an org table cell contains the HMS 1@ 11' 37"
is there an easy way to get the total (time)seconds?
(1*3600 + 11*60 + 37 = 4297)
if $4 = 1@ 11' 37"
how do I get $8 = 4297?
thanks
ryan
--
He felt that his whole life was some kind of dream and he sometimes
wondered whose it was and whether they were enjoying it. - Douglas
Adams
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-05-03 1:52 Ryan Moszynski
@ 2014-05-03 3:01 ` William Henney
2014-05-03 3:22 ` William Henney
0 siblings, 1 reply; 135+ messages in thread
From: William Henney @ 2014-05-03 3:01 UTC (permalink / raw)
To: Ryan Moszynski; +Cc: emacs-org
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
Hi Ryan
Convert to degrees, then multiply by 3600:
| - | - | - | 1@ 11' 37" | - | - | - | 4297 |
#+TBLFM: $8=3600 deg($4); %d
Cheers
Will
On Fri, May 2, 2014 at 8:52 PM, Ryan Moszynski <ryan.moszynski@gmail.com>wrote:
> If an org table cell contains the HMS 1@ 11' 37"
>
> is there an easy way to get the total (time)seconds?
>
> (1*3600 + 11*60 + 37 = 4297)
>
>
> if $4 = 1@ 11' 37"
>
> how do I get $8 = 4297?
>
> thanks
>
> ryan
>
> --
> He felt that his whole life was some kind of dream and he sometimes
> wondered whose it was and whether they were enjoying it. - Douglas
> Adams
>
>
--
Dr William Henney, Centro de Radioastronomía y Astrofísica,
Universidad Nacional Autónoma de México, Campus Morelia
[-- Attachment #2: Type: text/html, Size: 1374 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2014-05-03 3:01 ` William Henney
@ 2014-05-03 3:22 ` William Henney
0 siblings, 0 replies; 135+ messages in thread
From: William Henney @ 2014-05-03 3:22 UTC (permalink / raw)
To: Ryan Moszynski; +Cc: emacs-org
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
Or, even better, just divide by the HMS form for 1 second (0@ 0' 1"):
| - | - | - | 1@ 11' 37" | - | - | - | 4297 |
#+TBLFM: $8=$4 \ 0@ 0' 1"
Note that \ is integer division, so there is no need for a format conversion
Will
P.S. I highly recommend reading the [[info:calc#Basic Arithmetic]] section
of the calc manual
On Fri, May 2, 2014 at 10:01 PM, William Henney <whenney@gmail.com> wrote:
> Hi Ryan
>
> Convert to degrees, then multiply by 3600:
>
> | - | - | - | 1@ 11' 37" | - | - | - | 4297 |
> #+TBLFM: $8=3600 deg($4); %d
>
> Cheers
>
> Will
>
>
>
> On Fri, May 2, 2014 at 8:52 PM, Ryan Moszynski <ryan.moszynski@gmail.com>wrote:
>
>> If an org table cell contains the HMS 1@ 11' 37"
>>
>> is there an easy way to get the total (time)seconds?
>>
>> (1*3600 + 11*60 + 37 = 4297)
>>
>>
>> if $4 = 1@ 11' 37"
>>
>> how do I get $8 = 4297?
>>
>> thanks
>>
>> ryan
>>
>> --
>> He felt that his whole life was some kind of dream and he sometimes
>> wondered whose it was and whether they were enjoying it. - Douglas
>> Adams
>>
>>
>
>
> --
>
> Dr William Henney, Centro de Radioastronomía y Astrofísica,
> Universidad Nacional Autónoma de México, Campus Morelia
>
--
Dr William Henney, Centro de Radioastronomía y Astrofísica,
Universidad Nacional Autónoma de México, Campus Morelia
[-- Attachment #2: Type: text/html, Size: 2488 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2015-01-24 16:23 M.S.Khed Khed
0 siblings, 0 replies; 135+ messages in thread
From: M.S.Khed Khed @ 2015-01-24 16:23 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: text/html, Size: 1 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2015-09-04 14:51 Eduardo Mercovich
2015-09-04 15:25 ` thomas
0 siblings, 1 reply; 135+ messages in thread
From: Eduardo Mercovich @ 2015-09-04 14:51 UTC (permalink / raw)
To: Org Mode Mailing List
Hello everbody.
I'm an emacs/org-mode newbie but I'm learning, so please forgive me if
this is obvious for you.
A couple days ago I updated org from the packages-list.
Now, when I'm trying to use a simple org table (typing TAB, for
example), I get:
"org-get-limited-outline-regexp: Variable binding depth exceeds
max-specpdl-size"
Also, while trying to export a document to html, I get:
"Variable binding depth exceeds max-specpdl-size"
Looking up, I saw that this is a mechanisms to protect against infinite
recursions, so I tried to increase the limit -just to get the exporting
done- putting in my .emacs this:
(setq max-specpdl-size 15000)
(setq max-lisp-eval-depth 15000)
But, no luck.
Any pointer about what could be happening, or how to solve it?
Thanks a lot in advance... :)
--
e
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2015-09-04 14:51 Eduardo Mercovich
@ 2015-09-04 15:25 ` thomas
2015-09-04 18:35 ` Eduardo Mercovich
0 siblings, 1 reply; 135+ messages in thread
From: thomas @ 2015-09-04 15:25 UTC (permalink / raw)
To: emacs-orgmode
you could revert to your working org installation (if you did not delete
that folder) by deleting / moving the folder with the faulty
installation (say "org-201508XX") from your .emacs.d/elpa directory.
If this solves your problems, then I would recommend starting a "bare"
emacs
emacs -q
and install org from elpa again. A few days ago I ran into that same
issue :-)
- thomas
On 04.09.2015 16:51, Eduardo Mercovich wrote:
> Hello everbody.
>
> I'm an emacs/org-mode newbie but I'm learning, so please forgive me if
> this is obvious for you.
>
> A couple days ago I updated org from the packages-list.
>
> Now, when I'm trying to use a simple org table (typing TAB, for
> example), I get:
> "org-get-limited-outline-regexp: Variable binding depth exceeds
> max-specpdl-size"
>
> Also, while trying to export a document to html, I get:
> "Variable binding depth exceeds max-specpdl-size"
>
> Looking up, I saw that this is a mechanisms to protect against infinite
> recursions, so I tried to increase the limit -just to get the exporting
> done- putting in my .emacs this:
>
> (setq max-specpdl-size 15000)
> (setq max-lisp-eval-depth 15000)
>
> But, no luck.
>
> Any pointer about what could be happening, or how to solve it?
> Thanks a lot in advance... :)
>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2015-09-04 15:25 ` thomas
@ 2015-09-04 18:35 ` Eduardo Mercovich
0 siblings, 0 replies; 135+ messages in thread
From: Eduardo Mercovich @ 2015-09-04 18:35 UTC (permalink / raw)
To: thomas; +Cc: emacs-orgmode
Dear Thomas.
> you could revert to your working org installation (if you did not delete
> that folder) by deleting / moving the folder with the faulty
> installation (say "org-201508XX") from your .emacs.d/elpa directory.
> If this solves your problems, then I would recommend starting a "bare"
> emacs
> emacs -q
> and install org from elpa again.
I did it, with some hiccups in the middle, and now I have a working
Org-mode version 8.3.1 (8.3.1-95-g1dbb25-elpaplus)
in
~/.emacs.d/elpa/org-20150831/
Thank you! :)
> A few days ago I ran into that same issue :-)
Even while upgrading is not yet perfect, the packaging system is
becoming better by each version.
As I'm not a bleeding edge developer, I may enjoy this version for a
while, but for those who may step on the same rock:
1 . I uninstalled org from the package manager (M-x list-packages, there
mark with "D" and execute with "x")
2 . unloaded every org file (this is important, close all org buffers
before installation),
3. . and installed again org from the package manager;
4. . after, installed org-plus-contrib.
Now it seems it's working fine, and I hope it may serve others too.
Don't forget to unload org buffers before install! (is upgrading the
same?).
Thanks a lot Thomas! :)
Best...
--
e
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2015-10-11 19:51 Shankar Rao
0 siblings, 0 replies; 135+ messages in thread
From: Shankar Rao @ 2015-10-11 19:51 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]
I have multiple savings accounts, some of which I want to partition into
mutiple virtual "subaccounts" that don't merit their own savings account. I
want to use org-mode tables to keep track how much money is each
subaccount. Given the following table:
#+TBLNAME: trans-150925
| ! | Amount | From | To | Subacct |
|---+--------+------------+------------+-------------|
| | 50 | Short Term | Inbox | Bond |
| | 200 | Inbox | Short Term | Bond |
| | 120 | Gifts | Inbox | Baby Gifts |
| | 75 | Short Term | Inbox | Furnishings |
In this example, I have accounts "Inbox", "Short Term", and "Gifts". Of
these accounts, "Short Term" has two subaccounts "Bond" and "Furnishings",
and "Gifts" has a subaccount "Baby Gifts". I want to create a function that
given a subaccount name, calculates the net amount to be
withdrawn/deposited to the subaccount. Note that "Inbox" doesn't have any
subaccounts, which I want to use to determine if a given transaction is a
withdrawal or deposit to the subaccount.
I have created the following two functions to implement this:
(defun sbr/org-lookup-trans (category date s-name r-name)
(let* ((table (concat "trans-" date))
(s-range (format "@I%s..@>%s" s-name s-name))
(s-col (org-table-get-remote table s-range))
(r-range (format "@I%s..@>%s" r-name r-name))
(r-col (org-table-get-remote table r-range)))
(org-lookup-all category s-col r-col)))
(defun sbr/get-net-subacct (category date)
(let* ((from-vec (sbr/org-lookup-trans category date "$Subacct" "$From"))
(to-vec (sbr/org-lookup-trans category date "$Subacct" "$To"))
(amount-vec (sbr/org-lookup-trans category date "$Subacct"
"$Amount"))
(from-inbox-ind <indices of all from-vec elements that equal
"Inbox">) ; A
(to-inbox-ind <indices of all to-vec elements that equal "Inbox">)
; B
(adds amount-vec[from-inbox-ind]) ; C
(subs amount-vec[to-inbox-ind])) ; D
(calc-eval (if (zerop (length subs))
adds
(concat adds "-" subs)))))
I need help filling in the pseudo code in lines A through D, namely:
1. how to get a list of all indices of elements in a vector that satisfy a
predicate?
2. how to reference a vector by a list of indices?
In this example the function should return the following values:
(sbr/get-net-subacct "Bond" "150925") ==> 150
(sbr/get-net-subacct "Furnishings" "150925") ==> -75
(sbr/get-net-subacct "Baby Gifts" "150925") ==> -120
How do I implement the above pseudocode functions? Is there a simpler way
to accomplish this task?
[-- Attachment #2: Type: text/html, Size: 5700 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2015-11-03 19:53 Fritz Kunze
0 siblings, 0 replies; 135+ messages in thread
From: Fritz Kunze @ 2015-11-03 19:53 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
i am running emacs on a chromebook namely emacs 24.4.1 and org
8.3.1-87-g4ef2c0...) on
chromebrew(https://skycocker.github.io/chromebrew/) . My question:How
to make emacs org-mode open links to sites in Google Chrome?How to
make emacs org-mode open links to sites in Google Chrome
thanks in advance,
fritz kunze (fkunze@gmail.com)
i tried adding these lines to my init.el file (with no effect):
(setq browse-url-browser-function 'browse-url-generic
browse-url-generic-program "chromium-browser")
(setq browse-url-browser-function 'browse-url-generic
browse-url-generic-program "google-chrome")
export BROWSER="google-chrome"
browse-url-generic-program
[-- Attachment #2: Type: text/html, Size: 1228 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2016-09-19 16:38 John Brodie
2016-09-20 20:32 ` Nicolas Goaziou
0 siblings, 1 reply; 135+ messages in thread
From: John Brodie @ 2016-09-19 16:38 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 5600 bytes --]
From: brodiej@SEA-9901331265.i-did-not-set--mail-host-address--so-tickle-me
To: emacs-orgmode@gnu.org
Subject: Bug: Babel :results raw doesn't replace results. [8.3.4
(8.3.4-72-gddd58f-elpa @
c:/Users/brodiej/AppData/Roaming/.emacs.d/elpa/org-20160530/)]
Date: Mon, 19 Sep 2016 09:35:36 -0700
Message-ID:
<tcbvsvaxru9t3.fsf@SEA-9901331265.i-did-not-set--mail-host-address--so-tickle-me
>
--text follows this line--
I'm creating a literate program using org-babel with python. If I change
the output of a source block to 'raw' the results are not replaced on
each run, they are appended. This is quite annoying, because it means
manual editing everytime I need to re-run my program. If I try to set
the flags 'replace' 'prepend' etc. they have no effect:
#+name: Example1
#+begin_src python :session :results raw :exports none
'dogs and cats'
#+end_src
#+RESULTS: Example1
dogs and cats
dogs and cats
dogs and cats
dogs and cats
dogs and cats
Emacs : GNU Emacs 25.0.92.1 (x86_64-w64-mingw32)
of 2016-03-03
Package: Org-mode version 8.3.4 (8.3.4-72-gddd58f-elpa @
c:/Users/brodiej/AppData/Roaming/.emacs.d/elpa/org-20160530/)
current state:
==============
(setq
org-id-locations-file
"c:/Users/brodiej/AppData/Roaming/.emacs.d/.cache/.org-id-locations"
org-export-backends '(ascii html icalendar latex odt confluence)
org-latex-default-figure-position "H"
org-export-babel-evaluate nil
org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-latex-default-packages-alist '(("AUTO" "inputenc" t) ("T1" "fontenc"
nil)
("" "fixltx2e" nil) ("" "graphicx" t)
("" "grffile" t)
("" "longtable" nil) ("" "wrapfig" nil)
("" "rotating" nil)
("normalem" "ulem" t) ("" "amsmath" t)
("" "textcomp" t)
("" "amssymb" t) ("" "capt-of" nil) (""
"hyperref" nil))
org-clock-persist-file
"c:/Users/brodiej/AppData/Roaming/.emacs.d/.cache/org-clock-save.el"
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-html-format-drawer-function '(lambda (name contents) contents)
org-log-done 'time
org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-link-translation-function 'toc-org-unhrefify
org-present-mode-hook '(spacemacs//org-present-start)
org-agenda-restore-windows-after-quit t
org-agenda-custom-commands '(("n" "Agenda and all TODOs"
((agenda "" nil) (todo "NEXT" nil) (alltodo
"" nil)) nil)
)
org-latex-format-headline-function
'org-latex-format-headline-default-function
org-default-notes-file "notes.org"
org-latex-image-default-width ".6\\linewidth"
org-startup-indented t
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-latex-format-drawer-function '(lambda (name contents) contents)
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append local] 5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes
toc-org-enable
org-bullets-mode flyspell-mode spacemacs/add-org-surrounds
evil-org-mode
org-eldoc-load)
org-latex-prefer-user-labels t
org-archive-hook '(org-attach-archive-delete-maybe)
org-level-color-stars-only t
org-ascii-format-drawer-function '(lambda (name contents width) contents)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-present-mode-quit-hook '(spacemacs//org-present-end)
org-export-async-init-file
"c:/Users/brodiej/AppData/Roaming/.emacs.d/layers/org/org-async-init.el"
org-todo-keywords '((sequence "TODO(t)" "NEXT(n)" "STARTED" "WAITING(w)"
"|" "DONE(d)"
"CANCELED(c)")
)
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el")
("elisp" . "el"))
org-confirm-elisp-link-function 'yes-or-no-p
org-startup-with-inline-images t
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-odt-format-drawer-function '(lambda (name contents) contents)
org-ditaa-jar-path
"C:\\Users\\brodiej\\AppData\\Roaming\\.emacs.d\\ditaa\\ditaa.jar"
org-html-format-headline-function
'org-html-format-headline-default-function
org-babel-load-languages '((python . t) (ditaa . t))
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-fontify-whole-heading-line t
org-agenda-files '("c:/docs/planner/brodie_planning.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-confirm-babel-evaluate nil
org-src-fontify-natively t
)
[-- Attachment #2: Type: text/html, Size: 7250 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2016-09-19 16:38 John Brodie
@ 2016-09-20 20:32 ` Nicolas Goaziou
0 siblings, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2016-09-20 20:32 UTC (permalink / raw)
To: John Brodie; +Cc: emacs-orgmode
Hello,
John Brodie <john.brodie@gmail.com> writes:
> I'm creating a literate program using org-babel with python. If I change
> the output of a source block to 'raw' the results are not replaced on
> each run, they are appended. This is quite annoying, because it means
> manual editing everytime I need to re-run my program.
You should use `drawer' instead of `raw' then. `raw' results cannot be
replaced, as you noticed, because there is no way to know where their
boundaries are.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2016-11-01 16:10 John Kitchin
0 siblings, 0 replies; 135+ messages in thread
From: John Kitchin @ 2016-11-01 16:10 UTC (permalink / raw)
To: brown; +Cc: John Kitchin, Emacs-orgmode@gnu.org
[-- Attachment #1.1: Type: text/plain, Size: 1088 bytes --]
We might not always want a full export of an org heading to html for sending an email. Eric Brown would like to just send something that looks like what he sees in org-mode. There is another way to get html from emacs: htmlize! Here is an example. Eric: if this is what you mean, see my modified org-mime.el at [[https://github.com/jkitchin/scimax/blob/master/org-mime.el]].
The command to send a subtree is: [[elisp:org-mime-subtree-htmlize]]
#+BEGIN_EXAMPLE
My comment was motivated by other usage where I wish that I could simply
wrap an entire simple text, whitespace-formatted email message,
e.g. generated from org export to a plain text buffer, with a Monospace
directive so that webmail users could appreciate what I see with Sans
Mono.
#+END_EXAMPLE
| a | b | c |
| 4 | 5 | 6 |
An equation \(e^{i\pi} + 1 = 0\)
A figure:
#+NAME: fig-particle
[[file:./images/Au-icosahedron-3.png]]
A code block:
#+BEGIN_SRC python
for i in range(5):
print(i)
#+END_SRC
* A subtree
An orgmode reference: [[#Dominik201408][Dominik201408]]. A figure reference: [[ref:fig-particle]].
[-- Attachment #1.2: Type: text/html, Size: 5832 bytes --]
[-- Attachment #2: 475609b3cce30ba7af08c3ab389ce997.png --]
[-- Type: image/png, Size: 9141 bytes --]
[-- Attachment #3: htmlize-mail_602c4147af78abc9245028abc638c8417a1a6bf0.png --]
[-- Type: image/png, Size: 299 bytes --]
[-- Attachment #4: Au-icosahedron-3.png --]
[-- Type: image/png, Size: 30407 bytes --]
[-- Attachment #5: Type: text/plain, Size: 190 bytes --]
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2018-03-02 16:10 Joseph Vidal-Rosset
0 siblings, 0 replies; 135+ messages in thread
From: Joseph Vidal-Rosset @ 2018-03-02 16:10 UTC (permalink / raw)
To: Eric Fraga; +Cc: Fabrice Niessen, emacs-orgmode list
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
Dear Eric,
Just a quick email to tell you that I have just succeeded to configure
gnus-alias [[https://www.emacswiki.org/emacs/GnusAlias]]
rather correctly mainly thanks to Fabrice Niessen
[[https://github.com/fniessen/emacs-leuven/blob/master/gnus-leuven.el]]
(many thanks Fabrice !)
and thanks to other related web pages. I still do not succeed to use
correctly regular expressions for gnus-alias-identity-rules but,
anyway, at the moment it works correctly for me. It is a very good
tool.
Best wishes,
Jo
[-- Attachment #2.1: Type: text/html, Size: 808 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2018-05-03 13:44 Arne Babenhauserheide
2018-05-03 14:29 ` Bastien
2018-05-11 20:07 ` Nicolas Goaziou
0 siblings, 2 replies; 135+ messages in thread
From: Arne Babenhauserheide @ 2018-05-03 13:44 UTC (permalink / raw)
To: emacs-orgmode
Dear Org Hackers,
When I use org-capture to capture a new task, the next headline
sometimes ends up being prefixed by the last line of the new task.
Example:
Begin:
* Foo
** old task
* Bar
After capture:
* Foo
** old task
** ❢ new task
:LOGBOOK:
CLOCK: [2018-05-03 Do 14:05]--[2018-05-03 Do 15:24] => 1:19
:END:
https://some.url/foo* Bar
Best wishes,
Arne Babenhauserheide
Emacs : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
of 2017-09-22, modified by Debian
Package: Org mode version 9.1.7 (9.1.7-12-g74f6ed-elpa @ /home/babenhauserheide/.emacs.d/elpa/org-20180305/)
current state:
==============
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe org-babel-header-arg-expand)
org-habit-show-all-today t
org-speed-command-hook '(org-speed-command-activate org-babel-speed-command-activate)
org-clock-history-length 35
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-clock-mode-line-total 'today
org-duration-format '((special . h:mm))
org-confirm-shell-link-function 'yes-or-no-p
org-columns-default-format "%25ITEM %TODO %3PRIORITY %TAGS %17Effort(Estimated Effort){:} %CLOCKSUM"
org-jira-done-states '("Closed" "Resolved" "Done" "Geschlossen" "Bearbeitet")
org-agenda-custom-commands '(("o" "Agenda and TODOs"
((agenda nil
((org-agenda-compact-blocks nil) (org-agenda-block-separator 45)
(org-agenda-overriding-header ""))
)
(tags-todo "-Arlaub-notodo" ((org-agenda-block-separator 45)))
(tags "KANBAN"
((org-agenda-block-separator 45) (org-agenda-compact-blocks nil)
(org-agenda-overriding-header ""))
)
)
)
)
org-default-notes-file "~/Plan/plan.org"
org-capture-templates '(("l" "Task for later" entry (file+headline "~/Plan/plan.org" "Tasks") "** ❢ %?\n\n"
:empty-lines 1 :clock-in t :clock-resume t)
("i" "Task to start immediately after filing" entry
(file+headline "~/Plan/plan.org" "Tasks") "** ☯ %?\n\n" :jump-to-captured t
:empty-lines 1 :clock-in t :clock-keep t)
("w" "weekly schedule" entry (file+headline "~/Plan/schedule.org" "Regular Schedule")
"** %?\n SCHEDULED: %^{Scheduled when?}T\n\n" :empty-lines 1 :clock-resume t)
)
org-clock-out-when-done nil
org-after-todo-state-change-hook '(org-clock-out-if-current kiwon/org-agenda-redo-in-other-window)
org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-agenda-clock-consistency-checks '(:max-duration "10:00" :min-duration 0 :max-gap "0:05" :gap-ok-around
("4:00" "12:30") :default-face
((:background "DarkRed") (:foreground "white")) :overlap-face nil
:gap-face nil :no-end-time-face nil :long-face nil :short-face nil)
org-babel-pre-tangle-hook '(save-buffer)
org-global-properties '(("Effort_ALL" . "0:30 1:00 2:00 3:00 6:00 8:00 16:00 40:00"))
org-mode-hook '(#[0 "\b\205\x1c\0\301 \205\x1c\0\302\303\301 !\304P!\305\x01!\205\x1a\0\306\x01!\262\x01\207"
[org-ctags-enabled-p buffer-file-name expand-file-name file-name-directory "/TAGS"
file-exists-p visit-tags-table]
3]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-bibtex-headline-format-function #[257 "\300\x01\236A\207" [:title] 3 "\n\n(fn ENTRY)"]
org-archive-hook '(org-attach-archive-delete-maybe)
org-directory "~/Plan"
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-agenda-start-with-clockreport-mode t
org-agenda-finalize-hook '((lambda nil (org-agenda-to-appt t)))
org-modules '(org-bbdb org-bibtex org-crypt org-ctags org-docview org-eww org-gnus org-habit org-info org-irc
org-mhe org-rmail org-w3m)
org-clock-report-include-clocking-task t
org-timer-default-timer "\"0:00:30\""
org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el") ("elisp" . "el"))
org-confirm-elisp-link-function 'yes-or-no-p
org-edit-src-content-indentation 0
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-string-limit 16
org-clock-budget-intervals '(("BUDGET_YEAR" ignore) ("BUDGET_MONTH" ignore)
("BUDGET_WEEK" org-clock-budget-interval-this-week))
org-link-parameters '(("id" :follow org-id-open) ("jira" :follow org-jira-open :export nil)
("w3m" :store org-w3m-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link)
("info" :follow org-info-open :export org-info-export :store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("eww" :follow eww :store org-eww-store-link)
("docview" :follow org-docview-open :export org-docview-export :store
org-docview-store-link)
("bibtex" :follow org-bibtex-open :store org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
("file+sys") ("file+emacs") ("doi" :follow org--open-doi-link)
("elisp" :follow org--open-elisp-link) ("file" :complete org-file-complete-link)
("ftp" :follow (lambda (path) (browse-url (concat "ftp:" path))))
("help" :follow org--open-help-link)
("http" :follow (lambda (path) (browse-url (concat "http:" path))))
("https" :follow (lambda (path) (browse-url (concat "https:" path))))
("mailto" :follow (lambda (path) (browse-url (concat "mailto:" path))))
("news" :follow (lambda (path) (browse-url (concat "news:" path))))
("shell" :follow org--open-shell-link))
org-babel-load-languages '((emacs-lisp . t) (shell . t) (python . t) (dot . t) (scheme . t))
org-clock-sound t
org-clock-in-hook '(kiwon/org-agenda-redo-in-other-window)
org-reveal-start-hook '(org-decrypt-entry)
org-agenda-files '("~/Plan/plan.org" "~/Plan/reviews.org" "~/Plan/standups.org" "~/Plan/schedule.org")
org-clock-out-hook '(org-clock-remove-empty-clock-drawer kiwon/org-agenda-redo-in-other-window)
)
--
unpolitisch sein
heißt politisch sein,
ohne es zu merken.
- ArneBab
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-05-03 13:44 Arne Babenhauserheide
@ 2018-05-03 14:29 ` Bastien
2018-05-03 21:02 ` Arne Babenhauserheide
2018-05-04 5:38 ` Michael Welle
2018-05-11 20:07 ` Nicolas Goaziou
1 sibling, 2 replies; 135+ messages in thread
From: Bastien @ 2018-05-03 14:29 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: emacs-orgmode
Dear Arne,
there was a temporary glitch in earlier version of Org about this,
please upgrade Org to 9.1.12 through the package system and let us
know if you still have this issue.
Thanks!
--
Bastien
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-05-03 14:29 ` Bastien
@ 2018-05-03 21:02 ` Arne Babenhauserheide
2018-05-04 1:02 ` steen
2018-05-04 5:38 ` Michael Welle
1 sibling, 1 reply; 135+ messages in thread
From: Arne Babenhauserheide @ 2018-05-03 21:02 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Dear Bastien,
Thank you for your answer! I’ll check whether the update resolves this.
(and I’m sorry for the empty subject, I copied the email from Emacs,
since I do not have mail sending from emacs configured at work, and I
forgot to copy the subject).
Best wishes,
Arne
Bastien <bzg@gnu.org> writes:
> Dear Arne,
>
> there was a temporary glitch in earlier version of Org about this,
> please upgrade Org to 9.1.12 through the package system and let us
> know if you still have this issue.
>
> Thanks!
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-05-03 21:02 ` Arne Babenhauserheide
@ 2018-05-04 1:02 ` steen
0 siblings, 0 replies; 135+ messages in thread
From: steen @ 2018-05-04 1:02 UTC (permalink / raw)
To: arne_bab; +Cc: bzg, org-mode-email
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
FYI I am on org 9.1.4 and am still seeing this issue.
-- Steen
On Thu, May 3, 2018 at 2:26 PM Arne Babenhauserheide <arne_bab@web.de>
wrote:
> Dear Bastien,
>
> Thank you for your answer! I’ll check whether the update resolves this.
>
>
> (and I’m sorry for the empty subject, I copied the email from Emacs,
> since I do not have mail sending from emacs configured at work, and I
> forgot to copy the subject).
>
> Best wishes,
> Arne
>
> Bastien <bzg@gnu.org> writes:
>
> > Dear Arne,
> >
> > there was a temporary glitch in earlier version of Org about this,
> > please upgrade Org to 9.1.12 through the package system and let us
> > know if you still have this issue.
> >
> > Thanks!
>
>
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>
[-- Attachment #2: Type: text/html, Size: 1291 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-05-03 14:29 ` Bastien
2018-05-03 21:02 ` Arne Babenhauserheide
@ 2018-05-04 5:38 ` Michael Welle
1 sibling, 0 replies; 135+ messages in thread
From: Michael Welle @ 2018-05-04 5:38 UTC (permalink / raw)
To: emacs-orgmode
Hello,
Bastien <bzg@gnu.org> writes:
> Dear Arne,
>
> there was a temporary glitch in earlier version of Org about this,
> please upgrade Org to 9.1.12 through the package system and let us
> know if you still have this issue.
oh, i thought that is a feature of some kind. Let me upgrade... Hm, the
feature|issue still exist in 9.1.12.
The issue occurs if the capture buffer isn't finished with a newline. My
workaround:
;;
;; Since some time Org does not prepend a \n after inserting
;; a capture template. We fix this ;).
;;
(defun hmw/org-insert-newline-after-template ()
(goto-char (point-max))
(if (not (re-search-backward "\\(^$\\)" (point-at-bol) t))
(progn
(goto-char (point-max))
(insert "\n"))))
(setq org-capture-prepare-finalize-hook
'hmw/org-insert-newline-after-template)
Regards
hmw
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-05-03 13:44 Arne Babenhauserheide
2018-05-03 14:29 ` Bastien
@ 2018-05-11 20:07 ` Nicolas Goaziou
1 sibling, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2018-05-11 20:07 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: emacs-orgmode
Hello,
"Arne Babenhauserheide" <Arne_Bab@web.de> writes:
> Dear Org Hackers,
>
> When I use org-capture to capture a new task, the next headline
> sometimes ends up being prefixed by the last line of the new task.
>
> Example:
>
> Begin:
>
> * Foo
> ** old task
>
> * Bar
>
> After capture:
>
> * Foo
> ** old task
> ** ❢ new task
> :LOGBOOK:
> CLOCK: [2018-05-03 Do 14:05]--[2018-05-03 Do 15:24] => 1:19
> :END:
>
> https://some.url/foo* Bar
>
>
> Best wishes,
> Arne Babenhauserheide
>
>
>
> Emacs : GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
> of 2017-09-22, modified by Debian
> Package: Org mode version 9.1.7 (9.1.7-12-g74f6ed-elpa @
> /home/babenhauserheide/.emacs.d/elpa/org-20180305/)
Could you update Org mode and see if problem persists?
Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2018-10-15 8:04 Nik Clayton
2018-10-17 13:20 ` Nicolas Goaziou
2019-09-15 21:06 ` Matt Price
0 siblings, 2 replies; 135+ messages in thread
From: Nik Clayton @ 2018-10-15 8:04 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 3114 bytes --]
Hi,
I'd like to propose a couple of changes / enhancements to how org-export
exports some data in to HTML files to make it slightly easier to style
those files.
The first is re line-numbers.
At the moment those get exported as content in the HTML, although they're
really additional metadata. Amongst other things, this means that if you
copy/paste from the output you get the line numbers included in the text
that's copied.
CSS supports arbitrary counters that can be associated with content,
starting from an arbitrary value. My current hack that sort of works is the
following CSS:
/* Hide the current line numbers */
span.linenr {
display: none;
}
/* Style each line. Maintain a counter for each line, increment
by one for each <code>...</code> element.
.reveal pre.src code {
display: inline;
font-size: 125%;
line-height: 1.2;
counter-increment: line;
}
/* Show a line number before each line. */
.reveal pre.src code:before {
content: counter(line);
border-right: 1px solid #ddd;
padding: 0 0.5em;
margin-right: 0.5em;
width: 1em;
display: inline-block;
text-align: right;
}
and a change to org-html-do-format-code to wrap each line in its own
<code>...</code> element:
...
;; Transcoded src line.
(format "<code>%s</code>" loc)
...
But this adds line numbers to all code blocks, irrespective of the "-n"
option, and they all start from one.
What I'd like to do is change the output to:
1. Omit the <span class="linenr">...</span>" content.
2. Add an additional class to the pre element to indicate whether or not
this block should have line numbers.
3. Add a data-ox-starting-number (or similar) attribute to the pre element
that specifies what the starting line number for this block should be.
Couple of questions before I write a patch:
a) Does that sound reasonable?
b) Should this replace the current approach, or be an option that can be
toggled by a customisation?
And the second is re languages associated with exported SRC blocks.
At the moment the language is mentioned as src-... class (src-html,
src-javascript, etc).
I'd like to put the language in a data-ox-src-language attribute as well
(e.g., <pre class="src src-html" data-ox-src-language="HTML">...</pre>) so
that I can put use CSS to put badges indicating the language in the output.
Per
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
that would look something like:
.src:after {
content: attr(data-ox-src-language);
position: absolute;
top: -10px;
right: -10px;
font-size: 70%;
background: green;
color: white;
text-align: center;
line-height: 18px;
border-radius: .25em;
padding: 0 0.5em;
box-shadow: 0 0 1px #333;
}
I see there's already some code that tries to show language badges on hover
(which doesn't work for me for some reason, I haven't dug in to why).
Does this change sound reasonable?
Here's a screenshot from an export showing early versions of these changes
in action. Notice how the selected text (the first function) doesn't
include the line numbers in the selection.
[image: image.png]
N
[-- Attachment #1.2: Type: text/html, Size: 5456 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 31536 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-10-15 8:04 Nik Clayton
@ 2018-10-17 13:20 ` Nicolas Goaziou
2019-09-15 21:06 ` Matt Price
1 sibling, 0 replies; 135+ messages in thread
From: Nicolas Goaziou @ 2018-10-17 13:20 UTC (permalink / raw)
To: Nik Clayton; +Cc: emacs-orgmode
Hello,
Nik Clayton <nik@ngo.org.uk> writes:
> I'd like to propose a couple of changes / enhancements to how org-export
> exports some data in to HTML files to make it slightly easier to style
> those files.
>
> The first is re line-numbers.
[...]
> Couple of questions before I write a patch:
>
> a) Does that sound reasonable?
> b) Should this replace the current approach, or be an option that can be
> toggled by a customisation?
My HTML/CSS knowledge is feeble. But it does sound reasonable, if
there's no loss of feature and compatibility.
A patch would be nice for users exporting to HTML who want to test the
behaviour.
> And the second is re languages associated with exported SRC blocks.
[...]
> I see there's already some code that tries to show language badges on hover
> (which doesn't work for me for some reason, I haven't dug in to why).
>
> Does this change sound reasonable?
Ditto.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2018-10-20 9:02 stardiviner
0 siblings, 0 replies; 135+ messages in thread
From: stardiviner @ 2018-10-20 9:02 UTC (permalink / raw)
To: org-mode
Org source block header argument :var does not support quoted string with space separator like bellowing example:
For example
**** encrypt text -- ~<<< [TEXT]~
#+NAME: base64 encrypt text
#+begin_src sh
base64 <<< "stardiviner <numbchild@gmail.com>"
#+end_src
#+RESULTS: base64 encrypt text
: c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
**** decrypt text -- ~-d~
#+begin_src sh :var encrypted="base64 encrypt text"
# base64 -d <<< c3RhcmRpdmluZXIgPG51bWJjaGlsZEBnbWFpbC5jb20+Cg==
base64 -d <<< $encrypted
#+end_src
If I use #+NAME: base64-encrypt-text and :var encrypted=base64-encrypt-text, then it works fine.
--
[ stardiviner ] don't need to convince with trends.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2018-12-19 12:58 Emmanuel Charpentier
0 siblings, 0 replies; 135+ messages in thread
From: Emmanuel Charpentier @ 2018-12-19 12:58 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1.1: Type: text/plain, Size: 2223 bytes --]
[ Fourth attempt to send this to emacs-orgmode ; the first three attempts
were made from an account using an SMTP server seemingly blacklisted, but
no error message was sent back. Apologies if this turns out to be a
duplicate ]
I wish to be able to reference (i. e cross-references, lists) both some
tables or figures AND the code producing the objects.
To this effect, I added (distinct) #+caption:s to the source blocks AND
to the results, adorned with (distinct) org-ref's labels. An example is
included in the enclosed file Min-Ref.org.
The comparison of this source, the LaTeX code obtained by org-latex
export-to latex (Min-Ref.tex) and the resultant PDF (Min-Ref exported
by org-latex-export-to-pdf.pdf) show that the labels attributed to
source blocks are mislabeled as figures. Furthermore, while the org
source requests a list of figure, a list of table and a list of
listings (in that order), the list of figures appears *after* the list
of tables.
I am tempted to conclude that there is some confusion between figures
and listings. Further attempts tend to show that the problem may live n
the core org's code, rather than any specific exporter :
The ODT "native" exporter (org-odt-export-to-odt) is much less capable,
as shown in Min-Ref exported by org-odt-export-to-odt.odt.
Attempts to export via Pandoc to PDF (Min-Ref exported by org-pandoc-
export-to-latex-pdf.pdf), ODT (Min-Ref exported by org-pandoc-export-
to-odt.odt) and DOCX (Min-Ref.docx) show that these exporters may need
some specific configurations in order to be even vaguely usable.
Previous trials, using #+names: rather than org-ref's labels, gave
similar failures. If needed, I can reproduce these trials.
So I have a couple questions :
1) Is the confusion of source blocks and figures a bug, or do I miss a
subtle point ?
2) Is there some introductory material to the care and feeding of ox-
pandoc demonstrating the use of this exporter's options to enable the
addition of the needed features (figure inclusion, tables of tables /
figures / listings, etc...) ? The "manual" available as a README is way
too terse to be usable without diving in the source code and pandoc's
documentation.
Sincerely,
--
Emmanuel Charpentier
[-- Attachment #1.2: Type: text/html, Size: 3340 bytes --]
[-- Attachment #2: Min-Ref.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 10789 bytes --]
[-- Attachment #3: Min-Ref.org --]
[-- Type: application/octet-stream, Size: 1645 bytes --]
#+options: toc:nil
#+property: header-args:python :session
#+language: fr
#+title: What's up with references ?
#+author:
#+date: December 2018
#+toc: headlines
#+toc: figures
#+toc: tables
#+toc: listings
* Some reference samples
This is created using =org-ref= 's =label= 's and =ref= 's.
** A reference...
... to cite:gelmanBayesianDataAnalysis2013 ,a /good/ textbook.
** A table
A Python block producing a (silly) table.
#+caption: A (silly) Python block. label:lst:Python1
#+BEGIN_SRC python :results table :exports both
[[u+str(v) for v in range(1,4)] for u in ["a", "b"]]
#+END_SRC
#+caption: A (silly) Python table. label:tab:Python1
#+RESULTS:
| a1 | a2 | a3 |
| b1 | b2 | b3 |
The table ref:tab:Python1 is produced by the code ref:lst:Python1.
** A figure
A Python block producing a figure.
#+caption: A Python block producing a figure. label:lst:Python2
#+BEGIN_SRC python :results file :exports both
import matplotlib.pyplot as plt, numpy as np
from sympy import *
x=symbols("x")
f=lambda x:sin(x)/x
t=np.arange(-6*np.pi,6*np.pi, 0.1)
ft=[f(u) for u in t]
fig=plt.figure(figsize=(3,2))
plt.plot(t, ft, "b-")
fig.tight_layout()
plt.savefig("tstfig.pdf")
"tstfig.pdf"
#+END_SRC
#+caption: A (not so silly) figure produced by Python. label:fig:Python2
#+RESULTS:
[[file:tstfig.pdf]]
The figure ref:fig:Python2 is produced by the code ref:lst:Python2.
[[bibliographystyle:vancouver]]
[[bibliography:Minimal.bib]]
# Local Variables:
# org-latex-packages-alist: (("AUTO" "babel" t ("pdflatex")) ("AUTO" "polyglossia" t ("xelatex" "lualatex")))
# org-latex-pdf-process: ("latexmk -shell-escape -bibtex -f -pdf %f")
# End:
[-- Attachment #4: Min-Ref.tex --]
[-- Type: text/x-tex, Size: 2236 bytes --]
% Created 2018-12-17 lun. 15:49
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{grffile}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage[frenchb]{babel}
\date{December 2018}
\title{What's up with references ?}
\hypersetup{
pdfauthor={},
pdftitle={What's up with references ?},
pdfkeywords={},
pdfsubject={},
pdfcreator={Emacs 27.0.50 (Org mode 9.1.14)},
pdflang={Frenchb}}
\begin{document}
\maketitle
\tableofcontents
\listoftables
\listoffigures
\section{Some reference samples}
\label{sec:orgfe4b8ad}
This is created using \texttt{org-ref} 's \texttt{label} 's and \texttt{ref} 's.
\subsection{A reference\ldots{}}
\label{sec:org22891f6}
\ldots{} to \cite{gelmanBayesianDataAnalysis2013} ,a \emph{good} textbook.
\subsection{A table}
\label{sec:org844d514}
A Python block producing a (silly) table.
\begin{verbatim}
[[u+str(v) for v in range(1,4)] for u in ["a", "b"]]
\end{verbatim}
\captionof{figure}{A (silly) Python block. \label{lst:Python1}}
\begin{table}[htbp]
\caption{A (silly) Python table. \label{tab:Python1}}
\centering
\begin{tabular}{lll}
a1 & a2 & a3\\
b1 & b2 & b3\\
\end{tabular}
\end{table}
The table \ref{tab:Python1} is produced by the code \ref{lst:Python1}.
\subsection{A figure}
\label{sec:orgf75a27d}
A Python block producing a figure.
\begin{verbatim}
import matplotlib.pyplot as plt, numpy as np
from sympy import *
x=symbols("x")
f=lambda x:sin(x)/x
t=np.arange(-6*np.pi,6*np.pi, 0.1)
ft=[f(u) for u in t]
fig=plt.figure(figsize=(3,2))
plt.plot(t, ft, "b-")
fig.tight_layout()
plt.savefig("tstfig.pdf")
"tstfig.pdf"
\end{verbatim}
\captionof{figure}{A Python block producing a figure. \label{lst:Python2}}
\begin{figure}[htbp]
\centering
\includegraphics[width=.9\linewidth]{tstfig.pdf}
\caption{A (not so silly) figure produced by Python. \label{fig:Python2}}
\end{figure}
The figure \ref{fig:Python2} is produced by the code \ref{lst:Python2}.
\bibliographystyle{vancouver}
\bibliography{Minimal}
\end{document}
[-- Attachment #5: Min-Ref exported by org-latex-export-to-pdf.pdf --]
[-- Type: application/pdf, Size: 143423 bytes --]
[-- Attachment #6: Min-Ref exported by org-odt-export-to-odt.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 18946 bytes --]
[-- Attachment #7: Min-Ref exported by org-pandoc-export-to-latex-pdf.pdf --]
[-- Type: application/pdf, Size: 202284 bytes --]
[-- Attachment #8: Min-Ref exported by org-pandoc-export-to-odt.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 17044 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* (no subject)
@ 2019-02-04 3:40 Lawrence Bottorff
0 siblings, 0 replies; 135+ messages in thread
From: Lawrence Bottorff @ 2019-02-04 3:40 UTC (permalink / raw)
To: emacs-orgmode Mailinglist
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]
At the bottom of this <https://orgmode.org/manual/Literal-examples.html> is
a description of adding a `org-store-link` inside of a babel code block
edit called with C-c ' , however, it doesn't seem to work with C-c l ,
although M-x org-store-line does work. Or am I seeing, doing this wrong?
LB
[-- Attachment #2: Type: text/html, Size: 395 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: (no subject)
2018-10-15 8:04 Nik Clayton
2018-10-17 13:20 ` Nicolas Goaziou
@ 2019-09-15 21:06 ` Matt Price
1 sibling, 0 replies; 135+ messages in thread
From: Matt Price @ 2019-09-15 21:06 UTC (permalink / raw)
To: Nik Clayton; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]
I'm replying a year late to this thread, post-merge, because I've
discovered it breaks interaction with the highlight.js library(
https://highlightjs.org/) and therefore my workflow, which depends on
highlightjs via reveal.js.
My difficulty is with the current version of ~org-html-do-format-code~,
which currently surrounds each loc with a ~<code>~ tag and potentially some
classes:
(format "<code%s>%s</code>"
(if num-start
(format " data-ox-html-linenr=\"%s\"" line-num)
"")
loc)
On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton <nik@ngo.org.uk> wrote:
> Hi,
>
> I'd like to propose a couple of changes / enhancements to how org-export
> exports some data in to HTML files to make it slightly easier to style
> those files.
>
> The first is re line-numbers.
>
> At the moment those get exported as content in the HTML, although they're
> really additional metadata. Amongst other things, this means that if you
> copy/paste from the output you get the line numbers included in the text
> that's copied.
>
> CSS supports arbitrary counters that can be associated with content,
> starting from an arbitrary value. My current hack that sort of works is the
> following CSS:
> .....
> and a change to org-html-do-format-code to wrap each line in its own
> <code>...</code> element:
>
> ...
> ;; Transcoded src line.
> (format "<code>%s</code>" loc)
> ...
>
> a) Does that sound reasonable?
> b) Should this replace the current approach, or be an option that can be
> toggled by a customisation?
>
> I agree that thisseems to make sense for many applications. But
highlight.js is a very widely-used highlighting library that expects
exactly one ~<code>~ tag inside a given ~<pre>~ block. The additional
~<code>~ tags that org now generates on html export break highlight in
ways I don't believe can easily be fixed. I wonder if we could revisit the
idea of adding a user option that would allow this feature to be switched
off? If this would be of general use I can prepare a patch.
Thanks,
Matt
[-- Attachment #2: Type: text/html, Size: 3506 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
end of thread, other threads:[~2019-09-15 21:06 UTC | newest]
Thread overview: 135+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
2013-03-07 20:47 ` Carsten Dominik
2013-03-07 22:07 ` Achim Gratz
2013-03-08 10:04 ` Bastien
2013-03-08 10:39 ` was: " Andreas Röhler
2013-03-08 10:46 ` (no subject) Bastien
2013-03-08 10:59 ` Andreas Röhler
2013-03-08 11:05 ` Bastien
2013-03-08 11:18 ` Andreas Röhler
2013-03-08 11:23 ` Bastien
2013-03-08 13:00 ` Andreas Röhler
2013-03-08 13:12 ` Bastien
2013-03-08 15:22 ` Andreas Röhler
2013-03-08 15:40 ` Bastien
2013-03-08 20:39 ` T.F. Torrey
2013-03-08 21:19 ` Nicolas Goaziou
2013-03-08 21:57 ` Suvayu Ali
2013-03-08 22:15 ` interoperability matters " Gregor Zattler
2013-03-09 14:09 ` Bastien
2013-03-10 22:40 ` T.F. Torrey
2013-03-08 13:25 ` [RFC] Org syntax (draft) François Pinard
2013-03-08 15:23 ` Nicolas Richard
2013-03-08 22:06 ` Nicolas Goaziou
2013-03-09 10:52 ` Waldemar Quevedo
2013-03-09 14:23 ` Carsten Dominik
2013-03-09 14:42 ` Nicolas Goaziou
2013-03-09 15:05 ` Carsten Dominik
2013-03-15 20:22 ` Nicolas Goaziou
2013-03-17 18:48 ` Samuel Wales
2013-04-05 17:01 ` Bastien
2013-03-13 14:07 ` Nicolas Richard
2013-03-15 20:39 ` Nicolas Goaziou
2013-03-09 23:16 ` Achim Gratz
2013-03-09 23:49 ` Nicolas Goaziou
2013-03-10 4:35 ` Jambunathan K
2013-03-10 7:08 ` Nicolas Goaziou
2013-03-10 10:14 ` Bastien
2013-03-10 10:16 ` Bastien
2013-03-10 13:07 ` Achim Gratz
2013-03-10 14:11 ` Bastien
2013-03-10 16:02 ` Achim Gratz
2013-03-10 16:09 ` Jambunathan K
2013-03-10 17:12 ` Achim Gratz
2013-03-10 21:44 ` Jonathan Leech-Pepin
2013-03-10 15:44 ` Jambunathan K
2013-03-14 16:58 ` Eric S Fraga
2013-03-14 18:26 ` Jambunathan K
2013-03-14 18:51 ` David Engster
2013-03-14 19:03 ` [Out-of-Thread] " Jambunathan K
2013-03-14 19:15 ` David Engster
2013-03-14 19:23 ` Jambunathan K
2013-03-14 19:29 ` David Engster
2013-03-14 19:52 ` Jambunathan K
2013-04-09 16:37 ` Bastien
2013-03-17 7:18 ` Achim Gratz
2013-03-17 9:36 ` Sebastien Vauban
-- strict thread matches above, loose matches on Subject: below --
2019-02-04 3:40 (no subject) Lawrence Bottorff
2018-12-19 12:58 Emmanuel Charpentier
2018-10-20 9:02 stardiviner
2018-10-15 8:04 Nik Clayton
2018-10-17 13:20 ` Nicolas Goaziou
2019-09-15 21:06 ` Matt Price
2018-05-03 13:44 Arne Babenhauserheide
2018-05-03 14:29 ` Bastien
2018-05-03 21:02 ` Arne Babenhauserheide
2018-05-04 1:02 ` steen
2018-05-04 5:38 ` Michael Welle
2018-05-11 20:07 ` Nicolas Goaziou
2018-03-02 16:10 Joseph Vidal-Rosset
2016-11-01 16:10 John Kitchin
2016-09-19 16:38 John Brodie
2016-09-20 20:32 ` Nicolas Goaziou
2015-11-03 19:53 Fritz Kunze
2015-10-11 19:51 Shankar Rao
2015-09-04 14:51 Eduardo Mercovich
2015-09-04 15:25 ` thomas
2015-09-04 18:35 ` Eduardo Mercovich
2015-01-24 16:23 M.S.Khed Khed
2014-05-03 1:52 Ryan Moszynski
2014-05-03 3:01 ` William Henney
2014-05-03 3:22 ` William Henney
2014-01-30 0:03 Ken Okada
2014-01-30 0:15 ` Bastien
2014-01-30 0:22 ` John Hendy
2014-01-30 7:17 ` Ken Okada
2014-01-31 6:29 ` John Hendy
2014-01-31 7:11 ` Nick Dokos
2014-02-03 22:13 ` Marcin Borkowski
2013-11-06 6:13 Cecil Westerhof
2013-11-06 8:32 ` Bastien
2013-11-06 8:42 ` Bastien
[not found] ` <CAG-LmmDGaczy8pyeCTU6-YJ9oTBeEufqU6kC2PUb-U6ucexhZA@mail.gmail.com>
[not found] ` <87txfpaeli.fsf@bzg.ath.cx>
[not found] ` <CAG-LmmDFjqbuqfF1YJoeX6x_UdujK+0noeFcGSD15hs49Tbo=Q@mail.gmail.com>
2013-11-06 18:38 ` Cecil Westerhof
2013-10-11 7:14 "Recent items" Agenda view? Martin Beck
2013-10-11 20:35 ` Samuel Wales
2013-10-14 8:46 ` (no subject) Martin Beck
2013-03-03 0:55 Vikas Rawal
2013-01-29 9:43 Martin Beck
2013-01-30 12:12 ` Bernt Hansen
2013-01-24 12:11 Herbert Sitz
2013-01-15 19:26 Rick Frankel
2012-11-11 15:36 Fabrice Popineau
2012-11-11 23:09 ` Nicolas Goaziou
2012-11-12 7:40 ` Fabrice Popineau
2012-11-07 18:50 Kevin Buchs
2012-09-29 7:30 Neuwirth Erich
2012-09-29 7:39 ` Bastien
2012-09-29 8:09 ` Achim Gratz
2012-09-29 9:12 ` Bastien
2012-09-29 9:52 ` Achim Gratz
2012-08-24 16:21 Feiming Chen
2012-05-22 3:32 "Smart" quotes Mark E. Shoulson
2012-05-23 22:17 ` Nicolas Goaziou
2012-05-24 3:05 ` Mark E. Shoulson
2012-05-25 17:14 ` Nicolas Goaziou
2012-05-25 22:51 ` Mark E. Shoulson
2012-05-26 6:48 ` Nicolas Goaziou
2012-05-29 1:30 ` Mark E. Shoulson
2012-05-29 17:57 ` Nicolas Goaziou
2012-05-30 0:51 ` Mark E. Shoulson
2012-05-31 1:50 ` (no subject) Mark Shoulson
2012-05-31 13:38 ` Nicolas Goaziou
2012-05-11 20:56 Rick Frankel
2012-05-11 20:38 ` Eric Schulte
2012-05-11 22:43 ` Bernt Hansen
2012-05-17 6:23 ` Bastien
2012-01-23 12:00 Tom Regner
2012-01-23 16:34 ` Tom Regner
2012-01-23 20:31 ` Eric Schulte
2012-01-24 1:55 ` Tom Regner
2012-01-05 17:36 Ab Cd
2011-08-06 1:19 Vikas Rawal
2011-02-21 22:13 Vincent-Xavier JUMEL
2011-02-23 19:52 ` Bernt Hansen
2011-02-23 19:54 ` Bernt Hansen
2011-04-09 9:41 ` Vincent-Xavier JUMEL
2010-06-29 17:50 amscopub-mail
2009-09-18 12:35 Robin Green
2009-02-17 18:57 Matthew Lundin
2009-02-17 20:26 ` Carsten Dominik
2008-01-28 11:20 Dimitris Kapetanakis
2008-01-29 9:39 ` Bastien Guerry
2007-11-13 20:35 François Puitg
2007-10-20 10:33 Kevin Brubeck Unhammer
2007-10-21 22:20 ` Bastien
2006-05-25 10:43 Thomas Baumann
2006-05-25 12:49 ` Carsten Dominik
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).