Re: [O] Org-lint and #+call lines
Nicolas Goaziou writes: > Hello, > > t...@tsdye.com (Thomas S. Dye) writes: > >> So, I decided to track wip-lint. Now, the linting stops with this >> error: >> >> , >> | Org linting process starting... >> | let: Wrong type argument: listp, ":results replace org" >> ` >> >> The *Org Lint* buffer is empty, except for the header line. >> >> Here is the offending line in the Org mode file: >> >> ,-- >> | #+call: r-duplicate-ids() :results replace org >> `-- > > Fixed. Thank you. Thanks. This is really helpful. Is org-lint supposed to catch :results output graphics? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Org-lint and #+call lines
> Is org-lint supposed to catch :results output graphics? It catches :results output graphic Is it :results output graphics Regards,
Re: [O] Error when using org-ctrl-c-ctrl-c to add tags
Ken Mankoff writes: > I'm still experiencing this bug, although with a slightly different error > message. When "C-c C-c" on a headline, I see: > > org-set-tags: Wrong type argument: listp, org-tags-completion-function Do you see this from emacs -q? If not, how can I get to the state where this happens from emacs -q? Thanks, Rasmus -- Warning: Everything saved will be lost
Re: [O] Tangled Latex code gives error
Hi Lawrence,
Lawrence Bottorff writes:
> I'm following the Latex howto of org-mode babel. Here's the snippet
> from the howto I've got in a separate .org file (see bottom of howto
> page):
>
> #+LATEX_HEADER: \usepackage{tikz}
>
> First execute the second code block, to define the convenience macro
> and to set the required new variables in ob-latex.el. Then export to
> HTML and to pdf to see the tree exported as an SVG image and as
> embedded tikz respectively.
>
> * Tikz test
> Here's a tree, exported to both html and pdf.
>
> #+header: :file (by-backend (html "tree.svg") (t 'nil))
> #+header: :imagemagick
> #+header: :results (by-backend (pdf "latex") (t "raw"))
> #+header: :tangle yes
> #+begin_src latex
> \usetikzlibrary{trees}
> \begin{tikzpicture}
> \node [circle, draw, fill=red!20] at (0,0) {1}
> child { node [circle, draw, fill=blue!30] {2}
> child { node [circle, draw, fill=green!30] {3} }
> child { node [circle, draw, fill=yellow!30] {4} }};
> \end{tikzpicture}
> #+end_src
>
> * COMMENT setup
> #+header: :tangle yes
> #+begin_src emacs-lisp :results silent
> (setq org-babel-latex-htlatex "htlatex")
> (defmacro by-backend (&rest body)
> `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,
> @body))
> #+end_src
>
> This doesn't really produce a .svg of the tree as advertised, but
> exporting to Latex does produce it just fine.
Works as advertised for me. What version of orgmode are you using?
There has been a bug fix in that code recently.
Note, that in that example the :imagemagick flag is superfluous. It is
necessary, for instance, if you want to be able to get a inline
displayable image in png as well.
Then, the example should be
--8<---cut here---start->8---
#+header: :file (by-backend (html "tree.svg") (t "tree.png"))
#+header: :imagemagick
#+header: :results (by-backend (pdf "latex") (t "raw"))
#+begin_src latex
\usetikzlibrary{trees}
\begin{tikzpicture}
\node [circle, draw, fill=red!20] at (0,0) {1}
child { node [circle, draw, fill=blue!30] {2}
child { node [circle, draw, fill=green!30] {3} }
child { node [circle, draw, fill=yellow!30] {4} }};
\end{tikzpicture}
#+end_src
--8<---cut here---end--->8---
>
> My real confusion starts when I try to tangle the babel code blocks.
> The C-c C-v t command produces two separate files just fine, a .tex
> and .el, but then if I try to Run Latex on the .tex file just by
> itself it gives an error. Here's what the org-mode tangle produces:
>
[ ... snip ... ]
Tangling is not meant to produce full LaTeX files. If you want a full
and compilable LaTeX document, use the export functionality and export
to tex instead of pdf. Then, you can manually compile the tex file.
Hope that helps,
Andreas
Re: [O] Source code evaluation problem
On Saturday, 25 Apr 2015 at 18:35, Damian Bernardini wrote: > After a reinstallation I forgot to do make autoloads. > Now, it's working perfectly. > It was my mistake, sorry and thank you for your help. No problem; it happens to all of us at some point... Glad that you sorted it out. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Tangled Latex code gives error
On Sunday, 26 Apr 2015 at 19:20, Lawrence Bottorff wrote: > I'm following the Latex howto of org-mode babel. Here's the snippet from > the howto I've got in a separate .org file (see bottom of howto page): [...] > My real confusion starts when I try to tangle the babel code blocks. The > C-c C-v t command produces two separate files just fine, a .tex and .el, > but then if I try to Run Latex on the .tex file just by itself it gives an > error. Here's what the org-mode tangle produces: Why do you wish to tangle? The LaTeX will definitely not work standalone as it is not complete. You can export your document to LaTeX (C-c C-e l l) which is probably what you want? -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1062-gce4e64
Re: [O] Marking/highlighting text temporarily
This might be a case where having a link type that supports attributes would come in handy. Then you could use these like PDF comments. In the list of PDF comments in Adobe Acrobat for example, there is a checkbox you can use to check them off when you are done with one. Of course, you have to store that state somewhere! I think the pdf comment also stores the author, and maybe other information too like the date and time it was created. John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Apr 27, 2015 at 2:13 AM, Eric Abrahamsen wrote: > John Kitchin writes: > > > Very nice start! > > > > - make comment links a different color/face > > (e.g. https://github.com/jkitchin/org-ref/blob/master/org-ref.el#L360) > > Ah, nice -- too bad there's no built-in way to specify a face for link > types. This looks like it will do nicely, though! > > > otherwise, I think item 4 is the most important one on the todo list. We > > are writing lots of papers this year, so this will be a really helpful > tool! > > Cool, I'll start with that, then. > > I also thought of a command that would take what's in the tabulated list > buffer and convert it into an Org-mode buffer, with the text/comment > pairs in a two-column table. Then the user could export that buffer into > some other format and share a "comments sheet" with other people. > > A bit at a time... > > Eric > > > Eric Abrahamsen writes: > > > >> Eric Abrahamsen writes: > >> > >>> Vikas Rawal writes: > >>> > On 25-Apr-2015, at 6:22 am, John Kitchin > > wrote: > > Inspired by this conversation, I hacked up this functional comment > link: > > > http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ > > > It has a custom link type that exports in html and latex, and when > you click on it, it asks if you want to delete the comment. > > Nice. One small issue is that when I highlight a text and add comment > to it, and then delete the comment, one space following the last word > is removed. > > Also, it would be good to make the comment stand out in LaTeX (and > other) exports, preferably by pushing it to the margin (so it does not > move everything else). > >>> > >>> Hang on a bit, I'm wasting my afternoon expanding this... > >> > >> Okay, this is as far as I got today. I changed some behavior from John's > >> implementation: when following the links, it seemed like displaying the > >> comment text would be more useful than deleting it -- I think many of us > >> have "delete-org-link" functions lying around. I also couldn't get the > >> add-comment thing to work, as it complained when there was no region, so > >> I changed how that works. > >> > >> Lastly, I spent most of my time learning how tabular list mode works, > >> and haven't actually tested the export. Will save that for tomorrow. > >> Otherwise, here's the introduction from the Commentary. Comments and > >> suggestions very welcome! > >> > >> > >> > >> Provides a new link type for Org that allows you to create comments > >> on arbitrary chunks of text. The link prefix is "comment:". > >> > >> Add comments with `org-comment-add-comment'. Following the link > >> will display the text of the comment in a pop-up buffer. The > >> buffer is in special-mode, hit "q" to dismiss it. > >> > >> Call `org-comment-display-comments' to see all comments in a buffer. > >> > >> See the `org-comment-[backend]-export-style' options for ways to > >> format comments in export. > >> > >> TODO: > >> > >> 1. Better export customization options. > >> 2. What does the ODT comment XML look like? > >> 3. More functions in the display comment buffer: copy as > >> kill... what else? > >> 4. More functions in the comments list buffer, to display, pop to, > >> delete, and edit comment text. > >> 5. Is it possible to have multi-line filled tabular list items? > >> Long comments are not very useful if you can't see the whole thing. > >> 5. Allow multiple comment list buffers attached to different Org > >> buffers. > >> 6. Maybe a minor mode for ease of manipulating comments? > > > > -- > > Professor John Kitchin > > Doherty Hall A207F > > Department of Chemical Engineering > > Carnegie Mellon University > > Pittsburgh, PA 15213 > > 412-268-7803 > > @johnkitchin > > http://kitchingroup.cheme.cmu.edu > > >
Re: [O] Marking/highlighting text temporarily
On 2015-04-27, at 12:27, John Kitchin wrote: > This might be a case where having a link type that supports attributes > would come in handy. Then you could use these like PDF comments. In the > list of PDF comments in Adobe Acrobat for example, there is a checkbox you > can use to check them off when you are done with one. Of course, you have > to store that state somewhere! I think the pdf comment also stores the > author, and maybe other information too like the date and time it was > created. I think that Adobe Reader also sends it to the NSA. ;-) > John Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] custom agenda view not possible?
Hello,
On 2015-04-27 04:21, Traycer Bullet writes:
> I'm transitioning from a web-based to-do list, and one thing I rely on is
> viewing recently CREATED or CLOSED tasks, e.g. within the last 2 days. My hope
> is to recreate this with a custom agenda view, but I haven't been able to find
> the correct commands/filters. Keeping in mind I'm new to Emacs/Lisp/OrgMode,
> here's what I've tried so far (for just the CLOSED example):
>
> This doesn't work because tags-todo excludes 'DONE' status tasks:
> (add-to-list 'org-agenda-custom-commands
> '("J" "Completed Recently" tags-todo "CLOSED>=\"<-2d>\""))
>
> This doesn't work because the org-agenda-tag-filter-preset only works for
> tags:
> (add-to-list 'org-agenda-custom-commands
> '("J" "Completed Recently" todo "DONE"
> ((org-agenda-tag-filter-preset '("+CLOSED>=\"<-2d>\"")
>
> Regarding the desired CREATED agenda view, I use a script to add a CREATED
> timestamp as property to each task (see:
> http://stackoverflow.com/questions/12262220/add-created-date-property-to-todos-in-org-mode
> ),
> so a task will look something like this:
>
> TODO New task for today
> :PROPERTIES:
> :CREATED: [2015-04-13 Mon 17:57]
> :END:
>
> There is no agenda filtering preset options for Properties (only
> tags/category/regexp), which is the only way I could think of to do the
> necessary date comparisons (e.g. <-2d>).
>
> The task seems simple, so I'm hopeful I'm overlooking some way of
> accomplishing it.
I think the simplest approach would be to write a predicate and use it
with `org-agenda-skip-function'. I do this in my org-review package, see
https://github.com/brabalan/org-review/blob/master/org-review.el#L230
for an example of a function to use, and
https://github.com/brabalan/org-review/blob/master/org-review.el#L153
for the predicate it relies on (this also shows how to get properties
values and to time comparison).
Best,
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
signature.asc
Description: PGP signature
Re: [O] Org-lint and #+call lines
Nicolas Goaziou writes: >> Is org-lint supposed to catch :results output graphics? > > It catches > > :results output graphic > > Is it > > :results output graphics Nevermind. I realized allowed values and combinations are already known to Babel, so I improved the checker.
Re: [O] Tangled Latex code gives error
I'm attracted to the tangle option because the normal latex export seems to
take everything in my .org file, e.g.,
* Introduction
LaTeX is a document markup language and a document preparation system
for the TeX typesetting program.
#+BEGIN_LaTeX
\begin{eqnarray*}
\hat{f}(x) & \propto & \sum_{\nu} \frac{|F(\nu)H(\nu)|^2}{|N(\nu)|^2}
\frac{G(\nu)}{H(\nu)} e^{\frac{2 \pi i \nu x}{N}}\\
& \propto & \sum_{\nu} \frac{|F(\nu)|^2}{|N(\nu)|^2} H(\nu)
H^*(\nu)
\frac{G(\nu)}{H(\nu)} e^{\frac{2 \pi i \nu x}{N}}\\
& \propto & \sum_{\nu} H^*(\nu) G(\nu) e^{\frac{2 \pi i \nu
x}{N}}
\end{eqnarray*}
#+END_LaTeX
will result in both the * Introduction blurb as well as the stuff between
the tatex "structural elements" being exported. With latex babel I can
tangle and get only what I want. This is handy if I want to throw around a
lot of chatter and extraneous stuff that ultimately I won't want in my
final document. We might call this "annotations a la orgmode." But, yes,
then I don't get the built-in orgmode latex support that comes with a
regular latex export. Please advise if I'm wrong on this understanding.
On Mon, Apr 27, 2015 at 5:33 AM, Eric S Fraga wrote:
> On Sunday, 26 Apr 2015 at 19:20, Lawrence Bottorff wrote:
> > I'm following the Latex howto of org-mode babel. Here's the snippet from
> > the howto I've got in a separate .org file (see bottom of howto page):
>
> [...]
>
> > My real confusion starts when I try to tangle the babel code blocks. The
> > C-c C-v t command produces two separate files just fine, a .tex and .el,
> > but then if I try to Run Latex on the .tex file just by itself it gives
> an
> > error. Here's what the org-mode tangle produces:
>
> Why do you wish to tangle? The LaTeX will definitely not work
> standalone as it is not complete. You can export your document to LaTeX
> (C-c C-e l l) which is probably what you want?
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org
> release_8.3beta-1062-gce4e64
>
Re: [O] Error when using org-ctrl-c-ctrl-c to add tags
On 2015-04-27 at 04:26, Rasmus wrote: > Ken Mankoff writes: > >> I'm still experiencing this bug, although with a slightly different error >> message. When "C-c C-c" on a headline, I see: >> >> org-set-tags: Wrong type argument: listp, org-tags-completion-function > > Do you see this from emacs -q? If not, how can I get to the state where > this happens from emacs -q? A "make clean" before "make autoloads" fixed it. Sorry for the noise, -k.
Re: [O] Marking/highlighting text temporarily
Marcin Borkowski writes: > On 2015-04-27, at 12:27, John Kitchin wrote: > >> This might be a case where having a link type that supports attributes >> would come in handy. Then you could use these like PDF comments. In the >> list of PDF comments in Adobe Acrobat for example, there is a checkbox you >> can use to check them off when you are done with one. Of course, you have >> to store that state somewhere! I think the pdf comment also stores the >> author, and maybe other information too like the date and time it was >> created. > > I think that Adobe Reader also sends it to the NSA. ;-) I will provide a special org-comment-nsa-export-function option, to help you convey your "comments" directly to the place where it matters.
Re: [O] Marking/highlighting text temporarily
Emacs anticipated this need and can help formulate comments specifically for the NSA :) https://www.gnu.org/software/emacs/manual/html_node/emacs/Mail-Amusements.html John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Mon, Apr 27, 2015 at 8:37 AM, Eric Abrahamsen wrote: > Marcin Borkowski writes: > > > On 2015-04-27, at 12:27, John Kitchin wrote: > > > >> This might be a case where having a link type that supports attributes > >> would come in handy. Then you could use these like PDF comments. In the > >> list of PDF comments in Adobe Acrobat for example, there is a checkbox > you > >> can use to check them off when you are done with one. Of course, you > have > >> to store that state somewhere! I think the pdf comment also stores the > >> author, and maybe other information too like the date and time it was > >> created. > > > > I think that Adobe Reader also sends it to the NSA. ;-) > > I will provide a special org-comment-nsa-export-function option, to help > you convey your "comments" directly to the place where it matters. > > >
Re: [O] Marking/highlighting text temporarily
John Kitchin writes: > Emacs anticipated this need and can help formulate comments > specifically for the NSA :) > https://www.gnu.org/software/emacs/manual/html_node/emacs/Mail-Amusements.html Well that's pretty amazing. > On Mon, Apr 27, 2015 at 8:37 AM, Eric Abrahamsen > wrote: > > > Marcin Borkowski writes: > > > On 2015-04-27, at 12:27, John Kitchin > wrote: > > > >> This might be a case where having a link type that supports > attributes > >> would come in handy. Then you could use these like PDF > comments. In the > >> list of PDF comments in Adobe Acrobat for example, there is a > checkbox you > >> can use to check them off when you are done with one. Of > course, you have > >> to store that state somewhere! I think the pdf comment also > stores the > >> author, and maybe other information too like the date and time > it was > >> created. > > > > I think that Adobe Reader also sends it to the NSA. ;-) > > I will provide a special org-comment-nsa-export-function option, > to help > you convey your "comments" directly to the place where it matters.
Re: [O] org-latex question
>
>> In the document (manuscript of a book) that I am working, ALT_TITLE now
>> works in most cases. However, ALT_TITLE does not work for headlines in
>> Appendices, which come after
>>
>> \begin{appendices}
>
> Are you sure the problem isn't on the LaTeX side? Where does the
> appendices environment come from? It appears not to be defined in
> LaTeX2e nor in the standard classes.
>
I am sorry, it has nothing to do with appendices. Although I am not able to
exactly figure out where the problem is, I have an example file where ALT_TITLE
gets exported only for one headline and not for the others. Please see the
attached org and and latex files.
Vikas
temp.org
Description: Binary data
temp.tex
Description: Binary data
[O] navigate between source code blocks
Dear Org experts, I’ve got a simple question: how to speed up jumping between code blocks? My org file grows larger every day with more and more source code blocks. I find myself spending increasing amount of time finding the right code blocks to go to. Could anyone suggest a method to increase efficiency? So far I’ve tried (1) simple search and (2) C-c C-v g, which for some reason often fails to find blocks. Thanks very much! Zhihao
[O] #+LINK abbrevs possible in #+INCLUDEs ?
Hi! Emacs and git in today´s fresh version. I have two files: file1.org: #+LINK: HOME http://example.de * My Homepage You can find my homepage [[HOME][here]] #+INCLUDE: file2.org file2.org #+LINK: HOME2 http://other.example.de * My other page You can find my other page [[HOME2][here]] I can export file2.org to html as expected. I can´t export file1.org to html with the included file2.org. Only if I move the #+LINK line from file2 to file1 the export works as expected. In my setting file2.org must export standalone, so moving the LINKs to file1 is no option. An ugly workaround would be to include the abbreviation for HOME2 in both files. Ugly. Is there a woraround/setting to have local #+LINK directives working in included files? Regards Detlef
Re: [O] Conditional .gitignore for org-mode files
Hi David, David Dynerman writes: > Sorry in advance, this might be more of a git question than an org-mode > question, but I thought someone on this list might know the answer. > > Is it possible to conditionally gitignore certain files based on files > that are being tracked? > > What I'd like is something like the following gitignore logic: > > if filename.org is tracked by git: >ignore filename.tex, filename.html > > If this isn't possible, does anyone have any nice setups for ignoring > exported versions of org-mode files? Unfortunately, I don't know how to do what you asked, but what I tend to do in this situation is to run my exports in a build/ subdirectory, and then add build* to my .gitignore. Maybe that would work for you? Best, Richard
Re: [O] Conditional .gitignore for org-mode files
Dear David, David Dynerman writes: > What I'd like is something like the following gitignore logic: > > if filename.org is tracked by git: >ignore filename.tex, filename.html > > If this isn't possible, does anyone have any nice setups for ignoring > exported versions of org-mode files? The manual of gitignore indicates that gitignore don't handle other behaviors than pattern matching. --8<---cut here---start->8--- man gitignore --8<---cut here---end--->8--- My workaround is simply to gather org files into a same directory and add git ignore rules for each kind of generated file. --8<---cut here---start->8--- *.html *.tex *.ps *.pdf --8<---cut here---end--->8--- Hope that helps, -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A signature.asc Description: PGP signature
Re: [O] Org-lint and #+call lines
Nicolas Goaziou writes: > I realized allowed values and combinations are already known to Babel, > so I improved the checker. Looks good. Org-lint raises many more warnings now. Thanks, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [RFC] Org linting library
> -Original Message- > On > Behalf Of Nicolas Goaziou > Sent: Sunday, 2015 April 19 09:32 > To: Org Mode List > Subject: [O] [RFC] Org linting library > > Hello, > > The following library implements linting for Org syntax. The sole > public > function is `org-lint', which see. > Nicolas Goaziou > 0x80A93738 [Doug Lewan] Very cool. Thank you. -- ,Doug Douglas Lewan Shubert Ticketing (201) 489-8600 ext 224 or ext 4335 The human brain is the most complex thing known to man, according to the human brain.
Re: [O] org-latex question
Hello, Vikas Rawal writes: > I am sorry, it has nothing to do with appendices. Although I am not > able to exactly figure out where the problem is, I have an example > file where ALT_TITLE gets exported only for one headline and not for > the others. Please see the attached org and and latex files. > > Vikas > > #+STARTUP: hidestars > #+TITLE: Test title > #+AUTHOR: Draft: Do not Cite > #+OPTIONS: toc:nil num:2 H:4 > #+LATEX_CLASS: article > > * Chap 1 > ** Heading 1[fn:1] > :PROPERTIES: > :ALT_TITLE: Heading 1 > :END: > > * Chapter 2 > ** Heading 1 > *** Heading 2[fn:2] > :PROPERTIES: > :ALT_TITLE: Heading 2 > :END: > > * Chapter 3 > *** Heading 3[fn:3] > :PROPERTIES: > :ALT_TITLE: Heading 3 > :END: > > * Footnotes > > [fn:1] a,skdj akjd aksjd > > [fn:2] aksjdlkjaslkjd > > [fn:3] aksjd kajshd kahsd Fixed in 88ea2ced0e38646d393e038bc81d6a0d45b8dcd6. Thank you. Regards, -- Nicolas Goaziou
Re: [O] org-latex question
Vikas Rawal writes:
>>
>>> In the document (manuscript of a book) that I am working, ALT_TITLE
>>> now works in most cases. However, ALT_TITLE does not work for
>>> headlines in Appendices, which come after
>>>
>>> \begin{appendices}
>>
>> Are you sure the problem isn't on the LaTeX side? Where does the
>> appendices environment come from? It appears not to be defined in
>> LaTeX2e nor in the standard classes.
>>
>
> I am sorry, it has nothing to do with appendices. Although I am not
> able to exactly figure out where the problem is, I have an example
> file where ALT_TITLE gets exported only for one headline and not for
> the others. Please see the attached org and and latex files.
>
You have num:2, so subsubsections are not TOC'ed, so they don't get
the alternative. If you set it to 3, all should work.
Nick
Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
Hello, Detlef Steuer writes: > I have two files: > > file1.org: > > #+LINK: HOME http://example.de > > * My Homepage You can find my homepage [[HOME][here]] > > #+INCLUDE: file2.org > > > file2.org > #+LINK: HOME2 http://other.example.de > > * My other page > You can find my other page [[HOME2][here]] > > > I can export file2.org to html as expected. > > I can´t export file1.org to html with the included file2.org. > Only if I move the #+LINK line from file2 to file1 the export > works as expected. > > In my setting file2.org must export standalone, so moving the LINKs to > file1 is no option. An ugly workaround would be to include the > abbreviation for HOME2 in both files. Ugly. > > Is there a woraround/setting to have local #+LINK directives working in > included files? You can extract out #+LINK: keywords in a file, e.g. "setup.org" and use #+SETUPFILE: ... in both "file1.org" and "file2.org". You can also use #+SETUPFILE: file2.org in "file1.org". Set-up (e.g., link abbreviations) is not refreshed after expanding INCLUDE keywords. I cannot remember why, tho. Maybe for (dubious) efficiency reasons. Regards, -- Nicolas Goaziou
[O] BUG: named time references problem in formula
Hello, according to [[info:org#References]] (see Named references) is possible to use a property in formulas. This generally works, but not when the property is a time value as defined in [[info:org#Durations%20and%20time%20values]]. Please have a look at the following ECM: * test table with constant (working) :PROPERTIES: :constant: 3 :END: | month | days | results | |---+---+-| |01 | 1 | 3 | |02 | 3 | 9 | #+TBLFM: $3=$2*$PROP_constant; * test table with time constant (not working) :PROPERTIES: :time_constant: 08:00:00 :END: | month | days | time | |---+--+--| |01 |1 | | |02 |3 | | #+TBLFM: $3=$2*$PROP_time_constant;T Pressing C-u C-c C-c over the table shows in the message buffer: org-table-eval-formula: Wrong type argument: stringp, (13 "Bad format") Also is not possible to debug the code even with the formula debug enabled. Omitting the ";T" part will cause the debug to work and then the string #ERROR show up in the cell. My version is Org-mode version 8.3beta (release_8.3beta-1080-g367d48 @ /home/user/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
Re: [O] Bug: Priority #B in Agenda causes invalid face reference [8.2.1 (8.2.1-15-ge5cecc-elpa @ /Users/Paul/.emacs.d/elpa/org-20131021/)]
I'm using release_8.2.10 and experienced the same problem. The problem seems to be the function org-agenda-fontify-priorities which calls: (org-face-from-face-or-color 'priority nil (cdr (assoc p org-priority-faces))) which expects a face to inherit from. When org-priority-faces is nil or color or even does not specify the priority(e.g. "B") it inherits from nil and causes the message. Setting it to something like (quote ((65 . org-level-1) (66 . org-level-2) (67 . org-level-3) (68 . org-level-4 is a workaround to the problem. Renato
Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
> Hello, > > Detlef Steuer writes: > > > I have two files: > > > > file1.org: > > > > #+LINK: HOME http://example.de > > > > * My Homepage You can find my homepage [[HOME][here]] > > > > #+INCLUDE: file2.org > > > > > > file2.org > > #+LINK: HOME2 http://other.example.de > > > > * My other page > > You can find my other page [[HOME2][here]] > > > > > > I can export file2.org to html as expected. > > > > I can´t export file1.org to html with the included file2.org. > > Only if I move the #+LINK line from file2 to file1 the export > > works as expected. > > > > In my setting file2.org must export standalone, so moving the LINKs > > to file1 is no option. An ugly workaround would be to include the > > abbreviation for HOME2 in both files. Ugly. > > > > Is there a woraround/setting to have local #+LINK directives > > working in included files? > > You can extract out #+LINK: keywords in a file, e.g. "setup.org" and > use #+SETUPFILE: ... in both "file1.org" and "file2.org". OK, but still this is kind of ugly, because the LINKs really are file specific for ,- in the long run -, multiple files. > > You can also use > > #+SETUPFILE: file2.org > > in "file1.org". > The real file2.org is somewhat big and would be scanned completely, wouldn't it? > Set-up (e.g., link abbreviations) is not refreshed after expanding > INCLUDE keywords. I cannot remember why, tho. Maybe for (dubious) > efficiency reasons. > If you don't remember, may be it would be possible to try it out? Would love it and as a feature it looks natural for an included file! Thank you for the hints! Regards Detlef > > Regards, >
[O] Latex export or Latex tangle? Best practice?
In a previous post I was getting at the issue of whether I should just do regular export or use latex "code blocks" for what I wanted in a final document. What I want is the ability to create a big, rambling, annotated org file -- with "keeper" stuff inside the latex babel blocks -- then tangle the .org file, thereby leaving all the annotations and lead-up notes behind. I'm sure I'm not alone in wanting "notes" to evolve into a "finished product" and orgmode would seem to offer a good path. So, I don't want to have to hand-edit out my so-called annotations. Is keeping the good stuff in latex babel blocks a best practice? LB
[O] [BUG?] Blank line required between text and short caption
Hello,
Is it required by org syntax to separate short captions from body text?
In the following example:
* ECM
Some text that introduces this table.
#+CAPTION[Short caption]:
#+CAPTION: Longer caption
| Foo |
Latex export gives:
...
Some text that introduces this table.
\#+CAPTION[Short caption]:
\begin{table}[htb]
\caption{Longer caption}
...
Adding an empty line between the text and short caption produces the
expected results:
* ECM
Some text that introduces this table.
#+CAPTION[Short caption]:
#+CAPTION: Longer caption
| Foo |
...
Some text that introduces this table.
\begin{table}[htb]
\caption[Short caption]{Longer caption}
...
A regular (i.e. non-short) caption works regardless of the empty line:
* ECM
Some text that introduces this table.
#+CAPTION: A caption
| Foo |
Some text that introduces this table.
\begin{table}[htb]
\caption{A caption}
Regards,
Jake
Re: [O] Latex export or Latex tangle? Best practice?
I would use LaTeX code blocks when I need to write something in LaTeX that isn't easy to write in org mode, not to distinguish what is a note and what is part of the draft. For that I recommend comments, e.g., ### Start example ### * Section 1 ** COMMENT Some rough draft notes to myself yadda yadda more badda ** Some stuff that should be exported This is the actual important stuff that should be exported *** More stuff that should be exported yadda yada *** COMMENT More notes and stuff don't export *** Export this one too bla bla ### End example ### When you export the commented sections will be excluded. Best, Ista On Mon, Apr 27, 2015 at 2:12 PM, Lawrence Bottorff wrote: > In a previous post I was getting at the issue of whether I should just do > regular export or use latex "code blocks" for what I wanted in a final > document. What I want is the ability to create a big, rambling, annotated > org file -- with "keeper" stuff inside the latex babel blocks -- then tangle > the .org file, thereby leaving all the annotations and lead-up notes behind. > I'm sure I'm not alone in wanting "notes" to evolve into a "finished > product" and orgmode would seem to offer a good path. So, I don't want to > have to hand-edit out my so-called annotations. Is keeping the good stuff in > latex babel blocks a best practice? > > LB
Re: [O] #+LINK abbrevs possible in #+INCLUDEs ?
Detlef Steuer writes: > The real file2.org is somewhat big and would be scanned completely, > wouldn't it? Only special keywords are parsed. The advantage of SETUPFILE is that it works even outside of export. >> Set-up (e.g., link abbreviations) is not refreshed after expanding >> INCLUDE keywords. I cannot remember why, tho. Maybe for (dubious) >> efficiency reasons. > > If you don't remember, may be it would be possible to try it out? > Would love it and as a feature it looks natural for an included file! I agree. I added this in 2965f8fb0c048a20b52ba90627e7cca6fe706c93. Thank you. Regards,
Re: [O] [BUG?] Blank line required between text and short caption
Hello,
Jacob Gerlach writes:
> Is it required by org syntax to separate short captions from body text?
>
> In the following example:
>
> * ECM
> Some text that introduces this table.
> #+CAPTION[Short caption]:
> #+CAPTION: Longer caption
> | Foo |
>
>
> Latex export gives:
>
> ...
> Some text that introduces this table.
> \#+CAPTION[Short caption]:
> \begin{table}[htb]
> \caption{Longer caption}
> ...
>
No, it is a genuine bug from parser. This should be fixed in
eb77fed33fa0306ebed2224f7895b688320847b2.
Thank you.
Regards,
--
Nicolas Goaziou
[O] [PATCH] TINYCHANGE Allow attaching SVG images by default in exported ODT documents
Hello list.
The patch below changes org-odt-inline-image-rules value, thus
allowing exported ODT documents to include SVG images by default.
From 991f4add7c644902bd6bcd2a5b9eb01e1ea5ade9 Mon Sep 17 00:00:00 2001
From: Vicente Vera Parra
Date: Mon, 27 Apr 2015 18:02:22 -0300
Subject: [PATCH] ox-odt: Allow attaching SVG images by default
* lisp/ox-odt.el (org-odt-inline-image-rules): Modify default rule to
allow including inline SVG images in exported ODT documents.
TINYCHANGE
---
lisp/ox-odt.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index faf0b1c..444c1b7 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -765,7 +765,7 @@ link's path."
:value-type (regexp :tag "Path")))
(defcustom org-odt-inline-image-rules
- '(("file" . "\\.\\(jpeg\\|jpg\\|png\\|gif\\)\\'"))
+ '(("file" . "\\.\\(jpeg\\|jpg\\|png\\|gif\\|svg\\)\\'"))
"Rules characterizing image files that can be inlined into ODT.
A rule consists in an association whose key is the type of link
--
1.9.1
Re: [O] Target and link text normalised to `orgtargetn'
Nicolas Goaziou writes: >> Here's an updated patch. > > Thank you. Some comments follow. Pushed with your recommendations. Thanks. -- May the Force be with you
Re: [O] [bug, org] footnote-action broken with narrowed buffer
Nicolas Goaziou writes: >> Wouldn't it only find definition in the same file? If you use a popup >> indirect buffer narrowed to the footnote-definition in question I don't >> think these problems can exist. In any case, this would seem similar to >> the way ob handles code blocks. > > Good idea. I didn't thought about using "org-src.el", but, albeit not > perfect, it goes a long way towards avoiding these problems. > > I toyed a bit with that. Now C-' on a (non inline) footnote reference > should edit it in a dedicated buffer. > > Feedback welcome. I added this to org.texi. Note, C-c ' will fail in the following example 'cause the fn definition does not have contents-end. I started to try fix this but feel free to beat me to it. I likely will not have time to look more into it until the weekend. foo[fn:1] * Footnotes [fn:1] —Rasmus -- This is the kind of tedious nonsense up with which I will not put
Re: [O] Target and link text normalised to `orgtargetn'
Rasmus writes: > Pushed with your recommendations. Thanks. Thank you. Regards,
Re: [O] [bug, org] footnote-action broken with narrowed buffer
Rasmus writes: > I added this to org.texi. OK. > Note, C-c ' will fail in the following example 'cause the fn definition > does not have contents-end. I started to try fix this but feel free to > beat me to it. I likely will not have time to look more into it until the > weekend. > > foo[fn:1] > * Footnotes > > [fn:1] Fixed. Thank you. Regards,
Re: [O] [PATCH] TINYCHANGE Allow attaching SVG images by default in exported ODT documents
Vicente Vera writes: > The patch below changes org-odt-inline-image-rules value, thus > allowing exported ODT documents to include SVG images by default. I pushed your change. Thanks! Rasmus -- If you can mix business and politics wonderful things can happen!
Re: [O] [bug, org] footnote-action broken with narrowed buffer
Rasmus writes: > Would it make sense to allow this to hook into org-footnote-action? What do you mean by hooking it into `org-footnote-action'? To replace default action with this? This is not possible ATM because it doesn't handle inline footnotes at all (this requires some work in "org-src.el", since `org-src--edit-element' wasn't designed to edit inline objects), and, as you noticed it doesn't allow to create footnotes either (though this one is trivial to fix). Also, jumping to a footnote may still be useful, e.g. with nested footnotes. It is symmetric, too. However, interestingly, if both behaviours become mostly equivalent, we have first-class key bindings to choose from: "C-c C-o", "C-c '", "C-c C-c". > Note that new footnotes currently break the narrow, which is pretty > annoying. I know. This is bad, indeed. Regards,
Re: [O] [bug, org] footnote-action broken with narrowed buffer
Nicolas Goaziou writes: >> Would it make sense to allow this to hook into org-footnote-action? > > What do you mean by hooking it into `org-footnote-action'? To replace > default action with this? To have a defcustom that let you choose preferred method. Whether the default should be changed I don't know. > This is not possible ATM because it doesn't handle inline footnotes at > all (this requires some work in "org-src.el", since > `org-src--edit-element' wasn't designed to edit inline objects), and, There's no need IMO. ATM it moves to the second colon and I don't see other logical ways to handle it. > as you noticed it doesn't allow to create footnotes either (though this > one is trivial to fix). Would be great. > Also, jumping to a footnote may still be useful, e.g. with nested > footnotes. It is symmetric, too. Of course. But in particular when editing it may be useful to have a view like this where you can see both the main text and the fn buffer: || | main | | buf| || | fn buf | || > However, interestingly, if both behaviours become mostly equivalent, we > have first-class key bindings to choose from: "C-c C-o", "C-c '", "C-c > C-c". C-c C-c would then depend on a defcustom, I guess. At least it's a pity if C-c C-c only works in some cases, e.g. "if not narrowed". >> Note that new footnotes currently break the narrow, which is pretty >> annoying. > > I know. This is bad, indeed. OK. Rasmus -- ⠠⠵
Re: [O] Marking/highlighting text temporarily
Hi Eric, I added some functions in the attachment. they colorize the comments, add an org-comment menu to the org-menu, and some functions for pop to and delete comments from the list mode, and a hydra for commands to insert comments. Do you want to get this up on github to facilitate developing it? Eric Abrahamsen writes: > Eric Abrahamsen org-comment.el Description: application/emacs-lisp writes: > >> Vikas Rawal writes: >> >>> On 25-Apr-2015, at 6:22 am, John Kitchin >>> wrote: >>> >>> Inspired by this conversation, I hacked up this functional comment >>> link: >>> >>> >>> http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ >>> >>> >>> It has a custom link type that exports in html and latex, and when >>> you click on it, it asks if you want to delete the comment. >>> >>> Nice. One small issue is that when I highlight a text and add comment >>> to it, and then delete the comment, one space following the last word >>> is removed. >>> >>> Also, it would be good to make the comment stand out in LaTeX (and >>> other) exports, preferably by pushing it to the margin (so it does not >>> move everything else). >> >> Hang on a bit, I'm wasting my afternoon expanding this... > > Okay, this is as far as I got today. I changed some behavior from John's > implementation: when following the links, it seemed like displaying the > comment text would be more useful than deleting it -- I think many of us > have "delete-org-link" functions lying around. I also couldn't get the > add-comment thing to work, as it complained when there was no region, so > I changed how that works. > > Lastly, I spent most of my time learning how tabular list mode works, > and haven't actually tested the export. Will save that for tomorrow. > Otherwise, here's the introduction from the Commentary. Comments and > suggestions very welcome! > > > > Provides a new link type for Org that allows you to create comments > on arbitrary chunks of text. The link prefix is "comment:". > > Add comments with `org-comment-add-comment'. Following the link > will display the text of the comment in a pop-up buffer. The > buffer is in special-mode, hit "q" to dismiss it. > > Call `org-comment-display-comments' to see all comments in a buffer. > > See the `org-comment-[backend]-export-style' options for ways to > format comments in export. > > TODO: > > 1. Better export customization options. > 2. What does the ODT comment XML look like? > 3. More functions in the display comment buffer: copy as > kill... what else? > 4. More functions in the comments list buffer, to display, pop to, > delete, and edit comment text. > 5. Is it possible to have multi-line filled tabular list items? > Long comments are not very useful if you can't see the whole thing. > 5. Allow multiple comment list buffers attached to different Org > buffers. > 6. Maybe a minor mode for ease of manipulating comments? -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: [O] [BUG?] Blank line required between text and short caption
On Mon, Apr 27, 2015 at 4:29 PM, Nicolas Goaziou wrote: > No, it is a genuine bug from parser. This should be fixed in > eb77fed33fa0306ebed2224f7895b688320847b2. Confirmed that it is fixed. Thank you. Regards, Jake
Re: [O] Marking/highlighting text temporarily
John Kitchin writes: > Hi Eric, > > I added some functions in the attachment. they colorize the comments, > add an org-comment menu to the org-menu, and some functions for pop to > and delete comments from the list mode, and a hydra for commands to > insert comments. Do you want to get this up on github to facilitate > developing it? Oh great! Thanks a lot. We are duplicating effort a bit here (but only a bit, I'd also written display/delete functions for the list buffer), so yes, it would be good to coordinate development. I suppose it depends a bit on where this is going to end up: I'm assuming either org/contrib/lisp, or else as an Elpa package. I don't see much difference, except in terms of accessibility to contributors -- I don't have access to the Org repo, but putting it there might get more contributors on balance. As a package only I would have direct access. What do you think? The hydra thing is interesting -- I wasn't aware of that package. Better not to require it unconditionally though, right? Thanks, Eric > Eric Abrahamsen writes: > >> Eric Abrahamsen > > > writes: >> >>> Vikas Rawal writes: >>> On 25-Apr-2015, at 6:22 am, John Kitchin wrote: Inspired by this conversation, I hacked up this functional comment link: http://kitchingroup.cheme.cmu.edu/blog/2015/04/24/Commenting-in-org-files/ It has a custom link type that exports in html and latex, and when you click on it, it asks if you want to delete the comment. Nice. One small issue is that when I highlight a text and add comment to it, and then delete the comment, one space following the last word is removed. Also, it would be good to make the comment stand out in LaTeX (and other) exports, preferably by pushing it to the margin (so it does not move everything else). >>> >>> Hang on a bit, I'm wasting my afternoon expanding this... >> >> Okay, this is as far as I got today. I changed some behavior from John's >> implementation: when following the links, it seemed like displaying the >> comment text would be more useful than deleting it -- I think many of us >> have "delete-org-link" functions lying around. I also couldn't get the >> add-comment thing to work, as it complained when there was no region, so >> I changed how that works. >> >> Lastly, I spent most of my time learning how tabular list mode works, >> and haven't actually tested the export. Will save that for tomorrow. >> Otherwise, here's the introduction from the Commentary. Comments and >> suggestions very welcome! >> >> >> >> Provides a new link type for Org that allows you to create comments >> on arbitrary chunks of text. The link prefix is "comment:". >> >> Add comments with `org-comment-add-comment'. Following the link >> will display the text of the comment in a pop-up buffer. The >> buffer is in special-mode, hit "q" to dismiss it. >> >> Call `org-comment-display-comments' to see all comments in a buffer. >> >> See the `org-comment-[backend]-export-style' options for ways to >> format comments in export. >> >> TODO: >> >> 1. Better export customization options. >> 2. What does the ODT comment XML look like? >> 3. More functions in the display comment buffer: copy as >> kill... what else? >> 4. More functions in the comments list buffer, to display, pop to, >> delete, and edit comment text. >> 5. Is it possible to have multi-line filled tabular list items? >> Long comments are not very useful if you can't see the whole thing. >> 5. Allow multiple comment list buffers attached to different Org >> buffers. >> 6. Maybe a minor mode for ease of manipulating comments? > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu
Re: [O] Latex export or Latex tangle? Best practice?
On Mon, 27 Apr 2015, Lawrence Bottorff wrote: In a previous post I was getting at the issue of whether I should just do regular export or use latex "code blocks" for what I wanted in a final document. What I want is the ability to create a big, rambling, annotated org file -- with "keeper" stuff inside the latex babel blocks -- then tangle the .org file, thereby leaving all the annotations and lead-up notes behind. I'm sure I'm not alone in wanting "notes" to evolve into a "finished product" and orgmode would seem to offer a good path. So, I don't want to have to hand-edit out my so-called annotations. Is keeping the good stuff in latex babel blocks a best practice? LB I sometimes use noweb references for the purpose of having either a concise code block to tangle or a document for export that draws on code blocks elsewhere in the document. From what I see higher in this thread, I recommend that you export a subtree that includes src blocks with noweb refs. Whatever latex boilerplate you need can be :EXPORT_*: properties. see (info "(org) Noweb reference syntax") and the paragraphs at the end of (info "(org) Export settings") HTH, Chuck
Re: [O] Org-lint and #+call lines
Nicolas Goaziou writes: > Nicolas Goaziou writes: > >>> Is org-lint supposed to catch :results output graphics? >> >> It catches >> >> :results output graphic >> >> Is it >> >> :results output graphics > > Nevermind. > > I realized allowed values and combinations are already known to Babel, > so I improved the checker. Org-lint gives this warning: ,-- | 31 low Unknown value "no-export" for header ":eval" `-- But, ob-core.el appears to know the value: , | ob-core.el: (,eval-no-export (and ,export (or (equal ,eval "no-export") ` Is this a false positive? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-latex question
> > [fn:3] aksjd kajshd kahsd
>
> Fixed in 88ea2ced0e38646d393e038bc81d6a0d45b8dcd6. Thank you.
>
>
>
The second and third headings are getting exported as:
\subsection*[Heading 2]{Heading 2\footnote{aksjdlkjaslkjd}}
I do not think the * should be there.
Vikas
Re: [O] org-latex question
> You have num:2, so subsubsections are not TOC'ed, so they don't get > the alternative. If you set it to 3, all should work. > That is what we have been discussing. There are situations where you do not want a headline to appear in TOC, but still want the ALT_TITLE used. It is now possible in org-mode, but there was some bug because of which it did not always work. Nicholas has just fixed it, but, I think, there is still an extra * appearing. Vikas
Re: [O] `org-get-category' and `org-entry-get' do not return the same value
Dear Nicolas, Nicolas Goaziou writes: > Samuel Loury writes: > >> I use the version cd6fa4c15e8e35afa6beb9e89ad3723fb82df091 (git sha) of >> org-mode. >> >> Let's say I have a file looking like this: >> >> #+CATEGORY: c >> * foo >> :PROPERTIES: >> :CATEGORY: a >> :END: >> ** bar >>:PROPERTIES: >>:CREATED: [2015-01-30 Fri 08:37] >>:END: >> >> With the point on bar, `org-get-category' returns "a" while >> (org-entry-get (point) "CATEGORY" t) returns "c". Notice that it returns >> "c" even if the third argument is INHERIT. > > This should be fixed. Thank you. Thank you for taking the time to fix the problem. I just fetched the last version of the sources and realized the CATEGORY handling still strange. The CATEGORY keyword is taken into account only at the upper level in the headline hierarchy. I will illustrate the in the same example as above with a small modification: --8<---cut here---start->8--- #+CATEGORY: c * foo :PROPERTIES: :CATEGORY: a :END: ** bar :PROPERTIES: :CATEGORY: b :END: --8<---cut here---end--->8--- `org-get-category' in the bar headline returns 'a', while I would expect it to return 'b'. I realized that this change was introduced in the following commit: --8<---cut here---start->8--- commit 80bccca4e249cbb5812963863ccffbdcf4b25edd Author: Nicolas Goaziou Date: Tue Mar 31 16:22:10 2015 +0200 Fix `org-refresh-category-properties' * lisp/org.el (org-refresh-category-properties): Ignore false positives when setting category. Also, deprecate old CATEGORY keyword behaviour: new keywords override old ones. --8<---cut here---end--->8--- Most of my work flow with org-mode relies on this old behavior. I searched through the sources, the git history and the mailing list to find out why this behavior was changed but found nothing. I don't understand why one would want to remove this behavior. Does it raise a technical issue? -- Konubinix GPG Key: 7439106A Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A signature.asc Description: PGP signature
