Re: [O] [ox] possible to modify org-export-document-properties OTG
Nicolas Goaziou writes: > Rasmus 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!!!
Re: [O] [ox] possible to modify org-export-document-properties OTG
Rasmus 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] Possible bug: Can not search for text in links - only description
On Sat, Mar 21, 2015 at 7:34 PM, Alexis wrote: > > On 2015-03-21T01:59:07+1100, Richard Lawrence > 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 wrote: > You *can* search in links without changing modes. > > 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 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] [ox] possible to modify org-export-document-properties OTG
Nicolas Goaziou 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] 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: Rainerkrugsde > PGP: 0x0F52F982
Re: [O] Possible bug: Can not search for text in links - only description
On 2015-03-21T01:59:07+1100, Richard Lawrence 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
Rasmus writes: > Nicolas Goaziou 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,
[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 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] 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 writes: > On 2015-02-18, at 20:37, Andreas Leha > 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
[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.
[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 Пересылаемое сообщение От кого: Денис Мекшун Кому: 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] 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@)")
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/
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] Config best practices?
Sebastien Vauban writes: > Marcin Borkowski wrote: >> On 2015-03-21, at 04:05, Nick Dokos 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
Re: [O] Config best practices?
Sebastien Vauban 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] Embedding diagrams in Org
On 2015-02-18, at 20:37, Andreas Leha 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?
Marcin Borkowski wrote: > On 2015-03-21, at 04:05, Nick Dokos 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] Config best practices?
On 2015-03-21, at 04:05, Nick Dokos 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
[O] bug#18870: bug#18870: \emsp and alignment in org clock report
Leo Ufimtsev 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] ID property generated by org-mobile
Alexis wrote: > On 2015-03-20T22:45:02+1100, Randomcoder 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 writes: > Nicolas Goaziou 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] ID property generated by org-mobile
On 2015-03-20T22:45:02+1100, Randomcoder 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] [org-element, FR] make secondary-string midnight compatible
Hello, Rasmus 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?
Nick Dokos wrote: > Marcin Borkowski writes: >> On 2015-03-20, at 10:07, Sebastien Vauban 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