Ihor Radchenko writes:
> We are back to the previous comments on the patch itself. You need to
> address the problem with older versions of texinfo. What will happen
> if one tries to open a document generated with your patch using old
> texinfo version? Will it render correctly?
I compiled
Matt Huszagh writes:
> :var header arguments can be provided multiple times. This is supported
> directly at the source block and through the default header argument
> facility. However, this was not handled correctly when the var was
> evaluated from a closure in a default header argument (only
Hi Kaushal,
> I read about the release of Org Contrib: https://git.sr.ht/~bzg/
> org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 ..
>
> The release notes mention that few of the org-contrib packages have
> moved to your repos on GitHub. But none of those repos are visible:
>
Max Nikulin writes:
> On 04/06/2022 22:35, Arthur Miller wrote:
>>
>> However before I continue, I am thinking of ditching the 'read-key'
>> completely
>> and switching to "standard" Emacs way of implementing interactivity via mode
>> and
>> mode-map. I am currently playing with such
On 04/06/2022 22:35, Arthur Miller wrote:
>
However before I continue, I am thinking of ditching the 'read-key' completely
and switching to "standard" Emacs way of implementing interactivity via mode and
mode-map. I am currently playing with such implementation, which to me appears
both simpler
Hi All,
This is just a little patchset to treat `#+include: URL' the same way as
`#+setupfile: URL'. All the usual `#+include:' bells and whistles (`::*Heading',
`:lines', etc.) work as normal.
All the best,
Timothy
>From df0b382e43cf44860247fafd14bd2932fe3ed026 Mon Sep 17 00:00:00 2001
From:
On 05/06/2022 21:32, Timothy wrote:
This is just a little patchset to treat #+include: URL the same way as
#+setupfile: URL. All the usual #+include: bells and whistles
(::*Heading, :lines, etc.) work as normal.
Is it possible to disable fetching remote files by some setting? If I
remember
> It would help if closure part and multi-variable part were split into
> separate paragraphs.
The closure part and muliple header argument part are already in
separate paragraphs. The multiple header argument part, however, is
incorporated into an introductory paragraph that very briefly
Hello Christopher,
I read about the release of Org Contrib:
https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6
..
The release notes mention that few of the org-contrib packages have moved
to your repos on GitHub. But none of those repos are visible:
Ihor Radchenko writes:
> Arthur Miller writes:
>
>> However before I continue, I am thinking of ditching the 'read-key'
>> completely
>> and switching to "standard" Emacs way of implementing interactivity via mode
>> and
>> mode-map. I am currently playing with such implementation, which to
Bastien Guerry writes:
> Hi Kaushal,
>
>> I read about the release of Org Contrib: https://git.sr.ht/~bzg/
>> org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6 ..
>>
>> The release notes mention that few of the org-contrib packages have
>> moved to your repos on GitHub. But none of
Kaushal Modi writes:
> On Sun, Jun 5, 2022, 9:40 AM Kaushal Modi wrote:
>
> Have you moved those repos elsewhere?
>
> I kept on looking at the release 0.4 commit message on the org-contrib and
> didn't realize that the "release notes"
> referred in that Mastodon thread are at the different
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> We are back to the previous comments on the patch itself. You need to
>> address the problem with older versions of texinfo. What will happen
>> if one tries to open a document generated with your patch using old
>> texinfo version? Will it
On Sun, Jun 5, 2022, 9:40 AM Kaushal Modi wrote:
>
> Have you moved those repos elsewhere?
>
I kept on looking at the release 0.4 commit message on the org-contrib and
didn't realize that the "release notes" referred in that Mastodon thread
are at the different place on sr.ht .
I see that
"Christopher M. Miles" writes:
> Here is the repository homepage:
> https://repo.or.cz/ob-clojure-literate.el.git
Thanks, I updated the release notes:
https://git.sr.ht/~bzg/org-contrib/refs/release_0.4
--
Bastien
I need some help with a debugging problem:
I'm using
#+cite_export: csl ~/Templates/csl/AGLC-intext.csl
where AGLC-intext.csl is a custom csl file.
Exporting to html gives this error in *Messages*:
citeproc-s-slice-by-matches: Wrong type argument: stringp, nil
The error does not occur with
Dear All,
On Mon, 6 Jun 2022 at 03:45, Alan Tyree wrote:
> A short random test shows that the export chokes when there is a single name
> for an author. Again an example:
> author = {{Wolfsberg Group}} works fine;
> author = {{Wolfsberg}} chokes.
Alan, could you open an issue in the
>From fb57b46759b8f5dc94e1f4224a62c73d0086e4be Mon Sep 17 00:00:00 2001
From: Yury Kholodkov
Date: Sun, 5 Jun 2022 20:13:51 +0300
Subject: [PATCH 21030/21030] manual: Fix variable name
---
doc/org-manual.org | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Sun, Jun 5, 2022 at 6:48 PM Alan Tyree wrote:
> I need some help with a debugging problem:
>
> I'm using
>
> #+cite_export: csl ~/Templates/csl/AGLC-intext.csl
>
> where AGLC-intext.csl is a custom csl file.
I'm not sure if citeproc-el checks validity before running, but have
you confirmed
Arthur Miller writes:
> Ihor Radchenko writes:
>
>> Arthur Miller writes:
>>
>>> However before I continue, I am thinking of ditching the 'read-key'
>>> completely
>>> and switching to "standard" Emacs way of implementing interactivity via
>>> mode and
>>> mode-map. I am currently playing
Thanks for the prompt reply, Bruce.
I guess the bad news is that the csl file validates. I also should have
mentioned that everything parses properly with pandoc, so I guess it is a
cireproc-el glitch.
>From the brief error report, it must just be choking on a specific bibtex
entry, so it would
Alan Tyree writes:
> I guess the bad news is that the csl file validates. I also should have
> mentioned that everything parses properly with pandoc, so I guess it is a
> cireproc-el glitch.
>
> From the brief error report, it must just be choking on a specific bibtex
> entry, so it would still
org changed from master to main and maint to bugfix. this is a q
related to that.
for a clean repo, i figured out that i can do cd to repo, git checkout
master, git branch -m main.
i have a repo where i have patches that i carry along i a local
branch. these are rebased automagically when i
Thanks, Ihor. That found it.
The bibtex entry had:
author = {BIS},
Change to:
author = {{Bank for International Settlements}},
and it all works a treat.
A short random test shows that the export chokes when there is a single
name for an author. Again an example:
author = {{Wolfsberg Group}}
24 matches
Mail list logo
