Re: [O] ID property generated by org-mobile
On 2015-03-20T22:45:02+1100, Randomcoder randomcod...@gmail.com said: R Does the ID property have any use? I know I can disable it, but R where R is it being used ? (the ID property that org-mobile generates for R each heading) R Are there any drawbacks to just disabling it with (setq R org-mobile-force-id-on-agenda-items nil) ? R Is it being used somewhere in particular ? i think it might be used for syncing purposes, to uniquely identify items that need to be added, removed etc. Alexis.
Re: [O] Config best practices?
On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote: Yes, but why do you do that? What are you trying to accomplish? What does keeping the configuration in order mean? I have that org-one-to-many utility, which splits the Org file at (selected) headings, effectively making them separate Org files. If I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords in that file, it makes sense to put the same configs in the files split from the main one. Putting them into their own headline may be the simplest way to tell org-one-to-many what to copy to each generated file. I don't like putting them at the top; while #+TITLE or #+AUTHOR do make sense there (and don't in the split files!), cluttering the first few screens with e.g. LaTeX definitions is not my favorite way of using Org-mode. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University
Re: [O] ID property generated by org-mobile
Alexis wrote: On 2015-03-20T22:45:02+1100, Randomcoder randomcod...@gmail.com said: R Does the ID property have any use? I know I can disable it, but R where R is it being used ? (the ID property that org-mobile generates for R each heading) R Are there any drawbacks to just disabling it with (setq R org-mobile-force-id-on-agenda-items nil) ? R Is it being used somewhere in particular ? i think it might be used for syncing purposes, to uniquely identify items that need to be added, removed etc. I also think it serves that purpose. Though, I'm quite sure Orgzly does not rely on such ID; how does it do, then? Best regards, Seb -- Sebastien Vauban
Re: [O] [ox, patch] Keywords what should go in ox?
Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Do you think that you /always/ want pdfkeywords to hold exactly the same contents as what you could put in your document? You as in me: yes most certainly. IIUC, it contradicts your initial post where you wanted, at some later time, to add bells and whistles to keywords displayed in the output (e.g., turning them into links). I'm not very keen on the idea of KEYWORD doing two different things. If that's not the case, I'm fine with it. Do you think that a user who wants to fill pdfkeywords will always want to also add these contents in the body of the document? Which is why the patch provided a switch in #+OPTIONS. The switch is all or nothing. Again, you're talking about two different features : keywords in meta-data and keywords in data. Regards,
Re: [O] Config best practices?
Nick Dokos wrote:
Marcin Borkowski mb...@wmi.amu.edu.pl writes:
On 2015-03-20, at 10:07, Sebastien Vauban sva-n...@mygooglest.com wrote:
Marcin Borkowski wrote:
I'm wondering what people do to keep the configuration of their Org
files in order.
I'm not sure to correctly grasp your objective. Could you restate it?
Sure.
Where do you put things like
#+OPTIONS: toc:nil
or
#+SEQ_TODO: TODO | DONE
or
#+LATEX_HEADER: \newcommand{\eps}{\varepsilon}
?
I use a dedicated top-level headline, with a COMMENT keyword, but
I started to think that a :noexport: tag might be a better idea.
Are there any advantages of one over the other, or other approaches
altogether?
I can tell you they aren't isomorphic... The noexport tag simply says
don't export this subtree. The COMMENT keyword adds don't run any
Babel code block in there.
COMMENT also says that the whole subtree is not to be exported according
to the doc:
(info (org) Comment lines)
Has that changed?
Nope, it hasn't: I wrote that COMMENT *adds* don't run any code to
don't export this subtree either. So, we're both on the same
frequency.
So I guess that – since the lines with options etc. are not exported
anyway – that using a :noexport: tag might be a better idea. Am I right?
The reason I'm asking is that I'm tweaking my org-one-to-many utility
so that it propagates the config to all the generated files.
Still not that clear to me. Maybe an ECM would clarify your request?
As you wish. This is what I usually do.
* Headline
* Another one
** Subheadline
* COMMENT Config
#+LATEX_HEADER: \newcommand{\eps}{\varepsilon}
#+SEQ_TODO: TODO | DONE CANCEL
#+OPTIONS: toc:nil
Yes, but why do you do that? What are you trying to accomplish? What
does keeping the configuration in order mean?
+1
I sometimes use a Setup heading marked with COMMENT, so it does not get
exported. I never put babel stuff in there so I haven't worried about
that, but if Seb is correct that it prevents babel from evaluating
things in the subtree, that's a bonus. If you are just trying to
(mostly) hide it from view, add an :ARCHIVE: tag to the heading.
But most of the time I have them at the top of the file in plain view.
+1.
Sometimes, I also have a Setup section at the top, with a :ARCHIVE:
tag so that it does not expand when cycling view states (via S-TAB).
Best regards,
Seb
--
Sebastien Vauban
[O] bug#18870: bug#18870: \emsp and alignment in org clock report
Leo Ufimtsev lufim...@redhat.com writes: Interesting, I didn't know that. Thank you for pointing it out. Maybe then just go along with the variable that would give people the choice, (I wouldn't mind '\emsp' being the default, so long as it can be changed to something else). Having a variable to choose in which way Org should be broken doesn't sound great to me. The trick could be to use an Org entity which is as large as its overlay. Even better if that entity is readable without that overlay. I'll look into it soon. Regards,
Re: [O] [org-element, FR] make secondary-string midnight compatible
Hello, Rasmus ras...@gmx.us writes: As is evident from the git log, I have made the following mistake at least twice: (org-element-parse-secondary-string nil restrictions) I wish this would just return nil instead of an error. In particular, in ox files you have to do (org-element-parse-secondary-string (or whatever ) restrictions) Which is a bit noisy. Done in bcf6970369e0cbf183ab2b2865fa215d0781e7ab. Regards, -- Nicolas Goaziou
Re: [O] Config best practices?
Marcin Borkowski wrote: On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote: Yes, but why do you do that? What are you trying to accomplish? What does keeping the configuration in order mean? I have that org-one-to-many utility, which splits the Org file at (selected) headings, effectively making them separate Org files. If I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords in that file, it makes sense to put the same configs in the files split from the main one. Putting them into their own headline may be the simplest way to tell org-one-to-many what to copy to each generated file. I don't like putting them at the top; while #+TITLE or #+AUTHOR do make sense there (and don't in the split files!), cluttering the first few screens with e.g. LaTeX definitions is not my favorite way of using Org-mode. As I wrote, you could choose for an ARCHIVE'd heading (one that's always collapsed) or for a SETUPFILE? Best regards, Seb -- Sebastien Vauban
Re: [O] fontenc makes pdf non-searchable
On 21 March 2015, Martin Leduc wrote:
I'm using org-mode to write a paper and export it to a pdf. It compiles just
fine.
However, when opening the experted pdf (with evince or okular) and searching
for a word, the output from the search function is a list of words with
apparently incorrect character encoding.
I get the same result when compiling directly the exported tex file. However,
if I remove the line:
\usepackage[T1]{fontenc}
the compiled pdf becomes correctly interpreted by the search function. According to the
documentation of the org-article latex class, There is no facility to disable
loading fontenc.
That seems odd to me. Can you provide an ECM, a minimal complete example, that
causes this problem?
Bill
--
William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
Re: [O] Embedding diagrams in Org
On 2015-02-18, at 20:37, Andreas Leha andreas.l...@med.uni-goettingen.de
wrote:
I also use tikz in my org files. I just include a slightly more
involved version of Eric's example to show some of the beauty of org.
OK, so I'm trying to understand it. (One of the reasons is that it
doesn't work for me; somehow I couldn't get the svg export for inclusion
in HTML. OTOH, conversion using pdf2svg does work for me (in LaTeX
files), so I want to learn how to utilize it for Org-mode.)
This includes a caption for the diagram, and different output formats
for different export routes.
Best,
Andreas
--8---cut here---start-8---
#+LATEX_HEADER: \usepackage{tikz}
* tikz example
#+name: tikz_example
#+header: :packages '(( tikz))
What does the above line do exactly?
#+header: :file (by-backend (latex example_diagram.tikz) (html
example_diagram.svg) (t example_diagram.png))
The manual says that after :file I can have a string or a list of two
strings. Does the above mean that it is in fact macroexpanded? Do
I get it correctly that the (t example_diagram.png) refers to manual
evaluation and not the evaluation during the export?
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry
800
#+header: :results file raw
#+header: :fit yes
#+begin_src latex
\begin{tikzpicture}
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[-] (a) -- (b);
\end{tikzpicture}
#+end_src
And, last but not least: how exactly the magic of tikz - svg is
supposed to work here? Do I get it correctly that in you example,
Imagemagick handles both png and svg? What if I want to use pdf2svg
instead?
#+caption: A tikz example diagram with a caption
#+results: tikz_example
[[file:example_diagram.png]]
--8---cut here---end---8---
TIA,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University
Re: [O] Config best practices?
Sebastien Vauban sva-n...@mygooglest.com writes: I can tell you they aren't isomorphic... The noexport tag simply says don't export this subtree. The COMMENT keyword adds don't run any Babel code block in there. COMMENT also says that the whole subtree is not to be exported according to the doc: (info (org) Comment lines) Has that changed? Nope, it hasn't: I wrote that COMMENT *adds* don't run any code to don't export this subtree either. So, we're both on the same frequency. Ah, sorry: I misunderstood. -- Nick
Re: [O] Config best practices?
Sebastien Vauban sva-n...@mygooglest.com writes: Marcin Borkowski wrote: On 2015-03-21, at 04:05, Nick Dokos ndo...@gmail.com wrote: Yes, but why do you do that? What are you trying to accomplish? What does keeping the configuration in order mean? I have that org-one-to-many utility, which splits the Org file at (selected) headings, effectively making them separate Org files. If I e.g. use LaTeX macro definitions, or custom (per-file) TODO keywords in that file, it makes sense to put the same configs in the files split from the main one. Putting them into their own headline may be the simplest way to tell org-one-to-many what to copy to each generated file. I don't like putting them at the top; while #+TITLE or #+AUTHOR do make sense there (and don't in the split files!), cluttering the first few screens with e.g. LaTeX definitions is not my favorite way of using Org-mode. As I wrote, you could choose for an ARCHIVE'd heading (one that's always collapsed) or for a SETUPFILE? The SETUPFILE sounds to me like the best solution, assuming that the different files are sharing configuration. -- Nick
[O] To support the :dbport value
Good day, I use the org-mode to take statistical data from remote servers. And founf out that current scheme such this doesn't support a port value: #+name: ALLODS-248601-database #+header: :engine mysql #+header: :dbhost 127.0.0.1 #+header: :dbuser test #+header: :dbpassword test #+header: :database test #+begin_src sql :file /tmp/test.csv SELECT * FROM test; #+end_src I made some changes to the ob-sql.el file and now it supports the :dbport value. I attached the file which include changes, and would like to suggest apply the settings to the future versions. Now it works like this: #+name: ALLODS-248601-database #+header: :engine mysql #+header: :dbhost 127.0.0.1 #+header: :dbport 13306 #+header: :dbuser test #+header: :dbpassword test #+header: :database test #+begin_src sql :file /tmp/test.csv SELECT * FROM test; #+end_src I am a beginner lisp developer and I am not sure that I made correct fix, and would like to ask you to improve this file. -- Denis Mekshun
[O] Fwd: To support the :dbport value
I appologize, send the fixed of-sql.el file Пересылаемое сообщение От кого: Денис Мекшун m...@denismekshun.com Кому: emacs-orgmode@gnu.org Дата: Среда, 18 марта 2015, 18:12 +03:00 Тема: To support the :dbport value Good day, I use the org-mode to take statistical data from remote servers. And founf out that current scheme such this doesn't support a port value: #+name: ALLODS-248601-database #+header: :engine mysql #+header: :dbhost 127.0.0.1 #+header: :dbuser test #+header: :dbpassword test #+header: :database test #+begin_src sql :file /tmp/test.csv SELECT * FROM test; #+end_src I made some changes to the ob-sql.el file and now it supports the :dbport value. I attached the file which include changes, and would like to suggest apply the settings to the future versions. Now it works like this: #+name: ALLODS-248601-database #+header: :engine mysql #+header: :dbhost 127.0.0.1 #+header: :dbport 13306 #+header: :dbuser test #+header: :dbpassword test #+header: :database test #+begin_src sql :file /tmp/test.csv SELECT * FROM test; #+end_src I am a beginner lisp developer and I am not sure that I made correct fix, and would like to ask you to improve this file. -- Denis Mekshun -- ob-sql.el Description: Binary data
[O] Footnotes as links?
I guess this is either a feature request or a discussion point, but is there a good reason that footnotes aren't considered as links for the purposes of things like `org-next-link` (despite being displayed like links)? From where I'm sitting, this would be very useful for the sake of things like ace-links, which allows you to quickly navigate to on-screen links.
Re: [O] fontenc makes pdf non-searchable
Thanks for your response Bill.
You can find a minimal example here, with the org file, and the tex and pdf
files generated from it. Firts try to search within the pdf. It does not work
(at least on my side) To solve the problem, remove the line with
\usepackage[T1]{fontenc}
in the tex file, and compile it. It should now search normally.
Martin
Date: Sat, 21 Mar 2015 12:24:31 -0400
From: w...@pobox.com
To: mart...@hotmail.com
CC: emacs-orgmode@gnu.org
Subject: Re: [O] fontenc makes pdf non-searchable
On 21 March 2015, Martin Leduc wrote:
I'm using org-mode to write a paper and export it to a pdf. It compiles
just fine.
However, when opening the experted pdf (with evince or okular) and
searching for a word, the output from the search function is a list of
words with apparently incorrect character encoding.
I get the same result when compiling directly the exported tex file.
However, if I remove the line:
\usepackage[T1]{fontenc}
the compiled pdf becomes correctly interpreted by the search function.
According to the documentation of the org-article latex class, There is no
facility to disable loading fontenc.
That seems odd to me. Can you provide an ECM, a minimal complete example,
that
causes this problem?
Bill
--
William Denton ↔ Toronto, Canada ↔ https://www.miskatonic.org/
[O] Bug: Missing command description in org-mode manual [8.2.10 (release_8.2.10 @ c:/Users/j.haustedt/AppData/Roaming/.emacs.d/elpa/org-20150119/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
Emacs : GNU Emacs 24.4.1 (i686-pc-mingw32)
of 2014-10-24 on LEG570
Package: Org-mode version 8.2.10 (release_8.2.10 @
c:/Users/j.haustedt/AppData/Roaming/.emacs.d/elpa/org-20150119/)
current state:
==
(setq
org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe)
org-clock-in-resume t
org-clock-out-when-done nil
org-agenda-skip-scheduled-if-done t
org-clock-persist t
org-agenda-window-setup 'current-window
org-tab-first-hook '(org-hide-block-toggle-maybe
org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-hide-inline-tasks
org-cycle-show-empty-lines org-optimize-window-after-visibility-change)
org-agenda-custom-commands '((s SOMEDAY tags someday
((org-agenda-filter-preset (quote (+someday)))
(org-agenda-todo-ignore-with-date nil)))
(z
todo ZKTO)
(f
Agenda and flagged tasks ((tags zkto) (tags flagged) (agenda
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-babel-pre-tangle-hook '(save-buffer)
org-return-follows-link t
org-occur-hook '(org-first-headline-recenter)
org-clock-history-length 35
org-log-done 'time
org-metaup-hook '(org-babel-load-in-session-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-log-into-drawer t
org-agenda-window-frame-fractions '(1.0 . 1.0)
org-columns-default-format %80ITEM(Task) %10Effort(Effort){:} %10CLOCKSUM
org-agenda-span 1
org-agenda-format-date %Y-%m-%d
-
org-refile-use-outline-path 'file
org-clock-auto-clock-resolution nil
org-global-properties '((Effort_ALL . 0:10 0:30 1:00 2:00 3:00 4:00 5:00
6:00 8:00))
org-agenda-fontify-priorities '((65 (:foreground Red)) (66 (:foreground
Blue)) (67 (:foreground Darkgreen)))
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-completion-use-ido t
org-agenda-skip-deadline-if-done t
org-mode-hook '(org-clock-load
#[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-agenda-clockreport-parameter-plist '(:link t :maxlevel 4)
org-clock-into-drawer CLOCK
org-agenda-mode-hook '((lambda nil (hl-line-mode 1)))
org-finalize-agenda-hook '(my-org-agenda-to-appt voice-recordings)
org-from-is-user-regexp nil
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-todo-keywords '((sequence TODO(t) STARTED(s!) WAITING(w@/!) APPT(a)
PROJ(p) DELEGATED(g@/!) | DONE(d!)
ZKTO(z) CANCELED(c@))
)
[O] [patch] ob-latex: htlatex and imagemagick
Hi all,
please find attached a small patch that fixes a problem discussed
in [1].
In short, when executing a latex src block and htlatex is a valid
option, it should be used even if imagemagick is part of the headers.
Regards,
Andreas
[1] http://permalink.gmane.org/gmane.emacs.orgmode/96257
From 2986826441c24e2f0d6cf5efe6bf8aca75c4bdbb Mon Sep 17 00:00:00 2001
From: Andreas Leha andreas.l...@gmx.de
Date: Sat, 21 Mar 2015 22:11:37 +
Subject: [PATCH] ob-latex: htlatex preferred over imagemagick
* ob-latex.el (org-babel-execute:latex): change the order of the handlers
When `imagemagick' is given this entry acts as an else option.
So, it should always come last.
---
lisp/ob-latex.el | 80
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index ba83bf9..2727a2a 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -99,46 +99,6 @@ This function is called by `org-babel-execute-src-block'.
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
(insert body)))
- ((or (string-match \\.pdf$ out-file) imagemagick)
- (with-temp-file tex-file
- (require 'ox-latex)
- (insert
- (org-latex-guess-inputenc
- (org-splice-latex-header
- org-format-latex-header
- (delq
- nil
- (mapcar
- (lambda (el)
- (unless (and (listp el) (string= hyperref (cadr el)))
- el))
- org-latex-default-packages-alist))
- org-latex-packages-alist
- nil))
- (if fit \n\\usepackage[active, tightpage]{preview}\n )
- (if border (format \\setlength{\\PreviewBorder}{%s} border) )
- (if height (concat \n (format \\pdfpageheight %s height)) )
- (if width (concat \n (format \\pdfpagewidth %s width)) )
- (if headers
- (concat \n
- (if (listp headers)
- (mapconcat #'identity headers \n)
- headers) \n)
- )
- (if fit
- (concat \n\\begin{document}\n\\begin{preview}\n body
- \n\\end{preview}\n\\end{document}\n)
- (concat \n\\begin{document}\n body \n\\end{document}\n
- (when (file-exists-p out-file) (delete-file out-file))
- (let ((transient-pdf-file (org-babel-latex-tex-to-pdf tex-file)))
- (cond
- ((string-match \\.pdf$ out-file)
- (rename-file transient-pdf-file out-file))
- (imagemagick
- (org-babel-latex-convert-pdf
- transient-pdf-file out-file im-in-options im-out-options)
- (when (file-exists-p transient-pdf-file)
- (delete-file transient-pdf-file))
((and (or (string-match \\.svg$ out-file)
(string-match \\.html$ out-file))
(executable-find org-babel-latex-htlatex))
@@ -184,6 +144,46 @@ This function is called by `org-babel-execute-src-block'.
.html)
out-file)
(error HTML file produced but SVG file requested)
+ ((or (string-match \\.pdf$ out-file) imagemagick)
+ (with-temp-file tex-file
+ (require 'ox-latex)
+ (insert
+ (org-latex-guess-inputenc
+ (org-splice-latex-header
+ org-format-latex-header
+ (delq
+ nil
+ (mapcar
+ (lambda (el)
+ (unless (and (listp el) (string= hyperref (cadr el)))
+ el))
+ org-latex-default-packages-alist))
+ org-latex-packages-alist
+ nil))
+ (if fit \n\\usepackage[active, tightpage]{preview}\n )
+ (if border (format \\setlength{\\PreviewBorder}{%s} border) )
+ (if height (concat \n (format \\pdfpageheight %s height)) )
+ (if width (concat \n (format \\pdfpagewidth %s width)) )
+ (if headers
+ (concat \n
+ (if (listp headers)
+ (mapconcat #'identity headers \n)
+ headers) \n)
+ )
+ (if fit
+ (concat \n\\begin{document}\n\\begin{preview}\n body
+ \n\\end{preview}\n\\end{document}\n)
+ (concat \n\\begin{document}\n body \n\\end{document}\n
+ (when (file-exists-p out-file) (delete-file out-file))
+ (let ((transient-pdf-file (org-babel-latex-tex-to-pdf tex-file)))
+ (cond
+ ((string-match \\.pdf$ out-file)
+ (rename-file transient-pdf-file out-file))
+ (imagemagick
+ (org-babel-latex-convert-pdf
+ transient-pdf-file out-file im-in-options im-out-options)
+ (when (file-exists-p transient-pdf-file)
+ (delete-file transient-pdf-file))
((string-match \\.\\([^\\.]+\\)$ out-file)
(error Can not create %s files, please specify a .png or .pdf file or try the :imagemagick header argument
(match-string 1 out-file
--
2.1.1
Re: [O] [ox] possible to modify org-export-document-properties OTG
Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr writes: Document properties are keywords where `org-element-context' is allowed to return an object. It doesn't make sense to add random keywords specific to some export back-ends to the list. I think something like SUBJECT in ox-koma-letter makes sense. It seems we are failing to communicate. I have nothing against SUBJECT being parsed in ox-koma-letter. However, `org-element-document-properties' are keywords expected to be parsed in _every_ export back-end. This is not for SUBJECT. At some point, I thought about adding a `parsed' behaviour to `org-export-options-alist' as a shortcut. Presumably you'd want to be able to toggle it for elements of export-options. I mean to use `parsed' at the BEHAVIOR position in `org-export-options-alist' entries. So, obviously, this is triggered per keyword. I don't understand why an export setting would affect an element interpretation such as org-element-map. Probably I have something different in mind than you. If you map over a parse tree, e.g., looking for bold objects, it is a bit tricky to tell `org-element-map' that SUBJECT is no longer a regular keyword but now possibly contains objects. OTOH, we can consider that SUBJECT is still a regular keyword, and that the property the keyword sets (e.g., :koma-letter-subject) contains the objects. In this case, it is no longer ambiguous for `org-element-map' and al., and `parsed' becomes an interesting shortcut. Regards,
Re: [O] Possible bug: Can not search for text in links - only description
On 2015-03-21T01:59:07+1100, Richard Lawrence richard.lawre...@berkeley.edu said: RL I am not sure if this counts as a bug or not, so someone else RL should still address this question. Maybe this is the desired RL behavior, given that the link text is hidden? Or maybe it's just RL not possible to search in hidden text? Cf. the `search-invisible` variable: search-invisible is a variable defined in `isearch.el'. Its value is open Documentation: If t incremental search/query-replace can match hidden text. A nil value means don't match invisible text. When the value is `open', if the text matched is made invisible by an overlay having an `invisible' property and that overlay has a property `isearch-open-invisible', then incremental search will show the contents. (This applies when using `outline.el' and `hideshow.el'.) To temporarily change the value for an active incremental search, use M-s i. Alexis.
Re: [O] [ox] possible to modify org-export-document-properties OTG
Nicolas Goaziou m...@nicolasgoaziou.fr writes: I think something like SUBJECT in ox-koma-letter makes sense. It seems we are failing to communicate. Probably I'm just slower :) I have nothing against SUBJECT being parsed in ox-koma-letter. However, `org-element-document-properties' are keywords expected to be parsed in _every_ export back-end. This is not for SUBJECT. Yep. That was why I asked if it was possible to add it on backend basis. But the oe-parse-secondary-string is fin. Now I know. I mean to use `parsed' at the BEHAVIOR position in `org-export-options-alist' entries. So, obviously, this is triggered per keyword. I /think/ that is what I would like. But I don't understand the what you mean concretely: would you have something like: (:subject SUBJECT nil nil space parsed) I don't understand how it could replace the behavior parameter. Would it be a cons? If you map over a parse tree, e.g., looking for bold objects, it is a bit tricky to tell `org-element-map' that SUBJECT is no longer a regular keyword but now possibly contains objects. OTOH, we can consider that SUBJECT is still a regular keyword, and that the property the keyword sets (e.g., :koma-letter-subject) contains the objects. In this case, it is no longer ambiguous for `org-element-map' and al., and `parsed' becomes an interesting shortcut. I agree this is a difficult problem. Personally, I think it is fine to consider a keyword as a keyword and nothing more, and not consider content within a keyword. However, as I recall, John had a post a while back about mapping over bold in CAPTIONS or something like that. I think it may be a mess to interpret content of a keyword at org-element-map level. Consider if #+SUBJECT is interpreted with in ox-koma-letter but not in an imaginary ox-new-letter. Would it not be confusing? —Rasmus -- Dung makes an excellent fertilizer
Re: [O] Embedding diagrams in Org
Hi Marcin,
see some inline comments. Note, that I have not done much research
on this and all my information may be outdated
Marcin Borkowski mb...@wmi.amu.edu.pl writes:
On 2015-02-18, at 20:37, Andreas Leha andreas.l...@med.uni-goettingen.de
wrote:
I also use tikz in my org files. I just include a slightly more
involved version of Eric's example to show some of the beauty of org.
OK, so I'm trying to understand it. (One of the reasons is that it
doesn't work for me; somehow I couldn't get the svg export for inclusion
in HTML. OTOH, conversion using pdf2svg does work for me (in LaTeX
files), so I want to learn how to utilize it for Org-mode.)
This includes a caption for the diagram, and different output formats
for different export routes.
Best,
Andreas
--8---cut here---start-8---
#+LATEX_HEADER: \usepackage{tikz}
* tikz example
#+name: tikz_example
#+header: :packages '(( tikz))
What does the above line do exactly?
This will ensure, that the produced latex file for the diagram loads
tikz. I could not find that documented, so maybe that should be
replaced by ':headers '(\\usepackage{tikz})'. In my first tests it
now seems unnecessary, maybe due to a change in the semantics of
LATEX_HEADER when LATEX_HEADER_EXTRA was introduced.
So, I guess you can omit that altogether.
#+header: :file (by-backend (latex example_diagram.tikz) (html
example_diagram.svg) (t example_diagram.png))
The manual says that after :file I can have a string or a list of two
strings. Does the above mean that it is in fact macroexpanded?
The argument of any header option can be replaced by an elisp form
(which then in this case should return a string or a list of two
strings).
Do
I get it correctly that the (t example_diagram.png) refers to manual
evaluation and not the evaluation during the export?
Yes. I use that to be able to see the diagram within the org document.
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry
800
#+header: :results file raw
#+header: :fit yes
#+begin_src latex
\begin{tikzpicture}
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[-] (a) -- (b);
\end{tikzpicture}
#+end_src
And, last but not least: how exactly the magic of tikz - svg is
supposed to work here? Do I get it correctly that in you example,
Imagemagick handles both png and svg?
Yes, imagemagick does both here. And there is a bug in imagemagick up
to 6.9 producing corrupt svg [1]. I guess that is hitting you. Try
upgrading your imagemagick.
What if I want to use pdf2svg
instead?
I do not think that this is possible right now.
BUT:
You can use htlatex.
If you look at worg [2], you'll find an example demonstrating that.
It mainly requires setting
'(setq org-babel-latex-htlatex htlatex)'.
I think that possibility might make pdf2svg unnecessary.
BUT 2:
This won't have an effect on the example in this thread.
I consider it a bug that the example I gave in this thread tries to run
imagemagick for the svg even if that variable is set to htlatex. I'll
file a bug report in a separate thread.
#+caption: A tikz example diagram with a caption
#+results: tikz_example
[[file:example_diagram.png]]
--8---cut here---end---8---
TIA,
HTH,
Andreas
Footnotes:
[1] http://www.imagemagick.org/discourse-server/viewtopic.php?t=27009
[2]
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3
Re: [O] Possible bug: Can not search for text in links - only description
On Sat, Mar 21, 2015 at 7:34 PM, Alexis flexibe...@gmail.com wrote: On 2015-03-21T01:59:07+1100, Richard Lawrence richard.lawre...@berkeley.edu said: RL I am not sure if this counts as a bug or not, so someone else RL should still address this question. Maybe this is the desired RL behavior, given that the link text is hidden? Or maybe it's just RL not possible to search in hidden text? Cf. the `search-invisible` variable: `search-invisible' is less helpful that one might think. I think that the difficulty arises from the fact that links use the invisibility text property. Folded trees, OTOH, use an invisibility overlay. Overlay invisibility is searched (and expanded for matches) when `search-invisible' is set to `open' (the default). While you can /search/ invisible text, AFAICT, isearch has no machinery to /show/ invisible text (just to open invisibility overlays). You can set `search-invisible' to `t', but then your search is likely to end up on the ellipses for a folded subtree (since it will no longer unfold). With `search-invisible' set to `t', point does end up on (still invisible) matches. I tried cobbling together a hack like: (add-hook 'isearch-update-post-hook (lambda () (if isearch-hidden (org-remove-from-invisibility-spec '(org-link)) (add-to-invisibility-spec '(org-link) (defun jg/isearch () (interactive) (let ((search-invisible t)) (isearch-forward))) But besides not opening overlays, I think you'd need a similar function on a couple more isearch hooks to make this work. On Fri, Mar 20, 2015 at 2:06 PM, Charles C. Berry ccbe...@ucsd.edu wrote: You *can* search in links without changing modes. menu-bar edit search search-forward Exa RET runs nonincremental-search-forward on Exa and finds Rainier's `*Example' if point preceeds it. search-forward suffers from the same problem as setting `search-invisible' to `t' - folded subtrees don't open. I suppose you could expand the whole tree first and then use it. M-x occur RET Exa RET This worked well for me. On Sat, Mar 21, 2015 at 7:45 PM, Randomcoder randomcod...@gmail.com wrote: In terms of searching through all open buffers, here is what I use (helm and helm-multi-occur): Can you comment on the capability to search invisible text (such as the invisible path for an org link)? For the problem at hand, there's no need to search multiple buffers, just to search the invisible text in a given buffer. For the (hopefully) infrequent case of finding a mistyped link, `org-toggle-link-display' or M-x occur should be adequate.
Re: [O] Possible bug: Can not search for text in links - only description
Hi Rainer, In terms of searching through all open buffers, here is what I use (helm and helm-multi-occur): , | (setq helm-M-x-requires-pattern 0) | | ;; http://emacs.stackexchange.com/a/740 | (require 'helm-regexp) | (eval-after-load helm-regexp | '(setq helm-source-moccur | (helm-make-source Moccur 'helm-source-multi-occur :follow 1))) | (defun my-helm-multi-occur-buffers () | multi-occur in all buffers backed by files. | (interactive) | (helm-multi-occur |(delq nil | (mapcar (lambda (b) |(when (buffer-file-name b) (buffer-name b))) | (buffer-list) | (global-set-key (kbd C-x C-p) (lambda () | (interactive) | (helm-mode 1) | (my-helm-multi-occur-buffers) | (helm-mode 0) | )) ` There are other solutions to this such as org-velocity: - http://orgmode.org/worg/org-contrib/org-velocity.html - https://github.com/Fuco1/org-velocity Both helm + helm-multi-occur and org-velocity offer auto-complete search functionality. Best regards On Fri, Mar 20, 2015 at 02:44:29PM +0100, Rainer M Krug wrote: Hi I got an error as follow when I tried to export: , | org-babel-exp process R at line 5495... | Evaluation of this R code-block is disabled. | user-error: Unable to resolve link *uLELFit ` I thought OK - I'll search for uLELFit and just fix this link - but I could do what I wanted, I did not manage to find the link. I figured out that I can not search for text in the link. Thins is quite annoying, especially as I even thought of opening the file in another texteditor, search for the string, and save it again. As an example: if this link is in an org-mode file, A search for exa does not return any results. [[*Examples][Link to exp]] Is this a problem on my side? , | Org-mode version 8.3beta (release_8.3beta-927-ge0b19d @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) | GNU Emacs 24.4.1 (x86_64-apple-darwin14.0.0, Carbon Version 157 AppKit 1343.16) of 2015-02-02 on Rainers-MacBook-Pro-4.local ` Thanks, Rainer -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982
Re: [O] [ox] possible to modify org-export-document-properties OTG
Rasmus ras...@gmx.us writes: I /think/ that is what I would like. But I don't understand the what you mean concretely: would you have something like: (:subject SUBJECT nil nil space parsed) (:subject SUBJECT nil nil parsed) `parsed' behavior implies `space' anyway, since we're talking about secondary strings. Basically, (plist-get info :subject) would return the same as the following, currently, (org-element-parse-secondary-string (plist-get info :subject) (org-element-restriction 'keyword)) I agree this is a difficult problem. Personally, I think it is fine to consider a keyword as a keyword and nothing more, and not consider content within a keyword. However, as I recall, John had a post a while back about mapping over bold in CAPTIONS or something like that. `org-element-map' can find objects in captions, with an optional argument. I think it may be a mess to interpret content of a keyword at org-element-map level. Consider if #+SUBJECT is interpreted with in ox-koma-letter but not in an imaginary ox-new-letter. Would it not be confusing? I think so. Regards,
Re: [O] [ox] possible to modify org-export-document-properties OTG
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rasmus ras...@gmx.us writes: I /think/ that is what I would like. But I don't understand the what you mean concretely: would you have something like: (:subject SUBJECT nil nil space parsed) (:subject SUBJECT nil nil parsed) `parsed' behavior implies `space' anyway, since we're talking about secondary strings. Is that always the case? I guess.. I agree this is a difficult problem. Personally, I think it is fine to consider a keyword as a keyword and nothing more, and not consider content within a keyword. However, as I recall, John had a post a while back about mapping over bold in CAPTIONS or something like that. `org-element-map' can find objects in captions, with an optional argument. If turns out to be important, perhaps it would also be possible to map keyword objects with an non-default argument. -- Don't panic!!!
