Re: [O] Exporting each subtree, including the headline?
Hi again, Just for the record, I figured out the solution to this. I had to modify the function to run org-mark-subtree on each element before calling the export function - this way, the whole selected region is exported, including the headline. If anyone is interested, you can see my final leanpub-export function here: https://github.com/zzamboni/dot-emacs/blob/master/init.org#publishing-to-leanpub Best, --Diego On Mon, Oct 15, 2018 at 8:20 PM Diego Zamboni wrote: > Hi, > > I am working on publishing a book using LeanPub ( > https://leanpub.com/learning-hammerspoon/), produced from an Org source > file. I am trying to use the code from > https://medium.com/@lakshminp/publishing-a-book-using-org-mode-9e817a56d144, > which you can see here: > https://gist.githubusercontent.com/badri/4d1bf1f0a24e8db5065e31946355cfe3/raw/86889ba22e381252e11aa3a8678f31023aa10f7e/leanpub-export.el > > The code works, and each resulting file (one per top-level subtree) > contains the corresponding section, but without the headline. I would like > the headling to be exported as well. > > I have been looking around and found this: > https://emacs.stackexchange.com/a/2260. This code exports each section > including its headline, but each file contains the corresponding section > PLUS everything after it. > > I've been poking around the org functions, but I haven't been able to > figure this out. Any ideas? > > Thanks in advance, > --Diego > >
Re: [O] How to make agenda generation faster
> I've thought about this for a while. It seems to me that the issue is > that Org buffers are, of course, plain-text buffers. There is no > persistent, in-memory representation other than the buffer, so whenever > Org needs structured/semantic data, it must parse it out of the buffer, > which is necessarily rather slow. If there were a way to keep an > outline tree in memory, parallel to the buffer itself, that would allow > operations like search, agenda, etc. to be greatly sped up. FYI A while ago I saw some cache implementation in org-element.el. Take a look at org-element--cache variable definition and the code below. (defvar org-element--cache nil "AVL tree used to cache elements. Each node of the tree contains an element. Comparison is done with `org-element--cache-compare'. This cache is used in `org-element-at-point'.") Best, Ihor Adam Porter writes: > Nicolas Goaziou writes: > >>> my understanding is that code that runs with lexical-binding enabled >>> is generally faster. >> >> Not really. But it's certainly easier to understand since it removes one >> class of problems. > > From what I've read, the byte-compiler can optimize better when > lexical-binding is used. > >> Instead of re-inventing the wheel, or putting efforts into a >> wheel-like invention, wouldn't it make sense to actually work on Org >> Agenda itself? >> >> So again, wouldn't it be nice to think about Org Agenda-ng? > > As a matter of fact, what's now called org-ql-agenda was originally > called org-agenda-ng. I factored org-ql out of it and realized that it > should probably be its own, standalone package. Then I renamed > org-agenda-ng to org-ql-agenda, so I could reasonably keep them in the > same repo, and because I don't know if I will ever develop it far enough > to be worthy of the name org-agenda-ng. It started as an experiment to > build a foundation for a new, modular agenda implementation, and maybe > it could be. > >> I didn't look closely at org-ql, but I had the idea of splitting the >> Agenda in two distinct parts. One would be responsible for collecting, >> possibly asynchronously, and caching data from Org documents. The other >> one would provide a DSL to query and display the results extracted from >> the output of the first part. The second part could even be made generic >> enough to be extracted from Org and become some part of Emacs. >> Displaying filtered data, maybe in a timeline, could be useful for other >> packages. Unfortunately, I don't have time to work on this. Ah well. > > I've thought about this for a while. It seems to me that the issue is > that Org buffers are, of course, plain-text buffers. There is no > persistent, in-memory representation other than the buffer, so whenever > Org needs structured/semantic data, it must parse it out of the buffer, > which is necessarily rather slow. If there were a way to keep an > outline tree in memory, parallel to the buffer itself, that would allow > operations like search, agenda, etc. to be greatly sped up. > > But how would that work in Emacs? Theoretically, we could write some > code, applied on self-insert-command, to update the "parallel tree > structure" as the user manipulates the plain-text in the buffer > (e.g. add a new node when the user types a "*" to create a new heading), > and also apply it to functions that manipulate the outline structurally > in the buffer. But, of course, that sounds very complicated. I would > not relish the idea of debugging code to keep a cached tree in sync with > a plain-text buffer outline. :) > > Besides that, AFAIK there would be no way to do it asynchronously other > than calling out to a child Emacs process (because elisp is still > single-threaded), printing and reading the data back and forth (which > would tie up the parent process when reading). Maybe in the future > elisp will be multithreaded... > > Anyway, org-ql tries to do some of what you mentioned. It does > rudimentary, per-buffer, per-query caching (as long as the buffer is not > modified, the cache remains valid), which helps when there are several > Org files open that are referred to often but not as often modified. > And the query and presentation code are separated (org-ql and > org-ql-agenda). > > I don't know how widely it's used, but the repo is getting some regular > traffic, and I'm using it as the backend for my org-sidebar package. > I'd be happy if it could be made more generally useful, or if it could > be helpful to Org itself in some way. Contributions are welcome. > > signature.asc Description: PGP signature
Re: [O] no more tikz -> png génération during HTML export
Hello, Eric S Fraga writes: > On Tuesday, 16 Oct 2018 at 11:46, Éric Würbel wrote: >> I think that this problem is very specific to the following case : >> - LaTeX SRC block >> - needed translation of this block into a png (and perhaps svg) image >> - preprocessing with pdflatex, so we end up with a pdf->png conversion. > > It is specific but this is a quite widely used process for many exporting to > HTML and ODT. > >> IMO we should perhaps add a warning in this worg page : >> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html > > I think this warning should be in the main manual. I didn't follow closely the issue so... suggestions or patches welcome. :) Regards, -- Nicolas Goaziou
Re: [O] How to make agenda generation faster
Hello, Adam Porter writes: > From what I've read, the byte-compiler can optimize better when > lexical-binding is used. It can, but AFAIK, it doesn't yet. It also means un-optimized lexical binding may be slightly slower than dynamic scoping for the time being. > I've thought about this for a while. It seems to me that the issue is > that Org buffers are, of course, plain-text buffers. There is no > persistent, in-memory representation other than the buffer, so whenever > Org needs structured/semantic data, it must parse it out of the buffer, > which is necessarily rather slow. If there were a way to keep an > outline tree in memory, parallel to the buffer itself, that would allow > operations like search, agenda, etc. to be greatly sped up. I don't think that's necessary. File caching as you suggest below, can go a long way. Filling cache during idle time, too. > But how would that work in Emacs? Theoretically, we could write some > code, applied on self-insert-command, to update the "parallel tree > structure" as the user manipulates the plain-text in the buffer > (e.g. add a new node when the user types a "*" to create a new heading), > and also apply it to functions that manipulate the outline structurally > in the buffer. But, of course, that sounds very complicated. I would > not relish the idea of debugging code to keep a cached tree in sync with > a plain-text buffer outline. :) My over-engineering-o-meter flashes red, too. > Anyway, org-ql tries to do some of what you mentioned. It does > rudimentary, per-buffer, per-query caching (as long as the buffer is not > modified, the cache remains valid), which helps when there are several > Org files open that are referred to often but not as often modified. That's what I did in an agenda upgrade I tried a few months ago. Unfortunately, caching is not compatible with the underlying logic of current Agenda, in particular with `org-agenda-skip-function'. > And the query and presentation code are separated (org-ql and > org-ql-agenda). That's a very good thing. > I don't know how widely it's used, but the repo is getting some regular > traffic, and I'm using it as the backend for my org-sidebar package. > I'd be happy if it could be made more generally useful, or if it could > be helpful to Org itself in some way. Contributions are welcome. That's not exactly what I'm suggesting. I suggest to move the work in Org tree, e.g., as an org-agenda-ng.el library, and, from there, implement back most of the features of the current agenda. Org cannot really benefit from libraries living outside Emacs, as we recently learnt with htmlize issue. Regards, -- Nicolas Goaziou
Re: [O] (no subject)
Hello, Nik Clayton writes: > I'd like to propose a couple of changes / enhancements to how org-export > exports some data in to HTML files to make it slightly easier to style > those files. > > The first is re line-numbers. [...] > Couple of questions before I write a patch: > > a) Does that sound reasonable? > b) Should this replace the current approach, or be an option that can be > toggled by a customisation? My HTML/CSS knowledge is feeble. But it does sound reasonable, if there's no loss of feature and compatibility. A patch would be nice for users exporting to HTML who want to test the behaviour. > And the second is re languages associated with exported SRC blocks. [...] > I see there's already some code that tries to show language badges on hover > (which doesn't work for me for some reason, I haven't dug in to why). > > Does this change sound reasonable? Ditto. Regards, -- Nicolas Goaziou
[O] use-package and "Error Autoloading file"
Hello everyone,
I'm trying to switch my config over to use-package and running into an
issue with org. Most of my init file seems to be org-related (!), so I
won't post the whole thing, but will try to summarize. I've also posted a
bug report to the use-package repo (
https://github.com/jwiegley/use-package/issues/730).
Like many people, I have lots of versions of org-mode installed on my
machine: the old org that comes with emacs 27.0.50, the version from the
org ELPA repo, which is a dependency of many other packages, and finally an
up-to-date git master, which is the version of org I prefer to use. When I
posted my bug report, I thought that the issue might result form using the
git repo, but it seems to persist even when I remove the repo paths from
load-path and take out the custom :load-path command form my use-package
for org.
On initial invocation of use-package and also on load of every subsequent
org-mode file, I get this error:
File mode specification error: (error Autoloading file ... failed to define
function org)
It also happens whenever I try to use the agenda, which seems completely
broken now. That's the main reason I hope to track down this bug :-(
This happens regardless of whether I use the ELPA org-plus-contrib or set
:load-path to the location of the lisp and contrb/lisp folders in the git
repo and :pin to manual. I'm wondering if anyone on the list has had and
hopefully solved this problem!
Here's the beginning of my current use-package invocation:
(use-package org
:ensure org-plus-contrib
:functions org
:init
(setq org-export-backends '(ascii beamer html hugo icalendar md gfm
reveal latex odt org))
:hook
((org-mode . (lambda () (flyspell-mode 1)))
(org-mode . turn-off-auto-fill))
:mode "\\.org"
:bind
(("C-c l" . 'org-store-link)
("C-c a" . 'org-agenda))
:commands (org-mode org-capture org-agenda )
:config
;; Targets include this file and any file contributing to the agenda - up
to 5 levels deep
(setq org-refile-targets (quote ((org-agenda-files :maxlevel . 5) (nil
:maxlevel . 5)
;;
;; ... set lots of variable values & do some other stuff
;;
)
Thank you as always!
Re: [O] use-package and "Error Autoloading file"
oh jeez, this was a trivial fix:
:mode "\\.org" . ;; --->
:mode ("\\.org" . org-mode)
Sorry for the noise, hope that maybe someone benefits from my stupidity!
On Wed, Oct 17, 2018 at 11:53 AM Matt Price wrote:
> Hello everyone,
>
> I'm trying to switch my config over to use-package and running into an
> issue with org. Most of my init file seems to be org-related (!), so I
> won't post the whole thing, but will try to summarize. I've also posted a
> bug report to the use-package repo (
> https://github.com/jwiegley/use-package/issues/730).
>
> Like many people, I have lots of versions of org-mode installed on my
> machine: the old org that comes with emacs 27.0.50, the version from the
> org ELPA repo, which is a dependency of many other packages, and finally an
> up-to-date git master, which is the version of org I prefer to use. When I
> posted my bug report, I thought that the issue might result form using the
> git repo, but it seems to persist even when I remove the repo paths from
> load-path and take out the custom :load-path command form my use-package
> for org.
>
> On initial invocation of use-package and also on load of every subsequent
> org-mode file, I get this error:
>
> File mode specification error: (error Autoloading file ... failed to
> define function org)
>
> It also happens whenever I try to use the agenda, which seems completely
> broken now. That's the main reason I hope to track down this bug :-(
>
> This happens regardless of whether I use the ELPA org-plus-contrib or set
> :load-path to the location of the lisp and contrb/lisp folders in the git
> repo and :pin to manual. I'm wondering if anyone on the list has had and
> hopefully solved this problem!
>
> Here's the beginning of my current use-package invocation:
>
> (use-package org
> :ensure org-plus-contrib
> :functions org
> :init
> (setq org-export-backends '(ascii beamer html hugo icalendar md gfm
> reveal latex odt org))
> :hook
> ((org-mode . (lambda () (flyspell-mode 1)))
> (org-mode . turn-off-auto-fill))
> :mode "\\.org"
> :bind
> (("C-c l" . 'org-store-link)
> ("C-c a" . 'org-agenda))
> :commands (org-mode org-capture org-agenda )
> :config
> ;; Targets include this file and any file contributing to the agenda -
> up to 5 levels deep
> (setq org-refile-targets (quote ((org-agenda-files :maxlevel . 5) (nil
> :maxlevel . 5)
> ;;
> ;; ... set lots of variable values & do some other stuff
> ;;
> )
>
> Thank you as always!
>
Re: [O] How to make agenda generation faster
Nicolas Goaziou writes: > It can, but AFAIK, it doesn't yet. It also means un-optimized lexical > binding may be slightly slower than dynamic scoping for the time > being. Well, I can't vouch for it myself, because I haven't studied the code. But here's one of the resources that suggests it is faster to use lexical binding: https://emacs.stackexchange.com/questions/2129/why-is-let-faster-with-lexical-scope > That's not exactly what I'm suggesting. I suggest to move the work in > Org tree, e.g., as an org-agenda-ng.el library, and, from there, > implement back most of the features of the current agenda. > > Org cannot really benefit from libraries living outside Emacs, as we > recently learnt with htmlize issue. Org is welcome to take any of the org-ql or org-ql-agenda code you think would be useful. However, before it could be suitable as a possible replacement, it will likely require more optimization. Some queries, especially more complex ones, are slower than the equivalent searches and agendas in the current Org Agenda code. This is because of the way the queries run predicates on each heading. Despite the current Org Agenda code's complexity, it is well optimized and hard to beat. I have a proof-of-concept branch that begins to implement a relatively simple optimization that converts one suitable predicate in a query to a buffer-global regexp search. It significantly improves speed in some cases, but a query with several predicates still has to run all but one of them as predicates. Another possible optimization would be to convert as many predicates in a query to buffer regexp searches as possible, collecting a list of heading positions in the buffer, and then do a final pass with the appropriate union/intersection/difference operations on the lists. Then the list of positions could be used to gather the heading data. I use a similar technique in helm-org-rifle, and it seems to work quickly. It would require some work on a sort of "query compiler" to do the transformation and optimization. I don't have much experience with that kind of programming; maybe someone else would be interested in helping with that. So before taking any of the code into Org itself, you might want to consider these issues and decide whether it could be a suitable approach. Let me know what you'd like to do and how I can help. Thanks, Adam
[O] Bug: ox-odt.el should support text:start-value [9.1.14 (9.1.14-7-g01c419-elpaplus @ …/org-plus-contrib-20181015/)]
I saw that exporting plain lists with specified starting numbers (‘[@20]') wasn't working—the lists just start over. I was a bit frustrated with this, so I went looking at the code and the ODF schema. I found that ODF supports the text:start-value attribute[1] that could be used where needed. I came up with the following hack: diff -ub ox-odt.el\~ ox-odt.el --- ox-odt.el~ 2018-10-17 16:47:32.859161792 -0400 +++ ox-odt.el 2018-10-17 21:04:46.391759435 -0400 @@ -1966,10 +1966,13 @@ CONTENTS holds the contents of the item. INFO is a plist holding contextual information." (let* ((plain-list (org-export-get-parent item)) + (count (org-element-property :counter item)) (type (org-element-property :type plain-list))) (unless (memq type '(ordered unordered descriptive-1 descriptive-2)) (error "Unknown list type: %S" type)) -(format "\n\n%s\n%s" +(format (concat "\n\n%s\n%s") contents (if (org-element-map item 'table #'identity info 'first-match) "" Diff finished. Wed Oct 17 21:17:59 2018 Emacs : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11, cairo version 1.14.8) of 2018-10-17 Package: Org mode version 9.1.14 (9.1.14-7-g01c419-elpaplus @ …/org-plus-contrib-20181015/) Footnotes: [1] http://docs.oasis-open.org/office/v1.2/cs01/OpenDocument-v1.2-cs01-part1.html#a_19_868_3__text_list-item_
Re: [O] Bug: ox-odt.el should support text:start-value [9.1.14 (9.1.14-7-g01c419-elpaplus @ …/org-plus-contrib-20181015/)]
Working code changes: diff -ub org-plus-contrib-20181008/ox-odt.el\~ org-plus-contrib-20181008/ox-odt.el --- org-plus-contrib-20181008/ox-odt.el~2018-10-12 19:13:13.095335320 -0400 +++ org-plus-contrib-20181008/ox-odt.el 2018-10-17 22:10:30.194483160 -0400 @@ -1966,10 +1966,13 @@ CONTENTS holds the contents of the item. INFO is a plist holding contextual information." (let* ((plain-list (org-export-get-parent item)) + (count (org-element-property :counter item)) (type (org-element-property :type plain-list))) (unless (memq type '(ordered unordered descriptive-1 descriptive-2)) (error "Unknown list type: %S" type)) -(format "\n\n%s\n%s" +(format (concat "\n\n%s\n%s") contents (if (org-element-map item 'table #'identity info 'first-match) "" Diff finished. Wed Oct 17 22:11:23 2018
Re: [O] temporary set source blocks major-mode-hook to nil locally to speed up Org Mode
Nicolas Goaziou writes: > Some major modes may use major mode hooks to finish setting up their > fontification process, who knows. > > In any case, it could be worth trying it. Do you want to provide a patch > for that? > > Regards, I dived into the source code of two functions which are related to defcustom variable ~org-src-fontify-natively~. Here is my try: #+begin_src diff modified lisp/org-src.el @@ -585,7 +585,14 @@ as `org-src-fontify-natively' is non-nil." (erase-buffer) ;; Add string and a final space to ensure property change. (insert string " ")) - (unless (eq major-mode lang-mode) (funcall lang-mode)) + (unless (eq major-mode lang-mode) + (message "%s enabled in source block" lang-mode) + ;; (make-local-variable (intern (format "%s-hook" lang-mode))) + ;; (set (intern (format "%s-hook" lang-mode)) nil) + (message "%s is %s" +(intern (format "%s-hook" lang-mode)) +(symbol-value (intern (format "%s-hook" lang-mode + (funcall lang-mode)) (org-font-lock-ensure) (let ((pos (point-min)) next) (while (setq next (next-property-change pos)) #+end_src But it seems does not work as I expected. Can't find out which real function is invoked when fontify every source blocks. >From cd43cd7c4c4e98d2b62af84a0729f82fb361c25f Mon Sep 17 00:00:00 2001 From: stardiviner Date: Thu, 18 Oct 2018 12:55:30 +0800 Subject: [PATCH] Set all lang-mode-hook to nil to speedup source blocks fontify. --- lisp/org-src.el | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/lisp/org-src.el b/lisp/org-src.el index 9c462b7e7..271ca82b9 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -585,7 +585,14 @@ as `org-src-fontify-natively' is non-nil." (erase-buffer) ;; Add string and a final space to ensure property change. (insert string " ")) - (unless (eq major-mode lang-mode) (funcall lang-mode)) + (unless (eq major-mode lang-mode) + (message "%s enabled in source block" lang-mode) + ;; (make-local-variable (intern (format "%s-hook" lang-mode))) + ;; (set (intern (format "%s-hook" lang-mode)) nil) + (message "%s is %s" + (intern (format "%s-hook" lang-mode)) + (symbol-value (intern (format "%s-hook" lang-mode + (funcall lang-mode)) (org-font-lock-ensure) (let ((pos (point-min)) next) (while (setq next (next-property-change pos)) -- 2.19.1 -- [ stardiviner ] don't need to convince with trends. Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
