Christopher Miles writes:
> Should I use the following options? I saw the warning. Does this freeze
> happens often? I decide to try it.
Setting org-element-use-cache to t should be enough to see differences.
Best,
Ihor
<#secure method=pgpmime mode=sign>
Thanks for your hints.
Should I use the following options? I saw the warning. Does this freeze happens
often? I decide to try it.
(defvar org-element-use-cache nil
"Non-nil when Org parser should cache its results.
WARNING: for the time being, using cache
I use org-goto to navigate my org-headings. If I use the *default* settings,
everything works fine. However, if I add the following customization,
my completion options become limited:
(setq org-goto-interface (quote outline-path-completion))
If I now search, for example, for a heading
Maxim Nikulin writes:
> On 12/02/2021 14:16, Kyle Meyer wrote:
>> Not relevant for the underlying issue, but doesn't xpdf require a colon
>> before the page number (i.e. ":%1")?
>
> At least for the application in debian & ubuntu xpdf package, page
> number should be specified without a colon.
On 2021-02-11 18:44, Diego Zamboni wrote:
> #2 is known (maybe documented? Not sure) behavior: using :noweb-ref
> accumulates multiple blocks with the same name, whereas #+NAME uses only
> the first one. I think #+NAME's are supposed to be unique within a document.
It seems that more recent
Christopher Miles writes:
> I checked org-element-context source code, it's not so long and complex. Why
> it caused so many items in Memory profiler result? Is it possible to optimize
> it?
You can try to use org-element-cache. That might help.
Best,
Ihor
On 2021-02-11 18:44, Diego Zamboni wrote:
> #2 is known (maybe documented? Not sure) behavior: using :noweb-ref
> accumulates multiple blocks with the same name, whereas #+NAME uses only
> the first one.
Deep in org-babel-tangle,
<#secure method=pgpmime mode=sign>
I did an profiler (with my extension "org-link-beautify").
Here is the result of (Memory and CPU).
I checked org-element-context source code, it's not so long and complex. Why it
caused so many items in Memory profiler result? Is it possible to optimize it?
Aloha Kyle,
Thanks for taking a look at this, and also for the instructions
how to test. I get the results you report.
Separately, off list, John Kitchin kindly noted that my symptoms
might be caused by org-ref. A bit of snooping led me to
understand that org-ref was installed on my
Jens Lechtenboerger writes:
> On 2021-02-12, Kyle Meyer wrote:
>
>> TEC writes:
>>
>>> Hi All,
>>>
>>> This is just some tweaks to the styling in ox-html that I think may
>>> appeal (and prevent ridiculously long lines on non-small displays, which
>>> are an issue for legibility).
>>>
>>> I
Kyle Meyer writes:
> This came up somewhat recently, and there were a couple of suggestions:
> https://orgmode.org/list/CA+pajW+jViTPE2cwTZ=thvzyhjrt000-bb6jk2nte4p9ufb...@mail.gmail.com/T/#u
Thanks for the information! That was really helpful. I retrieved some
information from that post and
You should be able to run C-c C-c on #+property: directives before the
first headline and they will be updated without reloading the buffer.
Best,
Tom
Jens Lechtenboerger writes:
> On 2021-02-12, Jens Lechtenboerger wrote:
>
>> I do not know why the CDATA lines exist. I don’t see a reason to
>> keep them (patch 0001), but that might be a lack of understanding on
>> my part.
>
> OK, that is probably for XHTML, where < and & are only allowed
Jens Lechtenboerger writes:
> I do not know why the CDATA lines exist. I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
I'll cover this in my reply to your follow-up.
> Patch 0003 is about whitespace fixes.
>
> Patches 0002, 0004,
On 2021-02-12, Jens Lechtenboerger wrote:
> I do not know why the CDATA lines exist. I don’t see a reason to
> keep them (patch 0001), but that might be a lack of understanding on
> my part.
OK, that is probably for XHTML, where < and & are only allowed
inside CDATA sections.
Timothy, did you
On 2021-02-12, Kyle Meyer wrote:
> TEC writes:
>
>> Hi All,
>>
>> This is just some tweaks to the styling in ox-html that I think may
>> appeal (and prevent ridiculously long lines on non-small displays, which
>> are an issue for legibility).
>>
>> I also took the opportunity to remove the
On 12/02/2021 14:16, Kyle Meyer wrote:
#+begin_src elisp
(setq org-file-apps '(("\\.pdf::\\([0-9]+\\)\\'" . "xpdf %s %1")))
#+end_src
Not relevant for the underlying issue, but doesn't xpdf require a colon
before the page number (i.e. ":%1")?
At least for the application in debian &
Hi Diego, hi all,
Diego Zamboni writes:
> I found it here: https://orgmode.org/org.html
Thanks a lot. I've just bookmarked it.
> But it doesn't seem to be linked from the new website.
Has there been a discussion about what manual to link to from the front
page?
As far as I can remember, I've
Hi Christine,
I found it here: https://orgmode.org/org.html
But it doesn't seem to be linked from the new website.
--Diego
On Fri, Feb 12, 2021 at 5:13 PM Christine Köhn wrote:
> Hi,
>
> I always used the manual online as one html page but it does not seem to
> be available since (?) the
I realize the wording before is bad. Here's a revamp:
How many global, persistent tags can you have with org-mode? I seem to have
org-tag-alist with its fast tag selection maxed out at 26. Is that the
limit for it, lower-case letters in the alphabet? I would like to have
potentially hundreds of
Hi,
I always used the manual online as one html page but it does not seem to
be available since (?) the website revamp. I prefer the manual as one
page for many reasons. Is it still available online?
Best,
Christine
Hi,
I'm using properties on buffer level to specify header-args for source
code blocks. I noticed that properties defined with #+PROPERTY: before
the first headline do not work unless the buffer is reloaded, but
properties defined in drawers work just fine. Are properties on buffer
level supposed
Hi,
In my Org docs I make a heavy use of replacement macros. I think they
are a powerful and versatile. I only see one problem: in my opinion, the
comma as a character to separate arguments seems unproductive to me. I
often use macros to enter textual content, and I find it a bit tedious
having
23 matches
Mail list logo
