Re: [O] Bug: Weird interaction between ox-extra and include :minlevel
I was thinking of #+ignore_tags. as an analog of #+exclude_tags. While #+exclude_tags removes a complete subtree from export, #+ignore_tags would only ignore headlines and insert the contents. When used in combination, subtree would be excluded no matter what. #+IGNORE_TAGS: ignore bar #+EXLUDE_TAGS: noexport foo The idea of ignore_tags, for me, would to allow grouping content within the Org file in a manner that differs from the grouping of content upon export - without having to resort to filter-hooks. Not that hooks are bad, but they are harder to construct without proper elisp skills and require knowledge about the Org API. Furthermore, tags are excellent because they're easy to manipulate and search for. On Thu, Apr 12, 2018 at 3:28 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > "Daniel P. Gomez" <gomez.d...@gmail.com> writes: > >> Is there any intention of bringing ox-extra functionality into main >> Org? Something like #+ignore_tags would be a powerful addition for >> fine grained export control, in my opinion. > > IIRC, "ox-extra" was written because we could not agree on a definition > and an implementation of the ignore headline feature. > > I don't know what you do mean by "something like #+ignore_tags", but you > could discuss it on this ML. > > Regards, > > -- > Nicolas Goaziou
[O] Bug: Weird interaction between ox-extra and include :minlevel
Hi all,
TLDR: Using ox-extras :IGNORE: tags break #+INCLUDE :minlevel.
Ideally ox-extras functionality could make it into ox.
I'm using Org Mode to structure my thesis, and one of the Org
features that I rely on the most are the #+INCLUDE derivatives.
My setup is such that I have a main thesis.org file with the
(simplified) following contents:
--
#+latexclass: thesis
#+setupfile: thesis.setup
#+exclude_tags: manuscript noexport
* Chapter 1
#+INCLUDE: chap1/chapter1.org :lines "3-"
etc..
--
And I have chapter files where, e.g., the Methods section is
formatted differently whether it is included in the main body of
the thesis or in a manuscript:
--
#+latexclass: manuscript
#+setupfile: manuscript.setup
#+exclude_tags: thesis noexport
etc..
# For thesis, include methods directly
* Methods :thesis:
#+INCLUDE: methods.org :lines "3-"
# For paper, wrap methods into a specific control sequence and
adjust headline levels.
* Methods :ignore:manuscript:
#+LATEX: \matmethods{
#+INCLUDE: methods.org :lines "3-" :minlevel 2
#+LATEX: }
* Insert Methods :ignore:manuscript:
#+LATEX: \showmatmethods{}
--
I don't know if this is the cleanest setup, but it works well for
me because I get to reuse my files.
The one issue I have with this setup, is that besides relying on
IGNORE tags, I also rely on :minlevel to adjust the headlines.
However, because ox-extra promotes all subtrees, it breaks
minlevel's functionality.
Would anyone have an idea on how to fix this? Is there any
intention of bringing ox-extra functionality into main Org?
Something like #+ignore_tags would be a powerful addition for fine
grained export control, in my opinion.
Thank you
--
Daniel P. Gomez
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
@@ +* Links +File link with description +[[file:setupfile2.org][A setupfile]] + +File link pointing to a specific header +[[file:../normal.org::top]] + +Bracketed file link without description +[[file:setupfile.org]] + +Plain file link +file:setupfile.org -- 2.16.2 Nicolas Goaziou writes: Hello, Daniel P Gomez <gomez.d...@gmail.com> writes: I noticed that (buffer-file-name (buffer-base-buffer)) will always return nil because `org-export--prepare-file-contents` is called in `org-export-include-keyword` after a call to `with-temp-buffer`. Two possible solutions to this issue would be either 1. passing the includer-file as an extra parameter to `org-export--prepare-file-contents` and then using `file-relative-name` to generate a relative path, or alternatively 2 . passing the matched string that points to the file to be included. Example: #+INCLUDE: "directory/file.org" Here, if file.org contains a link [[other/image.png]], then all one has to do is append the (file-name-directory matched) to the old-path. In this example this would result in directory/other/image.png. This second solution does not require a call to (buffer-file-name (buffer-base-buffer)), but seems hackish in the sense that we would pass 2 redundant arguments to `org-export-prepare-file-contents`: both the expanded and the non-expanded include-file filename. Perhaps I'm missing a simpler 3rd solution? I think solution 1 is fine. If we opt for solution 1 then new-path could be made relative here ;; (org-element-put-property new :path new-path) (org-element-put-property new :path (if includer-file (file-relative-name new-path (file-name-directory includer-file)) new-path)) Indeed. However, the (if includer-file ...) should be integrated in new-path binding, IMO. I will attempt to write them once the implementation is completed. Great. Thank you! Regards, -- Daniel P. Gomez
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Hi, > `org-export--prepare-file-contents' is called from the including > document, so you can get its path with (buffer-file-name > (buffer-base-buffer)). > > However, we need to handle the case where the including buffer is not > associated to a file, i.e., the Sexp above returns nil. > I noticed that (buffer-file-name (buffer-base-buffer)) will always return nil because `org-export--prepare-file-contents` is called in `org-export-include-keyword` after a call to `with-temp-buffer`. Two possible solutions to this issue would be either 1. passing the includer-file as an extra parameter to `org-export--prepare-file-contents` and then using `file-relative-name` to generate a relative path, or alternatively 2 . passing the matched string that points to the file to be included. Example: #+INCLUDE: "directory/file.org" Here, if file.org contains a link [[other/image.png]], then all one has to do is append the (file-name-directory matched) to the old-path. In this example this would result in directory/other/image.png. This second solution does not require a call to (buffer-file-name (buffer-base-buffer)), but seems hackish in the sense that we would pass 2 redundant arguments to `org-export-prepare-file-contents`: both the expanded and the non-expanded include-file filename. Perhaps I'm missing a simpler 3rd solution? > It would be nice to add a comment explaining what we are going to do. > Of course. ;; Adapt all file links within the included document that ;; contain relative paths in order to make these paths ;; relative to the base document, or absolute > I suggest the following inner part: > > (when (string= "file" (org-element-property :type link)) > (let* ((old-path (org-element-property :path link)) > (new-path (expand-file-name old-path (file-name-directory > file I noticed that the call to delete here will break `org-element-adopt-elements` later on since the real buffer positions will be changed and we are still querying for old, invalid positions stored in link. > ;; (delete-region (org-element-property :begin link) > ;; (org-element-property :end link)) > (insert (let ((new (org-element-copy link))) If we opt for solution 1 then new-path could be made relative here > ;; (org-element-put-property new :path new-path) (org-element-put-property new :path (if includer-file (file-relative-name new-path (file-name-directory includer-file)) new-path)) > (when (org-element-property :contents-begin link) > (org-element-adopt-elements new > (buffer-substring (org-element-property :contents-begin > link) > (org-element-property :contents-end > link Deleting immediately before the insertion works. (delete-region (org-element-property :begin link) (org-element-property :end link)) > (org-element-interpret-data new) > > Also, would you mind adding a test in "text-ox.el", within > `test-org-export/expand-include'? I will attempt to write them once the implementation is completed. Thanks for the support. Regards, Daniel > Regards, > > -- > Nicolas Goaziou
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
I've adapted the code such that it handles both bracketed and unbracketed links, and links with descriptions. As it is now, the changes are always automatically applied. > Also, rewriting needs not be always absolute path, if both directories > share a common root. I couldn't find a simple way of rewriting links without making them absolute, as `org-export--prepare-file-contents` does not have access to the path of the including file, only of the included file. On Thu, Mar 1, 2018 at 11:42 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Daniel P Gomez <gomez.d...@gmail.com> writes: > >> Currently when passing the :absolute-paths toggle to an include >> derivative, as in : >> >> #+INCLUDE: file.org :absolute-paths t >> >> The function `org-export--prepare-file-contents` will automatically >> deduce the directory from file.org and adapt links by calling: >> `(new-path (expand-file-name old-path (file-name-directory file)))`. >> I could either make this a default option, such that links get >> corrected but users can overwrite this by calling `:absolute-paths >> nil`, or I could completely remove this toggle and always correct >> links no matter what. > > I am wondering about the latter. If there is no reason to keep broken > file names, it makes sense to automatically apply it. > > Also, rewriting needs not be always absolute path, if both directories > share a common root. > >> One question regarding the implementation, currently I'm deleting the >> link with a call to `delete-region` and using `(insert "[[file:" >> new-path "]]")` to insert the corrected one. This does not take into >> consideration whether links are bracketed or not ( is there a >> functional difference if links are not bracketed?). > > Yes. White spaces are handled differently in each link type. > >> Also, my approach completely disregards link descriptions, which may >> be relevant if the linked file would be, for example, an html >> document. Would there be a cleaner org approach to replace the path >> keeping the description? > > You could check :contents-begin and :contents-end for the link. If they > are not nil, extract this region, and insert it again in the new link. > > Regards, > > -- > Nicolas Goaziou0x80A93738 0001-Fix-file-links-when-using-INCLUDE.patch Description: Binary data
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Currently when passing the :absolute-paths toggle to an include derivative, as in : #+INCLUDE: file.org :absolute-paths t The function `org-export--prepare-file-contents` will automatically deduce the directory from file.org and adapt links by calling: `(new-path (expand-file-name old-path (file-name-directory file)))`. I could either make this a default option, such that links get corrected but users can overwrite this by calling `:absolute-paths nil`, or I could completely remove this toggle and always correct links no matter what. One question regarding the implementation, currently I'm deleting the link with a call to `delete-region` and using `(insert "[[file:" new-path "]]")` to insert the corrected one. This does not take into consideration whether links are bracketed or not ( is there a functional difference if links are not bracketed?). Also, my approach completely disregards link descriptions, which may be relevant if the linked file would be, for example, an html document. Would there be a cleaner org approach to replace the path keeping the description? Thank you. Regards, Daniel On Thu, Mar 1, 2018 at 7:32 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Daniel P Gomez <gomez.d...@gmail.com> writes: > >> If there is any interest, I've created a patch adding support for a >> :absolute-paths functionality. >> As I said, I don't have much experience writing Elisp, so any >> suggestions on how to improve the code would be appreciated. If there >> is any interest in adding this feature to Org I could try to clean it >> up. > > Thank you. > > Would it make sense to automatically deduce this directory from included > file and apply this automatically? > > Regards, > > -- > Nicolas Goaziou
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
If there is any interest, I've created a patch adding support for a :absolute-paths functionality. As I said, I don't have much experience writing Elisp, so any suggestions on how to improve the code would be appreciated. If there is any interest in adding this feature to Org I could try to clean it up. Patch attached. On Wed, Feb 28, 2018 at 9:11 PM, Daniel P Gomez <gomez.d...@gmail.com> wrote: > Sorry for the ignorance, but where could I look up how to use a parse > tree filter? And where would these modifications make sense? > Any pointers towards documentation, functions, or any help of any kind > would be appreciated. I must say I am a bit lost. > > Thank you in advance, > > Daniel > > On Wed, Feb 28, 2018 at 6:51 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> > wrote: >> Hello, >> >> Daniel P Gomez <gomez.d...@gmail.com> writes: >> >>> If I include a file child.org in parent.org using the #+INCLUDE >>> derivative, and the following two conditions are true: >>> >>> 1. child.org and parent.org are not in the same directory nor share >>> directory structure, >>> 2. child.org contains file links with relative file paths, >>> >>> then exporting parent.org will produce a file with broken links. >>> >>> Is there a way to have org sort this out? >>> >>> Or even make this optional, >>> say by using: >>> >>> #+INCLUDE: child.org :fix-paths t >>> >>> I guess the quickest (but perhaps not cleanest) way to have this >>> feature would be to convert relative paths in file links into absolute >>> paths within `org-export-expand-include-keyword`. I'm not that well >>> versed in Elisp yet to do this yet, though. >>> >>> Are there any known solutions to this, or suggestions on how to get it >>> working? >> >> As you suggest, I would use a parse tree filter that turns every >> relative file link into an absolute one. >> >> Regards, >> >> -- >> Nicolas Goaziou 0001-Add-support-for-absolute-paths-in-INCLUDE-derivative.patch Description: Binary data
Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?
Sorry for the ignorance, but where could I look up how to use a parse tree filter? And where would these modifications make sense? Any pointers towards documentation, functions, or any help of any kind would be appreciated. I must say I am a bit lost. Thank you in advance, Daniel On Wed, Feb 28, 2018 at 6:51 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote: > Hello, > > Daniel P Gomez <gomez.d...@gmail.com> writes: > >> If I include a file child.org in parent.org using the #+INCLUDE >> derivative, and the following two conditions are true: >> >> 1. child.org and parent.org are not in the same directory nor share >> directory structure, >> 2. child.org contains file links with relative file paths, >> >> then exporting parent.org will produce a file with broken links. >> >> Is there a way to have org sort this out? >> >> Or even make this optional, >> say by using: >> >> #+INCLUDE: child.org :fix-paths t >> >> I guess the quickest (but perhaps not cleanest) way to have this >> feature would be to convert relative paths in file links into absolute >> paths within `org-export-expand-include-keyword`. I'm not that well >> versed in Elisp yet to do this yet, though. >> >> Are there any known solutions to this, or suggestions on how to get it >> working? > > As you suggest, I would use a parse tree filter that turns every > relative file link into an absolute one. > > Regards, > > -- > Nicolas Goaziou
[O] How to keep correct filepaths when using the #+INCLUDE derivative?
Dear org users, If I include a file child.org in parent.org using the #+INCLUDE derivative, and the following two conditions are true: 1. child.org and parent.org are not in the same directory nor share directory structure, 2. child.org contains file links with relative file paths, then exporting parent.org will produce a file with broken links. Is there a way to have org sort this out? Or even make this optional, say by using: #+INCLUDE: child.org :fix-paths t I guess the quickest (but perhaps not cleanest) way to have this feature would be to convert relative paths in file links into absolute paths within `org-export-expand-include-keyword`. I'm not that well versed in Elisp yet to do this yet, though. Are there any known solutions to this, or suggestions on how to get it working? Thanks in advance, Daniel
Re: [O] Have SRC_BLOCK :padline accept numbers
Dear Nicolas, Thanks for the constructive feedback. I've amended the commit including the changes you've mentioned. I did not change the following, though: (numberp (string-to-int padlines)) -> (string-match-p "\\`[0-9]+\\'" padlines) because that changed the behaviour of org-babel-tangle. Having a string-match-p as a match condition broke the default of adding no padlines in the first tangled SRC block (when passed with no arguments). I also noticed that adding this functionality to ob-tangle breaks eldoc for me. I guess all org babel header arguments have to be strings? Debugger entered--Lisp error: (wrong-type-argument stringp 2) ((:padline . 2)) ((:results . "replace output") (:exports . "both") (:padline . 2) (:eval . "never-export") (:tangle . "no") (:hlines . "no") (:noweb . "no") (:cache . "no") (:session . "none")) " ") org-eldoc-get-src-header() org-eldoc-documentation-function() eldoc-print-current-symbol-info() GNU Emacs 25.2.1 (x86_64-apple-darwin16.4.0, NS appkit-1504.81 Version 10.12.3 (Build 16D32)) of 2017-03-22 Copyright (C) 2017 Free Software Foundation, Inc. Yours, Daniel Nicolas Goaziou writes: > Hello, > > Daniel P Gomez <gomez.d...@gmail.com> writes: > >> I've written a small patch (attached here), following the contribution >> guidelines on the org-mode website. The "patched" repository can be found >> here: https://github.com/dangom/org-mode/tree/feature_padline > > Thank you. > >> Please let me know if there is anything else I should do. > > Some comments follow. > >> From f5e67856b6cefb7c5e9c1b6bd74321d3b47f1b05 Mon Sep 17 00:00:00 2001 >> From: Daniel Gomez <d.go...@posteo.org> >> Date: Tue, 28 Mar 2017 21:20:23 +0200 >> Subject: [PATCH] Add support for :padline with numbers in ob-tangle. >> > You need to add list modified functions here, with the actual > modifiaction, e.g., > > * lisp/ob-tangle.el (the-function-I-modified): Been there, done that. > > Also, if you haven't signed FSF papers yet, you need to add "TINYCHANGE" > at the end of the commit message. > >> -(unless (or (string= "no" (cdr (assq :padline (nth 4 spec >> - (= (point) (point-min))) >> - (insert "\n")) >> +(let ((padlines (format "%s" (cdr (assq :padline (nth 4 spec)) >> + (cond >> + ((and (string= "nil" padlines) (not (= (point) (point-min > > (not (= (point) (point-min))) -> (not (bobp)) > >> + (insert "\n")) >> + ((string= "no" padlines) >> + nil) >> + ((numberp (string-to-int padlines)) > > (numberp (string-to-int padlines)) -> (string-match-p "\\`[0-9]+\\'" padlines) > >> + (dotimes (i (string-to-int padlines)) (insert "\n"))) > > string-to-int -> string-to-number > > > Regards, -- Daniel P. Gomez
[O] Have SRC_BLOCK :padline accept numbers
A use case is tangling python source code snippets containing class definitions. ( http://emacs.stackexchange.com/questions/31738/org-mode-babel-ensure-two-empty-lines-between-tangled-code-blocks-for-python ) Per PEP8, the use of blank lines stipulates: "Surround top-level function and class definitions with two blank lines." To achieve two blank lines before a class definition, one would have to set :padline 2. I've written a small patch (attached here), following the contribution guidelines on the org-mode website. The "patched" repository can be found here: https://github.com/dangom/org-mode/tree/feature_padline Please let me know if there is anything else I should do. Thanks, Daniel 0001-Add-support-for-padline-with-numbers-in-ob-tangle.patch Description: Binary data
Re: [O] Emacs freeze after selecting a capture template
That solved the problem... I had (global-linum-mode 1) on my init.el, and that conflicts with org-capture somehow. I've changed it to (add-hook 'prog-mode-hook 'linum-mode) and the issue was gone. Thanks for the feedback Daniel On Thu, Nov 26, 2015 at 10:21 AM, Eric S Fraga <e.fr...@ucl.ac.uk> wrote: > On Wednesday, 25 Nov 2015 at 23:49, Daniel P Gomez wrote: > > Hi all, > > > > I'm new to Emacs and org-mode. I've tried to set up a simple TODO list by > > calling org-capture and when I select my [t] todo item on *Org Select*, > > Emacs freezes and I need to kill its process. > > > > On the mini-buffer I can read the following error message: > > > > Clipboard pasted as level 2 subtree > > Error in post-command-hook (linum-update-current): args-out-of-range 1 1) > > Maybe turn off linum-mode and see if things work. I know that linum > mode does cause problems with some modes... > -- > : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.2-338-g522ec9 >
[O] Emacs freeze after selecting a capture template
Hi all,
I'm new to Emacs and org-mode. I've tried to set up a simple TODO list by
calling org-capture and when I select my [t] todo item on *Org Select*,
Emacs freezes and I need to kill its process.
On the mini-buffer I can read the following error message:
Clipboard pasted as level 2 subtree
Error in post-command-hook (linum-update-current): args-out-of-range 1 1)
I've updated all packages to the latest version, and reinstalled the latest
Emacs 25, but the error persisted. Does anyone have an idea where this
might be coming from? Am I overseeing something very simple?
Thanks a lot.
Bests,
Daniel
on init.el:
(setq org-capture-templates
'(("t" "todo" entry (file+headline "/Users/dgomez/todo.org" "Tasks")
"* TODO [#A] %?")))
GNU Emacs 25.0.50.1 (x86_64-apple-darwin15.0.0, NS appkit-1404.13 Version
10.11.1 (Build 15B42)) of 2015-11-25
