Re: [O] Painfully Slow Export
On Wed, Jun 13, 2018 at 12:12 AM Berry, Charles wrote: > > On Jun 12, 2018, at 2:30 PM, Ken Mankoff wrote: > > > > Based on the profiling, I think the reason it takes 1 minute is because > the code blocks use <> blocks? > > I do not see this. > > It takes a bit longer to run the noweb example you gave with 200 `baz' src > blocks, but nothing crazy - like 10 seconds versus 5 for your other > example. I used `C-c C-e l L' for each. > > And the profiler gives `org-babel-expand-noweb-references' about 2% of the > total. > > You are using a recent version of org, right? > Yes: 9.1.13-elpa or org-20180604. Emacs-mac 26.1 port on OSX from Macports. Or Emacs 25.3 downloaded from https://emacsformacosx.com/builds Are you sure you hd 200 baz blocks? I'm not actually able to test with that many. 10 takes 1 second. 20 takes 10 seconds. 30 takes 30 seconds. It seems to grow exponentially. I don't have the patience to debug how long 100 takes. -k.
Re: [O] Bug: imenu fails with non-continuous structure [9.1.13 (release_9.1.13 @ /home/thblt/.emacs.d/lib/org/lisp/)]
Hello, Thibault Polge writes: > Steps to reproduce, from emacs -q: > > 1. (setq org-imenu-depth 10) > > 2. Create the following document: > > #+begin_src org > #+TITLE: Test > > * Level 1 > ** Level 2 > *** Level 3 > Level 4 > Level 8 > #+end_src > > Notice the break on the structure: levels 5, 6 and 7 are missing. > > 3. M-x imenu, select each Level n entry > > 4. imenu will crash after you've selected Level 4 > > I can reproduce this from emacs -q using org-mode from git master > (842002f9f7e3246cc285cc9bca1adb715120438d). I'm running 26.1 on > NixOS. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Painfully Slow Export
> On Jun 12, 2018, at 2:30 PM, Ken Mankoff wrote: > > Based on the profiling, I think the reason it takes 1 minute is because the > code blocks use <> blocks? I do not see this. It takes a bit longer to run the noweb example you gave with 200 `baz' src blocks, but nothing crazy - like 10 seconds versus 5 for your other example. I used `C-c C-e l L' for each. And the profiler gives `org-babel-expand-noweb-references' about 2% of the total. You are using a recent version of org, right? Chuck
Re: [O] Painfully Slow Export
As an MWE, I can test with "emacs -Q" and the following org file: #+PROPERTY: header-args :eval never-export # (setq org-export-use-babel t) #+BEGIN_SRC emacs-lisp :results none (org-babel-do-load-languages 'org-babel-load-languages '((shell . t))) #+END_SRC #+BEGIN_SRC sh :results org raw for i in $(seq 200); do echo "" echo "#+BEGIN_SRC sh :results output :exports results" echo "echo 'hello, world'" echo "#+END_SRC" echo "#+RESULTS:" echo ": goodbye" done #+END_SRC #+RESULTS: Execute the first code block to allow execution of the second. Execute the second code block to generate 200 more. Export. It takes ~6 seconds on my machine, which seems long but is bearable. Based on the profiling, I think the reason it takes 1 minute is because the code blocks use <> blocks?. I can verify this with the following MWE: #+PROPERTY: header-args :eval never-export # (setq org-export-use-babel t) #+NAME: foo #+BEGIN_SRC sh :results verbatim ls #+END_SRC #+RESULTS: #+NAME: bar #+BEGIN_SRC sh :results verbatim :noweb yes <> #+END_SRC #+RESULTS: #+NAME: baz #+BEGIN_SRC sh :results verbatim :noweb yes <> #+END_SRC #+RESULTS: Repeat the BAZ block with the <> about 100 times and export this, and it takes a long time. I killed it after ~30 seconds, because I think I have my evidence that :noweb yes is the culprit for the slow export. On Tue, Jun 12, 2018 at 11:15 PM Ken Mankoff wrote: > > On Tue, Jun 12, 2018 at 11:07 PM Berry, Charles wrote: > >> >> > On Jun 12, 2018, at 12:41 PM, Ken Mankoff wrote: >> > >> > Hi Chuck, >> > >> > It looks fine to me. I see: >> > >> > Name: fig:foo >> > Lang: python >> > Properties: >> > :header-args:eval never-export >> > :header-args:python nil >> > Header Arguments: >> > :cache no >> > :eval never-export >> > :exportsresults >> > :hlines no >> > :noweb yes >> > :resultsfile replace >> > :sessiondischarge_ts >> > :tangle no >> > >> > >> >> And still the src blocks execute? >> >> > No. The source blocks never execute. It just takes an entire minute to > export the file with 200 source blocks. If they executed it would probably > take a few hours. > >-k. >
Re: [O] orgalist: increase vspace between points, leave orgalist (indent)
Hello, Uwe Brauer writes: > First of all thanks for orgalist, I use it frequently and enjoy quite a > bit. There are two features I am missing (or don't know who to use > them). > > 1. How can I increase the vspace per default (say one blank line) between > 2 >points in a list? That is a variable which controls that behavior? For now, it obeys to `org-blank-before-new-entry'. In Orgalist 1.8, there is a new variable, `orgalist-separated-items', which basically does the same. > 2. Which key should I use to leave a list? Return just jumps >^ to position. But I am looking for a command which would jump. > > > > ^ here. Of course I can use return return and then backward-kill-word. > But is there any orgalist specific command which does this? Use C-j, or RET, depending on electric indentation. Regards, -- Nicolas Goaziou
Re: [O] Painfully Slow Export
On Tue, Jun 12, 2018 at 11:07 PM Berry, Charles wrote: > > > On Jun 12, 2018, at 12:41 PM, Ken Mankoff wrote: > > > > Hi Chuck, > > > > It looks fine to me. I see: > > > > Name: fig:foo > > Lang: python > > Properties: > > :header-args:eval never-export > > :header-args:python nil > > Header Arguments: > > :cache no > > :eval never-export > > :exportsresults > > :hlines no > > :noweb yes > > :resultsfile replace > > :sessiondischarge_ts > > :tangle no > > > > > > And still the src blocks execute? > > No. The source blocks never execute. It just takes an entire minute to export the file with 200 source blocks. If they executed it would probably take a few hours. -k.
Re: [O] Painfully Slow Export
> On Jun 12, 2018, at 12:41 PM, Ken Mankoff wrote: > > Hi Chuck, > > It looks fine to me. I see: > > Name: fig:foo > Lang: python > Properties: > :header-args:eval never-export > :header-args:python nil > Header Arguments: > :cache no > :eval never-export > :exportsresults > :hlines no > :noweb yes > :resultsfile replace > :sessiondischarge_ts > :tangle no > > And still the src blocks execute? Try this. Use the following in an org buffer: --8<---cut here---start->8--- #+PROPERTY: header-args :eval never-export #+begin_src emacs-lisp :exports results "BBB" #+end_src #+RESULTS: : AA --8<---cut here---end--->8--- C-c C-c on the PROPERTY line and confirm as above that the header-args are rightly set. Then `C-c C-e C-b t A' should give a buffer like this: --8<---cut here---start->8--- , | AA ` --8<---cut here---end--->8--- Which you can see implies that the src-block did not run, but the results were properly exported. This works for me on a brand new copy of master (9.1.13). If it fails for you, then you need to check your org setup. If it succeeds, but exporting your file still fails then there has to be something amiss in your file. I'd instrument `org-babel-execute-src-block' and see what the line with `(org-babel-check-evaluate info)' returns. It should be `nil'. If not you need to see what is in `info'. HTH, Chuck
Re: [O] Agenda search: setting sort-order
Bumping this question to see if anyone has a workaround -
I recently have been wishing to search for keywords and order
the results in reverse timestamp order.
This sounds like a fairly useful and common feature, so I think
there must be something I'm configuring incorrectly. I am able
to reproduce the problem using a fairly clean Emacs install (a
VM with no customizations).
Thanks,
--Nate
On Wed, May 30, 2018 at 4:57 PM, Nathan Neff wrote:
> Hi all,
>
> I'm using org-mode version 9.1.13 from elpa, and
> have a custom agenda command:
>
>
> (setq org-agenda-custom-commands
>'(
> ("z" search ""
>((org-agenda-sorting-strategy '(timestamp-up))
>
> And I have an org-file with this data:
>
> * TODO [#C] Test1
> :foo:
> <2018-04-24 Tue 19:30>
> * TODO [#A] Test2
> :foo:
> <2018-05-24 Thu 19:30>
> * TODO [#B] Test3
> :foo:
> <2017-12-24 Sun 23:33>
>
> The data is not sorted according to timestamp. I cannot seem to
> get the data sorted in any fashion when using the "search" agenda mode.
>
> However, if I change "search" to "tags" and search for the "foo" tag, then
> it appears that the sorting works. I've tested it with priority and
> timestamp
> using the above data and it sorts the items correctly.
>
> Why is my "search" agenda command ignoring the org-agenda-sorting-strategy?
>
> Thanks,
> --Nate
>
[O] New org-count-words function
Hi friends, Here's a new function that counts lines, words, and characters in the region or the subtree at point. It prints a message like `count-words` does, like: Subtree "Heading" has 7 line, 5 words, and 28 characters. Note that it does *not* count words in heading lines, planning lines, and drawers, so it gives a more useful count for the "prose" in the subtree. Here's the code: #+BEGIN_SRC elisp (defun ap/org-count-words () "If region is active, count words in it; otherwise count words in current subtree." (interactive) (if (use-region-p) (funcall-interactively #'count-words-region (region-beginning) (region-end)) (org-with-wide-buffer (cl-loop for (lines words characters) in (org-map-entries (lambda () (ap/org-forward-to-entry-content 'unsafe) (let ((end (org-entry-end-position))) (list (count-lines (point) end) (count-words (point) end) (- end (point) nil 'tree) sum lines into total-lines sum words into total-words sum characters into total-characters finally do (message "Subtree \"%s\" has %s lines, %s words, and %s characters." (org-get-heading t t) total-lines total-words total-characters) #+END_SRC It requires this supporting function: #+BEGIN_SRC elisp (defun ap/org-forward-to-entry-content ( unsafe) "Skip headline, planning line, and all drawers in current entry. If UNSAFE is non-nil, assume point is on headline." (unless unsafe ;; To improve performance in loops (e.g. with `org-map-entries') (org-back-to-heading)) (cl-loop for element = (org-element-at-point) for pos = (pcase element (`(headline . ,_) (org-element-property :contents-begin element)) (`(,(or 'planning 'property-drawer 'drawer) . ,_) (org-element-property :end element))) while pos do (goto-char pos))) #+END_SRC I think it's an improvement over the functions I've seen that do this. Hope someone finds it useful.
Re: [O] Painfully Slow Export
Hi Chris, Thanks for the hint. I didn't think to profile. This may be useful, but I'm not sure how to interpret the results, which are: - command-execute 15852 79% - call-interactively 15852 79% - funcall-interactively 15666 78% - org-export-dispatch15392 77% - org-latex-export-to-latex 15291 76% - org-export-to-file 15289 76% - org-export-as 15245 76% - org-babel-exp-process-buffer 14762 74% - org-babel-exp-src-block 14676 73% - org-babel-exp-do-export 10049 50% - org-babel-exp-results9324 46% - org-babel-expand-noweb-references 9200 46% - org-babel-get-src-block-info 8247 41% - org-babel-params-from-properties 6799 34% - org-entry-get6618 33% - org-entry-get-with-inheritance 6579 33% - org-up-heading-safe5466 27% On Tue, Jun 12, 2018 at 5:09 PM Chris wrote: > Hello, Ken! > > Ken Mankoff (mank...@gmail.com) 2018-06-12: > > Is there a way to speed up exporting? > > I may be jumping to conclusions here, and if so, please excuse me. Have > you tried profiling the export? (As in M-x profiler-start, run the > export, then M-x profiler-report?) This can shed a surprising amount of > light on why things are slow. (In my case, exporting was slow because of > a slow hook that got triggered multiple times during the exportage.) > > Regards, > Chris >
Re: [O] Painfully Slow Export
Hi Chuck, It looks fine to me. I see: Name: fig:foo Lang: python Properties: :header-args :eval never-export :header-args:python nil Header Arguments: :cache no :eval never-export :exports results :hlines no :noweb yes :results file replace :session discharge_ts :tangle no -k. On Tue, Jun 12, 2018 at 5:51 PM Berry, Charles wrote: > > > > On Jun 12, 2018, at 7:01 AM, Ken Mankoff wrote: > > > > I'm trying to export a file to LaTeX. It takes about one minute. The > > file is 12000 lines long and has 200 code blocks. I have set: > > > > #+PROPERTY: header-args :eval never-export > > > > That is the right idiom. Of course, you have to refresh the local setup > after typing that (C-c C-c with point in the PROPERTY line) or it will have > no effect until you save and re-open the file. > > It is good to check that you have refreshed and that there are no typos or > hidden chars in the line, so go to a src block and type > > C-c C-v C-i > > and verify that you see something like this > > , > | Lang: R > | Properties: > | :header-args:eval never-export > | :header-args:R nil > | Header Arguments: > | :cache no > | :eval never-export > | :exportscode > | :hlines no > | :noweb no > | :resultsreplace > | :sessionnone > | :tangle no > ` > > You should see both the :header-args line as you typed it and the :eval > line showing never-export. > > > which means, I think, no babel blocks should evaluate. > > > > (setq org-export-use-babel t) seems to be the culprit. > > Leave it set to `t'. > > Chuck > > > >
Re: [O] Painfully Slow Export
> On Jun 12, 2018, at 7:01 AM, Ken Mankoff wrote: > > I'm trying to export a file to LaTeX. It takes about one minute. The > file is 12000 lines long and has 200 code blocks. I have set: > > #+PROPERTY: header-args :eval never-export > That is the right idiom. Of course, you have to refresh the local setup after typing that (C-c C-c with point in the PROPERTY line) or it will have no effect until you save and re-open the file. It is good to check that you have refreshed and that there are no typos or hidden chars in the line, so go to a src block and type C-c C-v C-i and verify that you see something like this , | Lang: R | Properties: | :header-args:eval never-export | :header-args:R nil | Header Arguments: | :cache no | :eval never-export | :exportscode | :hlines no | :noweb no | :resultsreplace | :sessionnone | :tangle no ` You should see both the :header-args line as you typed it and the :eval line showing never-export. > which means, I think, no babel blocks should evaluate. > > (setq org-export-use-babel t) seems to be the culprit. Leave it set to `t'. Chuck
Re: [O] Painfully Slow Export
Hello, Ken! Ken Mankoff (mank...@gmail.com) 2018-06-12: > Is there a way to speed up exporting? I may be jumping to conclusions here, and if so, please excuse me. Have you tried profiling the export? (As in M-x profiler-start, run the export, then M-x profiler-report?) This can shed a surprising amount of light on why things are slow. (In my case, exporting was slow because of a slow hook that got triggered multiple times during the exportage.) Regards, Chris signature.asc Description: PGP signature
Re: [O] Babel problem: Output incomplete if it contains # character (only in session)
Marian Schubert writes: > Hello, > > I'm having trouble with babel block like this: > > #+BEGIN_SRC shell :results output :session xyz > echo "foo#bar" > #+END_SRC > > #+RESULTS: > : > : bar > > I expect results to be foo#bar, but it's just bar. > If I remove :session xyz it displays correct value, i.e.: I also face issues when there is a session involved with shell. Why don't you try: export PS1=$ at the beginning of the session as the first command and see if this fixes it for you? > #+RESULTS: > : foo#bar > > Any idea what might be wrong? > > Best regards, > Marian > -- Narendra Joshi
[O] Painfully Slow Export
I'm trying to export a file to LaTeX. It takes about one minute. The file is 12000 lines long and has 200 code blocks. I have set: #+PROPERTY: header-args :eval never-export which means, I think, no babel blocks should evaluate. (setq org-export-use-babel t) seems to be the culprit. If I set it to nil then export is sub-second. However, I would like some #+RESULTS: blocks to export (w/o eval). This requires o-e-o-b t. Is there a way to speed up exporting? Thanks, -k.
Re: [O] Org mode in combination with emacs follow-mode is terrible
On Tuesday, 12 Jun 2018 at 12:23, Gerald Wildgruber wrote: > Hi Eric, > > thanks for the input: indeed, I always use at least five windows (on a > 40" display), as this setup displays simultanously almost 60Kb of text, > an entire papaer, which is excellent! That's a lot of text so maybe it's really not surprising maybe that there is a lag. What happens if you edit the same file in text-mode? > Elsewise: do you see any reason or issue with both modes enabled that > could lead to such behavior: it would seem that emacs tries to > calculate something with every new keystroke, that involves all text > before point. Maybe font-lock and org-indent may impact on this? I also find that the presence of tables often slows org down although it's difficult to quantify the actual impact. -- Eric S Fraga via Emacs 25.2.2, Org release_9.1.13-791-g842002 signature.asc Description: PGP signature
Re: [O] Org mode in combination with emacs follow-mode is terrible
Hi Eric, thanks for the input: indeed, I always use at least five windows (on a 40" display), as this setup displays simultanously almost 60Kb of text, an entire papaer, which is excellent! I will try the results with fewer windows tomorrow, when back in office. Elsewise: do you see any reason or issue with both modes enabled that could lead to such behavior: it would seem that emacs tries to calculate something with every new keystroke, that involves all text before point. Gerald. On Di, Jun 12 2018, Eric S Fraga wrote: > On Monday, 11 Jun 2018 at 14:56, Gerald Wildgruber wrote: >> My typical setup is to use a maximized or full screen emacs frame split > > [...] > >> portions towards the end of the file. If I deactivate follow-mode, the >> problem disappears. > > I have a 38" monitor and I frequently do what you say. However, I > typically only split the frame into 3 windows. I don't remember seeing > any lag. But I am currently away so cannot verify. What happens if you > try with less windows? -- Dr. Gerald Wildgruber Institut für Philosophie, Literatur-, Wissenschafts- und Technikgeschichte Literaturwissenschaft mit Schwerpunkt Literatur und Wissenschaft Technische Universität Berlin Straße des 17. Juni 135 D-10623 Berlin http://www.philosophie.tu-berlin.de/menue/home/ T. +49 (0)30 314 25924 F. +49 (0)30 314 23107 wildgru...@tu-berlin.de - Sent with mu4e
Re: [O] Error in emacs 26.1 when publishing to html
>"KM" == Kaushal Modi writes: KM> htmlize.el is required for ox-html exports, especially if you export src KM> blocks. You need to have htmlize installed in the default load-path (you KM> will need to do that much customization in emacs -Q sessions too). Thank you. In fact I am upgrading from emacs 24 to emacs 26, and I get some problems with my org files. I have to adapt my customizations to the new publishing concepts in Org. Currently I am unable to get an HTML output. So I decided to begin with no customizations to try find the culprit. It does not work either because of htmlize. I was surprised because I didn't read anything about this in the manual. I have installed htmlize, and I am now looking for what does not work in my configuration. -- Pascal Quesseveur pques...@gmail.com
Re: [O] Org mode in combination with emacs follow-mode is terrible
On Monday, 11 Jun 2018 at 14:56, Gerald Wildgruber wrote: > My typical setup is to use a maximized or full screen emacs frame split [...] > portions towards the end of the file. If I deactivate follow-mode, the > problem disappears. I have a 38" monitor and I frequently do what you say. However, I typically only split the frame into 3 windows. I don't remember seeing any lag. But I am currently away so cannot verify. What happens if you try with less windows? -- Eric S Fraga via Emacs 25.2.2, Org release_9.1.13-791-g842002 signature.asc Description: PGP signature
[O] orgalist: increase vspace between points, leave orgalist (indent)
Hi First of all thanks for orgalist, I use it frequently and enjoy quite a bit. There are two features I am missing (or don't know who to use them). 1. How can I increase the vspace per default (say one blank line) between 2 points in a list? That is a variable which controls that behavior? 2. Which key should I use to leave a list? Return just jumps ^ to position. But I am looking for a command which would jump. ^ here. Of course I can use return return and then backward-kill-word. But is there any orgalist specific command which does this? List with increased vspace 1. How can I increase the vspace (say one blank line) between 2 points in a list. 2. Which key should I use to leave a list? Return just jumps ^ to position. But I am looking for a command which would jump. Thanks Uwe Brauer
Re: [O] [BUG] there are weird offset when org-insert-structure-template
Hello, stardiviner writes: > The original text: > > , > | We define refs the same way we define atoms, but the two are used rather > differently. > | Let's take a quick look at how they work below. > | > | (def names (ref [])) > | > | (dosync > | (ref-set names ["John"]) > | (alter names #(if (not-empty %) > | (conj % "Jane") %))) > | > | In this code, we define a ref called names, then open a transaction using > the dosync statement. Inside the transaction we set names to a vector with > the value "John". Next, we call alter to check if names is not empty and add > "Jane" to the vector of the names if that's the case. > | > | Note that since this is happening inside a transaction, the check for > emptiness depends on the existing state along with any state built up within > the same transaction. If we tried to add or remove a name in a different > transaction, it would have no visible effect on ours. In case of a collision, > one of the transactions would end up being retried. > ` > > Then I use region select code from (def to ))), then press [C-c C-, s]. > > It has weird offset like this: > > , > | #+begin_src > | (def names (ref [])) > | > | (dosync > | (ref-set names ["John"]) > | (alter names #(if (not-empty %) > | (conj % "Jane") %))) > | #+end_src > ` > > But when I region select by backward from ))) to (def, it works fine. > no offset. Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] how putting \begin{document} at the right place to export a specific latex class ?
For this very interesting setup, many thanks Tim. I am going to test it and I will inform you about the results and/or my difficulties. Many thanks again to Nick and to John, I always appreciate your very kind help. (This list is terrific.) (The problem with this latex class is that it uses unconventional commands at unconventional places.) Best wishes, -- Jo.
