Leo Vivier writes:
> I’ve noticed a small mistake in the doc for `org-time-stamp-inactive`.
> You’ll find the details in the patch.
Applied in acd163596 with minor tweaks to the commit message.
Thanks!
Sharon Kimble writes:
> I'm using 'C-u C-c C-x f r' and it isn't changing the footnote
> numbering! I am adding file-2 to file-1 and then using the key mantra,
> but the footnotes are not changing. In file-1 the last footnote is 756,
> and in file-2 the first footnote is 670 (I've no idea why it
* Summary
I have a patch that allows to put trace output and error output into
corresponding Org buffer. Current behaviour with outputs being splitted
so that they go to different buffers (Org buffer, REPL), is arbitrary
and inconvenient. The patch ensures backwards compatibility. I thus
believe
"Berry, Charles" writes:
> I see.
>
> It looks like you are back to `org-babel-lob-ingest'.
>
> Maybe the issue you raised at the start of having to re-ingest after changes
> could be addressed by a function in `org-babel-pre-tangle-hook'.
Thanks for the suggestion. I wrote up my solution at
On Wed, Apr 8, 2020 at 9:39 AM John Kitchin wrote:
> If I were to dream, each cite would have text-properties that include the key
> (so it is easy to get the key at point and do something with info in the
> corresponding database), and a help-echo function that could be user-defined,
> a
Hi Bastien,
I can confirm that the bug is not there anymore.
Best,
Ihor
Bastien writes:
> Hi Bram and Ihor,
>
> this should be fixed now in maint and master.
>
> I implemented a different fix, please test it and report
> any problem.
>
> Thanks,
>
> --
> Bastien
--
Ihor Radchenko,
PhD,
Hi Gijs, hi the list,
I am interested in this question because I met a similar problem few
weeks ago, whenI tried to useDoom Emacs:
https://github.com/hlissner/doom-emacs/issues/2708 where ol-gnus are
used.
Now I'm back with a simple version of emacs
On 06.04.20 18:13, Nicolas Goaziou wrote:
Heiko Schmidt writes:
This is exactly the reason why I'd love to have negative values for
the durations. It would open the possibility of doing something like
"accounting" of time.
I think you can do accounting of time without introducing negative
Dear Bob, others
> I had customized the value 'org-modules'. This was fine so long as we
> had 'org-gnus' (and other similar modules). But in org 9.3 this has
> become 'ol-gnus' (and ol-bbdb and so on). Now, 'ol-gnus' and the rest
> are included in the stock value of org-modules, but this was
>
org-ref relies very heavily on the link functionality to provide actions on
a cite, e.g. to open the pdf, or url, allow sorting, to change the cite
color when it is a bad key, etc If the new syntax also has that capability,
e.g. through font-lock, then I would consider integrating it into org-ref,
Hi.
Em [2020-04-06 seg 18:20:43+0200], Nicolas Goaziou escreveu:
> AFAIK, this file is not maintained anymore.
>
> Note that it strength was not the HTML report, but the fact that you
> could import the Org counterpart in your agenda files.
> [...]
> You may want to have a look at it, you will
Hi.
Em [2020-04-07 ter 03:33:33+], Kyle Meyer escreveu:
> This bisects to 7e52b7661 (org-agenda: Fix logic of
> `org-agenda-filter-make-matcher', 2020-02-19). Jorge, I tested the
> patch below against the test case you provided, though of course
> confirmation that it resolves the issue on
On Wed, Apr 8, 2020 at 5:32 AM Nicolas Goaziou wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Note that in CSL processors, the locators are meaningful key-values,
> > basically; not plain text strings.
>
> OK, but it is enough for Org to feed a CSL processor with, e.g.,
>
> key->
Hello,
Albert Krewinkel writes:
> Hi,
>
> Michael Welle writes:
>
>> using ox-gfm to export Org to Gitlab's markup syntax (for the wiki for
>> instance) seems to work quite nice. Gitlab's Org parser has some
>> shortcomings, so using Org syntax directly in Gitlab often results in
>> strangely
Hi,
Michael Welle writes:
> using ox-gfm to export Org to Gitlab's markup syntax (for the wiki for
> instance) seems to work quite nice. Gitlab's Org parser has some
> shortcomings, so using Org syntax directly in Gitlab often results in
> strangely rendered documents. What I'm interested in is
Hello,
"Bruce D'Arcus" writes:
> Note that in CSL processors, the locators are meaningful key-values,
> basically; not plain text strings.
OK, but it is enough for Org to feed a CSL processor with, e.g.,
key-> "@doe99"
prefix -> "see "
suffix -> ", pp. 33-35"
Then CSL processor
Kyle Meyer writes:
> Sharon Kimble writes:
>
>> In the org manual v9.3 on page 139 it explains how to renumber the
>> footnotes. I am presuming from reading it that it requires me to C-c
>> C-x r.
>
> I don't spot any mention of 'C-c C-x r'. The table in the footnote
> section that
On Wed, Apr 08 2020, Bruce D'Arcus wrote:
On Tue, Apr 7, 2020 at 5:13 PM Joost Kremers
wrote:
What would help, BTW, is if there's an easy way to find out
what
the bibliography file or files are that are associated with the
current Org buffer.
I guess the simplest and most flexible option
Hello,
using ox-gfm to export Org to Gitlab's markup syntax (for the wiki for
instance) seems to work quite nice. Gitlab's Org parser has some
shortcomings, so using Org syntax directly in Gitlab often results in
strangely rendered documents. What I'm interested in is a 'roundtrip
workflow'. If
Hi everybody,
I'm trying to get something via an org-link. I suspect that it is
possible, but the documentation is not clear enough for me to get it.
I want to make an org-link that get me directly in eshell a program,
and if it is possible to do it, I will bookmark this org-link.
To explain
Hello,
I’ve noticed a small mistake in the doc for `org-time-stamp-inactive`.
You’ll find the details in the patch.
HTH.
Best,
--
Leo Vivier
>From 021dd8d98b7d8e86fcfdff659cb225be6dc51939 Mon Sep 17 00:00:00 2001
From: Leo Vivier
Date: Wed, 8 Apr 2020 10:22:20 +0200
Subject: [PATCH] org:
21 matches
Mail list logo
