Re: [O] Evaluation of R code block depends on case of keywords???
>> Greetings. I happened to notice that in evaluating R source-code blocks in >> an Org-Mode file I got some cruft from my .Rprofile in the output on some >> occasions but not on others. >> >> To my surprise, it appears that the CASE of the keywords on the BEGIN_SRC >> line affects the output. Please see the appended for a simple example. >> >> I haven't been able to find this behavior documented any place, but of >> course it's possible I just missed it. >> >> Can somebody confirm/deny that Org-Mode is SUPPOSED to behave this way? >> >> Thanks, >> >> -- Mike >> >> >> * Mike's test of UPPER CASE keywords >> >> #+BEGIN_SRC R :RESULTS output :EXPORTS both >> >> x <- rnorm(5) >> >> #+END_SRC >> >> #+results: >> | -1.78820283900565 | >> | -0.469227269149123 | >> | -0.92353467915834 | >> | -0.0831621941877021 | >> | -1.5583681234565 | >> >> >> >> * Mike's test of lower case keywords >> >> #+BEGIN_SRC R :results output :exports both >> >> x <- rnorm(5) >> >> #+END_SRC >> >> #+results: >> : >> : >> : All ready to go... >> : >> : Fri Aug 19 15:46:15 2011 >> : Hasta la vista! > > Hi Mike, > I believe what is happening is that :RESULTS and :EXPORTS are not > recognized, so :results (the correct header argument) defaults to value. > > hth, > Tom > > -- > Thomas S. Dye > http://www.tsdye.com Thanks, Tom. I think your explanation is correct. The manual page: http://orgmode.org/manual/Specific-header-arguments.html#Specific-header-arguments does indeed show all of the arguments in lower case. I had seen BEGIN_SRC and begin_src used interchangeably and so assumed that same latitude applied to the keywords. And I have a slight preference for putting keywords in upper case and values in lower case, just to distinguish one class of things from the other. My bad. -- Mike
Re: [O] Evaluation of R code block depends on case of keywords???
Michael Hannon writes: > Greetings. I happened to notice that in evaluating R source-code blocks in an > Org-Mode file I got some cruft from my .Rprofile in the output on some > occasions but not on others. > > To my surprise, it appears that the CASE of the keywords on the BEGIN_SRC line > affects the output. Please see the appended for a simple example. > > I haven't been able to find this behavior documented any place, but of course > it's possible I just missed it. > > Can somebody confirm/deny that Org-Mode is SUPPOSED to behave this way? > > Thanks, > > -- Mike > > > * Mike's test of UPPER CASE keywords > > #+BEGIN_SRC R :RESULTS output :EXPORTS both > > x <- rnorm(5) > > #+END_SRC > > #+results: > | -1.78820283900565 | > | -0.469227269149123 | > | -0.92353467915834 | > | -0.0831621941877021 | > | -1.5583681234565 | > > > > * Mike's test of lower case keywords > > #+BEGIN_SRC R :results output :exports both > > x <- rnorm(5) > > #+END_SRC > > #+results: > : > : > : All ready to go... > : > : Fri Aug 19 15:46:15 2011 > : Hasta la vista! Hi Mike, I believe what is happening is that :RESULTS and :EXPORTS are not recognized, so :results (the correct header argument) defaults to value. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] BUG: example/src blocks and latex export
Bastien wrote:
> Hi Nick,
>
> Nick Dokos writes:
>
> > * foo
> >
> > Verbiage to begin the paragraph
> > #+begin_src shell
> > get-config.py var section [section ...]
> > #+end_src
> > and verbiage to end the same paragraph.
> >
> > * bar
> >
> > Verbiage to begin the paragraph
> > #+begin_example
> > get-config.py var section [section ...]
> > #+end_example
> > and verbiage to end the same paragraph.
>
> I tested your patch with the example above and I get this:
>
> ,
> | Verbiage to begin the paragraph
> |
> | \lstset{language=shell}
> | \begin{lstlisting}
> | get-config.py var section [section ...]
> | \end{lstlisting}
> |
> | and verbiage to end the same paragraph.
> | \section*{bar}
> | \label{sec-2}
> |
> |
> | Verbiage to begin the paragraph
> |
> | \begin{verbatim}
> | get-config.py var section [section ...]
> | \end{verbatim}
> | and verbiage to end the same paragraph.
> `
>
> It looks better than the current export (less white lines) but still
> has a problem with the first "and verbiage..." being indented.
>
> Is this intentional? Or do you want the same behavior for #+begin_src
> and #+begin_example?
>
> In overall, I think number of white lines should be the same in the Org
> source file and in the LaTeX exported file, so a patch here is welcome.
> But maybe I misunderstood something in Eric's reply.
>
So here's another patch to get rid of some more newlines, these ones after
a listings or minted environment. I tried both with the previously posted file
and setting org-export-latex-listings to t or 'minted. AFAICT, it works as it
should and should not break anything else, but... This is to be applied on top
of the previous one (and it's still very much a trial balloon).
BTW, the defcustom of org-export-latex-listings seems to be outdated:
custom thinks it's a boolean, but it can now take at least one more value
(minted - see the docstring).
Thanks,
Nick
>From 5337cbb0669c6b05170190ec1e5751bdcf132d87 Mon Sep 17 00:00:00 2001
From: Nick Dokos
Date: Fri, 19 Aug 2011 18:36:50 -0400
Subject: [PATCH 2/2] Get rid of gratuitous newline after listing/minted
environment.
Signed-off-by: Nick Dokos
---
lisp/org-exp.el |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index a2a2fb3..f795fbd 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -2689,11 +2689,11 @@ INDENT was the original indentation of the block."
(format "\\begin{%s}\n%s\\end{%s}\n"
custom-environment rtn custom-environment))
(listings-p
- (format "\\begin{%s}\n%s\\end{%s}\n"
+ (format "\\begin{%s}\n%s\\end{%s}"
"lstlisting" rtn "lstlisting"))
(minted-p
(format
- "\\begin{minted}[%s]{%s}\n%s\\end{minted}\n"
+ "\\begin{minted}[%s]{%s}\n%s\\end{minted}"
(mapconcat #'make-option-string
org-export-latex-minted-options ",")
backend-lang rtn)))
--
1.7.5.1.169.g505a1
[O] Evaluation of R code block depends on case of keywords???
Greetings. I happened to notice that in evaluating R source-code blocks in an Org-Mode file I got some cruft from my .Rprofile in the output on some occasions but not on others. To my surprise, it appears that the CASE of the keywords on the BEGIN_SRC line affects the output. Please see the appended for a simple example. I haven't been able to find this behavior documented any place, but of course it's possible I just missed it. Can somebody confirm/deny that Org-Mode is SUPPOSED to behave this way? Thanks, -- Mike * Mike's test of UPPER CASE keywords #+BEGIN_SRC R :RESULTS output :EXPORTS both x <- rnorm(5) #+END_SRC #+results: | -1.78820283900565 | | -0.469227269149123 | | -0.92353467915834 | | -0.0831621941877021 | | -1.5583681234565 | * Mike's test of lower case keywords #+BEGIN_SRC R :results output :exports both x <- rnorm(5) #+END_SRC #+results: : : : All ready to go... : : Fri Aug 19 15:46:15 2011 : Hasta la vista!
Re: [O] [babel] [bug] inline src_R breaks downstream src block
Hi Charles,
yes, there are some problems with parsing inline source blocks.
Stephen also reported that these colon lines
: were $\beta_2$ = src_R{round(out3$coef[3], 4)}
: and $\beta_3$ = src_R{round(out3$coef[4], 4)}
where not exporting correctly... Eric, can you have a look at
these problems?
Thanks!
"Charles C. Berry" writes:
> ,
> | | * inline code block example
> | | | AAA
> | blah blah src_R[:results output]{cat(rnorm(2))}
> | CC
> | #+begin_src R :eval never :exports none
> | 1+2
> | a <- b + c
> | xyz
> | #+end_src
> |
> `
>
>
> When I run C-c C-e A y, I get a buffer that misses the 'DDD...' line.
>
> When I run C-c C-e L y, I get a buffer that ends like this:
>
>
> | AAA
> | blah blah \texttt{-1.172165 -0.5324113}
> | CC
> | \begin{src}R DDD
> | | \end{document}
> `
>
> More complicated examples exhibit other problems, I speculate that
> parsing the inline src_R and setting up to find the next
> #+begin_src...#+end_src instance is what has gone wrong.
>
> FWIW, changing the :exports header to 'code' seems to give correct
> results
>
> Also, placing a dummy example like this:
>
> ,
> | #+begin_example
> | #+end_example
> `
>
> after the src_R line produces correct results.
>
> Chuck
>
>
> Charles C. BerryDept of Family/Preventive Medicine
> cbe...@tajo.ucsd.edu UC San Diego
> http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
>
>
>
>
--
Bastien
Re: [O] Markup in BEGIN_EXAMPLE and alike block
Hi Vladimir, Vladimir Lomov writes: > *** Determining adapter chipset and used driver > > #+BEGIN_EXAMPLE > zbox$ lspci -v > ... > 04:00.0 Network controller: *RaLink RT2860* > Subsystem: Device 1a3b:1059 > Flags: bus master, fast devsel, latency 0, IRQ 19 > Memory at febf (32-bit, non-prefetchable) [size=64K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Kernel driver in use: *rt2800pci* > Kernel modules: rt2800pci > #+END_EXAMPLE > > But in exported html file the '*'s are remain. Is it possible to use > markup in BEGIN_EXAMPLE? Or I have to use another type of block? No, this is currently not possible, sorry. -- Bastien
[O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
Hi again,
I want to use haskell code blocks in order to evaluate them. The
problem is that, depending on what haskell interpreters are installed
on the computer, Babel will call a different interpreter to evaluate
the code with. Also, the haskell interpreter interface appears to be
highly stateful and unreliable.
Here's an example -- ghc6 is installed, but not hugs:
#+begin_src haskell :results output
import System.IO
openFile "doesNotExist.ppt" ReadMode
#+end_src
#+results:
: Loading package ghc-prim ... linking ... done.
: Loading package integer-gmp ... linking ... done.
: Loading package base ... linking ... done.
The interesting thing is that this output only occurs on the first run
of the code -- if I hit C-cC-c again, the #+results: section will be
empty.
Now the same source, with hugs installed in addition to ghc6 -- the
source block is the same, but the output is very different:
#+results:
: Type :? for help
: ERROR - Syntax error in expression (unexpected keyword "import")
Again, if I press C-cC-c again, the first line of output ("Type :? for
help") is no longer present.
This is what I suggest:
- Do away with "haskell" as the keyword for haskell code blocks, just
like graphviz blocks use "dot" instead of simply "graphviz".
- Introduce new keywords -- I propose at least "runghc", "ghci", and
"hugs". This is important since there are significant source-level
differences (see above) between hugs and ghc and even between the
compiler and interpreter from the same project (ghc and ghci).
Without these, the progammer will never be able to predict how the
code is evaluated and which compiler or interpreter they must code
for.
- Make sure the incorporation of the output or the value is done
correctly (also see my previous bug report for this).
Enough for today,
András
Emacs : GNU Emacs 23.3.1 (i486-pc-linux-gnu, GTK+ Version 2.24.3)
of 2011-04-10 on raven, modified by Debian
Package: Org-mode version 7.7 (release_7.7.160.g3e33)
current state:
==
(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-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t)
(haskell . t) (latex . t) (octave . t)
(R . t) (ruby . t) (scheme . t) (sh
. t))
org-metaup-hook '(org-babel-load-in-session-maybe)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex") ("haskell" .
"hs") ("asymptote" . "asy")
("emacs-lisp" . "el"))
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-blank-before-new-entry nil
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-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-occur-hook '(org-first-headline-recenter)
org-from-is-user-regexp nil
org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
org-confirm-babel-evaluate nil
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-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-blocks '((src org-babel-exp-src-block nil) (comment
org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil) (dot
org-export-blocks-format-dot nil))
)
Re: [O] org-agenda.el acquired a dependency on org-clock.el
Nick Dokos writes: > Commit 8c3ecbe3 introduced a new dependency > > org-agenda.el --> org-clock.el > > by moving the org-hh:mm-string-to-minutes etc. functions into org-clock.el. > Presumably, org-agenda.el now needs a I reverted this change, so you should not have this error anymore. HTH, -- Bastien
Re: [O] result of code evaluation
Greetings! I have another question regarding the output of the bash script. I have a bunch of echo statements. org-mode outputs now everything in a table. Is it possible to suppress this and have just plain lines? That was the behavior with a simple script. Thanks, Henri-Paul -- Henri-Paul Indiogine Curriculum & Instruction Texas A&M University TutorFind Learning Centre Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine
Re: [O] BUG: example/src blocks and latex export
Bastien wrote:
> Hi Nick,
>
> Nick Dokos writes:
>
> > * foo
> >
> > Verbiage to begin the paragraph
> > #+begin_src shell
> > get-config.py var section [section ...]
> > #+end_src
> > and verbiage to end the same paragraph.
> >
> > * bar
> >
> > Verbiage to begin the paragraph
> > #+begin_example
> > get-config.py var section [section ...]
> > #+end_example
> > and verbiage to end the same paragraph.
>
> I tested your patch with the example above and I get this:
>
> ,
> | Verbiage to begin the paragraph
> |
> | \lstset{language=shell}
> | \begin{lstlisting}
> | get-config.py var section [section ...]
> | \end{lstlisting}
> |
> | and verbiage to end the same paragraph.
> | \section*{bar}
> | \label{sec-2}
> |
> |
> | Verbiage to begin the paragraph
> |
> | \begin{verbatim}
> | get-config.py var section [section ...]
> | \end{verbatim}
> | and verbiage to end the same paragraph.
> `
>
> It looks better than the current export (less white lines) but still
> has a problem with the first "and verbiage..." being indented.
>
> Is this intentional? Or do you want the same behavior for #+begin_src
> and #+begin_example?
>
Not intentional. But I have org-export-latex-listings set to nil, so in
my case, the src block gets turned into a verbatim environment, not into
a listings environment, and there is no empty line there. Let me play
around a bit with org-export-latex-listings and see.
I guess the change in org-latex-verbatim-wrap takes care of my case,
but there is another (gratuitous?) newline inserted after listings.
> In overall, I think number of white lines should be the same in the
> Org source file and in the LaTeX exported file, so a patch here is
> welcome. But maybe I misunderstood something in Eric's reply.
I tend to agree, but I can also understand Eric's wish for visual
separation. However, as I pointed out in my earlier reply to him, I
think that's a separate problem, not addressed (or affected) by this
patch.
Thanks for testing,
Nick
Re: [O] Keeping an eye on byte-compilation warnings
Hi Achim, Achim Gratz writes: > In org-fixup-indentation: > org.el:7368:32:Warning: reference to free variable `org-property-end-re' > > In org-set-property: > org.el:14316:34:Warning: reference to free variable `fn' Both fixed, thanks! -- Bastien
Re: [O] org-icons package
Hi Dan, Dan Davison writes: > org-icons needs to be moved into contrib/, hooked in via a > lightweight patch against org.el, instead of being implemented as a > monolithic change to org.el. I made a start on that in this branch: > > https://github.com/dandavison/org-devel/tree/org-icons Great -- let us know when we can move this to contrib/! Best, -- Bastien
Re: [O] [odt] htmlfontify + Support for src blockfontification
Jambunathan K writes: >> we are discussing in abstract terms, and that might distract us from >> DTRT together: can you show the patched version of htmlfontify.el? > > Here you go. Thanks. I will look into this next week. Not before tuesday, as I'm off for a long week-end. Best, -- Bastien
Re: [O] org-icons package
Oké Dan, Understood. That sounds right; to move all the code into the org-icons.el file. That way the patch is no longer needed, and org-icons can live in the contrib dir (together with a directory for the images). I think its best if I make a fork of your repo. That gives me some space for working on the code. Once I have made some progress (I won't be very fast...), I will send you a Pull request. The changes that you have made until now, are found here: https://github.com/dandavison/org-devel/tree/org-icons/contrib/org-icons Right? Your right, org-icons is a nice way to change the looks of org buffers. I'll go through the code first, to get an understanding of what can be done. Ciao, Renzo On 18 August 2011 22:48, Dan Davison wrote: > Hi Renzo, > org-icons needs to be moved into contrib/, hooked in via a lightweight patch > against org.el, instead of being implemented as a monolithic change to > org.el. I made a start on that in this branch: > https://github.com/dandavison/org-devel/tree/org-icons > but I'm not sure that I got very far. Note that that is a branch in a clone > of the org repo, as opposed to the org-icons repos which are standalone > repos and do not contain org. > I thought org-icons was interesting because it offers the possibility of > allowing users to make arbitrary superficial changes to org aesthetics. For > example, the #+begin_src...#+end_src boilerplate is rather heavy for some > peoples' tastes. At one point I had it replacing that with a little (ruby, > snake) for (ruby, python) code... But I think it also allows the possibility > of overlaying with text. I'd be happy to give you push access to that repo, > but, you may as well just fork it as I have no plans to work on it. > I don't know how to contact Nicolas. I believe that he is on record as > saying he did not plan to develop org-icons further. > Good luck, > Dan
Re: [O] BUG: example/src blocks and latex export
Hi Nick,
Nick Dokos writes:
> * foo
>
> Verbiage to begin the paragraph
> #+begin_src shell
> get-config.py var section [section ...]
> #+end_src
> and verbiage to end the same paragraph.
>
> * bar
>
> Verbiage to begin the paragraph
> #+begin_example
> get-config.py var section [section ...]
> #+end_example
> and verbiage to end the same paragraph.
I tested your patch with the example above and I get this:
,
| Verbiage to begin the paragraph
|
| \lstset{language=shell}
| \begin{lstlisting}
| get-config.py var section [section ...]
| \end{lstlisting}
|
| and verbiage to end the same paragraph.
| \section*{bar}
| \label{sec-2}
|
|
| Verbiage to begin the paragraph
|
| \begin{verbatim}
| get-config.py var section [section ...]
| \end{verbatim}
| and verbiage to end the same paragraph.
`
It looks better than the current export (less white lines) but still
has a problem with the first "and verbiage..." being indented.
Is this intentional? Or do you want the same behavior for #+begin_src
and #+begin_example?
In overall, I think number of white lines should be the same in the Org
source file and in the LaTeX exported file, so a patch here is welcome.
But maybe I misunderstood something in Eric's reply.
Thanks,
--
Bastien
Re: [O] Missing Mobile TODO questions
Hi Iain, Iain Houston writes: > I'd be very grateful for some help setting up Mobile Org. I'm not using org-mobile myself, I hope someone will be able to help you on this. Best, -- Bastien
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi Andras, Andras Major writes: > - If, in the source, the "." precedes a double space " " or a newline, > use ". ". > > - In any other case, use ".\ ". I wonder how such a function would look like. Does anyone wants to try to write it? Even pseudo-code would be fine at this stage. > The reason this would work is the Emacs convention of writing ASCII > such that there is at least one more space (at least two) between > sentences. I believe that the Emacs fill-* functions also make use of > this convention. C-h v sentence-end TAB gives several variable that let the user change the number of spaces after a sentence. So I guess this is not really "Emacs convention of writing ASCII", but a more general American convention. Would the values of sentence-end* be taken into account by the feature you describe above? -- Bastien
Re: [O] Wishlist: allow range of table elements to be filled by sbe
Hi András I am not sure if you really need the data between the sh output and the sbe input as a table. If not, this can be used: #+source: shcode(x = 0) #+begin_src sh echo "$x" #+end_src | 1 | 2 | 3 | #+TBLFM: @1$1..@1$3 = '(sbe "shcode" (x "$#")) Michael 2011/8/19 András Major : > Hi, > > I'd like to use a babel code block to fill a table with values. The > sbe elisp function looks like the right thing for this task, but it > appears that the result of the code block always goes into a single > cell of a table. I can specify ranges of values, but then the entire > output is placed into each of the specified cells. > > Here is how I imagine things should work: > > #+srcname: shcode > #+begin_src sh :exports output table silent > echo "1 2 3" > #+end_src > > | 1 | 2 | 3 | > #+TBLFM: $1..$3='(sbe shcode) > > Note that this is *NOT* real output from the code block in the current > version of org-mode, it's what I want it to be. There are two things > that cause this to break at the moment: > > - The range $1..$3 doesn't work, I have to prepend a row specifier as > in @<$1..@>$3 or suchlike, which is rather counterintuitive but > seems to work. > > - The output "1 2 3" are not separated into the various cells but all > placed into each cell. > > Or am I doing something wrong here?
Re: [O] Problem with shift-up
On Fri, Aug 19, 2011 at 11:10 AM, Peter Frings wrote: > Hi gang, > > sorry to bother you all again, but my transition to the new emacs is now > taking days and I’m getting really frustrated. > > I’m trying to find out why shift-arrow on a date/time stamp no longer works > with my brand new and shiny set-up. > > Emacs 23, org-mode 7.7. > > When running a minimal set-up (as described on the worg-FAQ), the > shift-arrows keys work as expected: they change the date and time values in > org’s timestamps. > > When loading the starter-kit from Kieran Healy [1], things are not so smooth. > I’ve been disabling all possible packages, trying to isolate the culprit, but > to no avail. I searched the web and this mailing list, and found someone else > with the same problem [2], but alas, no conclusive answer. > > In both cases, 'shift-select-mode’ is t. > > With the minimal set-up, S-up is bound to this (using C-h k): > runs the command org-shiftup, which is an interactive compiled > Lisp function in `org.el’. > > With the starter-kit, it’s: > (translated from ) runs the command previous-line, which is > an interactive compiled Lisp function in `simple.el’. (windmove-default-keybindings) is called in starter-kit-keybindings.org, and this does take of the shift + direction keys. The 'Helpful packages' section of starter-kit-org.org also looks suspicious. Best, Ista > > What the heck is ‘translating’ this key binding? How can I find the guilty > one so I can do very cruel things to it? > > Pointers very much appreciated! > Peter. > > [1] http://kjhealy.github.com/emacs-starter-kit/ > [2] http://comments.gmane.org/gmane.emacs.orgmode/34329 > > > > -- Ista Zahn Graduate student University of Rochester Department of Clinical and Social Psychology http://yourpsyche.org
Re: [O] missing todo's in agenda after emacs/org upgrade
Carsten Dominik wrote: > 2. Moving through time does not work in a block view when the cursor is in > the TODO list. > > Maybe we can find ways to address these two issues? For example, including a > built-in command > for this double view, or seeding org-agenda-custom-commands with this > particular block? > > The 2. issue comes about because in a bock agenda, org only update the > local block to save time, and in a TODO list it does not make sense to > move through time. This could be fixed by checking for an agenda > block and updating that one instead. I will take a look at this and > make a proposal. This would be very nice indeed. Right now, one has to jump back to the beginning of the buffer, which is somewhat irritating. Cheers, Viktor
Re: [O] result of code evaluation
Hi Henri-Paul, Henri-Paul Indiogine wrote: > 2011/8/19 Sebastien Vauban : >> The only other solutions are: >> >> - use the option =:results raw=, but you can't do any replace anymore (of old >> results by new results) >> >> - =(setq org-babel-min-lines-for-block-output 1)=, to force Org to put the >> output enclosed in a #+begin/end_example block. > > I like the second option. I have place the line in my .emacs and it > works beautifully. I did it with (setq ... 2), so that only one-line results get prefixed by a colon. All the others are enclosed in a block. > Thanks! You're welcome. Glad to help. Best regards, Seb -- Sebastien Vauban
Re: [O] [odt] htmlfontify + Support for src blockfontification
Jambunathan K writes: >> +(defcustom org-export-odt-use-htmlfontify t The name of the variable is confusing -- we should mention this is about src block. >> + "Specify whether or not source blocks need to be fontified. >> +Turn this option on if you want to colorize the source code >> +blocks in the exported file. For colorization to work, you need >> +to make available an enhanced version of `htmlfontify' library." >> >> For now, the correct default value is `nil', otherwise users will >> encounter problems. > > No. There is an in-built deprecation as below: > > #+begin_src emacs-lisp >(if (and org-export-odt-use-htmlfontify > (or (featurep 'htmlfontify) (require 'htmlfontify)) > (fboundp 'htmlfontify-string)) > ...) > #+end_src Is it useful to set `org-export-odt-use-htmlfontify' to `t' in the absence of `htmlfontify-string'? If not, let's bind it to `nil' and wait for `htmlfontify-string' to be available for turning it on by default. Thanks, -- Bastien
Re: [O] [odt] htmlfontify + Support for src blockfontification
Jambunathan K writes: >> It just occurred to me: why using htmlfontify.el instead of >> htmlize.el? I guess there are good reasons... > > htmlfontify is part of Emacs and so a first class citizen. A user > doesn't have to install any additional package to get fontification > support. It will work out of the box. Okay. This suggests that we also should try to rely on htmlfontify.el instead of htmlize.el for other functions. What do you think? -- Bastien
Re: [O] Org errors while building agenda: (void-function org-hh:mm-string-to-minutes)
Hi Tassilo, Tassilo Horn writes: > it seems commit > > commit 8c3ecbe39a0c99e3724246d1eb460495a53721b6 > Author: Bastien Guerry > Date: Wed Aug 17 16:08:02 2011 +0200 > > Move three functions and add appropriate require/declarations. > > * org-clock.el (org-duration-string-to-minutes) > (org-minutes-to-hh:mm-string, org-hh:mm-string-to-minutes): > Move from org.el. > > has broken my agenda. I've reverted this commit. I first thought `org-duration-string-to-minutes' and associated variables and functions would better fit into org-clock.el, but I now see they are of more general purpose. Thanks for reporting this! -- Bastien
Re: [O] result of code evaluation
Hi Sebastien! 2011/8/19 Sebastien Vauban : > The only other solutions are: > > - use the option =:results raw=, but you can't do any replace anymore (of old > results by new results) > > - =(setq org-babel-min-lines-for-block-output 1)=, to force Org to put the > output enclosed in a #+begin/end_example block. I like the second option. I have place the line in my .emacs and it works beautifully. Thanks! Henri-Paul -- Henri-Paul Indiogine Curriculum & Instruction Texas A&M University TutorFind Learning Centre Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine
Re: [O] Problem with shift-up
Hi Peter, Peter Frings writes: > When loading the starter-kit from Kieran Healy [1], AFAIU, this starter-kit relies on the commit c88c76b of Org: https://github.com/kjhealy/emacs-starter-kit/tree/master/src Please make sure to report what your exact version of Org is (M-x org-version), that might help. > In both cases, 'shift-select-mode’ is t. What is the value of `org-support-shift-select'? Maybe the starter-kit is setting this variable. > With the minimal set-up, S-up is bound to this (using C-h k): > runs the command org-shiftup, which is an interactive compiled > Lisp function in `org.el’. Good :) > With the starter-kit, it’s: > (translated from ) runs the command previous-line, which is > an interactive compiled Lisp function in `simple.el’. > > What the heck is ‘translating’ this key binding? When a composed keybinding like does not point to any command, Emacs "translates" it to and use the associated command instead. > How can I find the guilty one so I can do very cruel things to it? I suggest you ask to the author of the starter-kit :) Let us know if you make progress, -- Bastien
Re: [O] result of code evaluation
Am 19.08.2011 21:06, schrieb Henri-Paul Indiogine: Greetings! I am just now starting to use babel in my org-mode files. I am intrigued by its capabilities, but I encountered a strange phenomenon: 8<--->8- #+srcname: test #+begin_src sh :results value #!/bin/bash echo "hello" #+end_src #+results: test : hello ---8<->8 Why is there a ":" at the beginning of the results line? Can I get rid of it? Thanks, Henri-Paul I dont know, but the example on http://orgmode.org/guide/Working-With-Source-Code.html also includes a ':' at the beginning of the line.
Re: [O] result of code evaluation
Hi Henri-Paul, Henri-Paul Indiogine wrote: > Greetings! > > I am just now starting to use babel in my org-mode files. I am > intrigued by its capabilities, but I encountered a strange phenomenon: > > 8<--->8- > #+srcname: test > #+begin_src sh :results value > #!/bin/bash > > echo "hello" > > #+end_src > > #+results: test > : hello > ---8<->8 > > Why is there a ":" at the beginning of the results line? Its purpose is to delimit the result block. Imagine you re-eval the code block, and that (by default, BTW) the result block must be overridden by the new value, Babel must have a way to identify what to delete first. > Can I get rid of it? The only other solutions are: - use the option =:results raw=, but you can't do any replace anymore (of old results by new results) - =(setq org-babel-min-lines-for-block-output 1)=, to force Org to put the output enclosed in a #+begin/end_example block. Best regards, Seb -- Sebastien Vauban
Re: [O] BUG: example/src blocks and latex export
Eric Schulte wrote: > > I get sane behavior with the attached patch, but I'm wondering if it > > breaks other backends, so if somebody is willing to test, I'd appreciate > > it (and of course, I'll test as well). For the time being at least, this > > is a trial balloon, not a real patch. > > > > Thanks for the patch, I would not want this behavior on by default > because I think the results in the Org-mode file are less visually > pleasing than when results are padded with spaces. Perhaps this > behavior could be controlled through a new header argument which would > default to the current behavior. > I tried evaluating the code block in the following file both with (my probably slightly stale version of) master: Org-mode version 7.7 (release_7.7.120.g2edd) and the version with the patch applied: Org-mode version 7.7 (release_7.7.121.gb267a) --8<---cut here---start->8--- #+BABEL: :exports code * foo Verbiage to begin the paragraph #+begin_src sh date #+end_src and verbiage to end the same paragraph. * bar Verbiage to begin the paragraph #+begin_example date #+end_example and verbiage to end the same paragraph. --8<---cut here---end--->8--- After C-c C-c in the code block, it looks like this in both cases: --8<---cut here---start->8--- #+BABEL: :exports code * foo Verbiage to begin the paragraph #+begin_src sh date #+end_src #+results: : Fri Aug 19 15:36:04 EDT 2011 and verbiage to end the same paragraph. * bar Verbiage to begin the paragraph #+begin_example date #+end_example and verbiage to end the same paragraph. --8<---cut here---end--->8--- So I don't think the patch changes anything in the visual appearance of the results. Am I missing something? Were you worried about this or something else? Of course, the line after the results does become a new paragraph in this case when exported to latex: there's yet *another* newline inserted after the results, but that is a separate problem, and the patch under discussion does not change that behavior at all. Agreed? Thanks, Nick
Re: [O] [bug] Asterisks in source and example blocks interpreted as headings
Hi, Eric Schulte wrote: > Daniel Bausch writes: >> AFAIK that is exactly the case, for which the "," rule is for. >> Just put a "," in front of the offending line and everything will be fine. >> On export the "," is removed. > > Using org-edit-special bound to C-c ' to edit the contents of source or > example blocks will inserted the leading ","s automatically when they > are required. Or TAB'ing inside the code block in the source Org buffer. Best regards, Seb PS- I (almost) never use the indirect buffer anymore, thanks to native highlighting. -- Sebastien Vauban
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi all, András Major wrote: >> > I'm fully aware of that, but that also messes up the spacing between >> > sentences. My proposed solution should be robust enough to be >> > more-or-less foolproof yet produce nice-looking output. >> >> What is nice-looking is a matter of personal taste. Personally, I tend >> to prefer everything close-set, as with \frenchspacing, although that > > For that, you can use \frenchspacing in the latex header. > >> If you _do_ want to keep the wider inter-sentence spacing, then you >> also need to worry about sentences that end with upper-case letters. > > True, but that is, in my experience, a very rare thing to happen. In > all the years of writing documents in (La)TeX, I don't think I've had > a single occurrence of this case. You can, of course, make the export > code even more sophisticated and check for this case and adapt the > output accordingly. Then the only rule for the user to remember would > be as simple as this: single space in org maps to inter-word space in > the output, double space maps to inter-sentence space. The problem is that this rule can be true, and certainly is, in English. But French typing conventions require those space before/after punctuation symbols: | symobl | before | after | |++---| | , | 0 | 1 | | . | 0 | 1 | | : | 1 | 1 | | ! | 1 | 2 | | ? | 1 | 2 | for the most commons. Hence, in French, there is never a double space inserted after a sentence period -- well for exclamation or interrogation marks. Best regards, Seb -- Sebastien Vauban
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Hi Achim, Achim Gratz wrote: > András Major writes: >> This would be most easily done using an sh block which returns a >> numeric exit code. > > No one keeps you from using > > echo $? > > in the last line of that shell block. Even if this is a smart workaround, it don't think this is equivalent to outputting "value" as, here, you'd get the value printed at the end of the call, but as well all what has been sent to stdout during the execution of the block. Best regards, Seb -- Sebastien Vauban
[O] result of code evaluation
Greetings! I am just now starting to use babel in my org-mode files. I am intrigued by its capabilities, but I encountered a strange phenomenon: 8<--->8- #+srcname: test #+begin_src sh :results value #!/bin/bash echo "hello" #+end_src #+results: test : hello ---8<->8 Why is there a ":" at the beginning of the results line? Can I get rid of it? Thanks, Henri-Paul -- Henri-Paul Indiogine Curriculum & Instruction Texas A&M University TutorFind Learning Centre Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Hi András and Eric, András Major wrote: > >> If we did return the value of shell scripts then ":results value" would >> almost always simply return 0 (or possibly an error message). For this >> reason shell code blocks do not implement value returns, but rather will >> always collect results from STDOUT. > > I think that this unnecessarily throws away potentially useful > functionality. Example: I want to fill a table with data such that the value > of a cell depends on whether a file (whose path is specified by another > cell, for instance) exists or not. This would be most easily done using an > sh block which returns a numeric exit code. I don't see a reason for making > clandestine exceptions to the rules in the manual and strongly suggest that > the output and value options be honoured for every language. I must admit that I was not aware of this peculiarity for sh blocks. And I guess there must be a reason for not honoring value vs output here. If not, I'd prefer it to exist -- even if Achim showed that both are always possible. > In order not to break existing Org files, I would suggest that the default > choice between value and output (when not explicitly specified) depend on > the language. With this functionality, sh code blocks that don't specify > ":results output" will still work as they did before. That possibility already exist. It can be done like this: #+begin_src emacs-lisp (add-to-list 'org-babel-default-header-args:sh '((:results . "value"))) #+end_src Best regards, Seb -- Sebastien Vauban
[O] Bug: Babel: haskell :results options output and value work contrary to docs [7.7 (release_7.7.107.g7a82)]
Here's another one: In a haskell code, the :results options value and
output both work erroneously. "value" returns the output, "output"
returns nothing into the :results block.
Example code:
#+begin_src haskell :results value
putStrLn "hello"
#+end_src
#+results:
: hello
#+begin_src haskell :results output
putStrLn "hello"
#+end_src
#+results:
#+begin_src haskell :results value
import System.IO
openFile "doesNotExist.ppt" ReadMode
#+end_src
#+results:
: Prelude System.IO> *** Exception: doesNotExist.ppt: openFile: does
not exist (No such file or directory)
#+begin_src haskell :results output
import System.IO
openFile "doesNotExist.ppt" ReadMode
#+end_src
#+results:
This just isn't right, is it?
András
Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
of 2010-12-11 on raven, modified by Debian
Package: Org-mode version 7.7 (release_7.7.107.g7a82)
current state:
==
(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-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t)
(haskell . t) (latex . t) (octave . t) (R . t)
(ruby . t) (scheme . t) (sh . t))
org-metaup-hook '(org-babel-load-in-session-maybe)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-babel-tangle-lang-exts '(("ruby" . "rb") ("latex" . "tex")
("haskell" . "hs") ("asymptote" . "asy")
("emacs-lisp" . "el"))
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-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-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-occur-hook '(org-first-headline-recenter)
org-from-is-user-regexp nil
org-export-preprocess-before-selecting-backend-code-hook
'(org-beamer-select-beamer-code)
org-confirm-babel-evaluate nil
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-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-blocks '((src org-babel-exp-src-block nil)
(comment org-export-blocks-format-comment t)
(ditaa org-export-blocks-format-ditaa nil)
(dot org-export-blocks-format-dot nil))
)
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Andras Major writes: > Hi, > > in TeX and LaTeX, the width of the glue (blank space) after a "." can > be one of two different values, depending on the context. There is > always a longer space between sentences than after a "." that doesn't > mark the end of a sentence (abbreviations, dates, etc.). Since > TeX/LaTeX usually can't recognize the latter case by itself, one can > help out by writing ".\ " or ".~" explicitly to enforce a short space. > Without these hints, printed output will look typographically wrong. > > Org-mode export doesn't allow me to easily include these hints without > affecting readability and export to other formats. Therefore I ask > that LaTeX export places ". " or ".\ " in the output automatically > depending on the context: Org-mode has a straightforward way to include these hints that makes it possible to take care of export to other formats: org-entities-user is a variable defined in `org-entities.el'. Its value is nil Documentation: 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 of the entity that can be inserted into an Org file as \name with the appropriate replacements for the different export backends. The order of the fields is the following name As a string, without the leading backslash LaTeX replacementIn ready LaTeX, no further processing will take place LaTeX mathp A Boolean, either t or nil. t if this entity needs to be in math mode. HTML replacement In ready HTML, no further processing will take place. Usually this will be an &...; entity. ASCII replacementPlain ASCII, no extensions. Symbols that cannot be represented will be left as they are, but see the. variable `org-entities-ascii-explanatory'. Latin1 replacement Use the special characters available in latin1. utf-8 replacementUse the special characters available in utf-8. If you define new entities here that require specific LaTeX packages to be loaded, add these packages to `org-export-latex-packages-alist'. An example due to Lawrence Mitchell is here: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-10-1 With some care, it is possible to keep readability fairly close to what it is in LaTeX markup. hth, Tom > > - If, in the source, the "." precedes a double space " " or a newline, > use ". ". > > - In any other case, use ".\ ". > > The reason this would work is the Emacs convention of writing ASCII > such that there is at least one more space (at least two) between > sentences. I believe that the Emacs fill-* functions also make use of > this convention. > > Thanks, > > András > > -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
András Major writes: > This would be most easily done using an sh block which returns a > numeric exit code. No one keeps you from using echo $? in the last line of that shell block. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Wishlist: allow range of table elements to be filled by sbe
Hi Eric, > sbe is just an elisp function which is called by the Org-mode > spreadsheet's function evaluation mechanisms. The spreadsheet does not > allow for insertion of results into multiple cells and thus neither does > the use of sbe. Hmmm. It appears that one can make sbe set multiple cells in the table -- simply make your code block output multiple results separated by "|" and set ":results table". This, however, also shifts any existing cells in the table, thus increasing the number of columns, instead of just overwriting the given number of cells. > I would recommend a solution like the following, which > reads the /entire/ table into a code block, and writes the results out > in place. This isn't always practical. In the case of the Org document I'm writing at the moment, the computation is rather expensive, and my goal is that you can edit a row in the table and run the calculation just for that row to see the result. Updating the entire table at once would be much too slow. > Every time the code block is evaluated multiple cells in the table are > changed. To only set specific table values use of the `setf' macro > would probably be more appropriate. How is setf used? I haven't found it in the documentation. András
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Hi Eric, > If we did return the value of shell scripts then ":results value" would > almost always simply return 0 (or possibly an error message). For this > reason shell code blocks do not implement value returns, but rather will > always collect results from STDOUT. I think that this unnecessarily throws away potentially useful functionality. Example: I want to fill a table with data such that the value of a cell depends on whether a file (whose path is specified by another cell, for instance) exists or not. This would be most easily done using an sh block which returns a numeric exit code. I don't see a reason for making clandestine exceptions to the rules in the manual and strongly suggest that the output and value options be honoured for every language. In order not to break existing Org files, I would suggest that the default choice between value and output (when not explicitly specified) depend on the language. With this functionality, sh code blocks that don't specify ":results output" will still work as they did before. András
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi Will, > > I'm fully aware of that, but that also messes up the spacing between > > sentences. My proposed solution should be robust enough to be > > more-or-less foolproof yet produce nice-looking output. > > What is nice-looking is a matter of personal taste. Personally, I tend > to prefer everything close-set, as with \frenchspacing, although that For that, you can use \frenchspacing in the latex header. > If you _do_ want to keep the wider inter-sentence spacing, then you > also need to worry about sentences that end with upper-case letters. True, but that is, in my experience, a very rare thing to happen. In all the years of writing documents in (La)TeX, I don't think I've had a single occurrence of this case. You can, of course, make the export code even more sophisticated and check for this case and adapt the output accordingly. Then the only rule for the user to remember would be as simple as this: single space in org maps to inter-word space in the output, double space maps to inter-sentence space. > If you are going to go this way, I think it should be optional. Not > everyone uses double spaces between sentences in their ascii text. I think that the same people wouldn't mind slightly wrong spacing in the printed output either. András
Re: [O] Highlight TODO keywords when using dash as bulletpoint
yeah, I'm going to do that. I was just curious why that wasn't possible. Thanks Bastien. On Fri, Aug 19, 2011 at 2:45 AM, Bastien wrote: > Hi Marcelo, > > Marcelo de Moraes Serpa writes: > > > I'd like to know if it's possible to highlight the TODO keywords when > > using dash " - " as the bulletpoint for items. Example: > > This is not possible to highlight them as being TODO keywords, as > TODO keywords only work on headlines (starting with an asterisk). > > > These are not matched as TODO keywords by org. Is there a way to > > setup org to do that? > > Why don't you use headlines instead of plain lists? > > Best, > > -- > Bastien >
Re: [O] [PATCH] Re: Publishing problem on Worg due to babel intro
Applied, Thanks -- Eric t...@tsdye.com (Thomas S. Dye) writes: > Adds a line to the manual specifying this requirement. > > Tom > > From 5ee660db5f5f4fbaac13ac3787c6e4bca3d2abeb Mon Sep 17 00:00:00 2001 > From: Tom Dye > Date: Fri, 19 Aug 2011 06:27:11 -1000 > Subject: [PATCH] * doc/org.texi: :var requires default value when declared > > --- > doc/org.texi |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/doc/org.texi b/doc/org.texi > index f7ac82e..f0a363b 100644 > --- a/doc/org.texi > +++ b/doc/org.texi > @@ -12200,7 +12200,8 @@ these are addressed in the language-specific > documentation. However, the > syntax used to specify arguments is the same across all languages. The > values passed to arguments can be literal values, values from org-mode tables > and literal example blocks, the results of other code blocks, or Emacs Lisp > -code---see the ``Emacs Lisp evaluation of variables'' heading below. > +code---see the ``Emacs Lisp evaluation of variables'' heading below. In > +every case, variables require a default value when they are declared. > > These values can be indexed in a manner similar to arrays---see the > ``indexable variable values'' heading below. > -- > 1.7.1 > > > Eric Schulte writes: > >> t...@tsdye.com (Thomas S. Dye) writes: >> >>> Christian Egli writes: >>> Hi all I enhanced the taskjuggler tutorial on worg. However the fix is not published as there is a problem with the intro page for Babel[1] (see also the publishing report[2]). The page also fails if I try to publish it locally with the following error message: mapc: Wrong type argument: consp, nil I don't understand where the problem is with this page but I'd appreciate if any of the authors (Eric, Dan, Tom) or anyone else could look into it. Thanks Christian Footnotes: [1] http://orgmode.org/worg/org-contrib/babel/intro.html [2] http://orgmode.org/worg/publishing.txt >>> >>> Yes, something is wrong here. >>> >>> Pressing C-c C-c on this line raises the error: >>> >>> #+call: square(x=6) >>> >>> If I change the square source block from: >>> >>> #+srcname: square(x) >>> #+begin_src python >>> return x*x >>> #+end_src >>> >>> to: >>> >>> #+srcname: square(x=1) >>> #+begin_src python >>> return x*x >>> #+end_src >>> >>> then the error goes away, but it is raised later in the export, >>> presumably on another code block. >>> >> >> When writing a code block *all* variables require a default value. I've >> added default values to all of the variables in this file and it now >> exports as expected. >> >> Cheers -- Eric >> >>> >>> hth, >>> Tom -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Re: Publishing problem on Worg due to babel intro
Adds a line to the manual specifying this requirement. Tom >From 5ee660db5f5f4fbaac13ac3787c6e4bca3d2abeb Mon Sep 17 00:00:00 2001 From: Tom Dye Date: Fri, 19 Aug 2011 06:27:11 -1000 Subject: [PATCH] * doc/org.texi: :var requires default value when declared --- doc/org.texi |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index f7ac82e..f0a363b 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -12200,7 +12200,8 @@ these are addressed in the language-specific documentation. However, the syntax used to specify arguments is the same across all languages. The values passed to arguments can be literal values, values from org-mode tables and literal example blocks, the results of other code blocks, or Emacs Lisp -code---see the ``Emacs Lisp evaluation of variables'' heading below. +code---see the ``Emacs Lisp evaluation of variables'' heading below. In +every case, variables require a default value when they are declared. These values can be indexed in a manner similar to arrays---see the ``indexable variable values'' heading below. -- 1.7.1 Eric Schulte writes: > t...@tsdye.com (Thomas S. Dye) writes: > >> Christian Egli writes: >> >>> Hi all >>> >>> I enhanced the taskjuggler tutorial on worg. However the fix is not >>> published as there is a problem with the intro page for Babel[1] (see >>> also the publishing report[2]). The page also fails if I try to publish >>> it locally with the following error message: >>> >>> mapc: Wrong type argument: consp, nil >>> >>> I don't understand where the problem is with this page but I'd >>> appreciate if any of the authors (Eric, Dan, Tom) or anyone else could >>> look into it. >>> >>> Thanks >>> Christian >>> >>> Footnotes: >>> [1] http://orgmode.org/worg/org-contrib/babel/intro.html >>> [2] http://orgmode.org/worg/publishing.txt >> >> Yes, something is wrong here. >> >> Pressing C-c C-c on this line raises the error: >> >> #+call: square(x=6) >> >> If I change the square source block from: >> >> #+srcname: square(x) >> #+begin_src python >> return x*x >> #+end_src >> >> to: >> >> #+srcname: square(x=1) >> #+begin_src python >> return x*x >> #+end_src >> >> then the error goes away, but it is raised later in the export, >> presumably on another code block. >> > > When writing a code block *all* variables require a default value. I've > added default values to all of the variables in this file and it now > exports as expected. > > Cheers -- Eric > >> >> hth, >> Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Attachments and refiling
At Fri, 19 Aug 2011 10:46:26 +0200, Bastien wrote: What about org-add-link-type? Besides the new link type name, org-add-link-type can receives two functions, one used to follow the link and another to export the link. I was able to make the attach link type work by using org-add-link-type, where the "follow" function is practically the same code I have used with #+LINK. However, I could not make the the "export" part work because I can't use org-attach-expand in it. Therefore, I don't know how to get the attach directory inside a function that I can pass to org-add-link-type as the export function. Unfortunately, my elisp skills are very limited to go any further for now. -- Darlan > > Hi Darlan, > > Darlan Cavalcante Moreira writes: > > > There is probably a way to make the attach link type also work when > > exporting the org buffer, but since I don't need this right now I didn't > > search how to do it. > > You could use a `org-export-preprocess-hook' to convert those "attach" > links into proper "file" links. > > -- > Bastien
Re: [O] Publishing problem on Worg due to babel intro
Christian Egli writes: > Eric Schulte writes: > >> When writing a code block *all* variables require a default value. I've >> added default values to all of the variables in this file and it now >> exports as expected. > > In the mean time I moved the intro to the FIXME directory so that my > stuff would be published on worg. Now that the intro exports do you want > me to move it back to where it belongs? > Yes, that would be great. Thanks -- Eric > > Thanks > Christian -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] ditaa
Hi Eric! 2011/8/19 Eric Schulte : > On a side note (and personal preference) I would highly recommend using > TikZ for LaTeX documents as the finished product seamlessly integrates > with the rest of the document and scales nicely from posted to post-card > printings. Yes, I agree. I had used TikZ previously and liked it a lot. I have left ditaa after trying it with minimal example and still having the problem. I do not have time to look at it any longer. I wrote the TikZ code instead in my org file and that works very well. Thanks, Henri-Paul -- Henri-Paul Indiogine Curriculum & Instruction Texas A&M University TutorFind Learning Centre Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine
[O] Org errors while building agenda: (void-function org-hh:mm-string-to-minutes)
Hi,
it seems commit
commit 8c3ecbe39a0c99e3724246d1eb460495a53721b6
Author: Bastien Guerry
Date: Wed Aug 17 16:08:02 2011 +0200
Move three functions and add appropriate require/declarations.
* org-clock.el (org-duration-string-to-minutes)
(org-minutes-to-hh:mm-string, org-hh:mm-string-to-minutes):
Move from org.el.
has broken my agenda. I get
Debugger entered--Lisp error: (void-function org-hh:mm-string-to-minutes)
org-hh:mm-string-to-minutes("16:30")
org-format-agenda-item(...)
because that function has been moved to org-clock.el, which I don't
use. If I require that, the agenda works again.
org-agenda.el contains `declare-function' statements for the three moved
functions to silence the byte compiler, but it does not require
org-clock in `org-format-agenda-item' nor do the three functions have
autoload cookies.
BTW: What's the original intention of the move? I don't see why those
functions are specific to org-clock...
Bye,
Tassilo
Re: [O] BUG: example/src blocks and latex export
Eric Schulte wrote: > If you want results embedded into a paragraph, then I would suggest > using an inline code block. Regular code blocks are "blocks" in that > they will break paragraphs and are treated (in my mind) more like > figures than inline elements. > Actually in my "real" case, I was using ``:exports code'' in a #+BABEL header, but I forgot to include that in the test. > > > > I get sane behavior with the attached patch, but I'm wondering if it > > breaks other backends, so if somebody is willing to test, I'd appreciate > > it (and of course, I'll test as well). For the time being at least, this > > is a trial balloon, not a real patch. > > > > Thanks for the patch, I would not want this behavior on by default > because I think the results in the Org-mode file are less visually > pleasing than when results are padded with spaces. Perhaps this > behavior could be controlled through a new header argument which would > default to the current behavior. > OK - I did not test evaluation at all: thanks for reminding me. > > ISTR this issue coming up on the list recently: did I imagine it? > > A similar issue regarding the insertion of spaces through repeated > evaluation and removal of results of a code block has been discussed > recently. I'm pushing up a small fix for that issue now. > I'll keep an eye out for it. Thanks, Nick
Re: [O] BUG: example/src blocks and latex export
Nick Dokos writes:
> Consider the following org file:
>
>
> * foo
>
> Verbiage to begin the paragraph
> #+begin_src shell
> get-config.py var section [section ...]
> #+end_src
> and verbiage to end the same paragraph.
>
> * bar
>
> Verbiage to begin the paragraph
> #+begin_example
> get-config.py var section [section ...]
> #+end_example
> and verbiage to end the same paragraph.
>
>
> When exported to latex with current git (Org-mode version 7.7
> (release_7.7.120.g2edd.dirty)),
> I get:
>
> Verbiage to begin the paragraph
>
> \begin{verbatim}
> get-config.py var section [section ...]
> \end{verbatim}
>
>
>
> and verbiage to end the same paragraph.
> \section{bar}
> \label{sec-2}
>
>
> Verbiage to begin the paragraph
>
> \begin{verbatim}
> get-config.py var section [section ...]
> \end{verbatim}
>
>
> and verbiage to end the same paragraph.
>
> so both instances of "verbiage to end the same paragraph" actually end
> up being in a different paragraph, with three empty lines after a
> source block and two empty lines after an example block, where none
> existed before. LaTeX indents the newly created paragraph and it
> looks ugly. Of course, just a single empty line is enough to do
> the damage, but the fact that there is more than one and that there
> are different numbers, indicates multiple places where a gratuitous
> newline is inserted.
>
If you want results embedded into a paragraph, then I would suggest
using an inline code block. Regular code blocks are "blocks" in that
they will break paragraphs and are treated (in my mind) more like
figures than inline elements.
>
> I get sane behavior with the attached patch, but I'm wondering if it
> breaks other backends, so if somebody is willing to test, I'd appreciate
> it (and of course, I'll test as well). For the time being at least, this
> is a trial balloon, not a real patch.
>
Thanks for the patch, I would not want this behavior on by default
because I think the results in the Org-mode file are less visually
pleasing than when results are padded with spaces. Perhaps this
behavior could be controlled through a new header argument which would
default to the current behavior.
> ISTR this issue coming up on the list recently: did I imagine it?
A similar issue regarding the insertion of spaces through repeated
evaluation and removal of results of a code block has been discussed
recently. I'm pushing up a small fix for that issue now.
Cheers -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Publishing problem on Worg due to babel intro
Eric Schulte writes: > When writing a code block *all* variables require a default value. I've > added default values to all of the variables in this file and it now > exports as expected. In the mean time I moved the intro to the FIXME directory so that my stuff would be published on worg. Now that the intro exports do you want me to move it back to where it belongs? Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland - Viel Neues fuer Hoerspiel-Fans: Eine aktuelle Uebersicht des Angebots bei der SBS finden Sie unter http://www.sbs.ch/hoerspiele .
[O] Problem with shift-up
Hi gang, sorry to bother you all again, but my transition to the new emacs is now taking days and I’m getting really frustrated. I’m trying to find out why shift-arrow on a date/time stamp no longer works with my brand new and shiny set-up. Emacs 23, org-mode 7.7. When running a minimal set-up (as described on the worg-FAQ), the shift-arrows keys work as expected: they change the date and time values in org’s timestamps. When loading the starter-kit from Kieran Healy [1], things are not so smooth. I’ve been disabling all possible packages, trying to isolate the culprit, but to no avail. I searched the web and this mailing list, and found someone else with the same problem [2], but alas, no conclusive answer. In both cases, 'shift-select-mode’ is t. With the minimal set-up, S-up is bound to this (using C-h k): runs the command org-shiftup, which is an interactive compiled Lisp function in `org.el’. With the starter-kit, it’s: (translated from ) runs the command previous-line, which is an interactive compiled Lisp function in `simple.el’. What the heck is ‘translating’ this key binding? How can I find the guilty one so I can do very cruel things to it? Pointers very much appreciated! Peter. [1] http://kjhealy.github.com/emacs-starter-kit/ [2] http://comments.gmane.org/gmane.emacs.orgmode/34329
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
On Fri, Aug 19, 2011 at 4:55 PM, Rasmus wrote:
> Andras Major writes:
>
>> Org-mode export doesn't allow me to easily include these hints without
>> affecting readability and export to other formats. Therefore I ask
>> that LaTeX export places ". " or ".\ " in the output automatically
>> depending on the context:
>
> I would like something like this too. Actually, what I would prefer even
> more would be to stop Org from interpreting '{', '}', '\' and other common
> TeX symbols. More often than not I will want to use '\' as an escape
> character.
>
My latex/org knowledge is not great but if your use for braces is for
superscripts and subscripts, I believe you can have fair bit of
control with the option ^:{}.
I think what is required here is a stable escaping convention within org.
> —Rasmus
>
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Wishlist: allow range of table elements to be filled by sbe
András Major writes: > Hi, > > I'd like to use a babel code block to fill a table with values. The > sbe elisp function looks like the right thing for this task, but it > appears that the result of the code block always goes into a single > cell of a table. I can specify ranges of values, but then the entire > output is placed into each of the specified cells. > > Here is how I imagine things should work: > > #+srcname: shcode > #+begin_src sh :exports output table silent > echo "1 2 3" > #+end_src > > | 1 | 2 | 3 | > #+TBLFM: $1..$3='(sbe shcode) > > Note that this is *NOT* real output from the code block in the current > version of org-mode, it's what I want it to be. There are two things > that cause this to break at the moment: > > - The range $1..$3 doesn't work, I have to prepend a row specifier as > in @<$1..@>$3 or suchlike, which is rather counterintuitive but > seems to work. > > - The output "1 2 3" are not separated into the various cells but all > placed into each cell. > > Or am I doing something wrong here? > sbe is just an elisp function which is called by the Org-mode spreadsheet's function evaluation mechanisms. The spreadsheet does not allow for insertion of results into multiple cells and thus neither does the use of sbe. I would recommend a solution like the following, which reads the /entire/ table into a code block, and writes the results out in place. #+results: this-is-the-table | 1 | 4 | 7 | | 2 | 5 | 8 | | 3 | 6 | 9 | #+source: this-is-the-table #+begin_src emacs-lisp :var table=this-is-the-table (mapcar (lambda (row) (mapcar (lambda (cell) (* cell 2)) row)) table) #+end_src Every time the code block is evaluated multiple cells in the table are changed. To only set specific table values use of the `setf' macro would probably be more appropriate. Hope this helps -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Publishing problem on Worg due to babel intro
t...@tsdye.com (Thomas S. Dye) writes: > Christian Egli writes: > >> Hi all >> >> I enhanced the taskjuggler tutorial on worg. However the fix is not >> published as there is a problem with the intro page for Babel[1] (see >> also the publishing report[2]). The page also fails if I try to publish >> it locally with the following error message: >> >> mapc: Wrong type argument: consp, nil >> >> I don't understand where the problem is with this page but I'd >> appreciate if any of the authors (Eric, Dan, Tom) or anyone else could >> look into it. >> >> Thanks >> Christian >> >> Footnotes: >> [1] http://orgmode.org/worg/org-contrib/babel/intro.html >> [2] http://orgmode.org/worg/publishing.txt > > Yes, something is wrong here. > > Pressing C-c C-c on this line raises the error: > > #+call: square(x=6) > > If I change the square source block from: > > #+srcname: square(x) > #+begin_src python > return x*x > #+end_src > > to: > > #+srcname: square(x=1) > #+begin_src python > return x*x > #+end_src > > then the error goes away, but it is raised later in the export, > presumably on another code block. > When writing a code block *all* variables require a default value. I've added default values to all of the variables in this file and it now exports as expected. Cheers -- Eric > > hth, > Tom -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] ditaa
Henri-Paul Indiogine writes:
> Greetings!
>
> This is from my .emacs
>
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((R . t)
>(ditaa . t)
>.
>.
> (defun my-org-confirm-babel-evaluate (lang body)
> (not (string= lang "ditaa"))) ; don't ask for ditaa
> (setq org-confirm-babel-evaluate 'my-org-confirm-babel-evaluate)
>
>
> This is what I obtain in the exported tex file:
>
> \hyperref[home-henk-Dropbox-dissertation-work-flow.png]{file:/home/henk/Dropbox/dissertation/work-flow.png}
>
When I export the following simple ditaa block
#+begin_src ditaa :file work-flow.png
+---+ ++
| | ||
| Org |>| Tex|
| | ||
+---+ ++
#+end_src
I get the following in the resulting .tex file.
\includegraphics[width=.9\linewidth]{work-flow.png}
Are you using the most recent version of Org-mode? Perhaps try starting
up Emacs with a minimal configuration using the -Q flag to the emacs
executable, and see if the problem persists. If not it is caused by
something else in your configuration.
>
> The ditaa code is between these lines:
>
> #+CAPTION: Research work flow
> #+LABEL: fig:workflow
> #+begin_src ditaa :file /home/henk/Dropbox/dissertation/work-flow.png
> :cmdline -r -s 1.0
> ..
> #+end_src
>
> If I execute the code (C-c C-c) I obtain the following:
>
> ditaa version 0.9, Copyright (C) 2004--2009 Efstathios (Stathis) Sideris
>
> Running with options:
> round-corners
> scale = 1.0
> Reading file: /tmp/babel-4681Hni/ditaa-46811gs
> Locale: en_CA
> Dialog.bold
> Rendering to file: /home/henk/Dropbox/dissertation/work-flow.png
> Done in 5sec
>
> The png file is created. The only issue is the faulty tex code that
> is generated.
>
Is the previous text inserted into your org-mode buffer? If so then
that is certainly wrong, the only thing inserted into the org buffer as
results should be a file link to the resulting image.
>
> I have also noticed that the editing of the org file sometimes slows
> down considerably. Maybe it has nothing to do with it, but it
> happened after I started using ditaa. I am wondering about using TikZ
> instead.
>
This could be due to the `org-src-fontify-natively', try setting this
variable to nil and see if the problem persists.
On a side note (and personal preference) I would highly recommend using
TikZ for LaTeX documents as the finished product seamlessly integrates
with the rest of the document and scales nicely from posted to post-card
printings.
Best -- Eric
>
> Thanks,
> Henri-Paul
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Andras Major writes: > Hello, here is an example of apparently erroneous behaviour of the > :results switch. In this example, we use an sh block, but it also > appears to affect other languages (will need more investigation). > > Example Org code: > > #+begin_src sh :exports output > echo "Hello World 1" > #+end_src > > #+results: > : Hello World 1 > > #+begin_src sh :exports value > echo "Hello World 2" > #+end_src > > #+results: > : Hello World 2 > > Am I missing something here or should the second instance really > output something like an integer exit value from echo? > Hi András, If we did return the value of shell scripts then ":results value" would almost always simply return 0 (or possibly an error message). For this reason shell code blocks do not implement value returns, but rather will always collect results from STDOUT. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Babel woes
Andras Major writes: > Hi everyone, > > I've been trying to use org-mode for report generation lately, and > haven't really succeeded. Here's a list of issues I encounter: > > - Babel offers a way of generating a code block from the output or > value of a code block. That new block, however, is forced to the > same language as the original block -- that is doesn't allow me, for > example, to use a Haskell block to create an asymptote figure which > then generates an image in the HTML or PDF export version. Is there > a way around this limitation? > > - Ruby: is inf-ruby really required? Why can't I execute a ruby block > without it? > I just pushed up a fix for this. inf-ruby is now only required when session evaluation is used. I'll preface all of the Haskell questions with the caveat that this may be the first and most serious use of ob-haskell, so some growing pains are to be expected. > > - Haskell: there are at least two interpreters that babel will invoke, > depending on what is available (ghci and hugs), and those two are > incompatible in some areas (such as loading modules, where the > commands are different -- :add vs. :load). I haven't found a way of > + forcing the use of a specific interpreter; > + specifying command-line arguments to the interpreter (which would > eliminate the need for :add or :load). > This really makes using Haskell rather hit-and-miss, see below. > ob-haskell uses inf-haskell to evaluate haskell code. Should a header argument be added to pass additional arguments to the `run-haskell' function provided by inf-haskell? How does non-babel inf-haskell usage deal with this problem. > > - Haskell code usage is rather cumbersome: since Babel invokes an > interpreter rather than runghc, a Haskell block doesn't nearly have > the flexibility of a real Haskell program. In particular, one can > only make definitions (portably) in the Haskell code by creating a > separate block which is tangled but not executed. Another block, > which is executed, can then load the tangled module and use its > definitions (if it weren't for the problems described above and > below). > I am not familiar with runghc, does that allow execution of Haskell source code in a non-interactive way without explicit compilation. The decision to use interactive evaluation for Haskell was motivated by the desire to avoid an explicit compilation step -- something which has since been implemented for languages like C and would itself pose another non-session evaluation option. > > - The handling of interpreted Haskell appears to be rather dodgy: If I > want to load a module (in ghci) and then evaluate some function, > then I run into real trouble. None of my tests run at all when > first loaded into emacs, but if I execute some tests in a certain > order, it all starts working. I haven't been able to figure out yet > what goes wrong and what "playing around" makes things work, but it > appears that > #+begin_src haskell > :add SomeModule > someFunction > #+end_src > will not work because the :add statement is ignored. If I put the > two lines in separate Haskell blocks and execute each one > separately, then things start to work. > That is odd, I would recommend looking in the inf-haskell buffer to see if any lines are not being passed through to haskell. If modules must be loaded before the remainder of the code block is evaluated perhaps a :modules header argument could be tried. > > - I also tried using sbe to invoke a Haskell function from within a > table formula. Here I usually get an error "ERROR - Undefined > variable "x"", which sometimes goes away rather magically (I'm not > sure what makes it go away), after which things work just fine. > Emacs-lisp blocks written in the same manner work out of the box. > I'll need a reproducible example to answer this question. > > - Haskell uses a static type system, and there is no such thing as > automatic casting if a variable has the wrong type for a given > function. Thus, if I evaluate the numbers of a table using Haskell > and sbe, and some values have a decimal dot and other (integer) ones > omit it, then one of these versions will throw an error. Is there a > way of converting the values beforehand to a given type (say, > Double), only to make Haskell happy? > yes, you could pass the variables through an elisp function before passing them to haskell. > > Can anyone give me a hint of why these things don't work and whether > I'm doing something wrong? > > Oh, I'm using emacs from Debian testing (23.2+1-7) and org from git > (cloned today). > These problems are most likely largely due to the immaturity of ob-haskell and not to the specifics of your personal setup. Best -- Eric > > Thanks, > > András > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bug] Asterisks in source and example blocks interpreted as headings
Using org-edit-special bound to C-c ' to edit the contents of source or example blocks will inserted the leading ","s automatically when they are required. Best -- Eric Daniel Bausch writes: > Hi, > > AFAIK that is exactly the case, for which the "," rule is for. > Just put a "," in front of the offending line and everything will be fine. > On export the "," is removed. > > best regards, > Daniel > > Am Dienstag 16 August 2011, 20:27:01 schrieb Jason Dunsmore: >> Hello, >> >> I noticed that lines with leading asterisks inside of source and example >> blocks are interpreted as headings: >> >> --8<---cut here---start->8--- >> * Heading 1 >> >> #+begin_example >> foo >> * bar >> blah >> #+end_example >> >> * Heading 2 >> --8<---cut here---end--->8--- >> >> If you put the point on "Heading 1" and hit TAB, you'll see the >> following: >> >> --8<---cut here---start->8--- >> * Heading 1... >> * bar >> blah >> #+end_example >> >> * Heading 2 >> --8<---cut here---end--->8--- >> >> I'm using GNU Emacs 23.2.1 and Org-mode version 7.7 >> (release_7.7.97.g9d5c5) >> >> Regards, >> Jason > > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Andras Major writes:
> Org-mode export doesn't allow me to easily include these hints without
> affecting readability and export to other formats. Therefore I ask
> that LaTeX export places ". " or ".\ " in the output automatically
> depending on the context:
I would like something like this too. Actually, what I would prefer even
more would be to stop Org from interpreting '{', '}', '\' and other common
TeX symbols. More often than not I will want to use '\' as an escape
character.
—Rasmus
--
Sent from my Emacs
Re: [O] how to include effort in agenda prefix?
Hi Bastien, Bastien wrote: > "Sebastien Vauban" writes: > >>> I do try to keep current, but apparently I missed that! I see it in the >>> docstring, but I don't see its usage explained (in the docstring or in the >>> manual). Am I overlooking it? >> >> I confirm the explanation is missing from the doc. > > I just added a line in the docstring of `org-agenda-prefix-format'. If you only leave me less than 7 minutes to do it... I can't ;-) > Thanks! Good you did it straight away. Best regards, Seb -- Sebastien Vauban
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 3:23 PM, Bastien wrote: > Carsten Dominik writes: > >> Strange. Here it is again: > > Thanks -- please go ahead! Done. - Carsten > > (Good to get rid of "include-all", I stumbled on this while > debugging the agenda a while ago...) > > Best, > > -- > Bastien - Carsten
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi András 2011/8/19 András Major : >> > There is always a longer space between sentences than after a "." >> > that doesn't mark the end of a sentence >> >> This could easily be turned off with the use of a single \frenchspacing >> in the preamble (or in the document; you may switch between the two in >> the document as often as you like; e.g. \frenchspacing is active >> starting from the point TeX reads the macro until it is set back to >> \nonfrenchspacing). > > I'm fully aware of that, but that also messes up the spacing between > sentences. My proposed solution should be robust enough to be > more-or-less foolproof yet produce nice-looking output. > What is nice-looking is a matter of personal taste. Personally, I tend to prefer everything close-set, as with \frenchspacing, although that is mainly because it is very easy to screw up with LaTeX's default spacing, and then things look terrible. There is an interesting discussion at http://en.wikipedia.org/wiki/History_of_sentence_spacing If you _do_ want to keep the wider inter-sentence spacing, then you also need to worry about sentences that end with upper-case letters. For instance, in LaTeX you should write: "The paper by A. Major et~al.\ was discussed by the General Assembly of the UN\@." Without the "\@" LaTeX would not recognize the period following "UN" to be sentence-ending. Note that there is no need to do anything special after the "A." If you are going to go this way, I think it should be optional. Not everyone uses double spaces between sentences in their ascii text. Cheers Will -- Dr William Henney, Centro de Radioastronomía y Astrofísica, Universidad Nacional Autónoma de México, Campus Morelia
Re: [O] git repository over http?
Hi Jason, Jason Dunsmore writes: > I ran some tests and found that the download speed is proportional to > the size of the repo: Good to know, thanks. > If you clone via git://, it does some optimizations during the transfer, > whereas cloning via http:// does not. If I do a "git gc" on the repo, > it reduces the size of the repo on the server and the time to download > via http:// Okay -- can you "git gc" on the server? > I'd recommend using the repo.or.cz repo for http:// downloads. +1 Thanks for these informations! -- Bastien
Re: [O] missing todo's in agenda after emacs/org upgrade
Carsten Dominik writes: > Strange. Here it is again: Thanks -- please go ahead! (Good to get rid of "include-all", I stumbled on this while debugging the agenda a while ago...) Best, -- Bastien
Re: [O] how to include effort in agenda prefix?
"Sebastien Vauban" writes: >> I do try to keep current, but apparently I missed that! I see it in the >> docstring, but I don't see its usage explained (in the docstring or in the >> manual). Am I overlooking it? > > I confirm the explanation is missing from the doc. I just added a line in the docstring of `org-agenda-prefix-format'. Thanks! -- Bastien
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 3:08 PM, Bastien wrote: > Hi Carsten, > > Carsten Dominik writes: > >> OK, I am attaching a patch proposal which will clean this up a bit. > > Thanks for tackling these issues -- I can't read the patch thourh, > as it is just two lines long, can you resent it? Strange. Here it is again: agenda-include-all.patch Description: Binary data > >> It does: >> >> - Clean up the variable name include-all, which is confusing >> for readers of the code >> - Make `org-agenda-custom-commands' have a default value, >> which is a block that does put agenda and TODO list into >> one view. Note that I have changed the sequence from Peter's >> proposal, I am putting the agenda first - this makes more sense, >> I think, and also reduces the likelihood that the cursor will be >> in the TODO list when you are trying to move through time. >> - I have *not* changes the problem that trying to change time views >> in the TODO block will not work - this would have required >> more coding and would create undefined behavior in some block >> agendas. >> >> HTH, please give me feed back. Bastien, let me know if/when >> I should push this change. > > I'll test it this afternoon. > > Best, > > -- > Bastien - Carsten
Re: [O] how to include effort in agenda prefix?
Hi Sébastien, "Sebastien Vauban" writes: >> I do try to keep current, but apparently I missed that! I see it in the >> docstring, but I don't see its usage explained (in the docstring or in the >> manual). Am I overlooking it? > > I confirm the explanation is missing from the doc. Could you provide a patch for that? Thanks! -- Bastien
Re: [O] for beamer: org-export-latex-classes and BEAMER_FRAME_LEVEL?
Hi Marko, Marko Schütz Schmuck wrote: > I have tried to use BEAMER_FRAME_LEVEL instead of setting specific > sections/environments for the individual levels. If I remove all > entries from the sectioning part of org-export-latex-classes, `nil' is > called as a function. If I put anything in the sectioning part of > org-export-latex-classes those commands are used no matter what I set > as BEAMER_FRAME_LEVEL. > > I'd like to use BEAMER_FRAME_LEVEL. How to do it properly? Normally, there is no need to play with org-export-latex-classes. Could you post an ECM (example, complete but minimal) of a presentation you want to do via Org-Beamer? Please highlight what is the current results and what you would expect. Best regards, Seb -- Sebastien Vauban
Re: [O] missing todo's in agenda after emacs/org upgrade
Hi Carsten, Carsten Dominik writes: > OK, I am attaching a patch proposal which will clean this up a bit. Thanks for tackling these issues -- I can't read the patch thourh, as it is just two lines long, can you resent it? > It does: > > - Clean up the variable name include-all, which is confusing > for readers of the code > - Make `org-agenda-custom-commands' have a default value, > which is a block that does put agenda and TODO list into > one view. Note that I have changed the sequence from Peter's > proposal, I am putting the agenda first - this makes more sense, > I think, and also reduces the likelihood that the cursor will be > in the TODO list when you are trying to move through time. > - I have *not* changes the problem that trying to change time views > in the TODO block will not work - this would have required > more coding and would create undefined behavior in some block > agendas. > > HTH, please give me feed back. Bastien, let me know if/when > I should push this change. I'll test it this afternoon. Best, -- Bastien
Re: [O] [odt] htmlfontify + Support for src blockfontification
Jambunathan K writes: >> Hi Jambunathan, >> >> we are discussing in abstract terms, and that might distract us from >> DTRT together: can you show the patched version of htmlfontify.el? > > Here you go. > > Patch numbered 1 is the base htmlfontify.el (same as that in emacs-24 > trunk). I am also attaching a final copy of htmlfontify.el after it has > gone through the series of 5 patches. Sample test.org file to quickly understand the nature of changes. A line by line comparison will show how patches add up. > Jambunathan K. -- * Example 1 #+begin_src emacs-lisp ;; This is how one changes load-path (setq load-path (cons "~/elisp" load-path)) #+end_src * COMMENT This is how ODT output looks like #+begin_src nxml ;;Thisishowonechangesload-path (setqload-path(cons"~/elisp"load-path)) #+end_src * COMMENT This how the HTML output looks like #+begin_src nxml ;; This is how one changes load-path (setq load-path (cons "~/elisp" load-path)) #+end_src
Re: [O] [odt] htmlfontify + Support for src blockfontification
Bastien writes: > Hi Jambunathan, > > I see this addition in one of the latest commit: > > +(defcustom org-export-odt-use-htmlfontify t > + "Specify whether or not source blocks need to be fontified. > +Turn this option on if you want to colorize the source code > +blocks in the exported file. For colorization to work, you need > +to make available an enhanced version of `htmlfontify' library." > > For now, the correct default value is `nil', otherwise users will > encounter problems. No. There is an in-built deprecation as below: #+begin_src emacs-lisp (if (and org-export-odt-use-htmlfontify (or (featurep 'htmlfontify) (require 'htmlfontify)) (fboundp 'htmlfontify-string)) ...) #+end_src htmlfontify-string is a function that is available only in the enhanced version of htmlfontify. > Also, this change only make sense when the enhanced version of > htmlfontify.el is publicly available, so that we can point at a > URL. I guess this will be the case soon :) --
Re: [O] git repository over http?
Bastien writes: > Hi Jonathan, > > Jonathan Leech-Pepin writes: > >> The server does seem to support HTTP for pulling, however it is very >> slow. > > Yes, I noticed this too. > >> http:// does work for cloning and pulling from the main Repo, however >> there's nothing to indicate that anything is happening until the task >> is complete. > > Yes. > > Jason, is the slowliness something worth trying to fix? > Can we get some indication that the repo is currently being > cloned? I ran some tests and found that the download speed is proportional to the size of the repo: --8<---cut here---start->8--- $ time /usr/bin/git clone http://orgmode.org/org-mode.git Cloning into org-mode... real15m23.475s user0m30.434s sys 0m7.588s $ time /usr/bin/git clone git://orgmode.org/org-mode.git org-mode2 Cloning into org-mode2... remote: Counting objects: 51864, done. remote: Compressing objects: 100% (14898/14898), done. remote: Total 51864 (delta 41315), reused 46129 (delta 36900) Receiving objects: 100% (51864/51864), 53.00 MiB | 205 KiB/s, done. Resolving deltas: 100% (41315/41315), done. real5m19.350s user0m19.341s sys 0m2.576s $ time /usr/bin/git clone http://repo.or.cz/r/org-mode.git org-mode3 Cloning into org-mode3... real7m15.211s user0m21.293s sys 0m3.652s $ du -sh org-mode* 201Morg-mode 63M org-mode2 70M org-mode3 --8<---cut here---end--->8--- If you clone via git://, it does some optimizations during the transfer, whereas cloning via http:// does not. If I do a "git gc" on the repo, it reduces the size of the repo on the server and the time to download via http:// --8<---cut here---start->8--- $ cp -r /home/orgmode/org-mode.git/ /var/www/orgmode.org/org-mode-copy.git $ cd /var/www/orgmode.org/org-mode-copy.git $ du -sh 221M. $ git gc $ du -sh 65M . $ time /usr/bin/git clone http://orgmode.org/org-mode-copy.git Cloning into org-mode-copy... real5m6.472s user0m18.797s sys 0m2.300s $ du -sh org-mode-copy 63M org-mode-copy --8<---cut here---end--->8--- I'd recommend using the repo.or.cz repo for http:// downloads. repo.or.cz probably runs git-http-backend or does a "git gc" occasionally. Any user feedback for "git clone" would be up to the git client. It used to say "got... walk..." prior to 1.7. Not sure why they removed those messages in 1.7. Regards, Jason
[O] for beamer: org-export-latex-classes and BEAMER_FRAME_LEVEL?
I have tried to use BEAMER_FRAME_LEVEL instead of setting specific sections/environments for the individual levels. If I remove all entries from the sectioning part of org-export-latex-classes, `nil' is called as a function. If I put anything in the sectioning part of org-export-latex-classes those commands are used no matter what I set as BEAMER_FRAME_LEVEL. I'd like to use BEAMER_FRAME_LEVEL. How to do it properly? Thanks and best regards, Marko pgpZWS2iXAYwF.pgp Description: PGP signature
Re: [O] [odt] htmlfontify + Support for src blockfontification
> It just occurred to me: why using htmlfontify.el instead of > htmlize.el? I guess there are good reasons... htmlfontify is part of Emacs and so a first class citizen. A user doesn't have to install any additional package to get fontification support. It will work out of the box. Jambunathan K. --
Re: [O] missing todo's in agenda after emacs/org upgrade
On 19 Aug 2011, at 13:05, Carsten Dominik wrote: > On Aug 19, 2011, at 12:35 PM, Peter Frings wrote: >> On 19 Aug 2011, at 11:59, Carsten Dominik wrote: >> >>> The two main issues you are having are these: >>> >>> 1. There is no simple way for beginners to get both TODO and agenda in one >>> view >>> 2. Moving through time does not work in a block view when the cursor is in >>> the TODO list. >> Fixing 2 would be great. Maybe there are other keystrokes that can be >> delegated to other blocks (e.g. in order of appearance) if the >> currently-focussed block doesn’t handle them? > The reason why this would be confusing is that there might be > several blocks which accept a particular command, so it would > be unclear for the code how to select one, and even more > difficult for the user to have an intuitive feeling on what was > changed why…. I can understand that this requires quite some changes and that it might be a lot of work. However, I don’t think it would be counter-intuitive, unless there are many conflicting commands (i.e., a same keystroke that has a different effect depending on the block type). Are there that many? E.g., take the ‘w’ or ‘d’ keys in the agenda view. Suppose I’m on the TODO block and type a ‘w’. Would it be that much surprising if the agenda block switches to a week view? Probably not. Of course, there might be sufficient cases that prove me wrong; after all I’m not really familiar with the different blocks. So I’ll stop nagging :-) I’ll swap the order as you suggested and give it a try! Thanks! Peter.
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
On Aug 19, 2011, at 8:50 AM, Andras Major wrote: > Hi, > > in TeX and LaTeX, the width of the glue (blank space) after a "." can > be one of two different values, depending on the context. There is > always a longer space between sentences than after a "." that doesn't > mark the end of a sentence (abbreviations, dates, etc.). Since > TeX/LaTeX usually can't recognize the latter case by itself, one can > help out by writing ".\ " or ".~" explicitly to enforce a short space. > Without these hints, printed output will look typographically wrong. > > Org-mode export doesn't allow me to easily include these hints without > affecting readability and export to other formats. Therefore I ask > that LaTeX export places ". " or ".\ " in the output automatically > depending on the context: > > - If, in the source, the "." precedes a double space " " or a newline, > use ". ". > > - In any other case, use ".\ ". > > The reason this would work is the Emacs convention of writing ASCII > such that there is at least one more space (at least two) between > sentences. I believe that the Emacs fill-* functions also make use of > this convention. +1 I do like this idea. I am a big fan of the Emacs convention to use two spaces after a sentence - such a big fan that I have trouble reading ascii text where this convention is not used. - Carsten
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
> > There is always a longer space between sentences than after a "." > > that doesn't mark the end of a sentence > > This could easily be turned off with the use of a single \frenchspacing > in the preamble (or in the document; you may switch between the two in > the document as often as you like; e.g. \frenchspacing is active > starting from the point TeX reads the macro until it is set back to > \nonfrenchspacing). I'm fully aware of that, but that also messes up the spacing between sentences. My proposed solution should be robust enough to be more-or-less foolproof yet produce nice-looking output. András
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 12:35 PM, Peter Frings wrote: > Hello Carsten, > > > On 19 Aug 2011, at 11:59, Carsten Dominik wrote: > >> The two main issues you are having are these: >> >> 1. There is no simple way for beginners to get both TODO and agenda in one >> view >> 2. Moving through time does not work in a block view when the cursor is in >> the TODO list. > > A third one would be the docstring of org-agenda-include-all-todo set, > suggesting that it still works. If there is no intention to revive it, I’d > suggest to simply remove the entire variable. > > About issue 1, there could be a standard, ready-for-use custom command. But > don’t bother if I’m the only one that finds it convenient. > > Fixing 2 would be great. Maybe there are other keystrokes that can be > delegated to other blocks (e.g. in order of appearance) if the > currently-focussed block doesn’t handle them? The reason why this would be confusing is that there might be several blocks which accept a particular command, so it would be unclear for the code how to select one, and even more difficult for the user to have an intuitive feeling on what was changed why If you follow my proposal to have the agenda first and the TODO items second, the worst that can happen is that you have to move to the beginning of the buffer, which is a single key stroke. Maybe you can try - my feeling is that after a short adaptation period you will find this entirely acceptable. - Carsten > > > > Cheers, > Peter. > -- > c++; // this makes c bigger but returns the old value > - Carsten
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 12:35 PM, Peter Frings wrote: > Hello Carsten, > > > On 19 Aug 2011, at 11:59, Carsten Dominik wrote: > >> The two main issues you are having are these: >> >> 1. There is no simple way for beginners to get both TODO and agenda in one >> view >> 2. Moving through time does not work in a block view when the cursor is in >> the TODO list. > > A third one would be the docstring of org-agenda-include-all-todo set, > suggesting that it still works. If there is no intention to revive it, I’d > suggest to simply remove the entire variable. I agree. > > About issue 1, there could be a standard, ready-for-use custom command. But > don’t bother if I’m the only one that finds it convenient. > > Fixing 2 would be great. Maybe there are other keystrokes that can be > delegated to other blocks (e.g. in order of appearance) if the > currently-focussed block doesn’t handle them? > > > > Cheers, > Peter. > -- > c++; // this makes c bigger but returns the old value > - Carsten
Re: [O] missing todo's in agenda after emacs/org upgrade
Hello Carsten, On 19 Aug 2011, at 11:59, Carsten Dominik wrote: > The two main issues you are having are these: > > 1. There is no simple way for beginners to get both TODO and agenda in one > view > 2. Moving through time does not work in a block view when the cursor is in > the TODO list. A third one would be the docstring of org-agenda-include-all-todo set, suggesting that it still works. If there is no intention to revive it, I’d suggest to simply remove the entire variable. About issue 1, there could be a standard, ready-for-use custom command. But don’t bother if I’m the only one that finds it convenient. Fixing 2 would be great. Maybe there are other keystrokes that can be delegated to other blocks (e.g. in order of appearance) if the currently-focussed block doesn’t handle them? Cheers, Peter. -- c++; // this makes c bigger but returns the old value
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 11:02 AM, peter.fri...@agfa.com wrote:
> Good morning gents,
>
> I think you nailed it. Thanks!
>
>
> * Summary
> Having the todo list in a daily view is very convenient, but not provided
> out-of-the-box. The enabling of it used to be relatively simply with a single
> variable, but in more recent version it’s now reserved for org-savvy people.
> Hooray for
> http://orgmode.org/worg/org-tutorials/org-custom-agenda-commands.html
OK, I am attaching a patch proposal which will clean this up a bit.
It does:
- Clean up the variable name include-all, which is confusing
for readers of the code
- Make `org-agenda-custom-commands' have a default value,
which is a block that does put agenda and TODO list into
one view. Note that I have changed the sequence from Peter's
proposal, I am putting the agenda first - this makes more sense,
I think, and also reduces the likelihood that the cursor will be
in the TODO list when you are trying to move through time.
- I have *not* changes the problem that trying to change time views
in the TODO block will not work - this would have required
more coding and would create undefined behavior in some block
agendas.
HTH, please give me feed back. Bastien, let me know if/when
I should push this change.
Cheers
- Carsten
agenda-include-all.patch
Description: Binary data
>
>
> * What the problem was
> In Emacs 7.7, the variable org-agenda-include-all-todo no longer affects the
> daily/weekly view as documented.
>
> ** org-agenda-include-all-todo no longer works
> The docstrings states:
>
> docstring
> Set means weekly/daily agenda will always contain all TODO entries.
> The TODO entries will be listed at the top of the agenda, before
> the entries for specific days.
> This option is deprecated, it is better to define a block agenda instead.
>
>
> Note that it says it’s deprecated, but it’s still present and describes the
> behavior I was used to. But it doesn’t. Which is in-line what what Puneeth
> mentioned (commit 770c2ddfba5c173d1b33e7b247b49a8188994f76).
>
>
> ** Terminology
> Notice that org-agenda-include-all-todo’s docstring mentions ‘block agenda’,
> as does the ‘Agenda View’ chapter in the manual. But that term is nowhere to
> be found in Org’s customization options. You must first find ‘Agenda Custom
> Commands’, but there the docstring mentions “You can also define a set of
> commands, to create a __composite agenda__ buffer.” So there is a problem of
> terminology here.
>
>
> * Thoughts
> I do question this change a bit. I find it very convenient to have my to-do’s
> (scheduled or not) in my day view. Now, I must make a block agenda to get
> this. OK, I can handle that. However, out-of-the box behavior should suit
> beginners, and asking them to make a block agenda as the first thing to do is
> a bit heavy, no? (Have you seen the customization page for that? Frightening!)
>
> So, to get what I used to have[1] I need to define a custom view like this:
>
> (setq org-agenda-custom-commands
> '(("h" "All to-do's and Agenda"
> ((alltodo)
> (agenda "")
>
> [1] It’s not identical because of the block headers, but that might be
> something that is customizable. Haven’t checked it yet.
>
> Also, in the older version you could type `d’ or `w' to switch to day or week
> view from anywhere in the buffer; now you must make sure the cursor is on the
> agenda black and not in the todo black. This is a bit annoying.
>
>
>
> * Example
> Using GNU Emacs 23.3.1
>
> The example uses the todo list from Suvayu’s mail:
> ~/planning/minimal.org
> * TODO Plumber to fix leak
> <2011-08-04 Thu>
>
> * TODO RooStats tutorial
> SCHEDULED: <2011-01-25 Tue 09:00>
>
> * TODO Analysis deadline
> DEADLINE: <2011-08-19 Fri 15:00>
>
> * TODO Read Dune
> The above 3 entries show up in the agenda, but this one doesn’t.
>
>
> And a minimal emacs init file:
> ~/.emacs-minimal
> (add-to-list 'auto-mode-alist '("\\.\\(org\\ |org_archive\\|txt\\)$" .
> org-mode))
> (setq org-agenda-files '("~/planning/minimal.org"))
> (require 'org-install)
> (require 'org-habit)
>
> (global-set-key "\C-ca" 'org-agenda)
>
>
> Start with
> /Applications/Emacs.app/Contents/MacOS/Emacs --debug-init -Q -l
> ~/.emacs-minimal
>
>
> ** Behavior with Org 6.33x
> Org-mode 6.33x as version with Emacs 23)
>
> *** ‘out of the box’ setup
>
> Do `C-c a a’
>
> Weekly agenda shows=
> Week-agenda (W33):
> Monday 15 August 2011 W33
> Tuesday16 August 2011
> Wednesday 17 August 2011
> Thursday 18 August 2011
> Friday 19 August 2011
>
Re: [O] [odt] htmlfontify + Support for src blockfontification
Jambunathan K writes: > Till such time as this patch is integrated in to official Emacs, I would > like to check-in a copy of htmlfontify.el into the contrib dir. Will > there any objection to this? It just occurred to me: why using htmlfontify.el instead of htmlize.el? I guess there are good reasons... but without seeing the change to htmlfontify.el I fail to see them :) Thanks again for your patience about this issue. -- Bastien
Re: [O] [odt] htmlfontify + Support for src blockfontification
Hi Jambunathan, I see this addition in one of the latest commit: +(defcustom org-export-odt-use-htmlfontify t + "Specify whether or not source blocks need to be fontified. +Turn this option on if you want to colorize the source code +blocks in the exported file. For colorization to work, you need +to make available an enhanced version of `htmlfontify' library." For now, the correct default value is `nil', otherwise users will encounter problems. Also, this change only make sense when the enhanced version of htmlfontify.el is publicly available, so that we can point at a URL. I guess this will be the case soon :) -- Bastien
[O] BUG: example/src blocks and latex export
Consider the following org file:
--8<---cut here---start->8---
* foo
Verbiage to begin the paragraph
#+begin_src shell
get-config.py var section [section ...]
#+end_src
and verbiage to end the same paragraph.
* bar
Verbiage to begin the paragraph
#+begin_example
get-config.py var section [section ...]
#+end_example
and verbiage to end the same paragraph.
--8<---cut here---end--->8---
When exported to latex with current git (Org-mode version 7.7
(release_7.7.120.g2edd.dirty)),
I get:
--8<---cut here---start->8---
Verbiage to begin the paragraph
\begin{verbatim}
get-config.py var section [section ...]
\end{verbatim}
and verbiage to end the same paragraph.
\section{bar}
\label{sec-2}
Verbiage to begin the paragraph
\begin{verbatim}
get-config.py var section [section ...]
\end{verbatim}
and verbiage to end the same paragraph.
--8<---cut here---end--->8---
so both instances of "verbiage to end the same paragraph" actually end
up being in a different paragraph, with three empty lines after a
source block and two empty lines after an example block, where none
existed before. LaTeX indents the newly created paragraph and it
looks ugly. Of course, just a single empty line is enough to do
the damage, but the fact that there is more than one and that there
are different numbers, indicates multiple places where a gratuitous
newline is inserted.
I get sane behavior with the attached patch, but I'm wondering if it
breaks other backends, so if somebody is willing to test, I'd appreciate
it (and of course, I'll test as well). For the time being at least, this
is a trial balloon, not a real patch.
ISTR this issue coming up on the list recently: did I imagine it? If
not, could somebody provide a reference? My feeble attempts at searching
gmane were unsuccessful. I did find an old thread between Nicolas Girard
and Carsten and apparently things were fine for a while. Or I may be
thinking about Tom Dye's problem with lists embedded in a paragraph.
about a month ago, but this is a different problem.
Thanks,
Nick
>From b267aacef1e767cf6ba6d0d9aa8cb4109c7685d3 Mon Sep 17 00:00:00 2001
From: Nick Dokos
Date: Fri, 19 Aug 2011 05:02:57 -0400
Subject: [PATCH] Eliminate extra newline(s) after example or src block.
Signed-off-by: Nick Dokos
---
lisp/ob-exp.el|2 +-
lisp/org-exp.el |2 +-
lisp/org-latex.el |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 9da0487..d1b13c8 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -231,7 +231,7 @@ The function respects the value of the :exports header argument."
(defun org-babel-exp-code (info)
"Return the original code block formatted for export."
(org-fill-template
- "#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC\n"
+ "#+BEGIN_SRC %lang%flags\n%body\n#+END_SRC"
`(("lang" . ,(nth 0 info))
("flags" . ,((lambda (f) (when f (concat " " f))) (nth 3 info)))
("body" . ,(nth 1 info)
diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 740f195..a2a2fb3 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -2718,7 +2718,7 @@ INDENT was the original indentation of the block."
"\n#+BEGIN_" backend-name "\n"
(org-add-props rtn
'(org-protected t org-example t org-native-text t))
- "\n#+END_" backend-name "\n\n"))
+ "\n#+END_" backend-name "\n"))
(org-add-props rtn nil 'original-indentation indent
(defun org-export-number-lines (text &optional skip1 skip2 number cont
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index f46f9f5..17626b5 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -401,7 +401,7 @@ will pass them (combined with the LaTeX default list parameters) to
:type 'plist)
(defcustom org-export-latex-verbatim-wrap
- '("\\begin{verbatim}\n" . "\\end{verbatim}\n")
+ '("\\begin{verbatim}\n" . "\\end{verbatim}")
"Environment to be wrapped around a fixed-width section in LaTeX export.
This is a cons with two strings, to be added before and after the
fixed-with text.
--
1.7.5.1.169.g505a1
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Andras Major writes: > Hi, > in TeX and LaTeX, the width of the glue (blank space) after a "." can > be one of two different values, depending on the context. And depending on the use of \nonfrenchspacing and \frenchspacing. > There is always a longer space between sentences than after a "." > that doesn't mark the end of a sentence This could easily be turned off with the use of a single \frenchspacing in the preamble (or in the document; you may switch between the two in the document as often as you like; e.g. \frenchspacing is active starting from the point TeX reads the macro until it is set back to \nonfrenchspacing). -- Until the next mail..., Stefan. pgpk9oKN0N7KA.pgp Description: PGP signature
Re: [O] missing todo's in agenda after emacs/org upgrade
On Aug 19, 2011, at 11:02 AM, peter.fri...@agfa.com wrote:
> Good morning gents,
>
> I think you nailed it. Thanks!
>
>
> * Summary
> Having the todo list in a daily view is very convenient, but not provided
> out-of-the-box. The enabling of it used to be relatively simply with a single
> variable, but in more recent version it’s now reserved for org-savvy people.
> Hooray for
> http://orgmode.org/worg/org-tutorials/org-custom-agenda-commands.html
>
>
> * What the problem was
> In Emacs 7.7, the variable org-agenda-include-all-todo no longer affects the
> daily/weekly view as documented.
>
> ** org-agenda-include-all-todo no longer works
> The docstrings states:
>
> docstring
> Set means weekly/daily agenda will always contain all TODO entries.
> The TODO entries will be listed at the top of the agenda, before
> the entries for specific days.
> This option is deprecated, it is better to define a block agenda instead.
>
>
> Note that it says it’s deprecated, but it’s still present and describes the
> behavior I was used to. But it doesn’t. Which is in-line what what Puneeth
> mentioned (commit 770c2ddfba5c173d1b33e7b247b49a8188994f76).
>
>
> ** Terminology
> Notice that org-agenda-include-all-todo’s docstring mentions ‘block agenda’,
> as does the ‘Agenda View’ chapter in the manual. But that term is nowhere to
> be found in Org’s customization options. You must first find ‘Agenda Custom
> Commands’, but there the docstring mentions “You can also define a set of
> commands, to create a __composite agenda__ buffer.” So there is a problem of
> terminology here.
>
>
> * Thoughts
> I do question this change a bit. I find it very convenient to have my to-do’s
> (scheduled or not) in my day view. Now, I must make a block agenda to get
> this. OK, I can handle that. However, out-of-the box behavior should suit
> beginners, and asking them to make a block agenda as the first thing to do is
> a bit heavy, no? (Have you seen the customization page for that? Frightening!)
>
> So, to get what I used to have[1] I need to define a custom view like this:
>
> (setq org-agenda-custom-commands
> '(("h" "All to-do's and Agenda"
> ((alltodo)
> (agenda "")
>
> [1] It’s not identical because of the block headers, but that might be
> something that is customizable. Haven’t checked it yet.
>
> Also, in the older version you could type `d’ or `w' to switch to day or week
> view from anywhere in the buffer; now you must make sure the cursor is on the
> agenda black and not in the todo black. This is a bit annoying.
>
>
>
> * Example
> Using GNU Emacs 23.3.1
>
> The example uses the todo list from Suvayu’s mail:
> ~/planning/minimal.org
> * TODO Plumber to fix leak
> <2011-08-04 Thu>
>
> * TODO RooStats tutorial
> SCHEDULED: <2011-01-25 Tue 09:00>
>
> * TODO Analysis deadline
> DEADLINE: <2011-08-19 Fri 15:00>
>
> * TODO Read Dune
> The above 3 entries show up in the agenda, but this one doesn’t.
>
>
> And a minimal emacs init file:
> ~/.emacs-minimal
> (add-to-list 'auto-mode-alist '("\\.\\(org\\ |org_archive\\|txt\\)$" .
> org-mode))
> (setq org-agenda-files '("~/planning/minimal.org"))
> (require 'org-install)
> (require 'org-habit)
>
> (global-set-key "\C-ca" 'org-agenda)
>
>
> Start with
> /Applications/Emacs.app/Contents/MacOS/Emacs --debug-init -Q -l
> ~/.emacs-minimal
>
>
> ** Behavior with Org 6.33x
> Org-mode 6.33x as version with Emacs 23)
>
> *** ‘out of the box’ setup
>
> Do `C-c a a’
>
> Weekly agenda shows=
> Week-agenda (W33):
> Monday 15 August 2011 W33
> Tuesday16 August 2011
> Wednesday 17 August 2011
> Thursday 18 August 2011
> Friday 19 August 2011
> 8:00..
> 10:00..
> 12:00..
> 14:00..
> minimal:15:00.. Deadline: TODO Analysis deadline
> 16:00..
> 18:00..
> 20:00..
> minimal:Sched.207x: TODO RooStats tutorial
> Saturday 20 August 2011
> Sunday 21 August 2011
> -
>
> Daily agenda shows=
> Day-agenda (W33):
> Friday 19 August 2011
> 8:00..
> 10:00..
> 12:00..
> 14:00..
> minimal:15:00.. Deadline: TODO Analysis deadline
> 16:00
[O] Automatically build lists of links to related articles
Greetings, I write articles in their own page, with a main heading as the title. I've written a function that builds a table with links to other articles that share tags with the heading under which the table is built (and that share the same language, assuming that the :lang: property is set). The function I've come up with works, but it is rather ugly. I want it to work during export time, and the only way I've found to access the target's file name has been to rely on ftname being bound. I suspect I must be missing something rather obvious. Any hints on a better way to do this, one that doesn't rely on undocumented variable names bound by the export function? Here's my function: (defun related-entries () (let* ((entries ()) (heading (nth 4 (org-heading-components))) (with-tags (org-get-tags-at (point) t)) (origin-props (org-entry-properties nil 'standard)) (match-lang (cdr (or (assoc "lang" origin-props) (assoc "LANG" origin-props) (org-map-entries (lambda () (let* ((tags (org-get-tags-at (point) t)) (current-heading (nth 4 (org-heading-components))) (props (org-entry-properties nil 'standard)) (lang (cdr (or (assoc "lang" props) (assoc "LANG" props (blurb (cdr (or (assoc "blurb" props) (assoc "BLURB" props (fname (if (boundp 'ftname) ;; during export (file-relative-name (buffer-file-name) (file-name-directory ftname)) (buffer-file-name (if (and (not (string= current-heading heading)) (or (not match-lang) (and lang (equal lang match-lang))) (intersection tags with-tags :test 'equal)) (let ((art-name (nth 4 (org-heading-components (add-to-list 'entries (list (concat "[[file:" fname "::" art-name "][" art-name "]]" (if blurb (concat " --- " blurb) ""))) t) nil (org-publish-get-base-files (if (boundp 'project) ;; during export project (org-publish-get-project-from-filename (buffer-file-name) entries)) Best regards, jm -- http://juanreyero.com/ http://alandair.com
Re: [O] how to narrow Clock Total on repeating tasks?
Hi Michael, Michael Gilbert writes: > I have run into one problem that I don't > know how to apprach. Quite possibly there is an obvious answer in the > manual that I've missed and if so, please forgive me. (I have noticed that > most of my questions don't, in fact, have such answers though.) (Side note: when you have a question and expect to find an answer in the manual, please explicitely state this question in one sentence and point at the section that should cover it in the manual, it will help making it better.) Thanks! -- Bastien
Re: [O] [odt] htmlfontify + Support for src blockfontification
Hi Jambunathan, we are discussing in abstract terms, and that might distract us from DTRT together: can you show the patched version of htmlfontify.el? Thanks! -- Bastien
Re: [O] Wishlist: LaTeX export: automatically append backslash to "." unless at end of sentence
Hi, I'd like to note, that ".~" would lead to a hard space, that disallows a line break, so I think only ".\ " is correct, although Emacs M-q does not break after ". " with a single space, too, to be able to detect sentence ends. Daniel Am Freitag, 19. August 2011, 08:50:52 schrieb Andras Major: > in TeX and LaTeX, the width of the glue (blank space) after a "." can > be one of two different values, depending on the context. There is > always a longer space between sentences than after a "." that doesn't > mark the end of a sentence (abbreviations, dates, etc.). Since > TeX/LaTeX usually can't recognize the latter case by itself, one can > help out by writing ".\ " or ".~" explicitly to enforce a short space. > Without these hints, printed output will look typographically wrong. > > Org-mode export doesn't allow me to easily include these hints without > affecting readability and export to other formats. Therefore I ask > that LaTeX export places ". " or ".\ " in the output automatically > depending on the context: > > - If, in the source, the "." precedes a double space " " or a newline, > use ". ". > > - In any other case, use ".\ ". > > The reason this would work is the Emacs convention of writing ASCII > such that there is at least one more space (at least two) between > sentences. I believe that the Emacs fill-* functions also make use of > this convention. > > Thanks, > > András
Re: [O] missing todo's in agenda after emacs/org upgrade
Good morning gents,
I think you nailed it. Thanks!
* Summary
Having the todo list in a daily view is very convenient, but not provided
out-of-the-box. The enabling of it used to be relatively simply with a single
variable, but in more recent version it’s now reserved for org-savvy people.
Hooray for http://orgmode.org/worg/org-tutorials/org-custom-agenda-commands.html
* What the problem was
In Emacs 7.7, the variable org-agenda-include-all-todo no longer affects the
daily/weekly view as documented.
** org-agenda-include-all-todo no longer works
The docstrings states:
docstring
Set means weekly/daily agenda will always contain all TODO entries.
The TODO entries will be listed at the top of the agenda, before
the entries for specific days.
This option is deprecated, it is better to define a block agenda instead.
Note that it says it’s deprecated, but it’s still present and describes the
behavior I was used to. But it doesn’t. Which is in-line what what Puneeth
mentioned (commit 770c2ddfba5c173d1b33e7b247b49a8188994f76).
** Terminology
Notice that org-agenda-include-all-todo’s docstring mentions ‘block agenda’, as
does the ‘Agenda View’ chapter in the manual. But that term is nowhere to be
found in Org’s customization options. You must first find ‘Agenda Custom
Commands’, but there the docstring mentions “You can also define a set of
commands, to create a __composite agenda__ buffer.” So there is a problem of
terminology here.
* Thoughts
I do question this change a bit. I find it very convenient to have my to-do’s
(scheduled or not) in my day view. Now, I must make a block agenda to get this.
OK, I can handle that. However, out-of-the box behavior should suit beginners,
and asking them to make a block agenda as the first thing to do is a bit heavy,
no? (Have you seen the customization page for that? Frightening!)
So, to get what I used to have[1] I need to define a custom view like this:
(setq org-agenda-custom-commands
'(("h" "All to-do's and Agenda"
((alltodo)
(agenda "")
[1] It’s not identical because of the block headers, but that might be
something that is customizable. Haven’t checked it yet.
Also, in the older version you could type `d’ or `w' to switch to day or week
view from anywhere in the buffer; now you must make sure the cursor is on the
agenda black and not in the todo black. This is a bit annoying.
* Example
Using GNU Emacs 23.3.1
The example uses the todo list from Suvayu’s mail:
~/planning/minimal.org
* TODO Plumber to fix leak
<2011-08-04 Thu>
* TODO RooStats tutorial
SCHEDULED: <2011-01-25 Tue 09:00>
* TODO Analysis deadline
DEADLINE: <2011-08-19 Fri 15:00>
* TODO Read Dune
The above 3 entries show up in the agenda, but this one doesn’t.
And a minimal emacs init file:
~/.emacs-minimal
(add-to-list 'auto-mode-alist '("\\.\\(org\\ |org_archive\\|txt\\)$" .
org-mode))
(setq org-agenda-files '("~/planning/minimal.org"))
(require 'org-install)
(require 'org-habit)
(global-set-key "\C-ca" 'org-agenda)
Start with
/Applications/Emacs.app/Contents/MacOS/Emacs --debug-init -Q -l ~/.emacs-minimal
** Behavior with Org 6.33x
Org-mode 6.33x as version with Emacs 23)
*** ‘out of the box’ setup
Do `C-c a a’
Weekly agenda shows=
Week-agenda (W33):
Monday 15 August 2011 W33
Tuesday16 August 2011
Wednesday 17 August 2011
Thursday 18 August 2011
Friday 19 August 2011
8:00..
10:00..
12:00..
14:00..
minimal:15:00.. Deadline: TODO Analysis deadline
16:00..
18:00..
20:00..
minimal:Sched.207x: TODO RooStats tutorial
Saturday 20 August 2011
Sunday 21 August 2011
-
Daily agenda shows=
Day-agenda (W33):
Friday 19 August 2011
8:00..
10:00..
12:00..
14:00..
minimal:15:00.. Deadline: TODO Analysis deadline
16:00..
18:00..
20:00..
minimal:Sched.207x: TODO RooStats tutorial
*** To include the TODO items
Add this to the init file (or evaluate):
(setq org-agenda-inc
Re: [O] [odt] User-visible improvements
suvayu ali writes:
> Hi Jambu and Bastien,
>
> On Thu, Aug 18, 2011 at 9:31 AM, Bastien wrote:
>> Hi Jambunathan,
>>
>> these are great improvements -- I'm surprised people didn't thank
>> you more for this! So, thanks.
>>
>
> Does this feature mean we can export to other common word processor
> formats like .doc using the odt exporter and command line utilities
> for the final conversion? Although this is not of direct interest to
> me (I stay away from anything not Linux :-p), it might be interesting
> to my Mac/Windows friends. :)
Yes.
org->odt->
First link in the chain is through an org backend and the second link in
the chain is through a converter.
(Think of exporting to latex natively and then using pdflated to
generate pdf. The principle is just the same)
> I also see Jambu mentions odp to pdf.
Yes you can convert to already-existing_odp->pdf. More specifically you
can do all conversions that you typically do with "Save As" and "Export
to" options while working on Writer/Presentation/Spreadsheet/Web/Drawing
documents.
More specifically if you have latex, docbook or mediawiki extensions
installed you can export do a html->latex, odt->docbook, rtf->mediawiki
throught the converter.
The command to use is
M-x org-lparse-convert RET RET RET
and the external converter will do the job for you.
> I wasn't aware the odt exporter could export to odp.
You do a org->odt->odp. This is an easter egg in BasicODConverter (and
this feature is not available in unoconv). You can add a odp entry in
org-lparse-convert-capabilities as below
,
| (("Text" < Under Text category
| ("odt" "ott" "doc" "rtf")
| (("pdf" "pdf")
|("odt" "odt")
|("xhtml" "html")
|("rtf" "rtf")
|("ott" "ott")
|("doc" "doc")
|("ooxml" "xml")
|("html" "html")
|("odp" "odp"))) < Add this entry
| [snip])
`
odt->odp currently uses File->Send->Outline To Presentation
(BasicODConverter is authored by me. So without much of haggling :-) I
can have it do File->Send->Autoabstract to Presentation)
This is an asynchronous call and it is NOT headless. So basically the
LibreOffice window will pop-up and wait for few second before declaring
that conversion is done.
If there is enough interest in this direction I would file a feature
request against LibreOffice to provide a synchronous API for outline to
presentation conversion. (From the OpenOffice mailing list I understand
that odt->html conversion was asynchronous but was later converter to
synchronous mechanism based on a bug report filed by the JODConverter)
, from Main.Bas in BasicODConverter dir
| ' Export Outline to Presentation
| dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")
| dispatcher.executeDispatch(inDoc.CurrentController.Frame,
".uno:SendOutlineToStarImpress", "", 0, Array())
|
| ' Dispatch event above is aynchronous. Wait for a few seconds for the
above event to finish
| Wait(WaitFor * 1000)
`
> This would be something I would love to test more. Is there any
> special configuration I need to do? I tried looking for variables, but
> nothing jumped out as an obvious customisation in a cursory glance.
> And of course a huge thanks to Jambu. :)
--
Re: [O] Attachments and refiling
Hi Darlan, Darlan Cavalcante Moreira writes: > There is probably a way to make the attach link type also work when > exporting the org buffer, but since I don't need this right now I didn't > search how to do it. You could use a `org-export-preprocess-hook' to convert those "attach" links into proper "file" links. -- Bastien
Re: [O] Bug: Extra space inserted in repeated tasks' date line
"Sebastien Vauban" writes: >> Please try latest git repo. I should have fixed the problem you mention. > > AFAICT, this works like a charm! Even in the case of refiling, which I did not > test yesterday -- well today! Thanks for the quick test and confirmation! -- Bastien
Re: [O] Bug: Extra space inserted in repeated tasks' date line
Hi Bastien, Bastien wrote: > "Sebastien Vauban" writes: > >> This works in many cases, but suffers some problems. Anyway, you're >> really not far from giving this a definitive solution[1]. > > Please try latest git repo. I should have fixed the problem you mention. AFAICT, this works like a charm! Even in the case of refiling, which I did not test yesterday -- well today! Thanks a lot... Best regards, Seb -- Sebastien Vauban
Re: [O] [error] Capture template `m': number-or-marker-p
Hello,
> With the update of 20 mins ago or so, that is [2011-08-18 Thu 23:00] (CET),
> I've got the following error when trying to use a capture template I use many
> times every day.
>
> Debugger entered--Lisp error: (error "Capture template `m':
> number-or-marker-p")
> signal(error ("Capture template `m': number-or-marker-p"))
> error("Capture template `%s': %s" "m" number-or-marker-p)
> (condition-case error (org-capture-place-template) ((error quit) (if ...
> ...) (set-window-configuration ...) (error "Capture template `%s': %s" ...
> ...)))
> (if (equal goto 0) (org-capture-insert-template-here) (condition-case error
> (org-capture-place-template) (... ... ... ...)) (if (and ... ...)
> (condition-case nil ... ...)) (if (org-capture-get :immediate-finish)
> (org-capture-finalize nil)))
> (cond ((equal entry "C") (customize-variable ...)) ((equal entry "q")
> (error "Abort")) (t (org-capture-set-plist entry) (org-capture-get-template)
> (org-capture-put :original-buffer orig-buf :original-file ...
> :original-file-nondirectory ... :annotation annotation :initial initial)
> (org-capture-put :default-time ...) (org-capture-set-target-location)
> (condition-case error ... ...) (setq org-capture-clock-keep ...) (if ... ...
> ... ... ...)))
> (let* ((orig-buf ...) (annotation ...) (initial ...) (entry ...)) (when
> (stringp initial) (remove-text-properties 0 ... ... initial)) (when (stringp
> annotation) (remove-text-properties 0 ... ... annotation)) (cond (... ...)
> (... ...) (t ... ... ... ... ... ... ... ...)))
> (cond ((equal goto ...) (org-capture-goto-target)) ((equal goto ...)
> (org-capture-goto-last-stored)) (t (let* ... ... ... ...)))
> org-capture(nil)
> call-interactively(org-capture nil nil)
>
> FYI, the capture template in question:
>
> #+begin_src emacs-lisp
> (setq org-capture-templates
> `(("m" "Mail" entry
>(file+headline ,org-default-notes-file "Tasks")
>"* TODO %:subject%? (from %:fromname) :mail:
>SCHEDULED: %t
>%:date-timestamp-inactive
>
> #+begin_verse
> %i
> #+end_verse
>
> From %a"
>:empty-lines 1 :immediate-finish)))
> #+end_src
>
> Best regards,
> Seb
>
> PS- BTW, I still don't understand how to get real data instead of those
> useless ellipses in the above stack trace.
>
> I've the following in my .emacs file, but it clearly seems without any
> effect!??
>
> #+begin_src emacs-lisp
> ;; maximum depth of lists to print in the result of the evaluation
> commands
> ;; before abbreviating them: no limit
> (setq eval-expression-print-level nil)
>
> ;; maximum length of lists to print in the result of the evaluation
> commands
> ;; before abbreviating them: no limit
> (setq eval-expression-print-length nil)
> #+end_src
This seems closed with the last git of this morning (past-09:42).
Thanks!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [odt] htmlfontify + Support for src blockfontification
Based on my experience I have received far more feedback/bug reports on odt exporter since 7.6 release than when it was in my own git. All three suggestions made here miss the whole point. They are suggesting to hide a useful piece of work underneath githubs, repos etc. - It is not a question of availability but it is a question of availability at the right place where most users can find it without even knowing it. (Did anyone know of org-icons package a few months back?) I am an artist, I need a stage and an audience. I am not a philosopher who keeps his thoughts and work private for his own consumption. - There also seem to be an unarticulated assumption that a transitional software should be as perfect as a released software. It need not be so. Those who have been on the emacs-devel list would know that much of the bidi development is already part of emacs-24 and the discussions last few weeks have been more about tightening the screws and fixing the user-experience component of it. You would also similar parallels with buffer alist related simplifications proposed by martin rudalics. If my understanding is correct, they are genuine interest on the part of emacs developers to steer the patch for overall good. The rule of thumb is that don't hesitate to accept big pieces (provided they are proven worthy - in a proof of concept sense of word). Calling an enhanced htmlfontify.el a duplication is misstating of facts. Again let me cite the example of htmlize. It is available publicly (somewhere?). Why should it be part of contrib dir? I know at some point it was a patched up version of the "original" htmlize. If you are willing to engage in a discussion I can walk through it. If the decision is unilateral I am afraid I cannot do much about it. Btw, I have been sitting on an elpa patch since November of last year. Everytime I submitted I had to spend atleast 1 hr+ to polish it. Now it is totally forgotten. Enough said ... Jambunathan K. --
Re: [O] Closing brace with LaTeX export
"Dr. Adrian Wrigley" writes: > I was using Debian Squeeze, which has the 6.33 by default. Debian should not squeeze users into using such old versions ;) -- Bastien
Re: [O] Highlight TODO keywords when using dash as bulletpoint
Hi Marcelo, Marcelo de Moraes Serpa writes: > I'd like to know if it's possible to highlight the TODO keywords when > using dash " - " as the bulletpoint for items. Example: This is not possible to highlight them as being TODO keywords, as TODO keywords only work on headlines (starting with an asterisk). > These are not matched as TODO keywords by org. Is there a way to > setup org to do that? Why don't you use headlines instead of plain lists? Best, -- Bastien
Re: [O] Bug: Extra space inserted in repeated tasks' date line
Hi Sébastien, "Sebastien Vauban" writes: > This works in many cases, but suffers some problems. Anyway, you're > really not far from giving this a definitive solution[1]. Please try latest git repo. I should have fixed the problem you mention. Thanks! -- Bastien
