Re: org-contacts.el use lexical-let not defined in cl-lib

2021-04-23 Thread Kyle Meyer
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

[PATCH] Refresh inline plotted images

2021-04-23 Thread Timothy
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

Re: unable to resolve link to Gnus email

2021-04-23 Thread Kyle Meyer
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

Re: Bug: org-caputure fails, sometimes [9.3.7 (release_9.3.7-705-gea9463 @ /home/oub/emacs/site-lisp/packages/org/)]

2021-04-23 Thread Kyle Meyer
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

Re: stability of toc links

2021-04-23 Thread Timothy
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

Re: (Not so) Short note about citations in Org

2021-04-23 Thread Bruce D'Arcus
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,

Re: wip-cite status question and feedback

2021-04-23 Thread Bruce D'Arcus
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

Re: stability of toc links

2021-04-23 Thread Samuel Wales
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

Re: stability of toc links

2021-04-23 Thread Samuel Wales
[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. > >

Re: stability of toc links

2021-04-23 Thread Samuel Wales
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

unable to resolve link to Gnus email

2021-04-23 Thread Seb
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

Re: stability of toc links

2021-04-23 Thread Maxim Nikulin
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

Re: wip-cite status question and feedback

2021-04-23 Thread András Simonyi
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

Re: wip-cite status question and feedback

2021-04-23 Thread András Simonyi
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

Re: wip-cite status question and feedback

2021-04-23 Thread Bruce D'Arcus
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

Re: wip-cite status question and feedback

2021-04-23 Thread Bruce D'Arcus
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

Re: wip-cite status question and feedback

2021-04-23 Thread András Simonyi
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

Re: [PATCH] org-protocol: Fix missing '+' in js snippet

2021-04-23 Thread Maxim Nikulin
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) + \\='

Re: wip-cite status question and feedback

2021-04-23 Thread Nicolas Goaziou
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

Re: wip-cite status question and feedback

2021-04-23 Thread Nicolas Goaziou
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]. >> >

org-contacts.el use lexical-let not defined in cl-lib

2021-04-23 Thread Michael Eliachevitch
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

Re: Backwards compatability

2021-04-23 Thread Eric S Fraga
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

Re: Idea for handling timezones

2021-04-23 Thread tomas
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