* [Babel] Reporting 2 problems of code execution @ 2010-11-28 20:04 Sébastien Vauban 2010-11-29 4:34 ` Charles C. Berry 0 siblings, 1 reply; 10+ messages in thread From: Sébastien Vauban @ 2010-11-28 20:04 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ #+TITLE: 2 problems with executing block codes #+DATE: 2010-11-28 #+LANGUAGE: en Hi Eric and Dan, * Abstract Reporting two problems: 1. parsing problem of unescaped text from a shell block 2. end marker repeated upon execution of elisp block Note that I added the RESULT thing in my default headers. * Data Let's say I want to grep trough arbitrary text, such as: #+results:a-couple-of-lines : He said "I'll do it" : but that cannot be echo'ed! ... or to let it scanned by AWK for post-processing (like generating some DOT representation). But, first, as errors are popping up, let's say I can just output it as is. * Shell code #+begin_src sh :var data=a-couple-of-lines :exports both echo "$data" #+end_src #+results: #+BEGIN_RESULT #+END_RESULT The data is impossible (*for me*, as is) to print out from a shell code. Though, it is in Emacs-Lisp... without any change. Note that it's the second *single quote* only that's causing a problem, not the first one... * Emacs-Lisp code Executing this: #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both (prin1-to-string data) #+end_src #+results: #+BEGIN_RESULT #+begin_example "He said \"I'll do it\" but that cannot be echoed!" #+END_RESULT#+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example #+end_example works, but the *end marker is repeated* as long as we re-execute the block. Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Babel] Reporting 2 problems of code execution 2010-11-28 20:04 [Babel] Reporting 2 problems of code execution Sébastien Vauban @ 2010-11-29 4:34 ` Charles C. Berry 2010-11-29 9:03 ` Sébastien Vauban 0 siblings, 1 reply; 10+ messages in thread From: Charles C. Berry @ 2010-11-29 4:34 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- Attachment #1: Type: TEXT/PLAIN, Size: 2716 bytes --] On Sun, 28 Nov 2010, Sébastien Vauban wrote: > #+TITLE: 2 problems with executing block codes > #+DATE: 2010-11-28 > #+LANGUAGE: en > > Hi Eric and Dan, > > * Abstract > > Reporting two problems: Did you mean to include ":results output" in the headers? When I do that in eaco of the src blocks I get what I think you were expecting. See inline below. Chuck > > 1. parsing problem of unescaped text from a shell block > 2. end marker repeated upon execution of elisp block > > Note that I added the RESULT thing in my default headers. > > * Data > > Let's say I want to grep trough arbitrary text, such as: > > #+results:a-couple-of-lines > : He said "I'll do it" > : but that cannot be echo'ed! > > ... or to let it scanned by AWK for post-processing (like generating some DOT > representation). > > But, first, as errors are popping up, let's say I can just output it as is. > > * Shell code > > #+begin_src sh :var data=a-couple-of-lines :exports both > echo "$data" > #+end_src > > #+results: > #+BEGIN_RESULT > #+END_RESULT #+begin_src sh :results output :var data=a-couple-of-lines :exports both echo "$data" #+end_src #+results: : He said "I'll do it" : but that cannot be echo'ed! > > The data is impossible (*for me*, as is) to print out from a shell code. > Though, it is in Emacs-Lisp... without any change. > > Note that it's the second *single quote* only that's causing a problem, not > the first one... > > * Emacs-Lisp code > > Executing this: > > #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both > (prin1-to-string data) > #+end_src > > #+results: > #+BEGIN_RESULT > #+begin_example > "He said \"I'll do it\" > but that cannot be echoed!" > #+END_RESULT#+end_example > #+end_example > #+end_example > #+end_example > #+end_example > #+end_example > #+end_example > #+end_example > #+end_example > > works, but the *end marker is repeated* as long as we re-execute the block. #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both (prin1-to-string data) #+end_src #+results: : "He said \"I'll do it\" : but that cannot be echo'ed!" > > Best regards, > Seb > > -- > Sébastien Vauban > > > _______________________________________________ > 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 > Charles C. Berry Dept of Family/Preventive Medicine cberry@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 [-- Attachment #2: Type: text/plain, Size: 201 bytes --] _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Babel] Reporting 2 problems of code execution 2010-11-29 4:34 ` Charles C. Berry @ 2010-11-29 9:03 ` Sébastien Vauban 2010-11-29 16:47 ` Charles C. Berry ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Sébastien Vauban @ 2010-11-29 9:03 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hi Charles, Thanks a lot for taking a look at this, too... "Charles C. Berry" wrote: > On Sun, 28 Nov 2010, Sébastien Vauban wrote: >> Hi Eric and Dan, >> >> * Abstract >> >> Reporting two problems: > > Did you mean to include ":results output" in the headers? You're right that could be it. I often forget about adding that setting, even though it's more or less mandatory for the sh blocks -- at least, in many sh blocks I write... > When I do that in eaco of the src blocks I get what I think you were > expecting. I still don't. See below. >> 1. parsing problem of unescaped text from a shell block >> 2. end marker repeated upon execution of elisp block >> >> Note that I added the RESULT thing in my default headers. >> >> * Data >> >> Let's say I want to grep trough arbitrary text, such as: >> >> #+results:a-couple-of-lines >> : He said "I'll do it" >> : but that cannot be echo'ed! >> >> ... or to let it scanned by AWK for post-processing (like generating some >> DOT representation). >> >> But, first, as errors are popping up, let's say I can just output it as is. >> >> * Shell code >> >> #+begin_src sh :var data=a-couple-of-lines :exports both >> echo "$data" >> #+end_src >> >> #+results: >> #+BEGIN_RESULT >> #+END_RESULT > > #+begin_src sh :results output :var data=a-couple-of-lines :exports both > echo "$data" > #+end_src > > #+results: > : He said "I'll do it" > : but that cannot be echo'ed! It does not work for me. With the above, I (still) get: #+results: #+BEGIN_RESULT #+END_RESULT for results, and, in the *Org-Babel Error Output*: --8<---------------cut here---------------start------------->8--- sh: line 3: unexpected EOF while looking for matching `'' sh: line 7: syntax error: unexpected end of file --8<---------------cut here---------------end--------------->8--- >> The data is impossible (*for me*, as is) to print out from a shell code. >> Though, it is in Emacs-Lisp... without any change. >> >> Note that it's the second *single quote* only that's causing a problem, not >> the first one... >> >> * Emacs-Lisp code >> >> Executing this: >> >> #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both >> (prin1-to-string data) >> #+end_src >> >> #+results: >> #+BEGIN_RESULT >> #+begin_example >> "He said \"I'll do it\" >> but that cannot be echoed!" >> #+END_RESULT#+end_example >> #+end_example >> #+end_example >> #+end_example >> #+end_example >> #+end_example >> #+end_example >> #+end_example >> #+end_example >> >> works, but the *end marker is repeated* as long as we re-execute the block. > > #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both > (prin1-to-string data) > #+end_src > > #+results: > : "He said \"I'll do it\" > : but that cannot be echo'ed!" With or without the ":results output" (BTW, notice you've forgotten the colon in front of results), the result is the same. But, if you evaluate the block multiple times, in my case, the end marker (end_example) is still repeated... Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: [Babel] Reporting 2 problems of code execution 2010-11-29 9:03 ` Sébastien Vauban @ 2010-11-29 16:47 ` Charles C. Berry 2010-11-29 19:49 ` Dan Davison 2010-11-30 2:03 ` Eric Schulte 2 siblings, 0 replies; 10+ messages in thread From: Charles C. Berry @ 2010-11-29 16:47 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode [-- Attachment #1: Type: TEXT/PLAIN, Size: 2277 bytes --] On Mon, 29 Nov 2010, Sébastien Vauban wrote: > Hi Charles, > > Thanks a lot for taking a look at this, too... > > "Charles C. Berry" wrote: >> On Sun, 28 Nov 2010, Sébastien Vauban wrote: >>> Hi Eric and Dan, >>> >>> * Abstract >>> >>> Reporting two problems: >> >> Did you mean to include ":results output" in the headers? > > You're right that could be it. I often forget about adding that setting, even > though it's more or less mandatory for the sh blocks -- at least, in many sh > blocks I write... > > >> When I do that in eaco of the src blocks I get what I think you were >> expecting. > > I still don't. See below. > > [deleted] >> >> #+begin_src sh :results output :var data=a-couple-of-lines :exports both >> echo "$data" >> #+end_src >> >> #+results: >> : He said "I'll do it" >> : but that cannot be echo'ed! > > It does not work for me. With the above, I (still) get: > > #+results: > #+BEGIN_RESULT > #+END_RESULT > > for results, and, in the *Org-Babel Error Output*: > > --8<---------------cut here---------------start------------->8--- > sh: line 3: unexpected EOF while looking for matching `'' > sh: line 7: syntax error: unexpected end of file > --8<---------------cut here---------------end--------------->8--- > > Hmmm. So it looks like 'sh' is having some trouble here. Can you run the same code directly in the shell? That is can you set/export $data and then 'echo $data' at the command line [deleted] >> >> #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both >> (prin1-to-string data) >> #+end_src >> >> #+results: >> : "He said \"I'll do it\" >> : but that cannot be echo'ed!" > > With or without the ":results output" (BTW, notice you've forgotten the colon > in front of results), the result is the same. But, if you evaluate the block > multiple times, in my case, the end marker (end_example) is still repeated... > Sorry 'bout the missing ":" - it outputs the same results either way on my box. Chuck [rest deleted] Charles C. Berry Dept of Family/Preventive Medicine cberry@tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 [-- Attachment #2: Type: text/plain, Size: 201 bytes --] _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Babel] Reporting 2 problems of code execution 2010-11-29 9:03 ` Sébastien Vauban 2010-11-29 16:47 ` Charles C. Berry @ 2010-11-29 19:49 ` Dan Davison 2010-11-30 2:03 ` Eric Schulte 2 siblings, 0 replies; 10+ messages in thread From: Dan Davison @ 2010-11-29 19:49 UTC (permalink / raw) To: Sébastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: > Hi Charles, > > Thanks a lot for taking a look at this, too... > > "Charles C. Berry" wrote: >> On Sun, 28 Nov 2010, Sébastien Vauban wrote: >>> Hi Eric and Dan, >>> >>> * Abstract >>> >>> Reporting two problems: >> >> Did you mean to include ":results output" in the headers? > > You're right that could be it. I often forget about adding that setting, even > though it's more or less mandatory for the sh blocks -- at least, in many sh > blocks I write... > > >> When I do that in eaco of the src blocks I get what I think you were >> expecting. > > I still don't. See below. > > >>> 1. parsing problem of unescaped text from a shell block >>> 2. end marker repeated upon execution of elisp block >>> >>> Note that I added the RESULT thing in my default headers. >>> >>> * Data >>> >>> Let's say I want to grep trough arbitrary text, such as: >>> >>> #+results:a-couple-of-lines >>> : He said "I'll do it" >>> : but that cannot be echo'ed! >>> >>> ... or to let it scanned by AWK for post-processing (like generating some >>> DOT representation). >>> >>> But, first, as errors are popping up, let's say I can just output it as is. >>> >>> * Shell code >>> >>> #+begin_src sh :var data=a-couple-of-lines :exports both >>> echo "$data" >>> #+end_src >>> >>> #+results: >>> #+BEGIN_RESULT >>> #+END_RESULT >> >> #+begin_src sh :results output :var data=a-couple-of-lines :exports both >> echo "$data" >> #+end_src >> >> #+results: >> : He said "I'll do it" >> : but that cannot be echo'ed! > > It does not work for me. With the above, I (still) get: > > #+results: > #+BEGIN_RESULT > #+END_RESULT > > > for results, and, in the *Org-Babel Error Output*: > > sh: line 3: unexpected EOF while looking for matching `'' > sh: line 7: syntax error: unexpected end of file Hi Seb, Just to say that these blocks with embedded quotes are outputting OK for me on linux, but I do see the second bug you mention (repeatedly adding new lines on each execution). I'm guessing that the first one is a difference in shell quoting behaviour between out operating systems. Dan > > >>> The data is impossible (*for me*, as is) to print out from a shell code. >>> Though, it is in Emacs-Lisp... without any change. >>> >>> Note that it's the second *single quote* only that's causing a problem, not >>> the first one... >>> >>> * Emacs-Lisp code >>> >>> Executing this: >>> >>> #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both >>> (prin1-to-string data) >>> #+end_src >>> >>> #+results: >>> #+BEGIN_RESULT >>> #+begin_example >>> "He said \"I'll do it\" >>> but that cannot be echoed!" >>> #+END_RESULT#+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> #+end_example >>> >>> works, but the *end marker is repeated* as long as we re-execute the block. >> >> #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both >> (prin1-to-string data) >> #+end_src >> >> #+results: >> : "He said \"I'll do it\" >> : but that cannot be echo'ed!" > > With or without the ":results output" (BTW, notice you've forgotten the colon > in front of results), the result is the same. But, if you evaluate the block > multiple times, in my case, the end marker (end_example) is still repeated... > > Best regards, > Seb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: [Babel] Reporting 2 problems of code execution 2010-11-29 9:03 ` Sébastien Vauban 2010-11-29 16:47 ` Charles C. Berry 2010-11-29 19:49 ` Dan Davison @ 2010-11-30 2:03 ` Eric Schulte 2010-12-02 9:35 ` Sébastien Vauban 2 siblings, 1 reply; 10+ messages in thread From: Eric Schulte @ 2010-11-30 2:03 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: > > You're right that could be it. I often forget about adding that setting, even > though it's more or less mandatory for the sh blocks -- at least, in many sh > blocks I write... > You can specify this as the default header argument for all shell blocks with the following. #+begin_src emacs-lisp (add-to-list 'org-babel-default-header-args '((:results . "output"))) #+end_src ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Babel] Reporting 2 problems of code execution 2010-11-30 2:03 ` Eric Schulte @ 2010-12-02 9:35 ` Sébastien Vauban 2010-12-02 19:40 ` Eric Schulte 0 siblings, 1 reply; 10+ messages in thread From: Sébastien Vauban @ 2010-12-02 9:35 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hi Eric, "Eric Schulte" wrote: > Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes: >> You're right that could be it. I often forget about adding that setting, even >> though it's more or less mandatory for the sh blocks -- at least, in many sh >> blocks I write... > > You can specify this as the default header argument for all shell blocks > with the following. > > #+begin_src emacs-lisp > (add-to-list 'org-babel-default-header-args '((:results . "output"))) > #+end_src Thanks for the tip but... that may be a bit drastic, I mean forcing every snippet of *every language* to behave like that: I'm convinced it's the most natural choice for sh blocks, but maybe the less natural (i.e., must be overridden) for all other programming languages. In fact, I have the strong impression that we should need this on a language basis, something like: #+begin_src emacs-lisp (add-to-list 'org-babel-default-header-args '( (sh . (:results . "output")) (emacs-lisp . (:results . "value")))) #+end_src I feel the same about the Babel "file" property: #+BABEL: :engine mysql :cmdline -S server -U sa -P secret -d storeall -n -w 700 -s " " Not being able to specify the language these defaults apply to may rapidly lead to clashes... Or we have to set the default for the language for which we have the biggest number of chunks, and explicitly set the values for all the other snippets that are written in other languages. Maybe allowing such a specification line? #+BABEL sql: :engine mysql :cmdline -S server -U sa -P secret -d storeall -n -w 700 -s " " Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: [Babel] Reporting 2 problems of code execution 2010-12-02 9:35 ` Sébastien Vauban @ 2010-12-02 19:40 ` Eric Schulte 2010-12-02 19:58 ` Sébastien Vauban 0 siblings, 1 reply; 10+ messages in thread From: Eric Schulte @ 2010-12-02 19:40 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: > Hi Eric, > > "Eric Schulte" wrote: >> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: >>> You're right that could be it. I often forget about adding that setting, even >>> though it's more or less mandatory for the sh blocks -- at least, in many sh >>> blocks I write... >> >> You can specify this as the default header argument for all shell blocks >> with the following. >> >> #+begin_src emacs-lisp >> (add-to-list 'org-babel-default-header-args '((:results . "output"))) >> #+end_src > > Thanks for the tip but... that may be a bit drastic, I mean forcing every > snippet of *every language* to behave like that: He Seb, Sorry I miss-typed, I meant the following which is exactly your suggestion below. #+begin_src emacs-lisp (add-to-list 'org-babel-default-header-args:sh '((:results . "output"))) #+end_src > I'm convinced it's the most natural choice for sh blocks, but maybe > the less natural (i.e., must be overridden) for all other programming > languages. > > In fact, I have the strong impression that we should need this on a language > basis, something like: > > #+begin_src emacs-lisp > (add-to-list 'org-babel-default-header-args '( > (sh . (:results . "output")) > (emacs-lisp . (:results . "value")))) > #+end_src > > I feel the same about the Babel "file" property: > > #+BABEL: :engine mysql :cmdline -S server -U sa -P secret -d storeall > -n -w 700 -s " " > > Not being able to specify the language these defaults apply to may rapidly > lead to clashes... Or we have to set the default for the language for which we > have the biggest number of chunks, and explicitly set the values for all the > other snippets that are written in other languages. > > Maybe allowing such a specification line? > > #+BABEL sql: :engine mysql :cmdline -S server -U sa -P secret -d > storeall -n -w 700 -s " " > That seems like a good suggestion, the only question seems to be what is the most natural syntax. I think I would lean more towards something like #+SQL_SOURCE: Best -- Eric > > Best regards, > Seb ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Babel] Reporting 2 problems of code execution 2010-12-02 19:40 ` Eric Schulte @ 2010-12-02 19:58 ` Sébastien Vauban 2010-12-05 15:39 ` Eric Schulte 0 siblings, 1 reply; 10+ messages in thread From: Sébastien Vauban @ 2010-12-02 19:58 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hi Eric, "Eric Schulte" wrote: >> Thanks for the tip but... that may be a bit drastic, I mean forcing every >> snippet of *every language* to behave like that: > > He Seb, > > Sorry I miss-typed, I meant the following which is exactly your > suggestion below. > > #+begin_src emacs-lisp > (add-to-list 'org-babel-default-header-args:sh '((:results . "output"))) > #+end_src OK. Did not know that form did already exist... >> I feel the same about the Babel "file" property. >> Maybe allowing such a specification line? >> >> #+BABEL sql: :engine mysql :cmdline -S server -U sa -P secret -d >> storeall -n -w 700 -s " " > > That seems like a good suggestion, the only question seems to be what is > the most natural syntax. > > I think I would lean more towards something like > > #+SQL_SOURCE: I don't really care about the form. I'll let you make the best choice, the one that best fits the whole Babel thing. Though, your proposition seems very adequate to me... Best regards, Seb -- Sébastien Vauban _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode-mXXj517/zsQ@public.gmane.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: [Babel] Reporting 2 problems of code execution 2010-12-02 19:58 ` Sébastien Vauban @ 2010-12-05 15:39 ` Eric Schulte 0 siblings, 0 replies; 10+ messages in thread From: Eric Schulte @ 2010-12-05 15:39 UTC (permalink / raw) To: Sébastien Vauban; +Cc: emacs-orgmode Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes: [...] >>> I feel the same about the Babel "file" property. >>> Maybe allowing such a specification line? >>> >>> #+BABEL sql: :engine mysql :cmdline -S server -U sa -P secret -d >>> storeall -n -w 700 -s " " >> >> That seems like a good suggestion, the only question seems to be what is >> the most natural syntax. >> >> I think I would lean more towards something like >> >> #+SQL_SOURCE: > > I don't really care about the form. I'll let you make the best choice, the one > that best fits the whole Babel thing. Though, your proposition seems very > adequate to me... > I've added this to our task list. Cheers -- Eric ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-12-05 15:39 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-28 20:04 [Babel] Reporting 2 problems of code execution Sébastien Vauban 2010-11-29 4:34 ` Charles C. Berry 2010-11-29 9:03 ` Sébastien Vauban 2010-11-29 16:47 ` Charles C. Berry 2010-11-29 19:49 ` Dan Davison 2010-11-30 2:03 ` Eric Schulte 2010-12-02 9:35 ` Sébastien Vauban 2010-12-02 19:40 ` Eric Schulte 2010-12-02 19:58 ` Sébastien Vauban 2010-12-05 15:39 ` Eric Schulte
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.