Re: [O] Commented internal links bad in new export
Hello, Rafael rvf0...@gmail.com writes: The manual says, in section 4.2 Internal links: Targets may be located anywhere; sometimes it is convenient to put them into a comment line. For example # My Target But if I use such commented targets, then the new exporter does not see them, neither the one to LaTeX nor the HTML one. Thought you might want to know. Yes, this syntax is deprecated in the new exporter. Though, it introduces: #+TARGET: something Actually, the target system have changed a bit. For example, you may try to export the following: 1. item 1 2. itm item 2 The item [[itm]] makes it clear... Regards, -- Nicolas Goaziou
Re: [O] New LaTeX exporter and source code blocks
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I can't get a \begin{figure*} environment with multicolumn.
Org-mode
#+CAPTION: A sample black and white graphic (.eps format) that needs to span
two columns of text.
#+ATTR_LaTeX: multicolumn
[[file:flies.eps]]
--
Indeed. This is fixed now. Thank you for your reports !
Regards,
--
Nicolas Goaziou
Re: [O] orgstuct++ does not lurk silently in the shadow
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: ((adaptive-fill-function (quote nil)) (adaptive-fill-regexp (quote \(\([ [...] This looks good. It's the same as the previous bug: when I try to debug `org-indent-line-function', the problem disappears. I pushed another fix: I now rely on the existing org-let function, which safely evaluate let constructs. -- Bastien
Re: [O] [PATCH] Don't call org-footnote-unique label if using random labels
Hi Matt, Matt Lundin m...@imapmail.org writes: * lisp/org-footnote.el (org-footnote-new): Don't call org-footnote-unique-label if org-footnote-auto-label is set to random. Calling org-footnote-unique-label calls org-footnote-all-labels, which can dramatically slow down footnote creation in a buffer with many footnotes. This is unecessary if org-footnote-auto-label is set to random. Applied, thanks. -- Bastien
[O] [bug] org-create-formula-image-with-dvipng fails to find temporary file
Hello, Yesterday I've updated my git clone of org-mode after a few weeks of not found time to. I noticed the latex fragment preview (C-c C-x C-l) broke. I get messages like org-create-formula-image-with-dvipng: Removing old name: No such file or directory, /tmp/orgtex17198KSG.out Interestingly if another preview command is queued at the same the same fragment that just failed, it works. When run in a section outside of any fragment, where previously all fragments in this section would be rendered, it fails at the first run at the first fragment, at the second run it renders it and fails at the second, at the third run it renders it and fails at the third, and so on. Just to be sure I've ran emacs -Q, evaluated (add-to-list 'load-path ~/.emacs.d/org-mode/lisp) and opened a simple org file. Same issue. Right now I'm too short of time to dig into the code to figure out what's going on, but I wanted bring it up anyways in case some of you guys hit the same issue and search the mailing list for it. Best, Maik
[O] Python execution question
Hi list.
I try to process my data in python. I store outputs from different
scripts in separate txt files and load data using numpy.loadtxt. I want
to change it store outputs in results tables.
So I have this example table
#+TBLNAME: test-table
| 1e212 | 2e1 | 23e3 |
and use it as variable for python source code block below
#+BEGIN_SRC python :var rates=test-table
import numpy as np
for i in range(len(rates)):
rates[i]=map(float,rates[i])
rates2=np.array(rates)
return np.log10(rates2)
#+END_SRC
#+RESULTS:
| 212 | 1.30103 | 4.36172784 |
works OK so far.
And here comes a problem. I want to be able to debug my code in python
session. I use session header argument for it and access session via
org-babel-switch-to-session.
#+BEGIN_SRC python :var rates=test-table :session
import numpy as np
for i in range(len(rates)):
rates[i]=map(float,rates[i])
rates2=np.array(rates)
#+END_SRC
#+RESULTS:
Then it does not work. And inside of session i have the following
output:
__
rates=[[1e212, 2e1, 23e3]]
import numpy as np
for i in range(len(rates)):
rates[i]=map(float,rates[i])
rates2=np.array(rates)
open('/tmp/babel-54890hk/python-54897vP', 'w').write(str(_))
'org_babel_python_eoe'
... ... File stdin, line 3
rates2=np.array(rates)
^
SyntaxError: invalid syntax
Traceback (most recent call last):
File stdin, line 1, in module
NameError: name '_' is not defined
'org_babel_python_eoe'
_
Thank for help in advance.
Petro.
[O] links to folders with non-english characters don't work (emacs 2324 on osx)
hey, First I just wanted to thank everyone involved in creating orgmode, it's amazing and it has pretty much sold me on emacs. But, I've had some problems with links containing æøå. I'm an osx (lion) user. In emacs 23.4 (9.0) no paths with æøå where possible to open. For example, these did not work: file:~/dør.txt (didn't open) http://www.dører.no (the url bar of firefox contained www.d¯rer.no and, before that, some other strange formatting) file:~/dør The links above did work for urls with an o instead of an ø. The problem has been partially solved. I got a pretest version of emacs 24 (later I updated orgmode with package.el, but this did not seem to make a difference) and now the txt and url does work but the folder still does not. All links still work with an o in place of the ø's. The folder can be opened in dired. (Yes, I should learn how to use dired, but just emacs plus org is enough for now.) I hope there's some solution to this. ps. it seems like chinese characters don't work either file:~/黄立行超新星.txt (does open) file:~/黄立行超新星 (only opens in dired)
[O] [BUG] [babel] evaluation disabled completely with no-export
Hi all, there seems to be a bug in babel in connection with interactive source block evaluation when the header argument :eval no-export (ditto with never-export) is present. I get Evaluation Disabled when I try to evaluate (C-c C-c) this block: #+begin_src R :session *R* :exports none :eval no-export Sys.sleep(10) complexObject - 1:10 #+end_src Regards, Andreas PS: emacs 24.1.50, org-mode 7.8.09
Re: [O] [bug] new exporter fails on read only files
Nicolas,
unfortunately, I have immediately run into another problem with the new
exporter (to latex) when going back to my long document (a project
proposal).
I have a minimal example which illustrates the problem. The attached
are a simple org file with the resulting latex file. The key problem is
that the =tabular= command has an empty argument, the argument that is
meant to specify the table alignments.
Specifically, the new exporter generates:
,
| \begin{center}
| \begin{tabular}{}
| \hline
| Task Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12\\
`
whereas the old one generates
,
| \begin{center}
| \begin{tabular}{l}
| \hline
| Task Q1Q2Q3 [...]
`
(last line truncated by me as it was too long)
This is with org up to date from a few minutes ago (see signature). For
the new exporter, I started emacs with -Q and then:
#+begin_src emacs-lisp
(add-to-list 'load-path ~/git/org-mode)
(add-to-list 'load-path ~/git/org-mode/lisp)
(add-to-list 'load-path ~/git/org-mode/contrib/lisp/)
(require 'org-install)
(require 'org-export)
(require 'org-e-latex)
#+end_src
Thanks,
eric
#+TITLE: examplebug.org
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2012-01-09 Mon
#+latex_header: \newcommand{\deliverable}[1]{D\ref{deliverable:#1}}
* new exporter
sec:bug
This section illustrates a simple bug in the new exporter, I think.
The project has the following deliverables:
1. \label{deliverable:evaporative-model} The evaporative model
2. \label{deliverable:system-model} The system model
3. \label{deliverable:control-model} The control model
4. \label{deliverable:control-model-recycle} ... and with a recycle
5. \label{deliverable:preprocessing-system} ... and with preprocessing
The work plan for this project is shown in the following table:
#+latex: \renewcommand{\arraystretch}{1.5}
|+++-++++-+-++-+-+|
| Task | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 | Q8 | Q9 | Q10 | Q11 | Q12|
|+++-++++-+-++-+-+|
| \ref{sec:evaporative} | XX | XX | XX |||| | || | ||
| \ref{sec:systems} ||| | XX | XX || | || | XX ||
| \ref{sec:control} ||| ||| XX | XX | XX || | | XX |
| \ref{sec:desalination} ||| |||| | | XX | XX | ||
|+++-++++-+-++-+-+|
| Deliverables ||| \deliverable{evaporative-model} || \deliverable{system-model} || \deliverable{control-model} | \deliverable{control-model-recycle} || | | \deliverable{preprocessing-system} |
|+++-++++-+-++-+-+|
% Created 2012-05-06 Sun 23:21
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\newcommand{\deliverable}[1]{D\ref{deliverable:#1}}
\providecommand{\alert}[1]{\textbf{#1}}
\author{Eric S Fraga}
\date{2012-01-09 Mon}
\title{examplebug.org}
\hypersetup{
pdfkeywords={},
pdfsubject={},
pdfcreator={Generated by Org mode 7.8.09 in Emacs 24.1.50.1.}}
\begin{document}
\maketitle
\tableofcontents
\vspace*{1cm}
Re: [O] orgstuct++ does not lurk silently in the shadow
Bastien b...@gnu.org writes: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: ((adaptive-fill-function (quote nil)) (adaptive-fill-regexp (quote \(\([ [...] This looks good. It's the same as the previous bug: when I try to debug `org-indent-line-function', the problem disappears. I pushed another fix: I now rely on the existing org-let function, which safely evaluate let constructs. Bastien, unfortunately, I still have problems. I am using org completely up to date (a few minutes ago). I do not turn orgstruct++-mode on automatically at all any more but instead turn it on manually by M-x orgstruct++-mode RET once I'm in a Message buffer. I tried it just now, replying to your email as my test. Turned on the mode, tried to fill the quoted text and it all got mixed up. Undid that. Then went to the bottom and tried to insert a new line and got: org-indent-line-function: Lisp nesting exceeds `max-lisp-eval-depth' Turned off orgstruct++-mode (by M-x ... RET again) and filling of quoted text works fine as does normal writing. I will try (tomorrow) to isolate this with emacs -Q but my problem is that my gnus configuration is really really messy and difficult to isolate. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-489-g541288
Re: [O] orgstuct++ does not lurk silently in the shadow
Eric Fraga e.fr...@ucl.ac.uk writes: unfortunately, I still have problems. I am using org completely up to date (a few minutes ago). me too, I just posted on the gnus.user list ... -- cheers, Thorsten
Re: [O] [BUG] [babel] evaluation disabled completely with no-export
Hi Andreas, This works for me, could you try to reproduce the problem with emacs -Q, to check if maybe the cause lies in your personalization? Best, Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, there seems to be a bug in babel in connection with interactive source block evaluation when the header argument :eval no-export (ditto with never-export) is present. I get Evaluation Disabled when I try to evaluate (C-c C-c) this block: #+begin_src R :session *R* :exports none :eval no-export Sys.sleep(10) complexObject - 1:10 #+end_src Regards, Andreas PS: emacs 24.1.50, org-mode 7.8.09 -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] orgstuct++ does not lurk silently in the shadow
Hi Eric, Eric Fraga e.fr...@ucl.ac.uk writes: unfortunately, I still have problems. I am using org completely up to date (a few minutes ago). I do not turn orgstruct++-mode on automatically at all any more but instead turn it on manually by M-x orgstruct++-mode RET once I'm in a Message buffer. I tried it just now, replying to your email as my test. Turned on the mode, tried to fill the quoted text and it all got mixed up. You are using the exact same version of Gnus and Emacs than I do. Unless you forgot to reload the correct (uncompiled?) version of Org -- I barely dare suggesting this :) -- then this comes from something in your configuration. But no matter where it comes from, we should fix it! Undid that. Then went to the bottom and tried to insert a new line and got: org-indent-line-function: Lisp nesting exceeds `max-lisp-eval-depth' If you're certain you're loading Org correctly, please try the attached patch and just tell me if the error disappears. One possibility I can think of is that perhaps you turn on both orgstruct-mode and orgstruct++-mode. In that case when orgstruct++-mode will save the fill*/indent* variables from the _previous_ mode, it will suppose they are the ones from message-mode, which will not be true and will perhaps cause a loop. The attached patch prevents such a loop. Turned off orgstruct++-mode (by M-x ... RET again) and filling of quoted text works fine as does normal writing. This is already a progress against orgstruct++-mode as it worked before ... somewhat recomforting. I will try (tomorrow) to isolate this with emacs -Q but my problem is that my gnus configuration is really really messy and difficult to isolate. We just need this: C-x C-f ~/.gnus.el M-x occur RET message*hook Also check in your Emacs customization file. HTH, diff --git a/lisp/org.el b/lisp/org.el index e7c42db..17a5bc2 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -20534,7 +20534,8 @@ If point is in an inline task, mark that task instead. (org-move-to-column column) (when (and orgstruct-is-++ (eq pos (point))) (org-let org-fb-vars - '(indent-according-to-mode) + '(or (eq indent-line-function 'org-indent-line-function) + (indent-according-to-mode)) (defun org-indent-drawer () Indent the drawer at point. -- Bastien
Re: [O] New LaTeX exporter and source code blocks
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
I can't get a \begin{figure*} environment with multicolumn.
Org-mode
#+CAPTION: A sample black and white graphic (.eps format) that needs to span
two columns of text.
#+ATTR_LaTeX: multicolumn
[[file:flies.eps]]
--
Indeed. This is fixed now. Thank you for your reports !
Yes, it is fixed now. Thanks for all your help.
The new exporter does a nice job with the ACM-SIG template at
http://github.com/tsdye/orgmode-ACM-template.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [bug] new exporter fails on read only files
Hello, Eric Fraga e.fr...@ucl.ac.uk writes: unfortunately, I have immediately run into another problem with the new exporter (to latex) when going back to my long document (a project proposal). I have a minimal example which illustrates the problem. The attached are a simple org file with the resulting latex file. The key problem is that the =tabular= command has an empty argument, the argument that is meant to specify the table alignments. This should be fixed now. Thanks again for the report. Regards, -- Nicolas Goaziou
Re: [O] New LaTeX exporter and source code blocks
t...@tsdye.com (Thomas S. Dye) writes: The new exporter does a nice job with the ACM-SIG template at http://github.com/tsdye/orgmode-ACM-template. Nice. I will merge some changes to the export engine during the next week, then I'll try to send to the ML a little summary on the various ways to control the output. Regards, -- Nicolas Goaziou
Re: [O] [BUG] [babel] evaluation disabled completely with no-export
Hi Eric, thanks for the quick response on a bogus bug. I can not reproduce it myself now. Seems it was the result from being in the middle of an update. Sorry for the noise, Andreas
[O] [Bug] New LaTeX exporter ignoring noexport
* Hi all, for me the new latex exporter seems to ignore the :noexport: tag with regard to source block execution. If I export this example, both source blocks get evaluated. (It works well, if I limit the scope of the export to a subtree) ** Do NOT export this :noexport: Test #+begin_src R Sys.sleep(10) #+end_src ** Export this No test #+begin_src R 1:5 #+end_src Regards, Andreas
Re: [O] [Bug] New LaTeX exporter ignoring noexport
Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: for me the new latex exporter seems to ignore the :noexport: tag with regard to source block execution. If I export this example, both source blocks get evaluated. :noexport: isn't a directive that Babel recognizes. As a consequence, a :noexport: tag won't prevent a source block from being executed. There are other ways to specify it at the Babel level, though. On the other hand, a :noexport: tag prevents a subtree from being published, which is what happens here, as far as I can tell. Therefore, I don't qualify this as a bug. Regards, -- Nicolas Goaziou
[O] # tag should stick to the following text
Hi, Org people. I'm not sure I'm using # tag correctly, but my feeling is that it should stick to the following text in various Org operations. Let's say I have something like (as I think it): --8---cut here---start-8--- * Some container # tag1 * Title 1 # tag2 * Title 2 --8---cut here---end---8--- If I put # tag1 after Title 1, say, the generated HTML is such that using URL#tag1 will position the browser window to the first line after Title 1. Putting it before yields what I expect, that is, the browser jumps to Title 1. However, Org interpret the above as: --8---cut here---start-8--- * Some container # tag1 * Title 1 # tag2 * Title 2 --8---cut here---end---8--- putting the # tag2 as a line within the Title 1 header. If I later use
Re: [O] [Bug] New LaTeX exporter ignoring noexport
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: for me the new latex exporter seems to ignore the :noexport: tag with regard to source block execution. If I export this example, both source blocks get evaluated. :noexport: isn't a directive that Babel recognizes. As a consequence, a :noexport: tag won't prevent a source block from being executed. There are other ways to specify it at the Babel level, though. On the other hand, a :noexport: tag prevents a subtree from being published, which is what happens here, as far as I can tell. Therefore, I don't qualify this as a bug. Fair enough. I was just surprised, that the new exporter behaves differently from the old one in this respect. ( And I still think, that 1) the differentiation between babel and export wrt :noexport: is not intuitive and 2) turning off evaluation for a subtree on Babel level, is not as straight forward and visual as the simple :noexport: tag. So all in all I'll miss this feature in the new exporter. ) Regards, Andreas
Re: [O] # tag should stick to the following text
Hello, François Pinard pin...@iro.umontreal.ca writes: I'm not sure I'm using # tag correctly, but my feeling is that it should stick to the following text in various Org operations. Let's say I have something like (as I think it): # tag is a deprecated construct. I suggest to avoid bothering with it. Regards, -- Nicolas Goaziou
Re: [O] [bug] new exporter fails on read only files
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Fraga e.fr...@ucl.ac.uk writes: unfortunately, I have immediately run into another problem with the new exporter (to latex) when going back to my long document (a project proposal). I have a minimal example which illustrates the problem. The attached are a simple org file with the resulting latex file. The key problem is that the =tabular= command has an empty argument, the argument that is meant to specify the table alignments. This should be fixed now. Thanks again for the report. Thanks. Works perfectly with my minimal example *and* with my long document! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-482-gf47915
[O] can I force all-caps in part of a headline in a capture template?
I work for a public health department. Twice in the past 5 years we have
had to open evacuation shelters during a flood, for anywhere from 80 to
120 medically-frail evacuees. Our documentation system (paper) has
improved, but it is still not ideal. I am experimenting with whether
org-mode could meet our needs. It's basis in plain text may strike the
proper balance between structure and flexibility.
Part of my .emacs includes the following:
(setq org-capture-templates
'((a Admit entry
(file ~/Shelter/ShelterAdmissions.org)
* admit %^{LASTNAME}, %^{firstname} %U
:PROPERTIES:
%^{IDnumber}p
%^{Birthdate}p
%^{Age}p
%^{Sex}p
%^{Address1}p
%^{Address2}p
%^{City}p
%^{State}p
%^{Zipcode}p
%^{Doctor1}p
%^{Doctor2}p
%^{Pharmacy1}p
%^{Pharmacy2}p
:empty-lines: 1)
)
)
The first line in my ShelterAdmissions.org file is:
#+TODO: admit(a) in(i!) out(o@) | discharged(d@)
and things are working pretty well so far.
I'd like to know if there is a way to force LASTNAME to show up in
all-caps in ShelterAdmissions.org, regardless of how it is typed into
the capture template.
Thanks.
--Chris Ryan
Re: [O] # tag should stick to the following text
Nicolas Goaziou n.goaz...@gmail.com writes: # tag is a deprecated construct. Sigh! I just spent a few hours adding many of those and making sure everything is regular. When some feature is being deprecated, the Org manual should tell us, then ! :-) And at least where that feature is documented. Currently, the manual says: The preferred match for a text link is a dedicated target: the same string in double angular brackets. This is not ultra clear to me, my English is not ultra solid either. I interpreted it as meaning that the preferred way for a text link was such # tag constructs, that is, all the contrary of a deprecation. I suggest to avoid bothering with it. I'll adapt of course, but to what? If not # tag, then what is the way to create a named anchor at an arbitrary place in an Org file? Explicit HTML code? That does not look at all like an improvement: 1. it would be limited to HTML, 2. Org will not likely not follow links to these from within Emacs, 3. if explicit HTML is introduced through specialized Org comments, they suffer exactly from the edit problem # tag demonstrated, being tied to the preceding text instead of the following text. So, Nicolas, I would surely avoid bothering with this problem, but I do not feel I have that choice (yet). I hope the letter I wrote at the beginning of this little thread is not going to be dismissed or ignored. François
Re: [O] # tag should stick to the following text
Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, François Pinard pin...@iro.umontreal.ca writes: I'm not sure I'm using # tag correctly, but my feeling is that it should stick to the following text in various Org operations. Let's say I have something like (as I think it): # tag is a deprecated construct. I suggest to avoid bothering with it. With all due respect, that is not a satisfactory answer. I, for one (or for two: François would surely appreciate it too), would appreciate a pointer to the deprecation notice (I don't remember seeing one but that doesn't mean much), and a pointer (if different) to whatever construct is supposed to replace it. Thanks, Nick
Re: [O] # tag should stick to the following text
François Pinard pin...@iro.umontreal.ca writes: Nicolas Goaziou n.goaz...@gmail.com writes: I suggest to avoid bothering with it. I hope the letter I wrote at the beginning of this little thread is not going to be dismissed or ignored. Well, my original message accidentally left my machine before it was finished. I completed it and resent it, but the corrected message did not show in the mailing list. I guess the Message ID was the same, enough a reason for silent reject. I put a copy of the original message here: http://pinard.progiciels-bpi.ca/notes/Org.html#2012-05-06 François
Re: [O] can I force all-caps in part of a headline in a capture template?
Hi Chris,
Try this: in your .emacs, add the following code:
(defun prompt-for-lastname-and-upcase ()
(upcase (read-string Last name: )))
This defines a function that will prompt the user to type a last name
into the minibuffer, converts the result into uppercase, and returns it
as a string.
Then, in your capture template, change %^{LASTNAME} to
%(prompt-for-lastname-and-upcase).
Best,
Richard
Re: [O] can I force all-caps in part of a headline in a capture template?
Richard Lawrence richard.lawre...@berkeley.edu writes:
Try this: in your .emacs, add the following code:
(defun prompt-for-lastname-and-upcase ()
(upcase (read-string Last name: )))
This defines a function that will prompt the user to type a last name
into the minibuffer, converts the result into uppercase, and returns it
as a string.
Then, in your capture template, change %^{LASTNAME} to
%(prompt-for-lastname-and-upcase).
By the way, if you need to do the same thing for other fields, you can
do something like this instead:
(defun prompt-and-upcase (prompt-str)
(upcase (read-string prompt-str)))
This generalizes the original function I gave you; you can pass in a
prompt string.
Then, in your capture template, wherever you need an uppercase field:
%(prompt-and-upcase Whatever prompt you need: )
e.g.,
%(prompt-and-upcase Last name: )
Best,
Richard
Re: [O] orgstuct++ does not lurk silently in the shadow
Bastien b...@gnu.org writes: Hi Eric, Hello Bastien! [...] You are using the exact same version of Gnus and Emacs than I do. Unless you forgot to reload the correct (uncompiled?) version of Org -- I barely dare suggesting this :) -- then this comes from something in your configuration. Definitely using the latest org! And don't worry about asking: I have done sillier things in the past :-( Undid that. Then went to the bottom and tried to insert a new line and got: org-indent-line-function: Lisp nesting exceeds `max-lisp-eval-depth' If you're certain you're loading Org correctly, please try the attached patch and just tell me if the error disappears. The patch works! I have manually make orgstruct++-mode active: filling of paragraphs, including quoted ones, seems to work and there is no longer any infinite recursion. [...] We just need this: C-x C-f ~/.gnus.el M-x occur RET message*hook For completeness, I have no version of orgstruct++-mode or orgstruct-mode automatically turned on by any hook! Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-529-g035ab3.dirty
Re: [O] taskjuggler (tj3) export issues and proposals
John Hendy jw.he...@gmail.com writes: [...] @EricFraga: if implementing the LaTeX gantt package has moved into either of the two actionable categories you mentioned in our last discussion (http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01259.html), I'd be happy to hear about it :) Unfortunately, my change in my job (resulting in a move literally around the world, about as far as I could go ;-), has led to a real interruption in anything not directly work related! However, I am again starting to write some proposals that will need GANTT charts so maybe I can justify looking at this again. thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-529-g035ab3.dirty
Re: [O] adding custom org-keymaps for EVIL Vim emulator
Herbert Sitz hes...@gmail.com writes: I was playing around with Evil and like it quite a bit. It feels better than the previous Viper/Vimpulse package I was using, plus documentation is good, clear, and it seems easy to customize. One problem with Org for me has been keybindings. Even with a Vim emulator that does a decent job of vim-ifying Emacs, it still leaves all of the (numerous) Org-specific keymappings to deal with. It turns out to be quite easy to add custom keymappings to Org-mode to make commands accessible in a more Vim-like way. I've added the code below to my .emacs and it's a good start. Maybe some vim-friendly Org users will have ideas on how to grow it from here: Herbert, thanks for these. Very useful. I already had some bindings but have added some more based on yours. My current setup is: #+begin_src emacs-lisp (defun esf/evil-key-bindings-for-org () ;;(message Defining evil key bindings for org) (evil-declare-key 'normal org-mode-map gh 'outline-up-heading gj 'org-forward-same-level gk 'org-backward-same-level gl 'outline-next-visible-heading H 'org-beginning-of-line ; smarter behaviour on headlines etc. L 'org-end-of-line ; smarter behaviour on headlines etc. t 'org-todo ; mark a TODO item as DONE ,c 'org-cycle ,e 'org-export-dispatch ,n 'outline-next-visible-heading ,p 'outline-previous-visible-heading ,t 'org-set-tags-command ,u 'outline-up-heading $ 'org-end-of-line ; smarter behaviour on headlines etc. ^ 'org-beginning-of-line ; ditto - 'org-ctrl-c-minus ; change bullet style 'org-metaleft ; out-dent 'org-metaright ; indent ) (mapcar (lambda (state) (evil-declare-key state org-mode-map (kbd M-l) 'org-metaright (kbd M-h) 'org-metaleft (kbd M-k) 'org-metaup (kbd M-j) 'org-metadown (kbd M-L) 'org-shiftmetaright (kbd M-H) 'org-shiftmetaleft (kbd M-K) 'org-shiftmetaup (kbd M-J) 'org-shiftmetadown)) '(normal insert))) #+end_src I've been using evil now for quite a few months and I am very happy with it. Especially for RSI sufferers, a mode based editor avoiding most C- and M- commands is very nice. Combined with ratpoison and keynav, my fingers seldom have to leave the home row! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-529-g035ab3.dirty
Re: [O] # tag should stick to the following text
Nick Dokos nicholas.do...@hp.com writes: Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, François Pinard pin...@iro.umontreal.ca writes: I'm not sure I'm using # tag correctly, but my feeling is that it should stick to the following text in various Org operations. Let's say I have something like (as I think it): # tag is a deprecated construct. I suggest to avoid bothering with it. With all due respect, that is not a satisfactory answer. I, for one (or for two: François would surely appreciate it too), would appreciate a pointer to the deprecation notice (I don't remember seeing one but that doesn't mean much), and a pointer (if different) to whatever construct is supposed to replace it. Thanks, Nick Isn't the deprecation the need to put the xxx in a comment (i.e. #)? The angle bracket syntax remains, I thought. But maybe I also am confused as to the current direction this is taking... -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.09-529-g035ab3.dirty
Re: [O] # tag should stick to the following text
l use that construct extensively and look forward to the clarification. Yours, Christian --- Sent from mobile. Please excuse my brevity.
[O] Extract item body with drawers/properties
Hi Folks, Is there a function to extract the body of an item minus all the auxiliary information? * Item This is the text I want. And here is the second line. SCHEDULED: 2012-05-12 DEADLINE: 2012-05-13 :PROPERTIES: :foo: bar :END: And it's conceivable there is more below drawers... ** Sub-Item 1 ** Sub-Item 2 Basically I want a function that does the following: (org-entry-get-text) This is the text I want And here is the second line. And it's conceivable there is more below drawers... Point is at * Item when this is called. For one project (org-toodledo), I coded a version (see below) that pulls out the drawers, drops properties SCHEDULED/DEADLINE/CLOSED, and pulls off any indentation, and it works pretty well, although it is probably not complete for all cases. However, I'm now working on extensions for another project (org-taskjuggler) and want to again pull out the note. I tried again to find such a function in the org source files, but I just can't seem to find it. Does it exist? If not, does it make sense to make my version below workable for org-mode developers in general? (Related, what is the right term for this block of text? Note? Content? Text?) Thanks ...cj (defun org-toodledo-entry-note () Extract the note for this task. (save-excursion (org-back-to-heading t) (when (looking-at org-complex-heading-regexp) (goto-char (match-end 0)) (let ((text (buffer-substring-no-properties (point) (if (re-search-forward org-complex-heading-regexp nil t) (match-beginning 0) (org-end-of-subtree t t) (with-temp-buffer (insert text) ;; Pull out DEADLINE / SCHEDULED / CLOSED fields (dolist (str (list (regexp-quote org-deadline-string) (regexp-quote org-scheduled-string) (regexp-quote org-closed-string))) (goto-char (point-min)) (when (re-search-forward (concat \\ str +[\[][^]\n]+[]][ \t]*) nil t) (replace-match ))) ;; Drop any empty lines with only (goto-char (point-min)) (while (re-search-forward ^ *\\( \\)+\n nil t) (replace-match )) ;; Drop any remaining (goto-char (point-min)) (while (re-search-forward nil t) (replace-match )) ;; org-export-remove-or-extract-drawers removed an argument sometime around version 7 (if (= (string-to-number org-version) 7) (org-export-remove-or-extract-drawers org-drawers nil) (org-export-remove-or-extract-drawers org-drawers nil nil)) ;; Trim leading/trailing empty lines, but preserve whitepace at the beginning of the line (goto-char (point-min)) (if (re-search-forward \\=\\( *\n\\)+ nil t) (replace-match )) (goto-char (point-min)) (if (re-search-forward \\( *\n\\)+\\' nil t) (replace-match )) (goto-char (point-max)) (insert \n) ;; Finally, if this was indented and indenting notes, remove indentation (when org-toodledo-indent-task-note (goto-char (point-min)) (when (re-search-forward ^ + nil t) (let ((str (match-string 0))) (goto-char (point-min)) (while (re-search-forward (format ^%s str) nil t) (replace-match ) (let ((s (buffer-substring-no-properties (point-min) (point-max (if (string-match \\(\\`[ \t]*[\n\r]+\\)+ s) (setq s (replace-match t t s))) (if (string-match \\([\n\r]+[ \t]*\\)+\\' s) (setq s (replace-match t t s))) s) ) ) ) ) )
