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

[Uwe Brauer]

> Uwe Brauer writes:


Hi


> With this backtrace alone (which involves org-capture catching the
> internal error), I think it's going to be hard for anyone to guess
> what's going on here.  It sounds like once you encounter this error,
> subsequent calls reliably trigger it.  Next time you run into it, I'd
> suggest re-evaluating org-capture to something like below to hopefully
> see a more informative backtrace.

> diff --git a/lisp/org-capture.el b/lisp/org-capture.el
> index 831c3e1f4..b20124ced 100644
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -693,9 +693,7 @@ (defun org-capture (&optional goto keys)
> (string-prefix-p "CAPTURE-" (buffer-name)))
>(kill-buffer (current-buffer)))
>  (set-window-configuration (org-capture-get :return-to-wconf))
> -(error "Capture template `%s': %s"
> -   (org-capture-get :key)
> -   (error-message-string error
> +(signal (car error) (cdr error
>   (when (and (derived-mode-p 'org-mode) (org-capture-get :clock-in))
> (condition-case nil
> (progn

Thanks, I pulled applied your patch and compiled, let us see what comes
out of it.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature

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

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> 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, or is it part of the prefix?

The delimiter is the semi-colon. Space is part of the prefix.
>
> prefix ;prefix
>
> So if I enter common prefix text as "prefix" and common suffix as
> "suffix", is this correct output?
>
>  ELISP> (bibtex-actions-format-citation-org (list "doe1" "doe2"))
> "[cite:prefix ;@doe1;@doe2; suffix]"
>
> ... or should it be:
>
> "[cite:prefix;@doe1;@doe2;suffix]"

The latter if you don't want to see space in prefix or suffix, i.e., if
this is "prefix" and "suffix".

Regards,
-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

Hello,

M. ‘quintus’ Gülker  writes:

> I sometimes use emphasis around citations, but since my citation
> styles all use footnotes, I think there should be no problem with
> this. For example, I would write something like this (I hope I got the
> syntax right):
>
> This is a test sentence[fn:1].
>
> * Footnotes
>
> [fn:1] See e.g. [cite:@doe1993 pp. 32-35], who explicitely argues
> /against/ the suggestion made by [cite:@someone1990 p. 50].
>
> Since the emphasis markers on the word "against" are outside the two
> citations, I would expect no problem here.

Indeed, there is no problem above. The discussion is about emphasis
within prefix or suffix.

Regards,
-- 
Nicolas Goaziou

Re: Bug: Incorrect duration format example in comments in 'org-duration.el' [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[Johnson]

Yes, the issue is due to using an older version of Org.

I searched the change log and saw that the compact form is introduced in 
Org 9.4, while mine is 9.3.


Thanks for your help!

Sincerely,
Johnson

On 4/20/2021 9:42 PM, NicolasGoaziou wrote:

Hello,

Johnson  writes:


I'm contributing to an org file python parser to correctly parse durations.

I found the comments in org-duration.el
(https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-duration.el#L31
),
mentioning that `1d3h5min` is a valid duration format.

So, I expect the following should work:

M-x eval-expression 
(org-duration-string-to-minutes "1d3h5min") 

I cannot reproduce it. I get 1625.0.

Maybe your Org is too old. So-called "compact" form was introduced after the 
others.

Regards,

org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

Hi Nicolas,

As I was working on adding a function to generate the new cite syntax,
an idea occurred to me that I'd like to raise, that would simplify
this model and syntax.

I ran the idea by the pandoc list just to confirm my thinking was
reasonable, since that has a lot of experience using these plain-text
citations.

https://groups.google.com/g/pandoc-discuss/c/zbntclaBWDc/m/DCx-mpfcDQAJ

Let's review:

In org-cite, we have citations, and citation items.

Citations may have optional styles.

Citation items may have an optional "suppress-author" "variant",
indicated with a "-". So:

[cite:-doe19;doe20]

The idea:

This distinction is wrong, and we should treat "suppress-author" as a
citation style instead.

The result would be:

[cite/supress-author:doe19;doe20]

Or even can keep the shorthand:

[cite/-:doe19;doe20]

In fact, with the change, could even remove it entirely

If you read the discussion in the pandoc list, there is mild, but I
don't think convincing, pushback.

Part of that pushback is an artifact of the fact that pandoc citations
don't have a notion of citation style, where you specify things like

OTOH, pandoc and (haskell) citeproc author John MacFarlane agrees that
in retrospect the pandoc decision was probably wrong, in part because
of another related issue.

Supress-author is a convention that CSL implementations settled on,
arguably a hack, to get around lack of explicit support for natbib
citet-like citations (though this is being added in the next version).

So to get "Doe (2019) argues" you would need to write "Doe [@doe19]"
in pandoc, for example.

But if you can do this in org-cite, "suppress-author" is no longer needed:

"[cite/text:@doe19] argues ..."

Both should probably be possible, but the textual (aka narrative)
style is what most users are looking for there IMO.

I think a positive side-effect is this model would match better LaTeX
output models (natbib and biblatex namely).

WDYT?

Bruce

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

[Bruce D'Arcus]

On Sat, Apr 24, 2021 at 3:53 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > 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, or is it part of the prefix?
>
> The delimiter is the semi-colon. Space is part of the prefix.

Got it; thanks!

Now implemented, which some docstring examples borrowed from your
explanation, and adding a few to clarify the different prefix/suffix
levels, that could be valuable for org documentation?

https://github.com/bdarcus/bibtex-actions/pull/113/commits/d7869c409751f065197a689579bd5e13ff1ed2ff

Bruce

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

Correction, though it doesn't change the conclusion.

On Sat, Apr 24, 2021 at 6:52 AM Bruce D'Arcus  wrote:

> So to get "Doe (2019) argues" you would need to write "Doe [@doe19]"
> in pandoc, for example.

Incorrect: the pandoc syntax for citet-like rendering is:

@doe19

So to drop the brackets.

Bruce

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

> 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 implement it: When a citation is wrapped
> into an anonymous footnote because a note style is used then the space
> between the citation and the previous token (if there was one) is
> removed.

Done.

Note, however, that this introduces some discrepancy with regards to
footnotes. In the following document

--8<---cut here---start->8---
1. Text [fn::[cite:@key]].

2. Text [cite:@key].

3. Text [fn:1].
--8<---cut here---end--->8---

only the space on the second line will be removed (assuming the cite has
note style) because Org does not move space around footnotes.

It does not sound to bad, tho.

Regards,
-- 
Nicolas Goaziou

Re: [Patch] to correctly sort the items with emphasis marks in a list

[Maxim Nikulin]

On 21/04/2021 22:45, Juan Manuel Macías wrote:


I have tried the Nicolas' patch (latest version) and I see that the
items with emphasis are already ordered well. However, it seems that the
problem with identical items with or without emphasis still persists:
which items should go before and in what order? For example, in the
following list I get:

- /a/
- *a*
- a
- *b*
- /b/
- b
- /v/
- *v*
- v


I am afraid, there is no easy way to take into account emphasis. Each 
item have to be split into logical units and locale-aware multilevel 
comparison should be applied to each unit separately. E.g. for 
description list, only term should be compared at first to properly 
order emphasized items, it does not matter if description starts from 
"a" or from "z". Simple `string-collate-lessp' for whole item uses 
further levels only strings are considered identical on previous levels. 
I had an idea to augment sort keys with some text properties for custom 
string comparator, but I decided that such complications would not 
ensure reliable sort for all possible cases.


- A :: B
- /A/ :: C
- *A* :: A

However `org-sort-remove invisible' still has some room for improvements 
(it is not mandatory in my opinion). I have realized it reading the 
thread on title representation for HTML export

https://orgmode.org/list/87h7jy4ebe@nicolasgoaziou.fr/

- <>A
- <<>>
- B

Re: org-cite: make 'suppress-author' a citation 'style'

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> This distinction is wrong, and we should treat "suppress-author" as a
> citation style instead.
>
> The result would be:
>
> [cite/supress-author:doe19;doe20]
>
> Or even can keep the shorthand:
>
> [cite/-:doe19;doe20]
>
> In fact, with the change, could even remove it entirely

We introduced :suppress-author because someone requested it at some
point. I don't remember who, but it may be worth asking that person.

I think there are two points to consider before removing suppress-author
syntax:

1. does it make sense to apply it independently on references within
   a full citation?

2. does it make sense to apply it on top of another style?

If both answers are no, this can definitely go away.

> Or even can keep the shorthand:
> 
> [cite/-:doe19;doe20]

Note that Org Citation library does not recognize styles. It is up to
the processor to interpret it as a short-hand for "suppress-author".

Regards,
-- 
Nicolas Goaziou

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

On Sat, Apr 24, 2021, 1:08 PM Nicolas Goaziou 
wrote:

> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > This distinction is wrong, and we should treat "suppress-author" as a
> > citation style instead.
> >
> > The result would be:
> >
> > [cite/supress-author:doe19;doe20]
> >
> > Or even can keep the shorthand:
> >
> > [cite/-:doe19;doe20]
> >
> > In fact, with the change, could even remove it entirely
>
> We introduced :suppress-author because someone requested it at some
> point. I don't remember who, but it may be worth asking that person.
>

I did some quick searching.

Wow; this goes back a long time!

Anyway, Richard Lawrence summarized previous discussions, which includes
this detail, in this 2015 post:

https://lists.gnu.org/archive/html/emacs-orgmode/2015-02/msg00932.html

Not sure if he introduced the idea or not, but if not, he should know.

I think there are two points to consider before removing suppress-author
> syntax:
>
> 1. does it make sense to apply it independently on references within
>a full citation?
>
> 2. does it make sense to apply it on top of another style?
>

Yes; excellent summary.

As I say, my impulse is to say no to both, outside some corner cases that
people could work around in other ways.

But I hope people will challenge me if this is a bad idea.

And hopefully Richard can weigh in.

If both answers are no, this can definitely go away.
>
> > Or even can keep the shorthand:
> >
> > [cite/-:doe19;doe20]
>
> Note that Org Citation library does not recognize styles. It is up to
> the processor to interpret it as a short-hand for "suppress-author".
>

Right; I understand.

Bruce

>

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 23. April 2021 um 09:24 Uhr -0400 schrieb Bruce D'Arcus:
> 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 concluding citation.[1]
> 
> 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.

As for German, the semantics are different. In Law discipline, in some
journals (not all) both styles can be used within the very same
document and have different meanings. That is,

> This is an example sentence, with a half-sentence following.¹

means that the citation ¹ references the entire sentence, whereas

> This is an example sentence, with a half-sentence following¹.

means that it references only the part following the comma ("with a
half-sentence following"). Normalising this into one uniform style
would be a semantic error. Not all journals handle it like that,
though. Some do prefer uniform look and glance over the semantic
difference.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu |For security:
Passau, Germany  | kont...@guelker.eu| () Avoid HTML e-mail
European Union   | PGP: see homepage | /\ http://asciiribbon.org

Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> Some sentence with a concluding citation [cite:@key].
>
> ... that should end up like this:
>
> Some sentence with a concluding citation.[1]
>
> 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.
>
> In any case, this sort of punctuation modification should be possible.

Could you show more example of this, possibly including quotes the
citation, or better, a precise description of the punctuation
modification you have in mind?

What may be possible to do is to have `org-cite-wrap-footnote' doing
such a modification according to an optional argument. So any caller
(i.e., a processor) could choose to activate it or not, perhaps
according to language.


Regards,
-- 
Nicolas Goaziou

Re: wip-cite status question and feedback

[Bruce D'Arcus]

On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > Some sentence with a concluding citation [cite:@key].
> >
> > ... that should end up like this:
> >
> > Some sentence with a concluding citation.[1]
> >
> > 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.
> >
> > In any case, this sort of punctuation modification should be possible.
>
> Could you show more example of this, possibly including quotes the
> citation, or better, a precise description of the punctuation
> modification you have in mind?

Yes.

Denis lays it out in this comment:

https://github.com/citation-style-language/documentation/issues/139#issuecomment-825934813

What he's arguing is that the rules vary by locale, with German, for
example (he's employed at a Swiss-German institution, I believe),
having different conventions than English, and American English
different than British English.

But an example from American English for illustration, derived from
Denis' examples.

"A simple quote" [cite:@doe].

When rendered, that should be this in an author-date style:

"A simple quote" (Doe 2021).

... and this in a note style:

"A simple quote."[^1]

So that rule would suggest something like:

- if a citation concludes a sentence, move the note mark and whatever
trailing quotation mark, outside the period.

But, Denis continues, "While this is perfectly acceptable in American
English, it is not in German, or even in British English. Here we have
to know whether the final period is part of the original quotation. If
yes, it will be put inside the quotes, otherwise outside." I'll paste
the rest of his examples at the end.

It's possible his rule here is more general, and would still be
acceptable in American English.

Does that help explain?

> What may be possible to do is to have `org-cite-wrap-footnote' doing
> such a modification according to an optional argument. So any caller
> (i.e., a processor) could choose to activate it or not, perhaps
> according to language.

This sounds like what would be needed, maybe with a sensible default.

Bruce

>>> Denis' other examples:

Quotation ending with a period:

"A simple quote."[^1]

Quotation not ending with a period:

Variant a)

"A simple quote".[^1]

Variant b)

"A simple quote"[^1].

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

I also came across this post from 2018 from Andras ...

https://orgmode.org/list/87in8jaywk@all.hu/

... which includes a link to his proposal on what we now call styles,
but there he calls (a la the TeX world) commands:

https://github.com/andras-simonyi/citeproc-el/wiki/Citation-types-and-commands

There, he includes "suppress author" as one among those.

Bruce

Re: org-cite: make 'suppress-author' a citation 'style'

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> I also came across this post from 2018 from Andras ...
>
> https://orgmode.org/list/87in8jaywk@all.hu/
>
> ... which includes a link to his proposal on what we now call styles,
> but there he calls (a la the TeX world) commands:
>
> https://github.com/andras-simonyi/citeproc-el/wiki/Citation-types-and-commands
>
> There, he includes "suppress author" as one among those.

In both links, he considers stacking a style with suppress-author, for
example "bare" and "bare + s.a". 

So that would be an argument for keeping suppress-author.

Regards,
-- 
Nicolas Goaziou

[PATCH] org-capture.el: Add new capture template option :refile-to

[Richard Garner]

Hi all,

The included patch adds a new property :refile-to to org capture
templates, allowing each template to have its own set of refile targets.
I find this really useful in practice and thought others might too.

Richard

---

>From 829c1ba4805327645fcb75b35b73ecb3a1700b2f Mon Sep 17 00:00:00 2001
From: Richard Garner 
Subject: 

* lisp/org-capture.el (org-capture-refile): bind `org-refile-targets'
to value of local capture template property :refile-to around call to
`org-refile'.

(org-capture-templates): document new capture template property
:refile-to.

TINYCHANGE
---
 lisp/org-capture.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9fbd00ccd..64ecd5fe1 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -246,6 +246,10 @@ properties are:
 
  :jump-to-captured   When set, jump to the captured entry when finished.
 
+ :refile-to  When exiting capture mode via `org-capture-refile', the
+ variable `org-refile-targets' will be temporarily bound
+ to the value of this property.
+
  :empty-linesSet this to the number of lines that should be inserted
  before and after the new item.  Default 0, only common
  other value is 1.
@@ -885,7 +889,8 @@ for `entry'-type templates"))
 (pos (make-marker))
 (org-capture-is-refiling t)
 (kill-buffer (org-capture-get :kill-buffer 'local))
-(jump-to-captured (org-capture-get :jump-to-captured 'local)))
+(jump-to-captured (org-capture-get :jump-to-captured 'local))
+(refile-to (org-capture-get :refile-to 'local)))
 ;; Since `org-capture-finalize' may alter buffer contents (e.g.,
 ;; empty lines) around entry, use a marker to refer to the
 ;; headline to be refiled.  Place the marker in the base buffer,
@@ -895,11 +900,12 @@ for `entry'-type templates"))
 ;; early.  We want to wait for the refiling to be over, so we
 ;; control when the latter function is called.
 (org-capture-put :kill-buffer nil :jump-to-captured nil)
-(org-capture-finalize)
-(save-window-excursion
-  (with-current-buffer base
-   (org-with-point-at pos
- (call-interactively 'org-refile
+(let ((org-refile-targets (or refile-to org-refile-targets)))
+  (org-capture-finalize)
+  (save-window-excursion
+(with-current-buffer base
+ (org-with-point-at pos
+   (call-interactively 'org-refile)
 (when kill-buffer
   (with-current-buffer base (save-buffer))
   (kill-buffer base))
-- 
2.17.2 (Apple Git-113)

Re: [PATCH] org-capture.el: Add new capture template option :refile-to

[Richard Garner]

Sorry, messed up the patch attachment, will resend in a new thread.

Richard


Richard Garner  writes:

> Hi all,
>
> The included patch adds a new property :refile-to to org capture
> templates, allowing each template to have its own set of refile targets.
> I find this really useful in practice and thought others might too.
>
> Richard
>
> ---
>
> From 829c1ba4805327645fcb75b35b73ecb3a1700b2f Mon Sep 17 00:00:00 2001
> From: Richard Garner 
> Subject: 
>
> * lisp/org-capture.el (org-capture-refile): bind `org-refile-targets'
> to value of local capture template property :refile-to around call to
> `org-refile'.
>
> (org-capture-templates): document new capture template property
> :refile-to.
>
> TINYCHANGE
> ---
>  lisp/org-capture.el | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/lisp/org-capture.el b/lisp/org-capture.el
> index 9fbd00ccd..64ecd5fe1 100644
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -246,6 +246,10 @@ properties are:
>  
>   :jump-to-captured   When set, jump to the captured entry when finished.
>  
> + :refile-to  When exiting capture mode via `org-capture-refile', the
> + variable `org-refile-targets' will be temporarily bound
> + to the value of this property.
> +
>   :empty-linesSet this to the number of lines that should be inserted
>   before and after the new item.  Default 0, only common
>   other value is 1.
> @@ -885,7 +889,8 @@ for `entry'-type templates"))
>(pos (make-marker))
>(org-capture-is-refiling t)
>(kill-buffer (org-capture-get :kill-buffer 'local))
> -  (jump-to-captured (org-capture-get :jump-to-captured 'local)))
> +  (jump-to-captured (org-capture-get :jump-to-captured 'local))
> +  (refile-to (org-capture-get :refile-to 'local)))
>  ;; Since `org-capture-finalize' may alter buffer contents (e.g.,
>  ;; empty lines) around entry, use a marker to refer to the
>  ;; headline to be refiled.  Place the marker in the base buffer,
> @@ -895,11 +900,12 @@ for `entry'-type templates"))
>  ;; early.  We want to wait for the refiling to be over, so we
>  ;; control when the latter function is called.
>  (org-capture-put :kill-buffer nil :jump-to-captured nil)
> -(org-capture-finalize)
> -(save-window-excursion
> -  (with-current-buffer base
> - (org-with-point-at pos
> -   (call-interactively 'org-refile
> +(let ((org-refile-targets (or refile-to org-refile-targets)))
> +  (org-capture-finalize)
> +  (save-window-excursion
> +(with-current-buffer base
> +   (org-with-point-at pos
> + (call-interactively 'org-refile)
>  (when kill-buffer
>(with-current-buffer base (save-buffer))
>(kill-buffer base))

[PATCH] org-capture.el: Add new capture template option :refile-to

[Richard Garner]

Hi all,

(Resending after messing up the first time.)

The included patch adds a new property :refile-to to org capture
templates, allowing each template to have its own set of refile targets.
I find this really useful in practice and thought others might too.

Richard

>From 829c1ba4805327645fcb75b35b73ecb3a1700b2f Mon Sep 17 00:00:00 2001
From: Richard Garner 
Date: Tue, 13 Apr 2021 13:53:49 +1000
Subject: [PATCH] org-capture.el: Add new capture template option :refile-to

* lisp/org-capture.el (org-capture-refile): bind `org-refile-targets'
to value of local capture template property :refile-to around call to
`org-refile'.

(org-capture-templates): document new capture template property
:refile-to.

TINYCHANGE
---
 lisp/org-capture.el | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9fbd00ccd..64ecd5fe1 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -246,6 +246,10 @@ properties are:
 
  :jump-to-captured   When set, jump to the captured entry when finished.
 
+ :refile-to  When exiting capture mode via `org-capture-refile', the
+ variable `org-refile-targets' will be temporarily bound
+ to the value of this property.
+
  :empty-linesSet this to the number of lines that should be inserted
  before and after the new item.  Default 0, only common
  other value is 1.
@@ -885,7 +889,8 @@ for `entry'-type templates"))
 	 (pos (make-marker))
 	 (org-capture-is-refiling t)
 	 (kill-buffer (org-capture-get :kill-buffer 'local))
-	 (jump-to-captured (org-capture-get :jump-to-captured 'local)))
+	 (jump-to-captured (org-capture-get :jump-to-captured 'local))
+	 (refile-to (org-capture-get :refile-to 'local)))
 ;; Since `org-capture-finalize' may alter buffer contents (e.g.,
 ;; empty lines) around entry, use a marker to refer to the
 ;; headline to be refiled.  Place the marker in the base buffer,
@@ -895,11 +900,12 @@ for `entry'-type templates"))
 ;; early.  We want to wait for the refiling to be over, so we
 ;; control when the latter function is called.
 (org-capture-put :kill-buffer nil :jump-to-captured nil)
-(org-capture-finalize)
-(save-window-excursion
-  (with-current-buffer base
-	(org-with-point-at pos
-	  (call-interactively 'org-refile
+(let ((org-refile-targets (or refile-to org-refile-targets)))
+  (org-capture-finalize)
+  (save-window-excursion
+(with-current-buffer base
+	  (org-with-point-at pos
+	(call-interactively 'org-refile)
 (when kill-buffer
   (with-current-buffer base (save-buffer))
   (kill-buffer base))
-- 
2.17.2 (Apple Git-113)

Re: org-cite: make 'suppress-author' a citation 'style'

[Bruce D'Arcus]

On Sat, Apr 24, 2021 at 4:09 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > I also came across this post from 2018 from Andras ...
> >
> > https://orgmode.org/list/87in8jaywk@all.hu/
> >
> > ... which includes a link to his proposal on what we now call styles,
> > but there he calls (a la the TeX world) commands:
> >
> > https://github.com/andras-simonyi/citeproc-el/wiki/Citation-types-and-commands
> >
> > There, he includes "suppress author" as one among those.
>
> In both links, he considers stacking a style with suppress-author, for
> example "bare" and "bare + s.a".

Maybe I'm missing something, but can those not be represented with flat styles?

E.g. "bare + s.a." is simply something like "date"?

> So that would be an argument for keeping suppress-author.

The question I raised is less whether that's needed, and more whether
it's a property of the citation, or the individual items within the
citation.

Bruce

Re: [PATCH] org-capture.el: Add new capture template option :refile-to

[Timothy]

Marking this patch as cancelled for updates.orgmode.org.

Re: [PATCH] I updated patch by deleteing duplicate tags

[Timothy]

This was not marked as applied. Doing so with the X-Woof-Patch header.

Kyle Meyer  writes:

> Christopher Miles writes:
>
>> Subject: [PATCH] org.el: Complete tags from both global and buffer local
>
> Thanks.  Applied (86ad8d279)...

Re: [PATCH] New "project" option for org-link-file-path-type

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

Jack Kamm  writes:

> Thanks, I've fixed the remaining issues you pointed out and pushed this
> in 5371b30fe.
>
> Cheers,
> Jack

Re: [final patch] Re: add new link type "contact:" for org-contacts.el

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

Bastien  writes:

> Of course, done (c822c80ef).
>
> Sorry I forgot about this patch, and thanks for your reply.

Re: [PATCH] Apply emacs manual css to org pages

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

Bastien  writes:

> I made this change and tested it online, the HTML Org manual now looks
> like the Emacs manual: https://orgmode.org/manual/
>
> Thanks for the suggestion!

> In any cas, the Emacs manual css is better than my attempt and using
> it for Org makes sense IMO.
>
> Best,

Re: [PATCH] Apply emacs manual css to org pages

[Timothy]

For some reason updates.orgmode.org registered this as a new patch??
Marking as closed via X-Woof-Patch header.

Greg Minshall  writes:

> Timothy,
>
>> This is a quick patch to use the Emacs manual CSS with our generated Org
>> manual.
>
> that's certainly visually pleasing.  nice!
>
> Greg

Re: [PATCH] ol: Avoid initial input when completing function for storing link

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

Kyle Meyer  writes:

> Pushed (00b4de329).

Re: [PATCH] org-contacts.el: Use `bound-and-true-p' to check (unbound) var

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

miles christopher  writes:

> Applied, I think this should be the final version.

Re: [PATCH] ob-java, a proposal on import improvement

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

ian martins  writes:

> It's no problem. Didn't mean to rush you. Thanks again for the patch. Applied.

Re: [PATCH] ob-java: Allow import to end with asterisk

[Timothy]

This was not marked as applied on updates.orgmode.org.
Doing so with the X-Woof-Patch header.

ian martins  writes:

> Thanks. And thanks for taking the time to fix issues that you find. It
> continues to improve because of your contributions.
> The patch looks good. Applied.

Re: [PATCH] Startup option to separate macros arguments with an alternative string

[Timothy]

As you have said you'll start a new thread for your revised proposal,
I'll mark this as closed on updates.orgmode.org via the X-Woof-Patch
header.

Juan Manuel Macías  writes:

> Ok, I agree. Next week I will start a new thread for submit this new
> proposal.
>
> Best regards,
>
> Juan Manuel

Re: [PATCH 0/1] Add option to delay fontification of source blocks

[Timothy]

Marking as closed on updates.orgmode.org via the X-Woof-Patch header.

Leo Okawa Ericson  writes:

> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.

Re: [PATCH 0/1] Add option to delay fontification of source blocks

[Timothy]

Marking as closed on updates.orgmode.org via the X-Woof-Patch header.

Leo Okawa Ericson  writes:

> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.

Re: [PATCH 0/1] Add option to delay fontification of source blocks

[Timothy]

Marking as closed on updates.orgmode.org via the X-Woof-Patch header.

Leo Okawa Ericson  writes:

> I can't think of a reason either (now that I know that jit-lock exists)
> so I will retract my patch.

Re: [final patch] Re: add new link type "contact:" for org-contacts.el

[Timothy]

I'm afraid it looks like I either made a typo while doing this, or
something odd happened. Regardless it didn't work correctly.

Take 2, sorry for the noise --- but at least the patch section on
updates.orgmode.org should be more useful now as it only shows pending
patches again.

Timothy  writes:

> This was not marked as applied on updates.orgmode.org.
> Doing so with the X-Woof-Patch header.
>
> Bastien  writes:
>
>> Of course, done (c822c80ef).
>>
>> Sorry I forgot about this patch, and thanks for your reply.

Re: Concerns about community contributor support

[Bastien]

Dear Timothy,

thanks for raising this points so carefully, they are important.

I see three distinct problems:

1. The lack of response and/or follow-up when people contribute by
   sending bug reports or patches on the list.

2. The lack of maintainance on documenting the contribution process
   and the correct expectations for future contributors.

3. The inherent difficulty to move the Org codebase forward.

I won't comment on (3).  For (1) and (2), I suggest appointing a
"contributor steward" with these responsibilities:

1. Maintain updates.orgmode.org (i.e. make sure it is accurate.)
2. Maintain the documentation for contributors.
3. Help contributors enhancing their patches.
4. Try to reproduce bugs (and confirm them for updates.orgmode.org)
5. Make sure patch contributors are not left with no answer.

You started (1), which is really appreciated.

Tim and others mentioned (2), and that's certainly needed too.

(3) has historically been the role of the maintainer and of the core
contributors, but helping with this is very welcome: knowing the doc
at https://orgmode.org/worg/org-contribute.html by heart, educating
contributors on the commit messages, etc.  This all helps.

(4) is perhaps the most daunting task: I even think we could have
someone only dedicated to this very important task.  Just count the
number of times Nicolas says "I cannot reproduce this."  Each time,
there is a real bug that is *not* fixed...

(5) is not about systematically welcome patch submitters with a
message (that would be annoying) but to monitor updates.orgmode.org
and decide what to do with a patch that didn't receive feedback:
either say thanks and ping the list for why you think the patch
deserves more attention, or thanks and dismiss the patch, or another
answer.

What do you think?  Would you be willing to take this role?

If not, that's perfectly okay, I'll send a call for help.

Thanks,

-- 
 Bastien

Re: Backwards compatability

[Bastien]

Hi Bithov,

we *do* care a lot about backward compatibility*.

We cannot make a strong commitment for contributed libraries and
external ones, though, otherwise Org would not evolve.

org-drill.el was removed from the contrib/ directory 1 year ago:
https://code.orgmode.org/bzg/org-mode/commit/2c8e8b4a

Perhaps you can try to find someone who wants to maintain it.

* https://bzg.fr/en/the-software-maintainers-pledge/

-- 
 Bastien

Re: [tip] search this mailing list with helm-surfraw

[Bastien]

Hi Juan,

Juan Manuel Macías  writes:

> I have written some elvis for my
> personal use, among them this simple script to search this mailing list,
> which I share here in case someone finds it useful:

Neat!  

You might want to write another one for the public-inbox archive:

E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas

Re: [tip] search this mailing list with helm-surfraw

[Greg Minshall]

Bastien,

> You might want to write another one for the public-inbox archive:
>
> E.g. https://orgmode.org/list/?q=Juan+Manuel+Mac%C3%ADas


okay, i'll bite: what *is* the difference between
https://orgmode.org/list and
https://lists.gnu.org/archive/html/emacs-orgmode/ ?

cheers, Greg

Contributor Steward role (was Re: Concerns about community contributor support)

[Timothy]

Dear Bastien,

Thank you for your well-thought-out reply.
With regards to the question your email ends with:

> What do you think?  Would you be willing to take this role?
> If not, that's perfectly okay, I'll send a call for help.

The short answer is "yes, mostly". The long answer follows :P

I also think that regardless it would be good to put out a call asking
if anyone else is interested/willing to do this: I'm going to be busy
sometimes, a reduced workload is clearly preferable, and less should
slip through the cracks :)

Bastien  writes:

> Dear Timothy,
>
> thanks for raising this points so carefully, they are important.
>
> I see three distinct problems:
>
> A. The lack of response and/or follow-up when people contribute by
>sending bug reports or patches on the list.

This is something I'm definitely happy to help with.

> B. The lack of maintainance on documenting the contribution process
>and the correct expectations for future contributors.

I'm happy to document this, but I don't know what expectations should be
set. I think this is a matter that should be decided by consensus among
the current/active maintainers.

> C. The inherent difficulty to move the Org codebase forward.

I think there are some things that can be done to improve the structure
and system of contribution/development, but I'm waiting on external
developments and it will take a fair bit of my time to properly
implement a prototype. ETA 1-2 years.

> I won't comment on (C).  For (A) and (B), I suggest appointing a
> "contributor steward" with these responsibilities:
>
> 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.)
> 2. Maintain the documentation for contributors.
> 3. Help contributors enhancing their patches.
> 4. Try to reproduce bugs (and confirm them for updates.orgmode.org)
> 5. Make sure patch contributors are not left with no answer.
>
> You started (1), which is really appreciated.

I'll try to keep this up :)

> Tim and others mentioned (2), and that's certainly needed too.

See my comment on (B) above.

> (3) has historically been the role of the maintainer and of the core
> contributors, but helping with this is very welcome: knowing the doc
> at https://orgmode.org/worg/org-contribute.html by heart, educating
> contributors on the commit messages, etc.  This all helps.

I can give this a go :)

> (4) is perhaps the most daunting task: I even think we could have
> someone only dedicated to this very important task.  Just count the
> number of times Nicolas says "I cannot reproduce this."  Each time,
> there is a real bug that is *not* fixed...

Mmmm, even if I say I'm willing to do this, I suspect this is something
I'd by nature push off enough that I'd frequently forget about this 😅.

> (5) is not about systematically welcome patch submitters with a
> message (that would be annoying) but to monitor updates.orgmode.org
> and decide what to do with a patch that didn't receive feedback:
> either say thanks and ping the list for why you think the patch
> deserves more attention, or thanks and dismiss the patch, or another
> answer.

This is how I see this two. As I indicated at the start, I'm happy to do
this, but I think a second person would help ensure that nobody slips
through the cracks.

--
Timothy

Re: org-cite: make 'suppress-author' a citation 'style'

[András Simonyi]

Dear All,

my 2c on this issue: citeproc-el supports per cite author suppression
under the hood, but citeproc-org always maps "suppress author" mode
citations to suppressing only the first cite, because my impression
was also that this is a citation-level option. This is how the
proposal on the citeproc-el wiki treats it too (which was, BTW, joint
work with Denis Maier).

best regards,
András

On Sun, 25 Apr 2021 at 00:52, Bruce D'Arcus  wrote:
>
> On Sat, Apr 24, 2021 at 4:09 PM Nicolas Goaziou  
> wrote:
> >
> > Hello,
> >
> > "Bruce D'Arcus"  writes:
> >
> > > I also came across this post from 2018 from Andras ...
> > >
> > > https://orgmode.org/list/87in8jaywk@all.hu/
> > >
> > > ... which includes a link to his proposal on what we now call styles,
> > > but there he calls (a la the TeX world) commands:
> > >
> > > https://github.com/andras-simonyi/citeproc-el/wiki/Citation-types-and-commands
> > >
> > > There, he includes "suppress author" as one among those.
> >
> > In both links, he considers stacking a style with suppress-author, for
> > example "bare" and "bare + s.a".
>
> Maybe I'm missing something, but can those not be represented with flat 
> styles?
>
> E.g. "bare + s.a." is simply something like "date"?
>
> > So that would be an argument for keeping suppress-author.
>
> The question I raised is less whether that's needed, and more whether
> it's a property of the citation, or the individual items within the
> citation.
>
> Bruce
>

Re: [tip] search this mailing list with helm-surfraw

[Bastien]

Hi Greg,

Greg Minshall  writes:

> okay, i'll bite: what *is* the difference between
> https://orgmode.org/list and
> https://lists.gnu.org/archive/html/emacs-orgmode/ ?

https://lists.gnu.org/archive/html/emacs-orgmode/ is the official
archive of the GNU mailing list called emacs-orgmode@gnu.org.

https://orgmode.org/list/ is a public-inbox instance giving access
to the complete archive of the emacs-orgmode@gnu.org mailing list.

>From my experience, searches on https://orgmode.org/list/ are both
more reliable and faster.  Linking to an article on public-inbox is 
also handy, because it relies on the message-id of the email, so
while https://lists.gnu.org/archive is the official place for GNU
mailing lists archives, https://orgmode.org/list/ is the service
we link to both in Worg and Woof! (https://updates.orgmode.org)

I hope this is not confusing.

Re: [PATCH] Async session eval (2nd attempt)

[Timothy]

Hi Jack, Kyle,

This is moving at a glacial pace, but I'd love to see this merged ---
there's clearly a lot of interest in this from the community if not
within this mailing list (ob-async which is more limited has 250 stars
on GitHub).

Jack, do you think you might be able to make these tweaks so I can
implore the maintainers to "just merge this"? :P

Kyle, if Jack doesn't get back to us do you think we could just make
those changes and merge the patch as-is at some point? Or merge it and
then add a commit making these fixes?

--
Timothy.

Kyle Meyer  writes:

> Jack Kamm writes:
>
>> I also have an async implementation for ob-R that's ready after this is
>> merged :)
>
> It's a bit disappointing that only one babel user has tested this out
> and provided feedback, but please feel free to merge this whenever you
> think it's ready.
>
> I'm very happy to leave the babel details to you, but here are minor
> comments from a quick read-through looking for things that will likely
> be changed/cleaned up (either in the Org repo or the Emacs repo) if left
> as is.
>
>> Subject: [PATCH] ob-comint.el, ob-python.el: Async session evaluation
> [...]
>> +;; Async evaluation
>
> For a heading comment, please use at least three semicolons.
>
>   (info "(elisp)Comment Tips")
>
>> +
>> +(defvar-local org-babel-comint-async-indicator nil
>> +  "Regular expression that `org-babel-comint-async-filter' scans for.
>> +It should have 2 parenthesized expressions,
>> +e.g. \"org_babel_async_\\(start\\|end\\|file\\)_\\(.*\\)\". The
>> +first parenthesized expression determines whether the token is
>> +delimiting a result block, or whether the result is in a file. If
>> +delimiting a block, the second expression gives a UUID for the
>> +location to insert the result. Otherwise, the result is in a tmp
>> +file, and the second expression gives the file name.")
>> +
>> +(defvar-local org-babel-comint-async-buffers nil
>> +  "List of org-mode buffers to check for Babel async output results.")
>
> s/org-mode/Org mode/ here and other spots, following
> doc/Documentation_Standards.org and tree-wide cleanups like de24694f0
> (Turn org-mode into Org or Org mode, 2016-08-23).
>
> Also, you're missing two spaces between some sentences.
>
>> +(defmacro org-babel-comint-async-delete-dangling-and-eval
>> +(session-buffer &rest body)
>> +  "Remove dangling text in SESSION-BUFFER and evaluate BODY.
>> +This is analogous to `org-babel-comint-with-output', but meant
>> +for asynchronous output, and much shorter because inserting the
>> +result is delegated to `org-babel-comint-async-filter'."
>> +  (declare (indent 1))
>> +  `(org-babel-comint-in-buffer ,session-buffer
>> + (goto-char (process-mark (get-buffer-process (current-buffer
>> + (delete-region (point) (point-max))
>> + ,@body))
>> +(def-edebug-spec org-babel-comint-async-with-output (sexp body))
>
> Please move this edebug spec to the `declare' form (see 7dd1cfb6c,
> 2021-02-12).
>
>> diff --git a/testing/lisp/test-ob-python.el b/testing/lisp/test-ob-python.el
>> index a2cc7b79c..0267678cd 100644
>> --- a/testing/lisp/test-ob-python.el
>> +++ b/testing/lisp/test-ob-python.el
>> @@ -207,6 +207,67 @@ (ert-deftest test-ob-python/session-value-sleep ()
>>  #+end_src"
>>  (org-babel-execute-src-block)
>>
>> +(ert-deftest test-ob-python/async-simple-session-output ()
>> +  (let ((org-babel-temporary-directory "/tmp")
>
> Prefer `temporary-file-directory' to hard coding "/tmp".
>
> Thanks.

Re: [PATCH] Add org-meta*-final-hook

[Timothy]

Hi Jay,

Apologies for how incredibly long it's taken for someone to reply to
your email. It looks like this is your first contribution, so please
don't think this is the norm 😅, you just seemed to slip through the
cracks.

Jay Bosamiya  writes:

> Similar to org-shiftup-final-hook, org-shiftdown-final-hook, etc, I have
> added org-metaup-final-hook, org-metadown-final-hook, etc. Please see
> attached patch.

This seems consistent with what we already have, and so a good addition 👍.

> Please do let me know if any changes are required.

It looks like you have >15 lines changed here, so this is not eligible
to be a TINYCHANGE, i.e. we require FSF assignment
(see: https://orgmode.org/contribute.html#copyright) if you haven't got
this already.

--
Timothy

Re: Concerns about community contributor support

[Tim Cross]

Bastien  writes:

> Dear Timothy,
>
> thanks for raising this points so carefully, they are important.
>
> I see three distinct problems:
>
> 1. The lack of response and/or follow-up when people contribute by
>sending bug reports or patches on the list.
>
> 2. The lack of maintainance on documenting the contribution process
>and the correct expectations for future contributors.
>
> 3. The inherent difficulty to move the Org codebase forward.
>
> I won't comment on (3).  For (1) and (2), I suggest appointing a
> "contributor steward" with these responsibilities:
>
> 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.)
> 2. Maintain the documentation for contributors.
> 3. Help contributors enhancing their patches.
> 4. Try to reproduce bugs (and confirm them for updates.orgmode.org)
> 5. Make sure patch contributors are not left with no answer.
>
> You started (1), which is really appreciated.
>
> Tim and others mentioned (2), and that's certainly needed too.
>
> (3) has historically been the role of the maintainer and of the core
> contributors, but helping with this is very welcome: knowing the doc
> at https://orgmode.org/worg/org-contribute.html by heart, educating
> contributors on the commit messages, etc.  This all helps.
>
> (4) is perhaps the most daunting task: I even think we could have
> someone only dedicated to this very important task.  Just count the
> number of times Nicolas says "I cannot reproduce this."  Each time,
> there is a real bug that is *not* fixed...
>
> (5) is not about systematically welcome patch submitters with a
> message (that would be annoying) but to monitor updates.orgmode.org
> and decide what to do with a patch that didn't receive feedback:
> either say thanks and ping the list for why you think the patch
> deserves more attention, or thanks and dismiss the patch, or another
> answer.
>
> What do you think?  Would you be willing to take this role?
>
> If not, that's perfectly okay, I'll send a call for help.
>
Hi Bastien et. al.

I agree and am willing to help if I can.

One thing I do think would be helpful, particularly for documentation on
maintenance of org mode, would be a clear outline of project goals and
philosophy. Some of this would be 'concrete' statements, such as the
minimum supported Emacs version, size of contribution and requirements
to sign FSF copyright assignment paperwork, inclusion of acceptance
tests, documentation, maintenance of backwards compatibility, API
stability etc. Other parts would be more 'fuzzy' guidelines, such as
avoiding complexity and 'blow out' in options/arguments, balancing
features and maintainability, what should become part of org core and
what should be in contributions or a completely separate add on package
and what guidelines are used in assessing extensions/enhancements for
inclusion etc.

It will be challenging to define this as there are a wide diversity of
views and priorities amongst the community. However, I think it would be
an overall benefit for both the community and on-going development of
org mode. 

While I would be happy to help with this, I think the initial content at
least needs to come from current key maintainers and if possible, some
input from Carsten would be good. 

-- 
Tim Cross