Re: [O] Visualizing org files

[Van L]

>>> Freeplane XML to org
>>
>> I took a look at images of Freeplane XML and it is boring.
>>
>> What I’d like to do is tile triangles (and the normal) as clusters
>> and/or scatters on meaningful planes of data/concepts which see a
>> landscape having moving parts in Disney’s Tron blockbuster Netflix
>> movie but less dark. And, like in the map apps for navigating by in
>> the smartphone you can tilt to adjust the angle to horizon for 3D
>> effect.
>>
>> How about Pixar’s USD (Universal Scene Description) information exchange 
>> format? 
>>
> Sounds very cool!!!

This app isn’t even close

  https://imindmap.com

and Org Mode is to have reproducible work in labwork!

Re: [O] Bug: ox-odt.el should support text:start-value [9.1.14 (9.1.14-7-g01c419-elpaplus @ …/org-plus-contrib-20181015/)]

[Mark A. Hershberger]

Nicolas Goaziou  writes:

> Could you provide a patch using git format-patch, with a proper commit
> message?

Attached.  Also see
.

> Also, if you haven't signed FSF papers, please add TINYCHANGE at the
> end of the commit message.

I have signed papers on file.

Mark.
>From 91cb08df2473c70b7817c37ae0744e051964ad07 Mon Sep 17 00:00:00 2001
From: "Mark A. Hershberger" 
Date: Fri, 19 Oct 2018 09:19:38 -0400
Subject: [PATCH] Add support for text:start-value to ox-odt.el

ODF supports starting lists at a set number via text:start-value.
Without this, ODF files just restart numbering when they should
continue with the specified number.
---
 lisp/ox-odt.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 70ef9de2e..b9a81f74d 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -1966,10 +1966,13 @@ contextual information."
 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)
 		""
-- 
2.19.1

[O] Bug: ox-beamer add label when option 'allowframebreaks' setted in org-beamer-frame-default-options [9.1.14 (9.1.14-7-g01c419-elpaplus @ .emacs.d/elpa/org-plus-contrib-20181015/)]

[Héctor Enríquez Ramón]

Latex beamer not allow 'label=' when 'allowframebreaks' setted in frame.

In file ox-beamer.el function org-beamer--format-frame search
'allowframebreaks' option inside beamer-opt but not inside variable
org-beamer-frame-default-options. Then insert 'label=..' with
'allowframebreaks' and latex hide continuation's frames.

Best regards. Héctor

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw
scroll bars)
 of 2018-05-30
Package: Org mode version 9.1.14 (9.1.14-7-g01c419-elpaplus @
/home/edo/.emacs.d/elpa/org-plus-contrib-20181015/)

Re: [O] How to make agenda generation faster

[Adam Porter]

On Oct 18, 2018 5:48 PM, "Nicolas Goaziou"  wrote:

> Are you saying that queries are turned into regexp searches within Org
files? If so, I don't think they should.

Yes, because this is the fastest way to search for matching entries in a
buffer, when it's possible to use a regexp search.

> Queries should only operate on the output of the data extraction,
possibly a list of defstructs. I.e., you first extract all meaningful data
from the document (during idle time, with cache, or whatever optimization
would be chosen), store it in an appropriate format, then query it.
>
> WDYT?

That would be ideal. The problem I foresee is that, when a buffer's cache
is not up-to-date, and the user runs an agenda query, the user will have to
wait for the buffer to be parsed and cached, which is much slower than a
regexp search through the buffer.

That was what I first tried with org-agenda-ng: I parsed the whole buffer
with org-element and ran predicates against the element tree.  It was much
too slow to be practical, so I switched to the current approach, which runs
predicates against each node, only checking the necessary metadata. It's
fast enough to be useful, but can still be slow in some cases, and I don't
think it would be fast enough as a replacement for the current agenda
code.  But with further optimization, like using whole-buffer regexp
searches when possible, it might be.

Another idea I've had, similar to yours, would be to pre-process buffers,
adding metadata as text-properties on heading lines. However, I haven't
tested it, and I don't know what the performance would be like. And it
would still suffer from the caching problem I mentioned.

I think the fundamental problems are 1) keeping the cache in sync with the
raw buffer, and 2) the slow speed of parsing an entire buffer's metadata at
once (depending on the size of the files, of course, but mine are big
enough to be slow, and I'm sure many users have larger ones).

Of course, maybe someone cleverer than me can figure out a clever solution
to these problems. :)