On Fri, Apr 23, 2021 at 09:45:14AM +0800, Shironeko wrote:
> Hi all,
>
> I originally thought having the timezone in the header of the file would make
> things simpler, since it meant all the timestamp would be in the same
> timezone,
> rather than potentially different ones. But it seems that th
On Thursday, 22 Apr 2021 at 17:41, Bithov Vinu wrote:
> Are any measures being done to make org-mode backwards compatible, so
I cannot speak for the "developers" but backwards compatibility is taken
into account at all times, from what I have seen. This does not mean
that things do not break as o
Dear all,
I'm not sure if this is the correct mailinglist for org-contrib bugs. I found
that org-contacts.el uses `lexical-let*` which is defined in `cl`, but it only
requires `cl-lib` where it is not defined.
I found this because I use
`org-contacts-message-complete-function` to autocomplete
Nicolas Goaziou writes:
> "Bruce D'Arcus" writes:
>
>> In general (conceptually), if you have one footnote in text, and one
>> in a footnote, with a note style, both will be rendered as footnotes.
>>
>> So in an adapted version from earlier:
>>
>>
>> Text 1 [@cite:@a].
>> Text 2[fn:1].
>>
>
Hello,
András Simonyi writes:
> well, I think there might be some legitimate use cases, e.g.,
> (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103)
This use-case is not convincing, because it ought to be the task of the
citation processor to italicize "cf." (perhaps through an o
On 19/04/2021 17:53, David Asabina wrote:
javascript:location.href = \\='org-protocol://capture?url=\\='+ \\
-encodeURIComponent(location.href) + \\='&title=\\=' \\
+encodeURIComponent(location.href) + \\='&title=\\=' + \\
encodeURIComponent(document.title) + \\='
Dear All,
On Fri, 23 Apr 2021 at 13:49, Nicolas Goaziou wrote:
> I went ahead and implemented `org-cite-wrap-citation' function in
> "oc.el" (from wip-cite-new branch). Here's a quick demo.
> --8<---cut here---start->8---
> (defun ngz-cite-demo-export-citatio
On Fri, Apr 23, 2021 at 8:56 AM András Simonyi wrote:
> Thank you, this is very promising! I've checked the behaviour of
> citeproc-org with and without a note style now and there is only one
> additional minor difference which I forgot to mention, I don't know
> how difficult would it be to imp
On Fri, Apr 23, 2021 at 9:10 AM Bruce D'Arcus wrote:
> I also forgot to mention this detail, and agree it's important to be
> able to do: to modify punctuation around such "footnoted-citations".
While I'm on it, one other related detail:
It can be that not only does the space get removed, but t
Dear All,
On Fri, 23 Apr 2021 at 14:03, Nicolas Goaziou wrote:
>> well, I think there might be some legitimate use cases, e.g.,
>> (see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103)
> This use-case is not convincing, because it ought to be the task of the
> citation processor t
On Fri, 23 Apr 2021 at 15:24, Bruce D'Arcus wrote:
> It can be that not only does the space get removed, but the note mark
> is moved outside the period.
>
> So if you have ...
>
> Some sentence with a concluding citation [cite:@key].
>
> ... that should end up like this:
>
> Some sentence with a
On 21/04/2021 23:24, Nicolas Goaziou wrote:
In particular, I'm not sure to understand how one system can generate an
ID based on the heading content and still limit itself to alphanumeric
characters. For example, what ID are generated with the following
document?
My impression is that such con
Hello,
Attempting to export with any exporter fails if document or a subtree
thereof contains an email link, e.g. captured from a Gnus buffer:
[[gnus:GroupName#EMAIL_ID][Email from John Doe]]
I get the error:
user-error: Unable to resolve link:
"gnus:Melanie#ef90b1cff5264135a82bff491006b...@ca
python is merely using a different romanization for the second script.
it might consider uppercase [same romanization] for the latter script
instead. other than that, the overall approach [using export] is good
imo.
idk what transliterators exist in emacs. i think the principle of
least surprise
[and also that i was merely looking at the examples and maxim's
analysis which i agree with, not tec's or others' code.]
On 4/23/21, Samuel Wales wrote:
> i should point out that idk what is allowed in links. if uppercase is
> not, then script need not be indicated or can just use a prefix.
>
>
i should point out that idk what is allowed in links. if uppercase is
not, then script need not be indicated or can just use a prefix.
On 4/23/21, Samuel Wales wrote:
> python is merely using a different romanization for the second script.
> it might consider uppercase [same romanization] for th
On Fri, Apr 23, 2021 at 9:24 AM Bruce D'Arcus wrote:
> Aside: looking through the CSL spec, it doesn't seem this is
> documented. It obviously should be.
>
> And I don't remember if that convention is locale-specific; e.g. if
> while that's the standard in English, it could be different in France
Nicolas,
Quick syntax question:
On Wed, Apr 21, 2021 at 7:34 PM Nicolas Goaziou wrote:
> As a reminder, the full citation syntax is
>
> [cite/style:common prefix ;prefix -@key suffix; ... ; common suffix]
Is the space you have here before the semi-colon significant as part
of the delimiter,
Maxim Nikulin writes:
> python3 -c 'import unidecode; print(unidecode.unidecode("こんにちは"))'
> konnichiha
>
> python3 -c 'import unidecode; print(unidecode.unidecode("ｺﾝﾆﾁﾊ"))'
> konnitiha
It looks like this isn't built into Emacs, and a package would be
needed: https://github.com/sindikat/unide
Uwe Brauer writes:
> I am running GNU emacs and org mode, whose versions are specified below.
> Sometimes when being in a gnus message buffer and running org-capture
> I obtain an error whose bug trace I attach. Usually I have to restart
> emacs.
>
> ,
> |
> | Debugger entered--Lisp error: (e
Seb writes:
> Hello,
>
> Attempting to export with any exporter fails if document or a subtree
> thereof contains an email link, e.g. captured from a Gnus buffer:
>
> [[gnus:GroupName#EMAIL_ID][Email from John Doe]]
>
> I get the error:
>
> user-error: Unable to resolve link:
> "gnus:Melanie#ef90
Hi All,
This patch improves the result of running org-plot in the following
situation
#+plot: ... file:"somefile.png"
[[file:somefile.png]]
Previously, when somefile.png is re-plotted the [[file:]] inline image
did not refresh. With this patch, after plotting, overlays of the
replotted image ar
Michael Eliachevitch writes:
> Dear all,
>
> I'm not sure if this is the correct mailinglist for org-contrib
> bugs.
Thanks for the report. Yes, this is the place [*]. stardiviner (+cc)
recently took over maintaining org-contacts.el.
> I found that org-contacts.el uses `lexical-let*` which is
23 matches
Mail list logo
