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 to
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,
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
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 ta
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 web
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
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 & ubunt
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 (obsole
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 t
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, 0005
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
>
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
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 w
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 als
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 system
<#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?
H
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,
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. I think #+NAME's are supposed to be unique within a document.
It seems that more recent versi
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. I
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 containing
<#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 s
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
23 matches
Mail list logo
