(no subject)

(no subject)

[Thomas Baumann]

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

Re: (no subject)

[Carsten Dominik]

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

(no subject)

[Kevin Brubeck Unhammer]

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

Re: (no subject)

[Bastien]

"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

(no subject)

[François Puitg]

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

(no subject)

[Dimitris Kapetanakis]

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

Re: (no subject)

[Bastien Guerry]

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

(no subject)

[Matthew Lundin]

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

Re: (no subject)

[Carsten Dominik]

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

(no subject)

[Robin Green]

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

(no subject)

[amscopub-mail]

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.

(no subject)

[Vincent-Xavier JUMEL]

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

Re: (no subject)

[Bernt Hansen]

"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

Re: (no subject)

[Bernt Hansen]

"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

Re: (no subject)

[Vincent-Xavier JUMEL]

: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

(no subject)

[Vikas Rawal]

(no subject)

[Ab Cd]

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.

(no subject)

[Tom Regner]

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

Re: (no subject)

[Tom Regner]

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

Re: (no subject)

[Eric Schulte]

[-- 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/

Re: (no subject)

[Tom Regner]

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

Re: (no subject)

[Eric Schulte]

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/

(no subject)

[Rick Frankel]

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

Re: (no subject)

[Bernt Hansen]

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

Re: (no subject)

[Bastien]

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

"Smart" quotes

[Mark E. Shoulson]

[-- Attachment #1: Type: text/html, Size: 1675 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: smartquotes2.patch --]
[-- Type: text/x-patch; name="smartquotes2.patch", Size: 2277 bytes --]

diff --git a/lisp/org-entities.el b/lisp/org-entities.el
index 8b5b3f3..ee54abc 100644
--- a/lisp/org-entities.el
+++ b/lisp/org-entities.el
@@ -47,6 +47,14 @@ in backends where the corresponding character is not available."
   :version "24.1"
   :type 'boolean)
 
+(defcustom org-smart-quotes nil
+  "Non-nil means display ' and \" characters as Unicode \"smart\" quotes.
+Org-mode will try to figure out if a quote character is opening or closing.
+
+Note: this does not affect export, only on-screen appearance."
+  :group 'org-entities
+  :type 'boolean)
+
 (defcustom org-entities-user nil
   "User-defined entities used in Org-mode to produce special characters.
 Each entry in this list is a list of strings.  It associates the name
diff --git a/lisp/org.el b/lisp/org.el
index 05f5375..213490e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5926,6 +5926,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
 		 '(1 'org-archived prepend))
 	   ;; Specials
 	   '(org-do-latex-and-special-faces)
+	   '(org-smartify-quotes)
 	   '(org-fontify-entities)
 	   '(org-raise-scripts)
 	   ;; Code
@@ -5948,6 +5949,33 @@ 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))
 
+(defconst org-smart-quotes-regex
+  ;; ' is a word character, " is punctuation.
+  "\\(\"\\<\\)\\|\\>\\s.*\\(\"\\)\\|\\(?:\\W\\|^\\)\\('\\)\\|\\w\\s.*\\('\\)")
+
+
+(defun org-smartify-quotes (limit)
+  "Make 'smart quotes' out of straight quotes."
+  (let* (start end subst k)
+    (when org-smart-quotes
+      (catch 'match
+	(while (re-search-forward org-smart-quotes-regex
+		limit t)
+	  (cond ((match-string 1)
+		 (setq k 1 subst "“"))
+		((match-string 2)
+		 (setq k 2 subst "”"))
+		((match-string 3)
+		 (setq k 3 subst "‘"))
+		((match-string 4)
+		 (setq k 4 subst "’")))
+	  (add-text-properties (match-beginning k) (match-end k)
+			       (list 'font-lock-fontified t))
+	  (compose-region (match-beginning k) (match-end k) subst nil)
+	  (backward-char 1)
+	  (throw 'match t))
+	nil))))
+
 (defun org-toggle-pretty-entities ()
   "Toggle the composition display of entities as UTF8 characters."
   (interactive)

[-- Attachment #3: ChangeLog --]
[-- Type: text/plain, Size: 159 bytes --]

2012-05-21  Mark Shoulson  <mark@kli.org>

	* lisp/org.el, lisp/org-entities.el: added org-smart-quotes
	for displaying ' and " characters as "smart quotes."

Re: "Smart" quotes

[Nicolas Goaziou]

Hello,


"Mark E. Shoulson" <mark@kli.org> writes:

> "Smart" quotes can be annoying when they aren't smart enough. But when
> they work you can miss them. I'm attaching a patch that defines a
> custom variable org-smart-quotes (nil by default), which when non-nil
> causes the " and ' characters to display as “smart” quotes, hopefully
> the right ones. They're still ' and " in the underlying text, just
> overlaid with “”.

This is not related to entities, so code shouldn't be in org-entities.el.

Also, quotes are dependent on locale[fn:1]. English/US only quotes look
like a niche to me. Would it be possible to modify the patch and have
this feature handle LANGUAGE keyword, or at least have a support for it?


Regards,

[fn:1] https://en.wikipedia.org/wiki/Non-English_usage_of_quotation_marks

-- 
Nicolas Goaziou

Re: "Smart" quotes

[Mark E. Shoulson]

On 05/23/2012 06:17 PM, Nicolas Goaziou wrote:
> Hello,
>
>
> "Mark E. Shoulson"<mark@kli.org>  writes:
>
>> "Smart" quotes can be annoying when they aren't smart enough. But when
>> they work you can miss them. I'm attaching a patch that defines a
>> custom variable org-smart-quotes (nil by default), which when non-nil
>> causes the " and ' characters to display as “smart” quotes, hopefully
>> the right ones. They're still ' and " in the underlying text, just
>> overlaid with “”.
> This is not related to entities, so code shouldn't be in org-entities.el.
Agreed.

>
> Also, quotes are dependent on locale[fn:1]. English/US only quotes look
> like a niche to me. Would it be possible to modify the patch and have
> this feature handle LANGUAGE keyword, or at least have a support for it?
Hm.  I like the idea, but it raises some questions for me.  It would be 
particularly good if this could share code/custom variables with the 
pieces of the (new) exporter that make smart quotes on export.  That way 
we could be sure that what it looks like onscreen would also be what it 
looked like when exported.  Looking at contrib/lisp/org-e-latex.el at an 
upcoming exporter for such things, I see a variable org-e-latex-quotes, 
which has nice language-aware parts... but misses an important point.  
Each language gets to define one regexp for opening quotes, one for 
closing quotes, and one for single quotes.  But don't we want to talk 
about (at least) two levels of quotes, see your own reference[fn:1]?  
Single quotes would be for inner, second-level quotes (if we're using 
double straight quotes according to (American) English usage, I would 
guess we'd be using single straight quotes the same way).  That works 
okay for English, where a single apostrophe not part of a grouping 
construct is going to be interpreted as a "close" single quote and look 
right for an apostrophe.  It might not work so good in French where 
apostrophes are also used, but also single guillemets for inner-level 
quotes.  Does the setup there need to be smarter, or at least more 
extensible, to allow for more than exactly three entries?  Clever enough 
regexps could distinguish inner quotes from apostrophes, etc.  
Should/can we consider extending this for the new exporters?

(I'm looking forward to HTML and ODT exporters that can do smart quotes; 
the straight quotes are really the main jarring things about using Org 
as a lightweight markup and exporting into something fancier)

~mark

Re: "Smart" quotes

[Nicolas Goaziou]

Hello,

"Mark E. Shoulson" <mark@kli.org> writes:

> Hm.  I like the idea, but it raises some questions for me.  It would
> be particularly good if this could share code/custom variables with
> the pieces of the (new) exporter that make smart quotes on export.
> That way we could be sure that what it looks like onscreen would also
> be what it looked like when exported.

I could be interesting, but keep in mind that no matter how "smart" your
quotes are, they will fail in some situations. So, it will have to be
optional for export, independently on their in-buffer status.

The OPTIONS keyword may be used, with q:t and q:nil items.

> Looking at contrib/lisp/org-e-latex.el at an upcoming exporter for
> such things, I see a variable org-e-latex-quotes, which has nice
> language-aware parts... but misses an important point.  Each language
> gets to define one regexp for opening quotes, one for closing quotes,
> and one for single quotes.  But don't we want to talk about (at least)
> two levels of quotes, see your own reference[fn:1]?

Probably. But that's going to be somewhat harder.

> Single quotes would be for inner, second-level quotes (if we're using
> double straight quotes according to (American) English usage, I would
> guess we'd be using single straight quotes the same way).  That works
> okay for English, where a single apostrophe not part of a grouping
> construct is going to be interpreted as a "close" single quote and
> look right for an apostrophe.

The regexp may be able to tell level 1 from level 2 quotes.

> It might not work so good in French where apostrophes are also used,

There are no spaces around apostrophes, so they shouldn't be caught by
the regexp.

> but also single guillemets for inner-level quotes.

What are single guillemets? I don't think there is such thing in French.

> Should/can we consider extending this for the new exporters?

I think it would be a good addition to the export mechanism, if you want
to give it a try.

> (I'm looking forward to HTML and ODT exporters that can do smart
> quotes; the straight quotes are really the main jarring things about
> using Org as a lightweight markup and exporting into something
> fancier)

A function, provided in org-export, could help changing dumb quotes into
smart quotes in plain text. Then, it would be easier for back-ends to
provide the feature, if they wanted to.


Regards,

-- 
Nicolas Goaziou

Re: "Smart" quotes

[Jambunathan K]

> I could be interesting, but keep in mind that no matter how "smart" your
> quotes are, they will fail in some situations. So, it will have to be
> optional for export, independently on their in-buffer status.
>
> The OPTIONS keyword may be used, with q:t and q:nil items.

I don't see an entry for this in `org-export-options-alist'.  So I
believe you are soliciting opinion on a fresh addition.

>> (I'm looking forward to HTML and ODT exporters that can do smart
>> quotes; the straight quotes are really the main jarring things about
>> using Org as a lightweight markup and exporting into something
>> fancier)
>
> A function, provided in org-export, could help changing dumb quotes into
> smart quotes in plain text. Then, it would be easier for back-ends to
> provide the feature, if they wanted to.

I can use it, if made available.  I think, It will be help if we force
all exporters to produce utf-8 files.
-- 

Re: "Smart" quotes

[Mark E. Shoulson]

On 05/25/2012 01:14 PM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@kli.org>  writes:
>
>> Hm.  I like the idea, but it raises some questions for me.  It would
>> be particularly good if this could share code/custom variables with
>> the pieces of the (new) exporter that make smart quotes on export.
>> That way we could be sure that what it looks like onscreen would also
>> be what it looked like when exported.
> I could be interesting, but keep in mind that no matter how "smart" your
> quotes are, they will fail in some situations. So, it will have to be
> optional for export, independently on their in-buffer status.
>
> The OPTIONS keyword may be used, with q:t and q:nil items.

"Smart" quotes absolutely have to be optional, and probably disabled by 
default.  They're going to fail sometimes, so they should only be there 
when you ask for them.  Smart-quotes-for-export and 
smart-quotes-onscreen need to be settable independently, yes.  
Smart-quotes-for-export needs to be settable per-file/per-buffer, with 
OPTIONS or something.  Smart-quotes-onscreen doesn't have to be 
buffer-local, though it might be a good idea.  Using q:t or maybe ":t in 
options seems perfectly good for setting exporting smart quotes.  It 
still would be good if onscreen and export could share code.

>> Looking at contrib/lisp/org-e-latex.el at an upcoming exporter for
>> such things, I see a variable org-e-latex-quotes, which has nice
>> language-aware parts... but misses an important point.  Each language
>> gets to define one regexp for opening quotes, one for closing quotes,
>> and one for single quotes.  But don't we want to talk about (at least)
>> two levels of quotes, see your own reference[fn:1]?
> Probably. But that's going to be somewhat harder.
>
>> Single quotes would be for inner, second-level quotes (if we're using
>> double straight quotes according to (American) English usage, I would
>> guess we'd be using single straight quotes the same way).  That works
>> okay for English, where a single apostrophe not part of a grouping
>> construct is going to be interpreted as a "close" single quote and
>> look right for an apostrophe.
> The regexp may be able to tell level 1 from level 2 quotes.

Do you mean that the author would use the same characters for both first 
and second level quotes, and the regexp would be smart enough to 
distinguish which level each was at?  I don't think that's possible, and 
you probably don't either.  What I meant, and you probably did as well, 
was that if we use apostrophes for second-level quotes, a regexp can be 
smart enough to tell the difference between a second-level quote and a 
non-quote apostrophe....

>> It might not work so good in French where apostrophes are also used,
> There are no spaces around apostrophes, so they shouldn't be caught by
> the regexp.

which is what you say here.  They *should* be caught by a regexp, but 
not the same one; they need to be smartified also, just not necessarily 
treated the same as second-level quotes.

>> but also single guillemets for inner-level quotes.
> What are single guillemets? I don't think there is such thing in French.

You're right; the Wikipedia page says that French uses quote-marks or 
the same double-chevrons for inner quotes.  I thought it used \lsaquo 
and \rsaquo, « like ‹ this › ».  Looks like it does in Swiss typography 
for various languages, according to the page.  Danish also uses the 
single-chevrons (pointing the other direction), and Azerbaijani and 
Basque, etc... Whatever.  What I meant was, if people are going to be 
writing using straight ascii quotes and expect them to be changed into 
language-appropriate quotes, they're going to want something like

"this is a 'quote', and that's all you need to know."

becoming, for instance

«this is a ‹quote›, and that’s all you need to know.»

that is, it should be possible to use the single quotes for inner 
quotes, which would mean more than just opening/closing/single in the 
org-e-latex-quotes (and analogous variables in other exporters).  Being 
able to determine when you need ‹› and when ’ might be a little 
uncertain, but it isn't hard to make a regexp that can make a decent 
guess at it.

>> Should/can we consider extending this for the new exporters?
> I think it would be a good addition to the export mechanism, if you want
> to give it a try.

I'd love to get org more export-friendly.  I'll see what I can 
understand of the (new) export code.

>> (I'm looking forward to HTML and ODT exporters that can do smart
>> quotes; the straight quotes are really the main jarring things about
>> using Org as a lightweight markup and exporting into something
>> fancier)
> A function, provided in org-export, could help changing dumb quotes into
> smart quotes in plain text. Then, it would be easier for back-ends to
> provide the feature, if they wanted to.
That sounds like a possibility, might make for good generic handling, 
only one bit of code to treat everything consistently... yeah, I didn't 
like the idea at first, I'm starting to like it more.  I'll think on it too.

~mark

Re: "Smart" quotes

[Nicolas Goaziou]

Hello,

"Mark E. Shoulson" <mark@kli.org> writes:

>> The regexp may be able to tell level 1 from level 2 quotes.
>
> Do you mean that the author would use the same characters for both
> first and second level quotes, and the regexp would be smart enough to
> distinguish which level each was at?  I don't think that's possible,
> and you probably don't either.

Actually, I do. Since you can tell an opening quote from a closing one
by the position of the white space (or parenthesis, beginning/end of
line) near it, I think you can deduce the quote level. I may be wrong,
though.

> "this is a 'quote', and that's all you need to know."
>
> becoming, for instance
>
> «this is a ‹quote›, and that’s all you need to know.»

"this is a "quote", and that's all you need to know" is as parsable to
me.

As a side note, at least in French, many typographers would recommend
"this is a /quote/, and that's all you need to know" here. Oh, and
I know that was just an example.

> I'd love to get org more export-friendly.  I'll see what I can
> understand of the (new) export code.

Do not hesitate to ask questions about it.


Regards,

-- 
Nicolas Goaziou

Re: "Smart" quotes

[Mark E. Shoulson]

On 05/26/2012 02:48 AM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@kli.org>  writes:
>
>>> The regexp may be able to tell level 1 from level 2 quotes.
>> Do you mean that the author would use the same characters for both
>> first and second level quotes, and the regexp would be smart enough to
>> distinguish which level each was at?  I don't think that's possible,
>> and you probably don't either.
> Actually, I do. Since you can tell an opening quote from a closing one
> by the position of the white space (or parenthesis, beginning/end of
> line) near it, I think you can deduce the quote level. I may be wrong,
> though.

Maybe, if it's all on one line.  But if the quote is several lines long, 
can you sensibly count the levels?  I guess it doesn't actually matter, 
but it starts to get weird if you find yourself looking arbitrarily far 
back, and then you start building in exceptions for crossing paragraph 
boundaries... And then there's the fact that multi-paragraph quotes 
usually have an open-quote for each paragraph but only one close-quote 
at the end... Actually keeping count of what level you're at, 
accurately, is a classic example of a non-regular language; you need a 
push-down automaton to keep count, and regular expressions don't cut 
it.  Then again, Emacs regexps are more powerful than simple regular 
expressions, and we only would want to keep track of even vs odd level 
anyway.

I'm rambling.  In sum, I'm going to start off /not/ trying to solve that 
problem, and assume the writer is going to use alternating " and ' as 
typography requires and not try to second-guess what level we're at.  As 
that progresses, maybe I'll come to understand better what can and can't 
(and should and shouldn't) be deduced by the regexps.

>> "this is a 'quote', and that's all you need to know."
>>
>> becoming, for instance
>>
>> «this is a ‹quote›, and that’s all you need to know.»
> "this is a "quote", and that's all you need to know" is as parsable to
> me.
>
> As a side note, at least in French, many typographers would recommend
> "this is a /quote/, and that's all you need to know" here. Oh, and
> I know that was just an example.

I see; because I can tell that the second " must be an open-quote and 
not closing the first, due to its position relative to the spaces.  It 
does seem possible, but I think I'm going to try not solving that 
problem first.

(And French typography raises other problems, since French puts lots of 
space around the quote-marks, to the extent that French typists typing 
plain-text will often put a space on both sides of a quote-mark, making 
it hard to see whether it opens or closes... another issue, not 
necessarily solvable, to watch for.)

~mark

Re: "Smart" quotes

[Nicolas Goaziou]

Hello,

"Mark E. Shoulson" <mark@kli.org> writes:

> Maybe, if it's all on one line.  But if the quote is several lines
> long, can you sensibly count the levels?

Well, yes.

> I guess it doesn't actually matter, but it starts to get weird if you
> find yourself looking arbitrarily far back, and then you start
> building in exceptions for crossing paragraph boundaries...

True. I had the exporter in mind, where you always start at the
beginning of the paragraph. It would be more difficult with search
starting in the middle of the paragraph.

> And then there's the fact that multi-paragraph quotes usually have an
> open-quote for each paragraph but only one close-quote at the end...

Some french typographers suggest to use a close-quote at the beginning
of the paragraph to avoid that confusion, or to simply drop them (since
they are a pain to maintain anyway). I don't know about other languages
but, if that's the same, is it a good idea to bother implementing it?

> Actually keeping count of what level you're at, accurately, is
> a classic example of a non-regular language; you need a push-down
> automaton to keep count, and regular expressions don't cut it.

This is limited to 2 levels.

> I'm rambling.  In sum, I'm going to start off /not/ trying to solve
> that problem, and assume the writer is going to use alternating " and
> as typography requires and not try to second-guess what level we're
> at.

You are right, the problem will be easier to solve with both " and '.

Though, "as typography requires" is not true. In France, the /Imprimerie
Nationale/ suggests to use guillemots at both levels. Remember that
typography is localized, which is the main difficulty of the
implementation.


Regards,

-- 
Nicolas Goaziou

Re: "Smart" quotes

[Mark E. Shoulson]

On 05/29/2012 01:57 PM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@kli.org>  writes:
>
>
>> I guess it doesn't actually matter, but it starts to get weird if you
>> find yourself looking arbitrarily far back, and then you start
>> building in exceptions for crossing paragraph boundaries...
> True. I had the exporter in mind, where you always start at the
> beginning of the paragraph. It would be more difficult with search
> starting in the middle of the paragraph.

Maybe the on-screen stuff is no harder; will just have to see.

>> And then there's the fact that multi-paragraph quotes usually have an
>> open-quote for each paragraph but only one close-quote at the end...
> Some french typographers suggest to use a close-quote at the beginning
> of the paragraph to avoid that confusion, or to simply drop them (since
> they are a pain to maintain anyway). I don't know about other languages
> but, if that's the same, is it a good idea to bother implementing it?

I've never heard of it.  But I think we may be overthinking this; we can 
drive ourselves crazy trying to compress a dozen different typographical 
traditions (and informal customs) into a few Elisp rules.  On the other 
hand, I don't think we need to throw up our hands and give up either! :)

>> Actually keeping count of what level you're at, accurately, is
>> a classic example of a non-regular language; you need a push-down
>> automaton to keep count, and regular expressions don't cut it.
> This is limited to 2 levels.
True.
>> I'm rambling.  In sum, I'm going to start off /not/ trying to solve
>> that problem, and assume the writer is going to use alternating " and
>> as typography requires and not try to second-guess what level we're
>> at.
> You are right, the problem will be easier to solve with both " and '.
>
> Though, "as typography requires" is not true. In France, the /Imprimerie
> Nationale/ suggests to use guillemots at both levels. Remember that
> typography is localized, which is the main difficulty of the
> implementation.

Also a good point.

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

Re: (no subject)

[Mark Shoulson]

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

Re: (no subject)

[Nicolas Goaziou]

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

Smart Quotes Exporting (Was: Re: (no subject))

[Mark E. Shoulson]

Sorry for messing up the thread subject header; I think I misused 
gmane's posting.

On 05/31/2012 09:38 AM, Nicolas Goaziou wrote:
> 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.

Oh, certainly; they're all a disaster.  I think I said that in the 
writeup at the top.  This is just proof of concept, nothing is in the 
right place, nothing is properly documented.  They have to be 
defcustoms, there needs to be a good :type in the defcustom as well as a 
proper docstring.  You'll get no argument from me about the lack (or 
inaccuracy) of docstrings and such.  I hadn't gotten that far yet.  I 
said the patch was only if you wanted to tinker with the development as 
this progresses.

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

Not sure I understand this comment.

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

Hm.  OK, this may indeed be (a) a problem and (b) an indication that I 
really don't understand the process as I thought I did... ... ...  Ah.  
So when the "plain" text is being exported, the exporter passes along 
the text in chunks as divided up by the formatting.  So string #2 is 
broken out from the others due to its being in italics.  That is indeed 
an issue.  Moreover, I never even properly considered the effects of 
formatting characters (as opposed to punctuation) right next to the 
quote-marks, even if this weren't a problem.

So... there's the filter-parse-tree-functions hook gets applied within 
the parse tree... so a back-end can add a function to that list which 
looks over the parse-tree and watches for these border cases (and also 
the ones within ordinary strings).  Looks like it's going to be tough to 
work in any flexibility to define further per-language or per-backend 
cleverness to handle anything beyond the "canonical set" of open-double, 
close-double, open-single, close-single, and mid-word.

To be sure, anything we do will most assuredly fail even on some fairly 
reasonable input, in which case the users are pretty much on their own 
and will have to do things the hard way.  And I could use that as the 
answer here, that, "well, it'll work only within plain-text strings" 
(and I might possibly still have to use that answer), but I would rather 
include the situations you bring up in the supported set and not throw 
up my hands at it.  So, yes, will look at that.
>> +  (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.

Good call.

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

I'd been looking at other functions that didn't have that available; 
thanks for pointing me at it.

~mark

Re: Smart Quotes Exporting

[Nicolas Goaziou]

Hello,

"Mark E. Shoulson" <mark@kli.org> writes:

> Oh, certainly; they're all a disaster.  I think I said that in the
> writeup at the top.  This is just proof of concept, nothing is in the
> right place, nothing is properly documented.  They have to be
> defcustoms, there needs to be a good :type in the defcustom as well as
> a proper docstring.  You'll get no argument from me about the lack (or
> inaccuracy) of docstrings and such.  I hadn't gotten that far yet.
> I said the patch was only if you wanted to tinker with the development
> as this progresses.

No worries, I was just making some comments before forgetting about
them.

>> +(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.
>
> Not sure I understand this comment.

Since `org-e-latex--quotation-marks' just calls
`org-export-quotation-marks', you can remove completely the former from
"org-export.el" and use the latter instead.

> So... there's the filter-parse-tree-functions hook gets applied within
> the parse tree... so a back-end can add a function to that list which
> looks over the parse-tree and watches for these border cases (and also
> the ones within ordinary strings).  Looks like it's going to be tough
> to work in any flexibility to define further per-language or
> per-backend cleverness to handle anything beyond the "canonical set"
> of open-double, close-double, open-single, close-single, and mid-word.
>
> To be sure, anything we do will most assuredly fail even on some
> fairly reasonable input, in which case the users are pretty much on
> their own and will have to do things the hard way.  And I could use
> that as the answer here, that, "well, it'll work only within
> plain-text strings" (and I might possibly still have to use that
> answer), but I would rather include the situations you bring up in the
> supported set and not throw up my hands at it.  So, yes, will look at
> that.

Actually it isn't very hard to handle this problem. But it will be
different than the fontification used in an Org buffer.

You might want to look at `org-element-normalize-contents', which solves
a similar problem: removing maximum common indentation at the parsed
paragraph level.

As a first approximation, I can imagine a function accepting an element,
an object or a secondary string and returning an equivalent element,
object or secondary string, with its quotes "smartified". The algorithm
could go like this:

Walk element/object/secondary-string's contents .

  1. When a string is encountered:

     1. If it has a quote as its first or last position, check for
        objects before or after the string to guess its status. An
        object never starts with a white space, but you may have to
        check :post-blank property in order to know if previous object
        had white spaces at its end.

     2. For each quote everywhere else in the string, your regexp can
        handle it fine.

  2. When an object belonging to `org-element-recursive-objects' is
     encountered, apply the function to this object.

  3. Accumulate returned strings or objects.

Use accumulated data as the contents of the new object to return (i.e.
just add the type and the same properties at the beginning of this list
if it was an object or an element, return it as-is if that was
a secondary string).

On the elements side, only paragraphs, verse-blocks and table-rows can
directly contain quotes. Also, headline, inlinetask item and
footnote-reference have secondary strings containing quotes.

I'm not sure yet where and how to install such a function, but I will
think about it when it is implemented.


Regards,

-- 
Nicolas Goaziou

Re: Smart Quotes Exporting

[Mark E. Shoulson]

On 06/01/2012 01:11 PM, Nicolas Goaziou wrote:
> Hello,
>
> "Mark E. Shoulson"<mark@kli.org>  writes:
>
>> Oh, certainly; they're all a disaster.  I think I said that in the
>> writeup at the top.  This is just proof of concept, nothing is in the
>> right place, nothing is properly documented.  They have to be
>> defcustoms, there needs to be a good :type in the defcustom as well as
>> a proper docstring.  You'll get no argument from me about the lack (or
>> inaccuracy) of docstrings and such.  I hadn't gotten that far yet.
>> I said the patch was only if you wanted to tinker with the development
>> as this progresses.
> No worries, I was just making some comments before forgetting about
> them.

Ah, ok.  Good!  Thanks.

>>> +(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.
>> Not sure I understand this comment.
> Since `org-e-latex--quotation-marks' just calls
> `org-export-quotation-marks', you can remove completely the former from
> "org-export.el" and use the latter instead.

Well, that was done on purpose, and maybe the reason will make sense.  
As I see it, each exporter should be able to have its own smartifier 
function, and the export engine should make no assumptions about that: 
just call the individual exporter's function.  On the other hand, many 
(but perhaps not all!) of the exporters may find themselves using 
essentially the same code just with different replacement strings.  So I 
thought that "general-purpose" should be in org-export.el, just for the 
convenience of exporters should they choose to make use of it.  So, many 
of the exporters' smartifier functions will really just be calls to the 
more general-purpose function.

Does that make sense?

>> So... there's the filter-parse-tree-functions hook gets applied within
>> the parse tree... so a back-end can add a function to that list which
>> looks over the parse-tree and watches for these border cases (and also
>> the ones within ordinary strings).  Looks like it's going to be tough
>> to work in any flexibility to define further per-language or
>> per-backend cleverness to handle anything beyond the "canonical set"
>> of open-double, close-double, open-single, close-single, and mid-word.
>>
>> To be sure, anything we do will most assuredly fail even on some
>> fairly reasonable input, in which case the users are pretty much on
>> their own and will have to do things the hard way.  And I could use
>> that as the answer here, that, "well, it'll work only within
>> plain-text strings" (and I might possibly still have to use that
>> answer), but I would rather include the situations you bring up in the
>> supported set and not throw up my hands at it.  So, yes, will look at
>> that.
> Actually it isn't very hard to handle this problem. But it will be
> different than the fontification used in an Org buffer.
Yes, the fontification on-screen is different, and uses a rather 
different function--but if I can help it, the same regexps!  So things 
work the same everywhere.

I also started thinking a little about what you write below, how we can 
inspect the characters just after or before quotes at the very beginning 
or end of each chunk.  It would be nice if it could all be encapsulated 
neatly in the regexp(s).
> As a first approximation, I can imagine a function accepting an element,
> an object or a secondary string and returning an equivalent element,
> object or secondary string, with its quotes "smartified". The algorithm
> could go like this:
>
> Walk element/object/secondary-string's contents .

Need it be element/object/secondary-string?  At the bottom level it's 
always about strings; the higher levels don't affect the processing of 
each string in isolation.  Do we need to intercept it at the element 
level or just wait to grab things in the plain-text filter, since we 
have access at that point too?

(Might also be that my understanding of the process and the nature of 
elements is faulty or limited.  Will have to see what works.)

>
>    1. When a string is encountered:
>
>       1. If it has a quote as its first or last position, check for
>          objects before or after the string to guess its status. An
>          object never starts with a white space, but you may have to
>          check :post-blank property in order to know if previous object
>          had white spaces at its end.

Hmm, this may in fact answer my question above: you need to be able to 
get at the object level to test the post-blank.  I'll experiment.

>       2. For each quote everywhere else in the string, your regexp can
>          handle it fine.
>
>    2. When an object belonging to `org-element-recursive-objects' is
>       encountered, apply the function to this object.
>
>    3. Accumulate returned strings or objects.
>
> Use accumulated data as the contents of the new object to return (i.e.
> just add the type and the same properties at the beginning of this list
> if it was an object or an element, return it as-is if that was
> a secondary string).
>
> On the elements side, only paragraphs, verse-blocks and table-rows can
> directly contain quotes. Also, headline, inlinetask item and
> footnote-reference have secondary strings containing quotes.

I also haven't yet worked in smarts (especially in the on-screen 
fontifier) for things like not fontifying inside comments or verbatim 
strings, etc.  That'll come in time.

> I'm not sure yet where and how to install such a function, but I will
> think about it when it is implemented.

Uuum... Maybe org-export-filter-parse-tree-functions?

~mark

Re: Smart Quotes Exporting

[Mark E. Shoulson]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

All right, preliminary patch is attached, *maybe* good enough for more 
serious consideration now, but might need some fixes. Still only uses 
ordinary regexps and plain-text strings, but can now handle the example 
with formatting-breaks next to quotes. Things have been moved into more 
appropriate locations, made customs, docstrings and types fixed, etc, etc.

It supports onscreen display of "smart" quotes (when enabled); I have 
the quotes displayed in org-document-info face so they are slightly 
distinct, to make it clearer that they are "altered" from what they are 
in the plain text. This may or may not be a popular (or good) idea. I 
have also built it into the new export engine in org-e-latex and 
org-e-html as proofs of concept. I'm not positive the latex one will 
work properly for German, though; there might need to be something 
enabled in LaTeX for it to format ,, into „.

It should probably be set not to smartify quotes onscreen in comments; I 
haven't done that yet.

Comments welcome; I hope I didn't complicate matters in the export 
engines too much.

~mark

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-smart-quotes-for-onscreen-display-and-for-latex-.patch --]
[-- Type: text/x-patch; name="0001-Add-smart-quotes-for-onscreen-display-and-for-latex-.patch", Size: 13760 bytes --]

From 1bc507cf69c94d5645436abc6e28e7d96999083e Mon Sep 17 00:00:00 2001
From: Mark Shoulson <mark@kli.org>
Date: Tue, 29 May 2012 23:01:12 -0400
Subject: [PATCH] Add `smart' quotes for onscreen display and for latex and
 html export

* lisp/org.el: Add `smart' quotes: custom variables to define
  regexps to recognize quotes, to define how and whether to
  display them, and org-fontify-quotes to display `smart-quote'
  characters when activated.

* contrib/lisp/org-export.el: Add function org-export-quotation-marks
  as a utility function usable by individual exporters to apply
  `smart' quotes.

* contrib/lisp/org-e-latex.el: Replace org-e-latex-quotes custom with
  org-e-latex-quotes-replacements and make org-e-latex--quotation-marks
  use the org-export-quotation-marks function in org-export.el.

* contrib/lisp/org-e-html.el: Replace org-e-html-quotes custom with
  org-e-html-quotes-replacements and enable org-e-html--quotation-marks,
  using org-export-quotation-marks function in org-export.el.
---
 contrib/lisp/org-e-html.el  |   57 ++++++++----------------
 contrib/lisp/org-e-latex.el |   67 ++++++++++-------------------
 contrib/lisp/org-export.el  |   26 +++++++++++
 lisp/org.el                 |  101 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 168 insertions(+), 83 deletions(-)

diff --git a/contrib/lisp/org-e-html.el b/contrib/lisp/org-e-html.el
index 53547a0..d4a505e 100644
--- a/contrib/lisp/org-e-html.el
+++ b/contrib/lisp/org-e-html.el
@@ -1077,37 +1077,24 @@ in order to mimic default behaviour:
 
 ;;;; Plain text
 
-(defcustom org-e-html-quotes
-  '(("fr"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
-     ("\\(\\S-\\)\"" . "~»")
-     ("\\(\\s-\\|(\\|^\\)'" . "'"))
-    ("en"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "``")
-     ("\\(\\S-\\)\"" . "''")
-     ("\\(\\s-\\|(\\|^\\)'" . "`")))
-  "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.
-
-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."
+(defcustom org-e-html-smart-quote-replacements
+  '(("fr" "&laquo;&nbsp;" "&nbsp;&raquo;" "&lsquo;" "&rsquo;" "&rsquo;")
+    ("en" "&ldquo;" "&rdquo;" "&lsquo;" "&rsquo;" "&rsquo;")
+    ("de" "&bdquo;" "&ldquo;" "&sbquo;" "&lsquo;" "&rsquo;"))
+  "What to export for `smart-quotes'.
+A list of five strings:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
   :group 'org-export-e-html
   :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     "))))
+	  (string :tag "Open double-quotes")    ; "“"
+	  (string :tag "Close double-quotes")   ; "”"
+	  (string :tag "Open single-quote")     ; "‘"
+	  (string :tag "Close single-quote")    ; "’"
+	  (string :tag "Mid-word apostrophe"))) ; "’"
 
 ;;;; Compilation
 
@@ -1497,15 +1484,7 @@ This is used to choose a separator for constructs like \\verb."
   "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-html-quotes)
-		 ;; Falls back on English.
-		 (assoc "en" org-e-html-quotes))))
-  text)
+  (org-export-quotation-marks text info org-e-html-smart-quote-replacements))
 
 (defun org-e-html--wrap-label (element output)
   "Wrap label associated to ELEMENT around OUTPUT, if appropriate.
@@ -2729,7 +2708,7 @@ contextual information."
   ;; 		  (format "\\%s{}" (match-string 1 text)) nil t text)
   ;; 	    start (match-end 0))))
   ;; Handle quotation marks
-  ;; (setq text (org-e-html--quotation-marks text info))
+  (setq text (org-e-html--quotation-marks text info))
   ;; Convert special strings.
   ;; (when (plist-get info :with-special-strings)
   ;;   (while (string-match (regexp-quote "...") text)
diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index 67e9197..2543c29 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -687,38 +687,28 @@ during latex export it will output
 
 ;;;; Plain text
 
-(defcustom org-e-latex-quotes
-  '(("fr"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
-     ("\\(\\S-\\)\"" . "~»")
-     ("\\(\\s-\\|(\\|^\\)'" . "'"))
-    ("en"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "``")
-     ("\\(\\S-\\)\"" . "''")
-     ("\\(\\s-\\|(\\|^\\)'" . "`")))
-  "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.
-
-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."
+(defcustom org-e-latex-quote-replacements
+  '(("en" "``" "''" "`" "'" "'")
+    ("fr" "«~" "~»" "‹~" "~›" "'")
+    ("de" ",," "``" "," "`" "'"))
+  "What to output for quotes.  Each element is a list of six strings.
+The first string specifies the language these quotes apply to (\"en\",
+\"fr\", \"de\", etc.; see the LANGUAGE keyword), and the other five
+define the strings to use for, in order:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
   :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
+	  (list
+	   (string :tag "Language code")
+	   (string :tag "Open double-quotes")
+	   (string :tag "Close double-quotes")
+	   (string :tag "Open single-quote")
+	   (string :tag "Close single-quote")
+	   (string :tag "Mid-word apostrophe"))))
 
 ;;;; Compilation
 
@@ -852,19 +842,8 @@ 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))
 
 (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..87f5c84 100644
--- a/contrib/lisp/org-export.el
+++ b/contrib/lisp/org-export.el
@@ -284,6 +284,32 @@ rules.")
   :tag "Org Export General"
   :group 'org-export)
 
+;; 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."
+  ;; (message text)
+  (let* ((regexps 
+	  (cdr 
+	   (or 
+	    (assoc (plist-get info :language)
+		   org-smart-quotes-regexps)
+	    (assq 'DEFAULT org-smart-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)))
+	      (setq text (replace-regexp-in-string re su text t t 9))))
+	  quotes))
+  text)
+
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
 (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 0157e36..70d7266 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3625,6 +3625,69 @@ When nil, the \\name form remains in the buffer."
   :version "24.1"
   :type 'boolean)
 
+(defcustom org-smart-quotes nil
+  "Non-nil means display `smart' quotes on-screen in place
+of \" and ' characters."
+  :group 'org-appearance
+  :type 'boolean)
+
+(defcustom org-smart-quotes-replacements
+  '("“" "”" "‘" "’" "’")
+  "What to display on-screen when `org-smart-quotes' is non-nil.
+A list of five strings:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
+  :group 'org-appearance
+  :type '(list
+	  (string :tag "Open double-quotes" "«")    ; "“"
+	  (string :tag "Close double-quotes" "»")   ; "”"
+	  (string :tag "Open single-quote" "‹")     ; "‘"
+	  (string :tag "Close single-quote" "›")    ; "’"
+	  (string :tag "Mid-word apostrophe" "’"))) ; "’"
+
+(defcustom org-smart-quotes-regexps
+  '((DEFAULT
+      "\\(?:\\s-\\|\\s(\\|^\\)\\(?9:\"\\)\\(?:\\w\\|\\s.\\|\\s_\\)\\|\\s-\\(?9:\"\\)$" 
+      "\\(?:\\S-\\)\\(?9:\"\\)\\(?:\\s-\\|$\\|\\s)\\|\\s.\\)\\|^\\(?9:\"\\)\\s-" 
+      "\\(?:\\s-\\|(\\|^\\)\\(?9:'\\)\\w\\|\\s-\\(?9:'\\)$"
+      "\\w\\(?9:'\\)\\(?:\\s-\\|\\s.\\|$\\)\\|^\\(?9:'\\)\\s-"
+      "\\w\\(?9:'\\)\\w"))
+  "Regexps for quotes to be made `smart' quotes upon export or onscreen.
+Each element is a list of six strings.  The car is the a string
+representing the language to which this definition applies (e.g. \"en\",
+\"fr\", \"de\", etc.); the cdr (the other five elements) are five REs 
+matching, in order:
+ 1. Opening double-quotes
+ 2. Closing double-quotes
+ 3. Opening single-quotes
+ 4. Closing single-quotes
+ 5. Mid-word apostrophes
+
+Each regexp should surround the actual quote in a capturing group, which
+must be specified as number 9 (so as not to conflict with other processing.)
+
+One element should have as its car the atom DEFAULT, to be used when no
+other element fits.  It is also the one used for on-screen display of
+`smart' quotes (see the variable `org-smart-quotes').
+
+As what makes an opening or closing quote is somewhat consistent across
+languages (as opposed to how they are represented in typography), the
+DEFAULT element is likely sufficient for most purposes."
+  :group 'org-export-general
+  :group 'org-appearance
+  :type '(repeat
+	  (list
+	   (choice (const DEFAULT)
+		   (string :tag "Language"))
+	   (regexp :tag "Open double-quotes")
+	   (regexp :tag "Close double-quotes")
+	   (regexp :tag "Open single-quote")
+	   (regexp :tag "Close double-quote")
+	   (regexp :tag "Mid-word apostrophe"))))
+
 (defvar org-emph-re nil
   "Regular expression for matching emphasis.
 After a match, the match groups contain these elements:
@@ -5927,6 +5990,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 +6012,43 @@ 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))
 
+(defun org-fontify-quotes (limit)
+  (require 'org-export)
+  (when org-smart-quotes
+    (let* ((start (point))
+	   k su
+	   (splice-string (lambda (lst join)
+			    (if (null (cdr lst)) (car lst)
+			      (concat (car lst) join
+				      (splice-string (cdr lst) join)))))
+	   (regexps
+	    (cdr
+	     (assq 'DEFAULT org-smart-quotes-regexps)))
+	   (i 1)
+	   (allreg
+	    (mapconcat (lambda (n) (prog1 (format "\\(?%d:%s\\)" i n)
+				     (setq i (1+ i))))
+		       regexps "\\|"))
+	   (quotes (pairlis regexps org-smart-quotes-replacements)))
+      (catch 'match
+	(while (re-search-forward allreg limit t)
+	  (cond ((match-string 1)
+		 (setq su (nth 0 org-smart-quotes-replacements)))
+		((match-string 2)
+		 (setq su (nth 1 org-smart-quotes-replacements)))
+		((match-string 3)
+		 (setq su (nth 2 org-smart-quotes-replacements)))
+		((match-string 4)
+		 (setq su (nth 3 org-smart-quotes-replacements)))
+		((match-string 5)
+		 (setq su (nth 4 org-smart-quotes-replacements))))
+	  (add-text-properties (match-beginning 9) (match-end 9)
+			       (list 'font-lock-fontified t
+				     'face 'org-document-info))
+	  (compose-region (match-beginning 9) (match-end 9) 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

Re: Smart Quotes Exporting

[Mark E. Shoulson]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

Update on the smart-quotes patch.  Supports the odt exporter now too, 
which I think covers all the current major "new" exporters for which it 
is relevant (adding smart quotes to ASCII export is a contradiction in 
terms; should it be in the "publish" exporter?  It didn't look like it 
to me).

Added an options keyword, '"' (that is, the double-quote mark) to select 
smart quotes on/off, and a defcustom for customizing your default.  Set 
the default default [sic] to nil, though actually it might be reasonable 
to set it to t.  Slight touch-up to the regexps since last time, but 
they will definitely be subject to a lot of fine-tuning as more special 
cases are found that break them and ways to fix it are found (the 
close-quote still breaks on one of "/a/." or "/a./")

It's pretty good on the whole, though, usually guesses right.  I know 
there's some work being done on the odt exporter; hope this fits in well 
with it.

How does it look to you?

~mark


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-smart-quotes-for-onscreen-display-and-for-latex-.patch --]
[-- Type: text/x-patch; name="0001-Add-smart-quotes-for-onscreen-display-and-for-latex-.patch", Size: 18446 bytes --]

From e6df2efd1a9ce36964a20fc06aa2a688acd87efb Mon Sep 17 00:00:00 2001
From: Mark Shoulson <mark@kli.org>
Date: Tue, 29 May 2012 23:01:12 -0400
Subject: [PATCH] Add `smart' quotes for onscreen display and for latex and
 html export

* lisp/org.el: Add `smart' quotes: custom variables to define
  regexps to recognize quotes, to define how and whether to
  display them, and org-fontify-quotes to display `smart-quote'
  characters when activated.

* contrib/lisp/org-export.el: Add function org-export-quotation-marks
  as a utility function usable by individual exporters to apply
  `smart' quotes.  Also add keyword '"' for customizing smart quotes,
  and custom default for it.

* contrib/lisp/org-e-latex.el: Replace org-e-latex-quotes custom with
  org-e-latex-quotes-replacements and make org-e-latex--quotation-marks
  use the org-export-quotation-marks function in org-export.el.

* contrib/lisp/org-e-html.el: Replace org-e-html-quotes custom with
  org-e-html-quotes-replacements and enable org-e-html--quotation-marks,
  using org-export-quotation-marks function in org-export.el.

* contrib/lisp/org-e-odt.el: Replace org-e-odt-quotes custom with
  org-e-odt-quotes-replacements and make org-e-odt--quotation-marks
  use org-export-quotations-marks function in org-export.el.
---
 contrib/lisp/org-e-html.el  |   57 ++++++++----------------
 contrib/lisp/org-e-latex.el |   67 ++++++++++-------------------
 contrib/lisp/org-e-odt.el   |   68 ++++++++++-------------------
 contrib/lisp/org-export.el  |   38 ++++++++++++++++
 lisp/org.el                 |  101 +++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 203 insertions(+), 128 deletions(-)

diff --git a/contrib/lisp/org-e-html.el b/contrib/lisp/org-e-html.el
index 4287a59..c49608d 100644
--- a/contrib/lisp/org-e-html.el
+++ b/contrib/lisp/org-e-html.el
@@ -1043,37 +1043,24 @@ in order to mimic default behaviour:
 
 ;;;; Plain text
 
-(defcustom org-e-html-quotes
-  '(("fr"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
-     ("\\(\\S-\\)\"" . "~»")
-     ("\\(\\s-\\|(\\|^\\)'" . "'"))
-    ("en"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "``")
-     ("\\(\\S-\\)\"" . "''")
-     ("\\(\\s-\\|(\\|^\\)'" . "`")))
-  "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.
-
-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."
+(defcustom org-e-html-smart-quote-replacements
+  '(("fr" "&laquo;&nbsp;" "&nbsp;&raquo;" "&lsquo;" "&rsquo;" "&rsquo;")
+    ("en" "&ldquo;" "&rdquo;" "&lsquo;" "&rsquo;" "&rsquo;")
+    ("de" "&bdquo;" "&ldquo;" "&sbquo;" "&lsquo;" "&rsquo;"))
+  "What to export for `smart-quotes'.
+A list of five strings:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
   :group 'org-export-e-html
   :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     "))))
+	  (string :tag "Open double-quotes")    ; "“"
+	  (string :tag "Close double-quotes")   ; "”"
+	  (string :tag "Open single-quote")     ; "‘"
+	  (string :tag "Close single-quote")    ; "’"
+	  (string :tag "Mid-word apostrophe"))) ; "’"
 
 ;;;; Compilation
 
@@ -1459,15 +1446,7 @@ This is used to choose a separator for constructs like \\verb."
   "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-html-quotes)
-		 ;; Falls back on English.
-		 (assoc "en" org-e-html-quotes))))
-  text)
+  (org-export-quotation-marks text info org-e-html-smart-quote-replacements))
 
 (defun org-e-html--wrap-label (element output)
   "Wrap label associated to ELEMENT around OUTPUT, if appropriate.
@@ -2691,7 +2670,7 @@ contextual information."
   ;; 		  (format "\\%s{}" (match-string 1 text)) nil t text)
   ;; 	    start (match-end 0))))
   ;; Handle quotation marks
-  ;; (setq text (org-e-html--quotation-marks text info))
+  (setq text (org-e-html--quotation-marks text info))
   ;; Convert special strings.
   ;; (when (plist-get info :with-special-strings)
   ;;   (while (string-match (regexp-quote "...") text)
diff --git a/contrib/lisp/org-e-latex.el b/contrib/lisp/org-e-latex.el
index 67e9197..2543c29 100644
--- a/contrib/lisp/org-e-latex.el
+++ b/contrib/lisp/org-e-latex.el
@@ -687,38 +687,28 @@ during latex export it will output
 
 ;;;; Plain text
 
-(defcustom org-e-latex-quotes
-  '(("fr"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "«~")
-     ("\\(\\S-\\)\"" . "~»")
-     ("\\(\\s-\\|(\\|^\\)'" . "'"))
-    ("en"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "``")
-     ("\\(\\S-\\)\"" . "''")
-     ("\\(\\s-\\|(\\|^\\)'" . "`")))
-  "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.
-
-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."
+(defcustom org-e-latex-quote-replacements
+  '(("en" "``" "''" "`" "'" "'")
+    ("fr" "«~" "~»" "‹~" "~›" "'")
+    ("de" ",," "``" "," "`" "'"))
+  "What to output for quotes.  Each element is a list of six strings.
+The first string specifies the language these quotes apply to (\"en\",
+\"fr\", \"de\", etc.; see the LANGUAGE keyword), and the other five
+define the strings to use for, in order:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
   :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
+	  (list
+	   (string :tag "Language code")
+	   (string :tag "Open double-quotes")
+	   (string :tag "Close double-quotes")
+	   (string :tag "Open single-quote")
+	   (string :tag "Close single-quote")
+	   (string :tag "Mid-word apostrophe"))))
 
 ;;;; Compilation
 
@@ -852,19 +842,8 @@ 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))
 
 (defun org-e-latex--wrap-label (element output)
   "Wrap label associated to ELEMENT around OUTPUT, if appropriate.
diff --git a/contrib/lisp/org-e-odt.el b/contrib/lisp/org-e-odt.el
index cab4c66..7eb92b6 100644
--- a/contrib/lisp/org-e-odt.el
+++ b/contrib/lisp/org-e-odt.el
@@ -2318,39 +2318,28 @@ in order to mimic default behaviour:
 
 ;;;; Plain text
 
-(defcustom org-e-odt-quotes
-  '(("fr"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "« ")
-     ("\\(\\S-\\)\"" . "» ")
-     ("\\(\\s-\\|(\\|^\\)'" . "'"))
-    ("en"
-     ("\\(\\s-\\|[[(]\\|^\\)\"" . "“")
-     ("\\(\\S-\\)\"" . "”")
-     ("\\(\\s-\\|(\\|^\\)'" . "‘")
-     ("\\(\\S-\\)'" . "’")))
-  "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.
-
-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."
+(defcustom org-e-odt-quote-replacements
+  '(("en" "“" "”" "‘" "’" "’")
+    ("fr" "« " " »" "‹ " " ›" "’")
+    ("de" "„" "“" "‚" "‘" "’"))
+  "What to output for quotes.  Each element is a list of six strings.
+The first string specifies the language these quotes apply to (\"en\",
+\"fr\", \"de\", etc.; see the LANGUAGE keyword), and the other five
+define the strings to use for, in order:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
   :group 'org-export-e-odt
-  :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
+	  (list
+	   (string :tag "Language code")
+	   (string :tag "Open double-quotes")
+	   (string :tag "Close double-quotes")
+	   (string :tag "Open single-quote")
+	   (string :tag "Close single-quote")
+	   (string :tag "Mid-word apostrophe"))))
 
 ;;;; Compilation
 
@@ -2485,19 +2474,8 @@ This is used to choose a separator for constructs like \\verb."
 	  when (not (string-match (regexp-quote (char-to-string c)) s))
 	  return (char-to-string c))))
 
-(defun org-e-odt--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-odt-quotes)
-		 ;; Falls back on English.
-		 (assoc "en" org-e-odt-quotes))))
-  text)
+(defun org-e-odt--quotation-marks (text info) 
+  (org-export-quotation-marks text info org-e-odt-quote-replacements))
 
 (defun org-e-odt--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..4e5f738 100644
--- a/contrib/lisp/org-export.el
+++ b/contrib/lisp/org-export.el
@@ -143,6 +143,7 @@
     (:with-priority nil "pri" org-export-with-priority)
     (:with-special-strings nil "-" org-export-with-special-strings)
     (:with-sub-superscript nil "^" org-export-with-sub-superscripts)
+    (:with-smart-quotes nil "\"" org-export-with-smart-quotes)
     (:with-toc nil "toc" org-export-with-toc)
     (:with-tables nil "|" org-export-with-tables)
     (:with-tags nil "tags" org-export-with-tags)
@@ -284,6 +285,33 @@ rules.")
   :tag "Org Export General"
   :group 'org-export)
 
+;; 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."
+  ;; (message text)
+  (when (plist-get info :with-smart-quotes)
+    (let* ((regexps 
+	    (cdr 
+	     (or 
+	      (assoc (plist-get info :language)
+		     org-smart-quotes-regexps)
+	      (assq 'DEFAULT org-smart-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)))
+		(setq text (replace-regexp-in-string re su text t t 9))))
+	  quotes)))
+  text)
+
+;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
 (defcustom org-export-with-archived-trees 'headline
   "Whether sub-trees with the ARCHIVE tag should be exported.
 
@@ -445,6 +473,16 @@ e.g. \"e:nil\"."
   :group 'org-export-general
   :type 'boolean)
 
+(defcustom org-export-with-smart-quotes t
+  "Non-nil means try to make quotes \"smart\" when exporting.
+
+For example, HTML export would convert \"Hello\" to &ldquo;Hello&rdquo;.
+
+The exact style of quotes depends on the language; see the LANGUAGE
+keyword and also the smart-quote custom settings for each exporter."
+  :group 'org-export-general
+  :type 'boolean)
+
 (defcustom org-export-with-planning nil
   "Non-nil means include planning info in export.
 This option can also be set with the #+OPTIONS: line,
diff --git a/lisp/org.el b/lisp/org.el
index b89889d..8a446ec 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3629,6 +3629,69 @@ When nil, the \\name form remains in the buffer."
   :version "24.1"
   :type 'boolean)
 
+(defcustom org-smart-quotes nil
+  "Non-nil means display `smart' quotes on-screen in place
+of \" and ' characters."
+  :group 'org-appearance
+  :type 'boolean)
+
+(defcustom org-smart-quotes-replacements
+  '("“" "”" "‘" "’" "’")
+  "What to display on-screen when `org-smart-quotes' is non-nil.
+A list of five strings:
+ 1. Open double-quotes
+ 2. Close double-quotes
+ 3. Open single-quote
+ 4. Close single-quote
+ 5. Mid-word apostrophe"
+  :group 'org-appearance
+  :type '(list
+	  (string :tag "Open double-quotes" "“")
+	  (string :tag "Close double-quotes" "”")
+	  (string :tag "Open single-quote" "‘")
+	  (string :tag "Close single-quote" "’")
+	  (string :tag "Mid-word apostrophe" "’")))
+
+(defcustom org-smart-quotes-regexps
+  '((DEFAULT
+      "\\(?:\\s-\\|\\s(\\|^\\)\\(?9:\"\\)\\(?:\\w\\|\\s.\\|\\s_\\)\\|\\s-\\(?9:\"\\)$" 
+      "\\(?:\\S-\\)\\(?9:\"\\)\\(?:\\s-\\|$\\|\\s)\\|\\s.\\)\\|^\\(?9:\"\\)\\s-" 
+      "\\(?:\\s-\\|(\\|^\\)\\(?9:'\\)\\w\\|\\s-\\(?9:'\\)$"
+      "\\w\\s.*\\(?9:'\\)\\(?:\\s-\\|\\s.\\|$\\)\\|^\\(?9:'\\)\\s-"
+      "\\w\\(?9:'\\)\\w"))
+  "Regexps for quotes to be made `smart' quotes upon export or onscreen.
+Each element is a list of six strings.  The car is the a string
+representing the language to which this definition applies (e.g. \"en\",
+\"fr\", \"de\", etc.); the cdr (the other five elements) are five REs 
+matching, in order:
+ 1. Opening double-quotes
+ 2. Closing double-quotes
+ 3. Opening single-quotes
+ 4. Closing single-quotes
+ 5. Mid-word apostrophes
+
+Each regexp should surround the actual quote in a capturing group, which
+must be specified as number 9 (so as not to conflict with other processing.)
+
+One element should have as its car the atom DEFAULT, to be used when no
+other element fits.  It is also the one used for on-screen display of
+`smart' quotes (see the variable `org-smart-quotes').
+
+As what makes an opening or closing quote is somewhat consistent across
+languages (as opposed to how they are represented in typography), the
+DEFAULT element is likely sufficient for most purposes."
+  :group 'org-export-general
+  :group 'org-appearance
+  :type '(repeat
+	  (list
+	   (choice (const DEFAULT)
+		   (string :tag "Language"))
+	   (regexp :tag "Open double-quotes")
+	   (regexp :tag "Close double-quotes")
+	   (regexp :tag "Open single-quote")
+	   (regexp :tag "Close double-quote")
+	   (regexp :tag "Mid-word apostrophe"))))
+
 (defvar org-emph-re nil
   "Regular expression for matching emphasis.
 After a match, the match groups contain these elements:
@@ -5931,6 +5994,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))
@@ -5952,6 +6016,43 @@ 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))
 
+(defun org-fontify-quotes (limit)
+  (require 'org-export)
+  (when org-smart-quotes
+    (let* ((start (point))
+	   k su
+	   (splice-string (lambda (lst join)
+			    (if (null (cdr lst)) (car lst)
+			      (concat (car lst) join
+				      (splice-string (cdr lst) join)))))
+	   (regexps
+	    (cdr
+	     (assq 'DEFAULT org-smart-quotes-regexps)))
+	   (i 1)
+	   (allreg
+	    (mapconcat (lambda (n) (prog1 (format "\\(?%d:%s\\)" i n)
+				     (setq i (1+ i))))
+		       regexps "\\|"))
+	   (quotes (pairlis regexps org-smart-quotes-replacements)))
+      (catch 'match
+	(while (re-search-forward allreg limit t)
+	  (cond ((match-string 1)
+		 (setq su (nth 0 org-smart-quotes-replacements)))
+		((match-string 2)
+		 (setq su (nth 1 org-smart-quotes-replacements)))
+		((match-string 3)
+		 (setq su (nth 2 org-smart-quotes-replacements)))
+		((match-string 4)
+		 (setq su (nth 3 org-smart-quotes-replacements)))
+		((match-string 5)
+		 (setq su (nth 4 org-smart-quotes-replacements))))
+	  (add-text-properties (match-beginning 9) (match-end 9)
+			       (list 'font-lock-fontified t
+				     'face 'org-document-info))
+	  (compose-region (match-beginning 9) (match-end 9) 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

Re: Smart Quotes Exporting

[Nicolas Goaziou]

Hello,

"Mark E. Shoulson" <mark@kli.org> writes:

> Update on the smart-quotes patch.  Supports the odt exporter now too,
> which I think covers all the current major "new" exporters for which
> it is relevant (adding smart quotes to ASCII export is a contradiction
> in terms;

ASCII exporter also handle UTF-8. So it's good to have there too.

> should it be in the "publish" exporter?  It didn't look like it to
> me).

No.

> Added an options keyword, '"' (that is, the double-quote mark) to
> select smart quotes on/off, and a defcustom for customizing your
> default.  Set the default default [sic] to nil, though actually it
> might be reasonable to set it to t.  Slight touch-up to the regexps
> since last time, but they will definitely be subject to a lot of
> fine-tuning as more special cases are found that break them and ways
> to fix it are found (the close-quote still breaks on one of "/a/." or
> "/a./")

Again, using regexps on plain text objects is a wrong approach, as you
need a better understanding of the whole paragraph structure to
properly. I already suggested a possible solution, is there anything
wrong with it?


Regards,

-- 
Nicolas Goaziou

Re: Smart Quotes Exporting

[Mark Shoulson]

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:

> 
> Hello,
> 
> "Mark E. Shoulson" <mark <at> kli.org> writes:
> 
> > Update on the smart-quotes patch.  Supports the odt exporter now too,
> > which I think covers all the current major "new" exporters for which
> > it is relevant (adding smart quotes to ASCII export is a contradiction
> > in terms;
> 
> ASCII exporter also handle UTF-8. So it's good to have there too.

Really?  I would have thought ASCII meant ASCII, as in 7-bit clean text.  More
of a "plain text" exporter then.  Fair enough.  I'll work it in.

> > should it be in the "publish" exporter?  It didn't look like it to
> > me).
> 
> No.

OK, good.

> 
> > Added an options keyword, '"' (that is, the double-quote mark) to
> > select smart quotes on/off, and a defcustom for customizing your
> > default.  Set the default default [sic] to nil, though actually it
> > might be reasonable to set it to t.  Slight touch-up to the regexps
> > since last time, but they will definitely be subject to a lot of
> > fine-tuning as more special cases are found that break them and ways
> > to fix it are found (the close-quote still breaks on one of "/a/." or
> > "/a./")
> 
> Again, using regexps on plain text objects is a wrong approach, as you
> need a better understanding of the whole paragraph structure to
> properly. I already suggested a possible solution, is there anything
> wrong with it?

It looked to me like your solution would essentially boil down to "do string
handling when there's a string, otherwise recur down and find the strings,"
which essentially means apply it to all the strings... and there were already
functions out there applying things to strings, so this can just ride along with
them.  Here, let's look at your suggestion and see if we can find what I missed:

] Walk element/object/secondary-string's contents .
] 
]   1. When a string is encountered:
]
]      1. If it has a quote as its first or last position, check for
]         objects before or after the string to guess its status. An
]         object never starts with a white space, but you may have to
]         check :post-blank property in order to know if previous object
]         had white spaces at its end.
]
]      2. For each quote everywhere else in the string, your regexp can
]         handle it fine.
]
]   2. When an object belonging to `org-element-recursive-objects' is
]      encountered, apply the function to this object.
]
]   3. Accumulate returned strings or objects.

So, if it's a string, use the regexps (if they can be smart enough to look at
beginning and end of the string, which they can--though I haven't been using the
:post-blank property so presumably something is amiss), and if it isn't a
string, recur down until you get to a string... Ah, but only if it's in
org-element-recursive-objects.  So the issue with the current state is that it
would wind up applying to too much? (it would hit code and verbatim elements,
for example, and that would be wrong.)  And detecting such things at the string
level would be the wrong place... So it remains to find the right place in the
processing to put a function like the one you describe.  I'm trying to get a
proper understanding of the code structure to see what you mean.  Looks like it
should be something like a transcoder, only called on everything... wait, called
on the top-level parsed tree object, recursively doing its thing before(?) the
transcoders of the individual objects get to it.  So almost something replacing
the (lambda (blob contents info) contents) stub in org-export-transcoder; does
that make sense to you? Otherwise, called somehow in org-export-data.  In either
case made a hook of some kind so that it is backend-specific.

Does it sound like I am understanding this right, to you?

The on-screen one would still use the plain-string computation, as you said,
since the full parse isn't available.  And that seems to work okay (the export
works okay too, for simple cases.)  It would also need to be tweaked not to act
on verbatim/comment text, etc.

Thanks,

~mark

Re: Smart Quotes Exporting

[Nicolas Goaziou]

Hello,

Mark Shoulson <mark@kli.org> writes:

>> ASCII exporter also handle UTF-8. So it's good to have there too.
>
> Really?  I would have thought ASCII meant ASCII, as in 7-bit clean
> text.

org-e-ascii.el (as old org-ascii.el) handles ASCII, Latin1 and UTF-8
encodings.

> It looked to me like your solution would essentially boil down to "do
> string handling when there's a string, otherwise recur down and find
> the strings," which essentially means apply it to all the
> strings... and there were already functions out there applying things
> to strings, so this can just ride along with them.  Here, let's look
> at your suggestion and see if we can find what I missed:
>
> ] Walk element/object/secondary-string's contents .
> ] 
> ]   1. When a string is encountered:
> ]
> ]      1. If it has a quote as its first or last position, check for
> ]         objects before or after the string to guess its status. An
> ]         object never starts with a white space, but you may have to
> ]         check :post-blank property in order to know if previous object
> ]         had white spaces at its end.
> ]
> ]      2. For each quote everywhere else in the string, your regexp can
> ]         handle it fine.
> ]
> ]   2. When an object belonging to `org-element-recursive-objects' is
> ]      encountered, apply the function to this object.
> ]
> ]   3. Accumulate returned strings or objects.
>
> So, if it's a string, use the regexps (if they can be smart enough to look at
> beginning and end of the string, which they can--though I haven't been using the
> :post-blank property so presumably something is amiss), and if it isn't a
> string, recur down until you get to a string... Ah, but only if it's in
> org-element-recursive-objects.

You're missing an important part: the regexps cannot be smart enough for
quotes at the beginning or the end of the string. There, you must look
outside the string. Hence:

> ]      1. If it has a quote as its first or last position, check for
> ]         objects before or after the string to guess its status. An
> ]         object never starts with a white space, but you may have to
> ]         check :post-blank property in order to know if previous object
> ]         had white spaces at its end.

But you can only do that from the element containing the string, not
from the string itself.

> So the issue with the current state is that it
> would wind up applying to too much? (it would hit code and verbatim elements,
> for example, and that would be wrong.)

No, you are not applying it too much (verbatim elements don't contain
plain-text objects) but your function hasn't got access to enough
information to be useful.

> So it remains to find the right place in the processing to put
> a function like the one you describe.  I'm trying to get a proper
> understanding of the code structure to see what you mean.  Looks like
> it should be something like a transcoder, only called on
> everything... 

Transcoders are type specific, so that's not an option.

> wait, called on the top-level parsed tree object, recursively doing
> its thing before(?) the transcoders of the individual objects get to
> it.

That's called a parse tree filter. That should be a possibility
indeed. The function would be applied on the parse tree and would
replace strings within elements containing plain text (that is
paragraph, verse-block and table-row types). parse tree filters are
applied very early in the export process.

Another option would be to integrate it into
`org-element-normalize-contents', but I think the previous way is
better.

> The on-screen one would still use the plain-string computation, as you said,
> since the full parse isn't available.

Yes.

> It would also need to be tweaked not to act on verbatim/comment text,
> etc.

Yes. You may want to use `org-element-at-point' and `org-element-type'
to tell if you're somewhere smart quotes are allowed (in table,
table-row, paragraph, verse-block elements).


Regards,

-- 
Nicolas Goaziou

Re: Smart Quotes Exporting

[Mark Shoulson]

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:

> 
> Hello,
> 
> Mark Shoulson <mark <at> kli.org> writes:
> 
> >> ASCII exporter also handle UTF-8. So it's good to have there too.
> >
> > Really?  I would have thought ASCII meant ASCII, as in 7-bit clean
> > text.
> 
> org-e-ascii.el (as old org-ascii.el) handles ASCII, Latin1 and UTF-8
> encodings.

I noticed that after writing my response.  The name just threw me a little.  
Yes, that exporter needs to handle it too.

> > It looked to me like your solution would essentially boil down to "do
> > string handling when there's a string, otherwise recur down and find
> > the strings," which essentially means apply it to all the
> > strings... and there were already functions out there applying things
> > to strings, so this can just ride along with them.  Here, let's look
> > at your suggestion and see if we can find what I missed:
> >
....
> > So, if it's a string, use the regexps (if they can be smart enough to look 
at
> > beginning and end of the string, which they can--though I haven't been 
using the
> > :post-blank property so presumably something is amiss), and if it isn't a
> > string, recur down until you get to a string... Ah, but only if it's in
> > org-element-recursive-objects.
> 
> You're missing an important part: the regexps cannot be smart enough for
> quotes at the beginning or the end of the string. There, you must look
> outside the string. Hence:

Well, wait; regexps can make some pretty darn good guesses at the beginnings 
or ends of strings.  Quotations don't normally end in spaces (in the 
conventions used with ""; French typography is different, but if you're using 
spaces around your quotes you have worse problems (line-breaks) to worry 
about).  So if a string ends in space(s) followed by a quote, it's very likely 
that quote is an open-quote for some stuff that comes after.  Conversely, if a 
string starts with a quote followed by some spaces, it's very likely a close-
quote to what went on before.

This isn't quite it; beginning-of-string followed by quote, then punctuation 
and then spaces is also a close-quote, etc... There is a lot of fine-tuning.  
But even what I currently have was able to handle your 

Caesar said, "/Alea Jacta est./"

example.  Yes, there are edge-cases which this won't catch, and it remains to 
be seen how pervasive and annoying those are.  It may be that repeated 
tweaking of regexps will handle enough of the ordinary cases.  It may be that 
after a few rounds of regexp-hacking someone will finally decide that regexp-
hacking just won't handle enough of the important cases.  But I think even as 
it stands now we'd probably handle 80-90% of the normal situations, which 
really is as much as we reasonably can hope for.

Could I trouble someone to try applying my patch and trying it out for 
yourself and seeing just how bad/good the performance is?  It seems to work 
okay for the cases I've been trying, but maybe my dataset isn't robust 
enough.  Let's give it a test and seen how many actual cases in common usage 
it gets wrong.  Maybe see how much can be fixed by tuning regexps.

> 
> > ]      1. If it has a quote as its first or last position, check for
> > ]         objects before or after the string to guess its status. An
> > ]         object never starts with a white space, but you may have to
> > ]         check :post-blank property in order to know if previous object
> > ]         had white spaces at its end.
> 
> But you can only do that from the element containing the string, not
> from the string itself.

The case where a quote both sits at the edge of a string (i.e. at the border 
of some element, formatting, etc) *and* does not have whitespace next to it, 
with possible punctuation, does not seem to be a normal occurrence to me.  If 
I'm wrong, how common *is* it?

> 
> > So the issue with the current state is that it
> > would wind up applying to too much? (it would hit code and verbatim 
elements,
> > for example, and that would be wrong.)
> 
> No, you are not applying it too much (verbatim elements don't contain
> plain-text objects) but your function hasn't got access to enough
> information to be useful.

The on-screen version, of course, will have to be smarter and check for 
the "face" formatting to make sure it doesn't happen in comments or verbatims; 
I am pretty sure it does not do that yet.
 
> > wait, called on the top-level parsed tree object, recursively doing
> > its thing before(?) the transcoders of the individual objects get to
> > it.
> 
> That's called a parse tree filter. That should be a possibility
> indeed. The function would be applied on the parse tree and would
> replace strings within elements containing plain text (that is
> paragraph, verse-block and table-row types). parse tree filters are
> applied very early in the export process.
> 
> Another option would be to integrate it into
> `org-element-normalize-contents', but I think the previous way is
> better.

Maybe.  I know it sounds like I'm fixated on the plain-text solution, but I'm 
not convinced the envisioned problems are more than theoretical, or that they 
will cause an unacceptable amount of error (keeping in mind that some error 
*is* acceptable and unavoidable).

> > The on-screen one would still use the plain-string computation, as you 
said,
> > since the full parse isn't available.
> 
> Yes.
> 
> > It would also need to be tweaked not to act on verbatim/comment text,
> > etc.
> 
> Yes. You may want to use `org-element-at-point' and `org-element-type'
> to tell if you're somewhere smart quotes are allowed (in table,
> table-row, paragraph, verse-block elements).

Probably.  I think I saw some other package make these decisions by peeking at 
the formatting and seeing if it is set in comment-face or something, but 
checking the element at point is presumably more sensible.

~mark

Re: Smart Quotes Exporting

[Nicolas Goaziou]

Hello,

Mark Shoulson <mark@kli.org> writes:

> Well, wait; regexps can make some pretty darn good guesses at the beginnings 
> or ends of strings.

I know that. They make a good job, I just want a better one.

> This isn't quite it; beginning-of-string followed by quote, then punctuation 
> and then spaces is also a close-quote, etc... There is a lot of fine-tuning.  
> But even what I currently have was able to handle your 
>
> Caesar said, "/Alea Jacta est./"
>
> example.

No, it doesn't handle that, actually, it's just sheer luck.  Indeed, the
quoting function is applied to "\"".  There's absolutely no space,
punctuation, etc. to save the day.  So it makes a wild guess with
a probability of 0.5 of success.  Since the guess is always the same,
"/a/" will always fail.

> The case where a quote both sits at the edge of a string (i.e. at the border 
> of some element, formatting, etc) *and* does not have whitespace next to it, 
> with possible punctuation, does not seem to be a normal occurrence to me.  If 
> I'm wrong, how common *is* it?

Even if it rarely happens, it can be _very_ annoying to have to cope
with bad guesses. If it can be avoided, I see no reason not to do so.

Now, here the infrastructure I propose.

Internally, the two following functions are required.

#+begin_src emacs-lisp
(defun org-export--smart-quotes-in-element (element backend)
  "Replace plain quotes with smart quotes in ELEMENT.

ELEMENT is an Org element or a secondary string.  BACKEND is the
back-end to check for rules, as a symbol.

This is a destructive operation.  Return new element."
  (let* ((type (org-element-type element))
         (properties (and type (nth 1 element))))
    ;; Destructively apply changes to secondary string, if any.
    (let ((secondary (and type (assq type org-element-secondary-value-alist))))
      (when secondary
        (let* ((sec-symbol (cdr secondary))
               (sec-value (plist-get properties sec-symbol)))
          (when sec-value
            (setq properties
                  (plist-put properties
                             sec-symbol
                             (org-export--smart-quotes-in-element
                              sec-value backend)))))))
    ;; Destructively change `:caption' if present.  Since it's a dual
    ;; keyword, apply smart quotes to both CAR and CDR, if required.
    (let ((caption (plist-get :caption properties)))
      (when caption
        (setq properties
              (plist-put properties
                         :caption
                         (cons
                          (org-export--smart-quotes-in-element
                           (car caption) backend)
                          (and (cdr caption)
                               (org-export--smart-quotes-in-element
                                (cdr caption) backend)))))))
    ;; Recursively apply changes to contents.  Rebuild ELEMENT along
    ;; the way, with updated strings.
    (let ((contents (if type (org-element-contents element) element))
          previous current next acc)
      (while contents
        (setq current (pop contents)
              next (car contents)
              previous current)
        (push
         (cond ((stringp current)
                ;; CURRENT is a string: Call
                ;; `org-export-quotation-marks' with appropriate
                ;; information.
                (org-export-quotation-marks
                 current
                 (and previous
                      (if (stringp previous)
                          (length (and (string-match " +\\'" previous)
                                       (match-string 0 previous)))
                        (org-element-property :post-blank previous)))
                 (and next
                      (if (not (stringp next)) 0
                        (length (and (string-match "\\` +" next)
                                     (match-string 0 next)))))
                 backend))
               ;; CURRENT is recursive: Move into it.
               ((plist-get properties :contents-begin)
                (org-export--smart-quotes-in-element current backend))
               ;; Otherwise, just accumulate CURRENT.
               (t current))
         acc))
      ;; Re-build transformed element.
      (if (or (not type) (eq type 'plain-text)) (nreverse acc)
        (nconc (list type properties) (nreverse acc))))))

(defun org-export-set-smart-quotes (tree backend info)
  "Replace plain quotes with smart quotes in TREE.

BACKEND is the back-end, as a symbol, used for transcoding.  INFO
is a plist used as a communication channel.

This is a destructive operation.  This function is meant to be
used as a parse tree filter for back-ends activating smart
quotes."
  ;; Destructively apply smart quotes to parsed keywords in info.
  (let ((value (plist-get info :title)))
    (when value
      (setq info
            (plist-put info
                       :title
                       (org-export--smart-quotes-in-element value backend)))))
  ;; Replace smart quotes in elements containing plain text or
  ;; secondary strings across the parse tree.
  (org-element-map
   tree '(paragraph verse-block table-cell headline inlinetask item)
   (lambda (el)
     (org-export-set-element el
                             (org-export--smart-quotes-in-element el backend))))
  ;; Return parse tree.
  tree)
#+end_src

Then, all is left to do is write the function replacing quotes in
a string, with additional information:

#+begin_src emacs-lisp
(defun org-export-quotation-marks (s &optional prev next backend)
  "Replace plain quotes with smart quotes in string S.

Optional argument PREV (resp. NEXT) is the number of white space
characters before (resp. after) the string, or nil if
S starts (resp. ends) a paragraph.

Optional argument BACKEND is a symbol representing the back-end
to use for substitutions.

The function returns the new string."
  ...)
#+end_src

Once this function is written, add `org-export-set-smart-quotes' as
a parse tree filter in `org-BACKEND-filters-alist'.

For example, one can add the following in org-e-latex.el to activate
smart quotes in latex export:

#+begin_src emacs-lisp
(defconst org-e-latex-filters-alist
  '((:filter-parse-tree . org-export-set-smart-quotes))
  "Alist between filters keywords and back-end specific filters.
See `org-export-filters-alist' for more information.")
#+end_src

Could you please try to modify your original
`org-export-quotation-marks' accordingly and test it?

>> Yes. You may want to use `org-element-at-point' and `org-element-type'
>> to tell if you're somewhere smart quotes are allowed (in table,
>> table-row, paragraph, verse-block elements).
>
> Probably.  I think I saw some other package make these decisions by peeking at 
> the formatting and seeing if it is set in comment-face or something, but 
> checking the element at point is presumably more sensible.

Thinking about it, looking at face used will definitely be faster,
though. That's your call.


Regards,

-- 
Nicolas Goaziou

Re: Smart Quotes Exporting

[Bastien]

Hi Mark and Nicolas,

in the patchwork¹, I've marked patches² related to this discussion as
"Not Applicable".

If there are progress made on this front, please send updated patches.
If there is a patch below that I should apply, please let me know.

Thanks!

¹ http://patchwork.newartisans.com/project/org-mode/list/
² Here are the patches:

http://patchwork.newartisans.com/patch/1330/
http://patchwork.newartisans.com/patch/1344/
http://patchwork.newartisans.com/patch/1346/
http://patchwork.newartisans.com/patch/1348/

-- 
 Bastien

(no subject)

[Feiming Chen]

[-- Attachment #1: Type: text/plain, Size: 28 bytes --]



 Sincerely, 
Feiming Chen

[-- Attachment #2: Type: text/html, Size: 250 bytes --]

(no subject)

[Neuwirth Erich]

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

Re: (no subject)

[Bastien]

Neuwirth Erich <erich.neuwirth@univie.ac.at> writes:

> 1 unexpected results:
>    FAILED  test-ob/org-babel-remove-result--results-org

Fixed, thanks.

-- 
 Bastien

Re: (no subject)

[Achim Gratz]

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

Re: (no subject)

[Bastien]

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

Re: (no subject)

[Achim Gratz]

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

(no subject)

[Kevin Buchs]

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

(no subject)

[Fabrice Popineau]

[-- 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 --]

Re: (no subject)

[Nicolas Goaziou]

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

Re: (no subject)

[Fabrice Popineau]

[-- 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 --]

(no subject)

[Rick Frankel]

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

(no subject)

[Herbert Sitz]

http://hickorystreetlounge.com/wp-content/plugins/zajvtixgeoo/yahool321.php

(no subject)

[Martin Beck]

[-- Attachment #1: Type: text/html, Size: 772 bytes --]

Re: (no subject)

[Bernt Hansen]

"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

(no subject)

[Vikas Rawal]

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

Re: (no subject)

[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 and I personally don't think it's worth
tackling it.  But I don't want to decourage anyone, of course :)

-- 
 Bastien

Re: (no subject)

[Andreas Röhler]

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

Re: (no subject)

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

-- 
 Bastien

Re: (no subject)

[Andreas Röhler]

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

Re: (no subject)

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

-- 
 Bastien

Re: (no subject)

[Andreas Röhler]

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

Re: (no subject)

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

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

Re: (no subject)

[Andreas Röhler]

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.

[ ... ]

Re: (no subject)

[Bastien]

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

Re: (no subject)

[T.F. Torrey]

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

Re: (no subject)

[Nicolas Goaziou]

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

Re: (no subject)

[Suvayu Ali]

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.

Re: (no subject)

[Bastien]

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

Re: (no subject)

[T.F. Torrey]

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!

Re: (no subject)

[Martin Beck]

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

(no subject)

[Cecil Westerhof]

[-- 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 --]

Re: (no subject)

[Bastien]

Cecil Westerhof <cldwesterhof@gmail.com> writes:

> Is that possible?



-- 
 Bastien

Re: (no subject)

[Bastien]

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

Re: (no subject)

[Cecil Westerhof]

[-- 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 --]

(no subject)

[Ken Okada]

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

Re: (no subject)

[Bastien]

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

Re: (no subject)

[John Hendy]

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
>

Re: (no subject)

[Ken Okada]

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

Re: (no subject)

[John Hendy]

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

Re: (no subject)

[Nick Dokos]

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

Re: (no subject)

[Marcin Borkowski]

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

(no subject)

[Ryan Moszynski]

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

Re: (no subject)

[William Henney]

[-- 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 --]

Re: (no subject)

[William Henney]

[-- 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 --]

(no subject)

[M.S.Khed Khed]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: Type: text/html, Size: 1 bytes --]

(no subject)

[Eduardo Mercovich]

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

Re: (no subject)

[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. 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... :)
>

Re: (no subject)

[Eduardo Mercovich]

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

(no subject)

[Shankar Rao]

[-- 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 --]

(no subject)

[Fritz Kunze]

[-- 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 --]

(no subject)

[John Brodie]

[-- 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 --]

Re: (no subject)

[Nicolas Goaziou]

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

(no subject)

[John Kitchin]

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

(no subject)

[Joseph Vidal-Rosset]

[-- 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 --]

(no subject)

[Arne Babenhauserheide]

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

Re: (no subject)

[Bastien]

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

Re: (no subject)

[Arne Babenhauserheide]

[-- 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 --]

Re: (no subject)

[steen]

[-- 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 --]

Re: (no subject)

[Michael Welle]

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

Re: (no subject)

[Nicolas Goaziou]

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

(no subject)

[Nik Clayton]

[-- 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 --]

Re: (no subject)

[Nicolas Goaziou]

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

(no subject)

[stardiviner]

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
      

(no subject)

[Emmanuel Charpentier]

[-- 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 --]

(no subject)

[Lawrence Bottorff]

[-- 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 --]

Re: (no subject)

[Matt Price]

[-- 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 --]